51–60 of 104 posts
Earlier quoted context omitted.
Good to hear. I sure hope they came up with a good, clear system to distinguish them.
As in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
Earlier quoted context omitted.
I don't think so: JPEG 2000, as far as I know, isn't generally supported for web use in web browsers, but it is supported in PDF.
JPEG-XL is recommended as the preferred format for HDR content for PDFs, so it’s more likely to be encountered: https://www.theregister.com/2025/11/10/another_chance_for_jp...
While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…
>medical images Isn't JPEG-XL a lossy codec?
Earlier quoted context omitted.
What are you talking about? You extract 3 exposure values from the raw camera buffer and merge and tone map them manually into a single HDR image. The final exported image format may not have the full supported color space, but that’s on you. Apple uses the P3 space by default. This has been supported by both Apple and third party apps for over a decade. I’ve implemented it myself.
That's not HDR. That's pretend HDR in an SDR file, an artistic effect, nothing more. Actual HDR needs at least 10 bits per channel and a modern display with peak brightness far in excess of traditional monitors. Ideally over 1,000 nits compared to typical LCD brightness of about 200. You also don't need "three pictures". That was a hack used for the oldest digital cameras that had about 8 bits of precision in their a…
I wrote camera firmware. I’ve implemented HDR on the both the firmware level, and later at the higher client level when devices became faster. You’re either overloading terminology to the point where we are just talking past each other, or you’re very confused.
Here are the direct links: blink-dev mailing list https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc... Tracking Bug (reopened) https://issues.chromium.org/issues/40168998
Yeah note that Google only said they're now open to the possibility, as long as it is written in Rust (rightly so). The patch at the end of that thread uses a C++ implementation so it is a dead end.
Earlier quoted context omitted.
As in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
I meant like a filename convention, and tags in the file itself.
While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…
But at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable?
Also, can we expect "near max potential" with AV2/near future or is it an ever-unachievable goal that shouldn't stop adding "non-max" codecs?
https://res.cloudinary.com/cloudinary-marketing/image/upload...
https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
Earlier quoted context omitted.
As in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
I meant like a filename convention, and tags in the file itself.
Earlier quoted context omitted.
>medical images Isn't JPEG-XL a lossy codec?
JPEG-XL is both a lossy and lossless codec. It is already being used in Camera DNG format, making the RAW image smaller. While lossy codec is hard to compare and up for debate. JPEG-XL is actually better as a lossless codec in terms of compression ratio and compression complexity. There is only one other codec that beats it but it is not open source.
