Live data from Hacker News

Google Revisits JPEG XL in Chromium After Earlier Removal

windowsreport.com

61–70 of 104 posts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#61
post #59
post #51

Earlier quoted context omitted.

I meant like a filename convention, and tags in the file itself.

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 important than between TIFF and PNG, or between JPG and HEIC. Knowing whether an image is degraded or not is the #1 important fact about an image for me, before anything else. It says so much about what the file is for and not for -- how I should or shouldn't edit it, what kind of format and compression level is suitable for saving after editing, etc.

After that comes whether it's animated or not, which is why .apng is so helpful to distinguish it from .png.

There's a good reason Microsoft Office documents aren't all just something like .msox, with an internal tag indicating whether they're a text document or a spreadsheet or a presentation. File extensions carry semantic meaning around the type of data they contain, and it's good practice to choose extensions that communicate the most important conceptual distinctions.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#62
post #60
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 (High Availability Lossless Image Compression)

https://news.ycombinator.com/item?id=38990568

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#63
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…

But JPEG has a lossless mode as well. How do you distinguish between the two now?

This is an arbitrary distinction, for example then why do mp3 and ogg (vorbis) have different extensions? They're both lossy audio formats, so by that requirement, the extension should be the same.

Otherwise, we should distinguish between bitrates with different extensions, eg mp3128, mp3192, etc.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#64
post #63

Earlier quoted context omitted.

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…

But JPEG has a lossless mode as well. How do you distinguish between the two now? This is an arbitrary distinction, for example then why do mp3 and ogg (vorbis) have different extensions? They're both lossy audio formats, so by that requirement, the extension should be the same. Otherwise, we should distinguish between bitrates with different extensions, eg mp3128, mp3192, etc.

In theory JPEG has a lossless mode (in the standard), but it's not supported by most applications (not even libjpeg) so it might as well not exist. I've certainly never come across a lossless JPEG file in the wild.

Filenames also of course try to indicate technical compatibility as to what applications can open them, which is why .mp3 and .ogg are different -- although these days, extensions like .mkv and .mp4 tell you nothing about what's in them, or whether your video player can play a specific file.

At the end of the day it's just trying to achieve a good balance. Obviously including the specific bitrate in a file extension goes too far.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#65
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…

>I find it incredibly helpful to know that .jpg is lossy and .png is lossless.

Unfortunately we have been through this discussion and author of JPEG-XL strongly disagree with this. I understand where they are coming from, but for me I agree with you it would have been easier to have the two separated in naming and extensions.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#66
post #54
post #36

Earlier quoted context omitted.

>medical images Isn't JPEG-XL a lossy codec?

Surely something close to perceptually lossless is sufficient for most use cases?

Think of all the use cases where the output is going to be ingested by another machine. You don't know that "perceptually lossless" as designed for normal human eyeballs on normal screens in normal lighting environments is going to contain all the information an ML system will use. You want to preserve data as long as possible, until you make an active choice to throw it away. Even the system designer may not know whether it's appropriate to throw that information away, for example if they're designing digital archival systems and having to consider future users who aren't available to provide requirements.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#68

Earlier quoted context omitted.

Yeah note that Google only said they're now open to the possibility, as long as it is written in Rust (rightly so). The patch at the end of that thread uses a C++ implementation so it is a dead end.

Rick specifically said commitment for long term maintenance and meeting usual standards for shipping. The implementation was abandoned in favor of a new one using rust, so not necessarily a dead end.

I meant the C++ patch is a dead end; not JPEG XL support in general. Seems like there's a Rust library that will have to be used instead.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#69
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…

> Knowing whether an image is degraded or not is the #1 important fact about an image for me

But how can you know that from the fact that it's currently losslessly encoded? People take screenshots of JPEGs all the time.

> After that comes whether it's animated or not, which is why .apng is so helpful to distinguish it from .png.

That is a useful distinction in my view, and there's some precedent for solutions, such as how Office files containing macros having an "m" added to their file extension.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#70
post #69

Earlier quoted context omitted.

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…

> Knowing whether an image is degraded or not is the #1 important fact about an image for me But how can you know that from the fact that it's currently losslessly encoded? People take screenshots of JPEGs all the time. > After that comes whether it's animated or not, which is why .apng is so helpful to distinguish it from .png. That is a useful distinction in my view, and there's some precedent for solutions, such a…

Obviously nothing prevents people from taking PNG screenshots of JPEGs. You can make a PNG out of an out-of-focus camera image too. But at least I know the format itself isn't adding any additional degradation over whatever the source was.

And in my case I'm usually dealing with a known workflow. I know where the files originally come from, whether .raw or .ai or whatever. It's very useful to know that every .jpg file is meant for final distribution, whereas every .png file is part of an intermediate workflow where I know quality won't be lost. When they all have the same extension, it's easy to get confused about which stage a certain file belongs to, and accidentally mix up assets.

Post reply on HN