Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Request: Re-open JPEG XL issue

bugs.chromium.org

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Request: Re-open JPEG XL issue

#91

Post by elishah »

PaulHoule wrote: post #9

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…

Yes, the unfortunate thing is that Google is not interested in a higher quality Web so much as they are in a Web that is cheaper to index and serve.

So it's unsurprising that they have pushed the format optimized for "as few bits as we can get away with before things like too terrible" rather than actually improving quality and extending capabilities.

Re: Request: Re-open JPEG XL issue

#92

Post by chungy »

danShumway wrote: post #53

I still need to sit down and convert my personal Linux computer over to using JPEG XL for picture archival and figure out what tools need to change or be updated. Using it on the web is one thing, but getting better compression for my family photos would also probably be a win, and I suspect it would be possible to build a pipeline for viewing/editing that would be fairly transparent.

I've been pretty happy with it, myself. All the base OS libraries support JPEG XL so it's nearly pain-free, excepting lack of web browser support.

Combined with GNU parallel, I did this:

    find -type f -iname \*.jpg -print0 | parallel -0 cjxl --lossless_jpeg=1 {} {.}.jxl 
    find -type f -iname \*.png -print0 | parallel -0 cjxl -d 0 {} {.}.jxl
    find -type f -iname \*.webp -print0 | parallel -0 dwebp -o {.}.png {} \&\& cjxl -d 0 {.}.png {.}.jxl
JPEGs get losslessly recompressed with JPEG XL. PNGs and (lossless) WebPs get converted to lossless JPEG XL.

Re: Request: Re-open JPEG XL issue

#93

Post by asddubs »

izacus wrote: post #82
untitaker_ wrote: post #15

this is a rando spamming the chromium issue tracker. what is newsworthy about this?

The fact that JXL is a new convenient crusade for people that hate on Chrome. You'll notice that noone is screaming at Mozilla for the same choice.

mozilla didn't remove their jxl support? It's behind a feature flag, like it always has been, but that doesn't mean they will get rid of it or never unflag it.

Re: Request: Re-open JPEG XL issue

#94

Post by izacus »

asddubs wrote: post #93
izacus wrote: post #82

Earlier quoted context omitted.

The fact that JXL is a new convenient crusade for people that hate on Chrome. You'll notice that noone is screaming at Mozilla for the same choice.

mozilla didn't remove their jxl support? It's behind a feature flag, like it always has been, but that doesn't mean they will get rid of it or never unflag it.

Exactly, it's not enabled either and there's no plans to. Neither for Edge.

Re: Request: Re-open JPEG XL issue

#95

Post by pornel »

jokoon wrote: post #70
pornel wrote: post #13

Earlier quoted context omitted.

If anything, it'd be AVIF. WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.

avif still has patents I think?

AV1 is licensed royalty-free with an alliance of all big tech behind it. AVIF has been shipped by Apple and Google.

There's always going to be FUD around software patents, because the system is broken, but AVIF is as good as possible in the pathological system.

Re: Request: Re-open JPEG XL issue

#96

Post by asddubs »

izacus wrote: post #94
asddubs wrote: post #93

Earlier quoted context omitted.

mozilla didn't remove their jxl support? It's behind a feature flag, like it always has been, but that doesn't mean they will get rid of it or never unflag it.

Exactly, it's not enabled either and there's no plans to. Neither for Edge.

it is implemented, it's just not released. if there's no plans, why did they add the feature flag to begin with?

Re: Request: Re-open JPEG XL issue

#97

Post by innocenat »

throw0101a wrote: post #64
PaulHoule wrote: post #9

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…

> 4K TV’s use Rec 2020 Is defined by some standard to be able to be declared "4K", or is it just what seems to be happening because all/most of the panel makers just threw it in?

ITU-R UHDTV Standard, the mainstream 4K TV standard, use Rec 2020.

In theory you can use any color primaries with any video resolution in computer (NOT on TV as those normally only support mainstream standard) as long as the the color space metadata is properly set, but in practise, some softwares ignore the metadata or the metadata got lost in the video processing chain. So in general, 4K video use Rec 2020, HD/FHD use Rec 709, and SD use Rec 601, for maximum compatibility.

Re: Request: Re-open JPEG XL issue

#98

Post by izacus »

asddubs wrote: post #96
izacus wrote: post #94

Earlier quoted context omitted.

Exactly, it's not enabled either and there's no plans to. Neither for Edge.

it is implemented, it's just not released. if there's no plans, why did they add the feature flag to begin with?

Same reason Chrome did.

Chrome team themselves quoted no interest of those browsers as the reason for removal of the flagged code. Seems like an obvious way to pressure Google into supporing JXL would be to get Mozilla to launch their support, together with Edge and Safari?

Re: Request: Re-open JPEG XL issue

#99

Post by danShumway »

chungy wrote: post #92
danShumway wrote: post #53

I still need to sit down and convert my personal Linux computer over to using JPEG XL for picture archival and figure out what tools need to change or be updated. Using it on the web is one thing, but getting better compression for my family photos would also probably be a win, and I suspect it would be possible to build a pipeline for viewing/editing that would be fairly transparent.

I've been pretty happy with it, myself. All the base OS libraries support JPEG XL so it's nearly pain-free, excepting lack of web browser support. Combined with GNU parallel, I did this: find -type f -iname \*.jpg -print0 | parallel -0 cjxl --lossless_jpeg=1 {} {.}.jxl find -type f -iname \*.png -print0 | parallel -0 cjxl -d 0 {} {.}.jxl find -type f -iname \*.webp -print0 | parallel -0 dwebp -o {.}.png {} \&\& cjxl…

Nice, I should give this a try and see what it does to my photo library size.

There are a few holdout programs that I think are missing support (Blender3D springs to mind), but I also think in the rare instances where that's a problem I could probably set up a quick shortcut or some hooks to on-the-fly run cjxl and convert back to jpeg/png temporarily for whatever operation I need to do.

Re: Request: Re-open JPEG XL issue

#100

Post by FireInsight »

insanitybit wrote: post #35
andybak wrote: post #25

Earlier quoted context omitted.

Because lots of people are hoping Google will change is mind and this is a small concrete step towards that.

Is there a good writeup about why people want this over other, existing formats?

I'm not aware, but the gist is that it's in some circumstances better than AVIF in size and/or quality. Both of the new formats are wayy better than good old JPEG and PNG, but AVIF is the one Google is pushing.
Post reply on HN