301–310 of 411 posts
I find it interesting how many comments here (presumably from "tech guys") confirm what the author wrote: > So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists, who anyway have largely decided that they were above science, maths and other menial materialistic concerns. I am a tech guy, and when a photographer…
Earlier quoted context omitted.
I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that…
Part of the reason is because it's a technically superior codec, check out John Snyer's series of blogs on comparisons, e.g., https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth... Video codecs as used for images also have big disadvantages since they weren't designed for many picture-focused workflows > only matters during the transitional period. which can be decades, so this matters a lot > it seems to ma…
As to hardware adding support for JXL, that seems extremely unlikely: image decoding is less impactful than video decoding, and the cost of adding custom decoding silicon to a chip is very high, as is adding support to software for that hardware. Being able to piggy-back on the work already done for video meaning you get that stuff for free makes it way more viable. AV1 decoding is already out there in virtually every new device, and rolling out hardware support is very slow, it's massively ahead in that respect.
This entire article reminds me of the ones a few decades about about the utter indignity of mp3's, and how us peasants that use it _AT ALL_ or at the very least with any bitrate under 320bps was just criminal. Then proceed to play the flac's in their car. Ok.
Earlier quoted context omitted.
The "t" or the "ct" ligature?
"st", also.
document.body.insertAdjacentHTML('beforeend','p { font-variant-ligatures: common-ligatures discretionary-ligatures contextual;}')
But besides this, I found typography of that article quite nice; interesting that there are thin spaces before "?" and "!" and wide spaces (not double spaces) after sentences - also "old school" (and often frowned upon). I guess some WP plugin does it, but I admit don't remember seeing seen this anywhere else recently. (And I like it.)
I've noticed the same issue with WebP and have gone back to JPG/PNG for most things (jpg for photos, png for UI-type images) I think the real problem is, like many of the commenters here, most people can't tell the difference because desktop monitors have been stuck in a deadzone of zero innovation for the last 10 years. I'm sure half the folks here are viewing his example images on a 2012-era HD 1920x1080 LCD, which…
I have an extremely hard time perceiving any difference on a 27" 4K monitor. I am not even sure I really see them. The examples are just bad. If you want to show something, screenshot and enlarge it to show the artifacts.
If I cared about archive image quality (and I do) , I wouldn't re-compress older images in a new format unless I could do so from uncompressed originals. Re-encoding from a lossy compressed source will make quality worse. Storage is cheap and getting cheaper. What would make sense is choosing safe settings for compressing new photos in the new format.
> Re-encoding from a lossy compressed source will make quality worse. JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.
> It is possible to losslessly transcode JPEG images into JPEG XL. Transcoding preserves the already-lossy compression data from the original JPEG image without any quality loss caused by re-encoding, while making the file size smaller than the original.
I wonder how it does that and why JPEG didn't notice it could. I would re-encode to JPEG-XL, when supported. So then the situation isn't that WebP is so great but rather Chrome's not so great.
Earlier quoted context omitted.
I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that…
Jpeg-XL is light enough to not require hardware support. Did you tried to transcode a PNG to avif? It's painful. Not the case with Jpeg XL. Meanwhile I urge you to read this article. Jpeg XL has way more features than avif. https://cloudinary.com/blog/the-case-for-jpeg-xl
I just don't think any of those features matter as much a battery life, most of them are about encoding speed which just seems wildly unimportant to me: encoding may be more work, but generally you view images far more than you make them, and admins and creators are in a better position to spend the time/effort to encode something, and hardware encoding may well end up making it a non-issue anyway.
People are out there running `zopflipng` and the like to try and get better sizes at the cost of more work at encode time, so it seems like that priority isn't just me.
>Look at the original JPEG at quality 85 : https://photo.aurelienpierre.com/wp-content/uploads/sites/3/... " alt="" /> Sorry, I can't. That doesn't actually display any image at all in my browser because you're relying on javascript execution to switch the img src to it's actual source. You don't need to do this for lazyload to work anymore. There's browser native lazyload. Just put the actual image in the src.
It's bizarre how the author's attitude is that the webp authors should know better. Yet his blog cannot link to images properly without JavaScript. My browser supports lazy loading images and srcset; all the things he would want. It does that without JavaScript. Yet he tries to implement that in JavaScript and does not have a fallback to use the browser's native implementation. It's difficult to take him seriously in criticizing others' competencies when he, in a blog post about image quality, cannot include images with over-complicating things to the point of breakage.
His point on color banding is clear and others have pointed out that the luma in 4:2:0 subsampling is terrible. But Google is not in the photography business. (Overlooking his attempt to convert from lossy compression to another lossy compression.) It is in the content business but only in so far as it furthers its advertising business. It is not in content for the same reason as the author so they don't share the same interests.
Compare https://jpeg.org/jpegxl/ to https://developers.google.com/speed/webp/
> JPEG XL is designed to meet the needs of image delivery on the web and professional photography.
If you search google's documentation on webp they mention photography like four times and never as "professional photography".
It's honestly funny that he is surprised that Google is advocating for a file format that does not suit his needs as a professional photographer. Google is an advertising business; everybody knows this.
Finally, I never see critics of (or anyone commenting on) webp mention that it supports transparency. What other format is someone to use if they want lossy transparency? It's great for small low quality thumbnails of images (like jpg or png) or animation (like gif) or video. You can throw just any input at ffmpeg and ask for a webp and it will give you something useful that represents one frame of the input. It fills that niche very well.
Once JPEG XL because well supported, I'd like to use it; I hear good things. But it isn't well supported yet so webp is the only option for images with lossy transparency.
Earlier quoted context omitted.
For me it's the horrible layout. For God's sake, stop making narrow columns of text. Having the text take up most of my monitor is much more pleasant to read.
Long lines of text cause significantly more eye strain than reasonably short ones. Generally, one should try to have ~80 characters per line of text.
I find it interesting how many comments here (presumably from "tech guys") confirm what the author wrote: > So there is a real issue with the design priorities of image algos from tech guys who clearly lack historical and artistic background, and don’t talk to artists, who anyway have largely decided that they were above science, maths and other menial materialistic concerns. I am a tech guy, and when a photographer…
I think it's more "the target audience for webp is people closer to and arguably less trained than my eyes and I can't see a difference" which is a pretty reasonable take. But tech people aren't typically the best communicators and so I'm not at all surprised it comes off crass. mp3 is "worse" than flac but if you say it sounds bad I'll absolutely tell you you're wrong and to get off Hi-Fi forums.
That appears to be the author's specific complaint against WEBP, and seems fair.