Live data from Hacker News

Request: Re-open JPEG XL issue

bugs.chromium.org

161–164 of 164 posts

Re: Request: Re-open JPEG XL issue

#161

Earlier quoted context omitted.

Wait, what? Even with gamma encoding?

yeah (especially in dark areas). On http://www.lagom.nl/lcd-test/gradient.php I can definitely see some in the lower quarter of brightness. It's not glaringly obvious, but it's definitely there.

8 bit is not quite enough, not even for the usual sRGB let alone HDR or wide gamut. This is why jpegli is such a promising new option.

Re: Request: Re-open JPEG XL issue

#162
post #55

Earlier quoted context omitted.

I switched to WebP about a year and a half ago. I’d been watching for a long time and it had finally reached the point where support was universal enough that I could not publish a JPEG. WebP has the big advantage that the quality setting is meaningful, you can set it at a certain level and then encode thousands of images and know the quality is about the same. This is by no means true about JPEG, if you are trying t…

> Years back I was concerned about the size of a large JPEG collection and recompressed them which was a big mistake because many of the images were compressed too hard. Distortion metrics[0] such as MS-SSIM, MS-SSIM*, SIMM, MSE, and PSNR can be used to define a cut-off or threshold for deciding the point at which the image is "compressed enough" by using one or more of those algorithms and predefining the amount of…

You can use jpegli for better jpeg compression heuristics. It uses custom heuristics that were originally used in JPEG XL, then copied over and further optimized using nelder-mead to minimize distortion metrics (butteraugli and simulacra 2)

Re: Request: Re-open JPEG XL issue

#163
post #45

Earlier quoted context omitted.

Although I can sympathize, I don't really understand the point of opening a new issue when all the same information has already been left in comments on the old closed issue. If the new issue gets closed, then it just reaffirms that the Chromium team doesn't care about this feature request. If the new issue somehow convinces the team to do something about it, then it shows that the team is utterly dysfunctional becau…

Further discussion on that closed issue is no longer possible right? So any new information that might cause a re-evaluation needs to be presented in a new issue. The new information here seems to be 'most people thought the previous decision was bad', rather than 'please I really want this'. Changing an old decision because most people think it was bad is not a sign of utter dysfunction.

Further discussion is possible there. It just does not get triaged like a new bug.

Re: Request: Re-open JPEG XL issue

#164
post #80
post #71

How much work is actually involved in adding support for this format? Like is it just plugging an existing implementation into the abstractions they already have for other image formats? or is there more to it?

For a browser, it means permanent, forever, support for the format and continued maintenance and security patching for the library. Any CVE, any issue that might cause the browser to be insecure will be blamed on the browser and the developers will have to make sure any codec they use is safe forever. That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (…

These sound like good reasons to quickly disable AVIF and move fully to JPEG XL. AVIF is about 3-5x more code than JPEG XL.
Post reply on HN