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

Samsung Joins Apple and Adobe in Supporting JPEG XL

r2.community.samsung.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#41

Post by lonjil »

izacus wrote: post #38
sugarpile wrote: post #3

I don't understand how google can just be consistently on the back foot of the "tech world hivemind" for going on 7 (?) years now and have zero shakeup of not just culture but at least PR.

Noone gave a crap about this format on this site until Google decided to not add it to Chrome. Noone used it, no posts were upvoted. It just became a thing when it was yet another reason to rant at Google. Note how noone is asking Mozilla why Firefox won't support it or actually building websites using it.

Actually, lots of people were talking about it, and lots of people at big companies like Facebook were excited when Google added it behind a flag. Shopify even rolled out JXL to their storefronts not long after JXL was added to Chrome.

> Note how noone is asking Mozilla why Firefox won't support it or actually building websites using it.

People do ask why Firefox isn't supporting it, but the answer is obvious: because Chrome dropped it, and Firefox has what, 5% market share?

And people do use it on websites, you just didn't notice because companies like Nike don't tend to write up blog articles about how they're using a cool new image format.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#42

Post by lonjil »

112233 wrote: post #40
lifthrasiir wrote: post #35

Earlier quoted context omitted.

That is done by a custom ICC profile. JPEG XL's own colorspace support is more like a shorthand for frequent presets.

how can custom ICC profile encode information about bayer filter layout, dark frame or dead/phase photosites?

The parent commenter is incorrect. Yes, the JXL authors do want to try to use JXL as a raw format, but they are focusing on other priorities right now, so the specification for how JXL could be used as a raw format doesn't exist yet. But the format is flexible enough to allow for it, without backwards-incompatible changes.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#43

Post by izacus »

lonjil wrote: post #41
izacus wrote: post #38

Earlier quoted context omitted.

Noone gave a crap about this format on this site until Google decided to not add it to Chrome. Noone used it, no posts were upvoted. It just became a thing when it was yet another reason to rant at Google. Note how noone is asking Mozilla why Firefox won't support it or actually building websites using it.

Actually, lots of people were talking about it, and lots of people at big companies like Facebook were excited when Google added it behind a flag. Shopify even rolled out JXL to their storefronts not long after JXL was added to Chrome. > Note how noone is asking Mozilla why Firefox won't support it or actually building websites using it. People do ask why Firefox isn't supporting it, but the answer is obvious: becaus…

> People do ask why Firefox isn't supporting it, but the answer is obvious: because Chrome dropped it, and Firefox has what, 5% market share?

How is that an excuse not to lead and show its usefulness via an example?

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#44

Post by jiggawatts »

navjack27 wrote: post #39
jiggawatts wrote: post #25

Just reminding everyone that it is now 2024, and it is still impossible to send a HDR still image to a group of people not all in the same ecosystem. Apple for example “supports” the JPEG XL format, but decodes it to sRGB SDR irrespective of the source image gamut. As of today, Adobe Lightroom running on an Apple iDevice can edit a RAW camera image in HDR, can export the result in three formats… none of which can be…

I've edited photos using Photoshop and Lightroom with HDR support and was able to immediately view them in preview on my m1 Mac mini. Of course it looked different than if I viewed it in multiple different browsers or even the Canary, Dev, beta, release branches of all of those browsers if they had support for the image format at all. But they definitely did view correctly because I made sure that the images weren't…

> view them in preview on my m1 Mac mini

Now send it to anyone, in any way. iMessage? Doesn’t work. Received on an iPhone? Won’t work. Android? Definitely not. Etc…

There is no one file format that works across ecosystems. Apple is even internally fragmented, with some formats working on MacOS that don’t on IOS.

> Of course it looked different

That is broken!!

This is precisely what I mean: HDR is often incorrectly decoded as SDR in Apple operating systems. This is worse than just sending an SDR JPG because the HDR-to-SDR conversion is unpredictable, and making the HDR image was a waste of time and bits.

Note that I didn’t say HDR video! I meant specifically HDR still images, the type that JPEG XL can encode.

Right now, in 2024, if I want to send someone HDR anything, the only robust method is to make it into a video and send them a YouTube link to it.

That’s a sad state of affairs.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#45

Post by lifthrasiir »

lonjil wrote: post #42
112233 wrote: post #40

Earlier quoted context omitted.

how can custom ICC profile encode information about bayer filter layout, dark frame or dead/phase photosites?

The parent commenter is incorrect. Yes, the JXL authors do want to try to use JXL as a raw format, but they are focusing on other priorities right now, so the specification for how JXL could be used as a raw format doesn't exist yet. But the format is flexible enough to allow for it, without backwards-incompatible changes.

Ah, yeah, the current JPEG XL is not enough for the full RAW coverage. (I was talking more about per-channel color spaces.) There is indeed a reserved extra channel type for specific filter layouts among others, but its specification doesn't exist yet.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#46

Post by JyrkiAlakuijala »

lifthrasiir wrote: post #15
Reason077 wrote: post #12

Earlier quoted context omitted.

Considering JPEG XL and Ultra HDR are both based on JPEG, couldn't they be combined into one standard? Wouldn't it be better for everyone if the whole industry could eventually agree on a single standard? Apple's HEIC is very annoying since it's not really supported by anything non-Apple. Would certainly be nice to see that go away.

It's crucial to distinguish JPEG the file format (now retronymed as JPEG 1) and JPEG the standardization group. JPEG XL is officially blessed by JPEG but otherwise irrelvant here, even though non-progressive JPEG 1 files can be losslessly recompssed into JPEG XL by its design. The main role of JPEG here was to specify explicit goals for JPEG XL proposals [1]. Interestingly enough, the JPEG 1 recompression was not a p…

I proposed lossless JPEG1 recompression as a functionality of JPEG XL after PIK/FUIF were chosen as a platform. The committee saw this of great value and we decided together this as an additional requirement after the competition was completed. We had a lot of experience of this in brunsli and were sure that we can deliver a good solution for it.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#47

Post by spider-mario »

ksec wrote: post #36
handsclean wrote: post #18

Earlier quoted context omitted.

Honest question: what’s so awful about WEBP? Though it’s worse than the gen arriving now, it’s better than or the same as the one before it for the use cases it supports, and free and open. I get the impression people associate it with brokenness and low quality, but the brokenness is just a lack of support, and the quality a creator choice. Maybe its original sin was not trying to be suitable for original data, lead…

It is not really awful . It is just way over hyped, over promised and under delivered. WebP was better than standard JPEG. But JPEG also improved via many other encoders such as MozJPEG. And it wasn't obvious what the advantage were, or it was so little it really shouldn't be included as a standard feature. Mozilla made their case back then with many testing and data point.

> WebP was better than standard JPEG.

Feature-wise, maybe (transparency, animation). Compression-wise, not really (better at low qualities because the artifacts are somewhat less objectionable than JPEG’s, but worse at high qualities).

Lossless WebP (practically a separate codec) is nice though, albeit 8-bit only.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#48

Post by JyrkiAlakuijala »

Reason077 wrote: post #12
ipsum2 wrote: post #10

Google, not content with existing image formats that support 10-bit like HEIC (used by Apple) and AVIF (based off of AV1, a codec that Google helped design and is better than JPEG), they decided in all their wisdom to make Ultra HDR for Android phones, which is an incompatible standard built on top of JPEG, which is separate from JPEG-XL. Now Samsung has released Super HDR, without any information about that standard…

Considering JPEG XL and Ultra HDR are both based on JPEG, couldn't they be combined into one standard? Wouldn't it be better for everyone if the whole industry could eventually agree on a single standard? Apple's HEIC is very annoying since it's not really supported by anything non-Apple. Would certainly be nice to see that go away.

I consider this would work best with a great local tone mapping algorithm and only sharing the HDR image (JPEG XL), then viewing it on SDR with a great local tone mapping algorithm. That would reduce the data size to transmit and give more guarantees that two people downloading the same file will see the same content.

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#49

Post by JyrkiAlakuijala »

archerx wrote: post #24
handsclean wrote: post #18

Earlier quoted context omitted.

Honest question: what’s so awful about WEBP? Though it’s worse than the gen arriving now, it’s better than or the same as the one before it for the use cases it supports, and free and open. I get the impression people associate it with brokenness and low quality, but the brokenness is just a lack of support, and the quality a creator choice. Maybe its original sin was not trying to be suitable for original data, lead…

I associate it with google, and I have associated google with bad and untrustworthy. Also google's hostility towards jpeg xl makes me even more apprehensive of their format and the way they tried to push it so hard. Also jpeg XL is just much better than webp. https://www.youtube.com/watch?v=qc2DvJpXh-A

Google is not hostile to JPEG XL.

Google Research develops and maintains JPEG XL, currently main focus on improving streaming encoding -- to use much less memory during the encoding process.

Google Chrome added and then removed experimental support of JPEG XL from Chrome. This has caused discussion in the related bugs.

https://bugs.chromium.org/p/chromium/issues/detail?id=145180... https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Re: Samsung Joins Apple and Adobe in Supporting JPEG XL

#50

Post by JyrkiAlakuijala »

lifthrasiir wrote: post #45
lonjil wrote: post #42

Earlier quoted context omitted.

The parent commenter is incorrect. Yes, the JXL authors do want to try to use JXL as a raw format, but they are focusing on other priorities right now, so the specification for how JXL could be used as a raw format doesn't exist yet. But the format is flexible enough to allow for it, without backwards-incompatible changes.

Ah, yeah, the current JPEG XL is not enough for the full RAW coverage. (I was talking more about per-channel color spaces.) There is indeed a reserved extra channel type for specific filter layouts among others, but its specification doesn't exist yet.

For some, possibly most, needs of using raw having yuv444, 14+ (or 16+) bits of precision and lossless or near-lossless (with strong guarantees of maximum error on individual pixels) compression is supposedly acceptable. I base this interpretation mostly on digital photography discussions I have seen on the internet. I am not a photographer myself.

(12 bits of component already requires adapting to the current lighting and can supposedly slow down professional photography.)

Post reply on HN