![]() ![]() If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case. The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. ![]() Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl. "and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp." You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere. It may also be worth noting that the author of commit to remove support from Chromium appears to be a WebP co-author, having given talks about WebP and being the primary contributor to libwebp. The issue on the Chromium tracker is now one of the most-starred and most-commented-on of all time because people from all over came to tell Google that they're insane, from Intel to Adobe to Facebook to Krita to Cloudinary to Shopify to Serif/Affinity to the VESA DisplayHDR Chairman. By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome" The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL Experimental flags and code should not remain indefinitely We will be removing the JPEG XL code and flag from Chromium for the following reasons: "Thank you everyone for your comments and feedback regarding JPEG XL. This is the terrible explanation they gave for dropping support: And this is especially true when you consider that you can reversibly reencode the billions of existing JPEGs on people's drives and on the web as JPEG-XLs losslessly for 20+% space savings. JPEG XL is a massive step forward for images on the web for a number of reasons, but it has especially massive benefits when it comes to preserving image quality across the web. With JPEG XL, many of those compressed messes would be much closer to the original image due to its extremely strong generational loss resilience (see the webm attachment to ). The original is probably still on someone's hard drive, but it's unlikely to be remembered, much less surface again, so compressed messes are all that's left. In many cases, the original high quality source has been lost to 404s and unpaid webhosting bills. Besides, it's not like they can just ask the platform to magically fix the image, so they just don't think about it. They don't know why an image that's been reposted from Facebook to Twitter to Instagram to Reddit to Imgur and back a dozen times has artifacting and color banding, and as long as they can still get the gist of the image, it doesn't matter to them. Or they do but they just assume that's the way things are. > Many images for the web are highly compressed but nobody really notices. Turning off color management works but really I should be blending in some red into green areas of the left image because that will make the colors closer to the original and also help with stereo imaging by reducing the difference in brightness between the left and right channels. I will get around to it one day but it's been a higher priority for me to deal with the same problem in print, where the green on my printer is very saturated but also very dark and the color management system blends in some red to make it brighter. The answer to this is to master a high color gamut image just for those devices and serve everyone else an sRGB. The green in a high color gamut display is more saturated than the sRGB primary so when you ask for sRGB green you get some red and blue mixed in which is an absolute disaster for a stereogram. ![]() I am into red-cyan anaglyph images where the most important thing is getting separation between the left and right channels. My current boggle w/ screens is actually what to do with "high color gamut" screens like the one on my iPad. Many images for the web are highly compressed but nobody really notices. That is, even my Android Go device is "good enough" in that if you really need to see more detail you can zoom in.Ī better comparison with audio would be the terrible quality of a 64 kbps Mp3 file which is going to sound awful on the cheapest bluetooth speakers or a $5000 set of speakers compared to 128 kbps Mp3 which sounds OK superficially but falls apart when compared to the source CD, or higher bit rates which are close to transparent. I'll go on the record and say that, unlike audio, where I'd be very concerned about the quality of speakers, I am not so concerned about the screen quality where my photographs are displayed. ![]()
0 Comments
Leave a Reply. |