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

Google Revisits JPEG XL in Chromium After Earlier Removal

windowsreport.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#71

Post by nothrabannosir »

crazygringo wrote: post #61
stavros wrote: post #59

Earlier quoted context omitted.

Presumably you can look at the file and tell which mode is used, though why would you care to know from the filename?

I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more impor…

Legacy. It’s how things used to be done. Just like Unix permissions, shared filesystem, drive letters in the file system root, prefixing urls with the protocol, including security designators in the protocol name…

Be careful to ascribe reason to established common practices; it can lead to tunnel vision. Computing is filled with standards which are nothing more than “whatever the first guy came up with”.

https://en.wikipedia.org/wiki/Appeal_to_tradition

Just because metadata is useful doesn’t mean it needs to live in the filename.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#72

Post by particlo »

if you wanna compare jxl vs avif by taking photos yourself and have an android phone then try this APK https://github.com/particlo/camataca i thought jxl was better by looking at its website benchmarks but then after trying it myself i find jxl generates ugly blocky artifacts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#73

Post by oktoberpaard »

fingerlocks wrote: post #55
jiggawatts wrote: post #26

Earlier quoted context omitted.

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 never mentioned a file format. These operations are performed on the raw buffer, there is no hack. There is no minimum bit depth for HDR (except for maybe 2) that’s just silly. High dynamic range images just remap the physical light waves to match human perception, but collecting those waves can be done at any resolution or bit depth. I wrote camera firmware. I’ve implemented HDR on the both the firmware level, and…

What you are taking about is also called HDR, but has nothing to do with what the other person is talking about. The other person is talking about the still image equivalent of HDR video formats. When displayed on an HDR capable monitor, it will map the brightest parts of the image to the extended headroom of the monitor instead of tone mapping it to be displayed on a standard SDR monitor. So to be even more clear: it defines brightness levels beyond what is normally 100%.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#74

Post by jchw »

RobotToaster wrote: post #38
jchw wrote: post #7

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.

So Firefox (or others) can't open a pdf with a embedded jpeg-2000/XL? Or does pdf.js somehow support it?

Apparently I really flubbed my wording for this comment. I'm saying they do support it inside of PDF, just not elsewhere in the web platform.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#75

Post by alwillis »

jiggawatts wrote: post #26
fingerlocks wrote: post #23

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…

> 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.

In the Apple Silicon era, the MacBook Pro has a 1,000 nit display, with peak brightness at 1,600 nits when displaying HDR content.

Affinity Studio [1] also supports editing and exporting "true" HDR images.

[1]: https://www.affinity.studio

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#76

Post by Nanopolygon »

ksec wrote: post #30

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…

AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#77

Post by Nanopolygon »

cipehr wrote: post #60
ksec wrote: post #40

Earlier quoted context omitted.

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.

What is the non-open source codec?

HALIC is by far the best lossless codec in terms of speed/compression ratio. If lossy mode were similarly available, we might not be discussing all these issues. I think he stopped developing HALIC for a long time due to lack of interest.

Its developer is also developing HALAC (High Availability Lossless Audio Compression). He recently released the source code for the first version of HALAC. And I don't think anyone cared.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#78

Post by jiggawatts »

alwillis wrote: post #75
jiggawatts wrote: post #26

Earlier quoted context omitted.

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…

> 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. In the Apple Silicon era, the MacBook Pro has a 1,000 nit display, with peak brightness at 1,600 nits when displaying HDR content. Affinity Studio [1] also supports editing and exporting "true" HDR images. [1]: https:/…

I have a 4K HDR OLED plugged into my Windows PC that works just fine for editing and viewing my photos.

I have no way, in general, to share those photos with you, not without knowing ahead of time what software you’re using. I’ll also have to whip up a web server with custom HTML and a bunch of hacks to encode my images that will work for you but not my friends with Android phones or Linux PCs.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#79

Post by charcircuit »

jiggawatts wrote: post #11

2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images. Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube. It's absolutely bonkers to me that we've all collectiv…

The web has supported 16 bit pngs for decades. This is enough bits for more dynamic range than a human eye with a fixed pupil size.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#80

Post by jiggawatts »

lxgr wrote: post #44
jiggawatts wrote: post #11

2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images. Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube. It's absolutely bonkers to me that we've all collectiv…

> 2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images. Huh? Safari seems to render HDR JPEG XLs without any issues these days (e.g. [1]), and supports wide gamut in even more formats as far a I remember. [1] https://jpegxl.info/resources/hdr-test-page.html

"Share" is the key word in my rant. I know spotty support exists here and there for one format or another.

The problem is that I can't, in general widely share a HDR image and have it be correctly displayed via ordinary chat applications, social media, email, or what have you. If it works at all, it only works with that One Particular Format in One Specific Scenario.

If you disagree, find me something "trivial", such as a photo sharing site that supports HDR image uploads and those images are viewable as wide-gamut HDR on mobile devices, desktops, etc... without any endpoint ever displaying the image incorrectly such a very dark, very bright, or shifted colors.

Post reply on HN