I think decompression times would be a relevant criteria, but they're surprisingly not there...
... something that might tell us, given a 3s encode with available technology, at what number of over-the-wire loads / decodes does it become more efficient to use a cheaper codec? Slightly less relevant with lossless, but still.
Did you know that, with the correct SIMD code, you can encode a 1080p bitmap into a 4:4:4 JPEG within 10 milliseconds on a typical consumer PC? Encoding times like this open up an entire dimension of new possibilities.
I do have a side project where I use libjpegturbo to synchronize a frame buffer between server & web client (i.e. 60 FPS real-time). HN may frown on using [m]jpeg for real-time applications today, but in my experience it has proven to be a very robust path. Bandwidth is really the only tradeoff (and it is a big one). This is the very last thing Netflix would want to do (short of sending RAW files to your TV), but it does provide some very compelling attributes in other areas such as streaming gaming.
Our networks are only getting faster over time. Intraframe video compression techniques are really elegant in their simplicity and resilience to motion-induced artifacts (as seen with x264, et. al.). They also can provide lower latency and easier recovery for clients (since every frame is a keyframe).
For real-time applications, I'd happily trade some extra bits per second to have a final result sooner. Especially if it looked better.
If you would transfer raw image data (rgba) you get what for full hd images? Around 7 fps? I don't even want to see the bus for modern smartphone cameras that now seem to casually have around 100 megapixels...
So very fast "on-site" encoding is pretty much mandatory today...
What I really want is to be able to send an initial jpeg keyframe to the client, and then use some application-level heuristic to determine if I should then send a delta-encoded frame (what to change based upon the prior) or another keyframe. For 90%+ of my frames, using a prior frame and indicating deltas would be far more efficient than sending a keyframe each time. Maintaining the previous frames on the server per-client is not a huge deal and would not impact latency if done properly.
I wonder if there is some way I can use jpeg itself to half-ass this sort of approach in the browser. Maybe... encode keyframes at ~80% quality and delta frames at 100% (still not guaranteed, I know). Maybe canvas compositing or simple buffer tricks with bitmaps could get ~95% of the way there. For my application, the pixels don't have to be perfect or accurate to any particular standards.
I'm currently in the process of scanning and archiving lots of photographs as high-resolution 16-bit PNG's and encoding speed is definitely a significant influence on how long this process takes.
The vast majority of use-cases and users barely care about encoding performance. Your use is in the tiny minority. That isn't to say that you don't have a use-case, just that because of how rarely encoding speed matters, it truly is "almost irrelevant" for 99.99% of users 99.99% of the time.
--------------
It definitely would be nice if JPEG-XL also had good encoding performance, though. There's an experimental fast encoder in development currently[1], although before that lands, it would be nice if your scanning tool supported a workflow somewhat like "scan in parallel with image encoding, present encoded images to user, and allow them to asynchronously go back and re-scan/encode/review pages that came out badly".
[1] https://github.com/libjxl/libjxl/tree/main/experimental/fast...
If you're doing this at such a scale that encoding speed matters (like if you're Instagram) the major concern would likely be cost, which you're going to save in bandwidth every time an image is viewed.
How am I going to "throw more CPU power at the problem" when I'm using a scanner hooked up to my laptop? Should I buy myself a new, more powerful laptop? That doesn't sound cheap.
As for "just" waiting... my time is valuable, and I have better things to do with it than wait... and, unfortunately, the process of scanning and encoding needs a lot of babysitting from me, so I can't just dump a bunch of photos in my scanner and come back when it's all over if I want even half-decent results, not to mention archival quality images.
In this real-world scenario, a quicker encoding speed would save me a lot of valuable time, and there's no getting around it short of hiring a skilled and trusted person to do it for me.
The use of intermediate formats is a well proven technique in video editing where encoding real time to AVC/HEVC at high quality is not possible. Codecs like ProRes are used that are much easier to encode to at the expense of storage space.
For context I started a neg scanning project a few years ago, ~150 rolls on an epson v850 (flatbed), and stuck with the default compressed tif after some surface research. There is little chance I would consider another processing step .. unless it was batched on a server somewhere! Very painstaking process, which has been on indefinite hold for a small while now (waiting for the AI to catch up).