Hacker News Reader

Hacker News

Comment by ChrisMarshallNY | Hacker News Reader

Full thread

ChrisMarshallNY

I really want this to work.

As has been pointed out in the comments, it needs to be adopted beyond the browser. And easily.

Anyone hear of FlashPix[0]?

Anyone?

Bueller?

It was a staged-resolution format that was introduced by a consortium in the 1990s.

The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).

The format was basically strangled in the crib. It was actually a fairly interesting idea, at the time, but files could be huge.

[0] https://en.wikipedia.org/wiki/FlashPix

[1] https://en.wikipedia.org/wiki/COM_Structured_Storage

View on HN

> The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).

HEIC and AVIF are based on the QuickTime file format, which doesn't seem very svelte either. I can't find any reference on the JPEG XL container format so it's probably it's own thing.

Good chance it’s TIFF, like JFIF.

No thanks, the only TIFF you'll find in a JXL is the (optional) Exif metadata.

HEIC and AVIF are both based on HEIF, which is based on ISOBMFF (just like for example MP4).

The JPEG XL container (which is optional and only needed if you want to attach metadata to an image) is also based (more directly and with less header overhead) on ISOBMFF.

The ISO media file format is, like GP said, basically QuickTime.

This can be a problem if you're the kind of completionist who needs to implement everything they see and make one C++ class per QuickTime atom - a problem I saw with a lot of mp4 codebases.

But there's no need to do this because almost all the things in the spec don't matter. Just don't read any of them and handle the rest procedurally and it'll be fine. It looks like JPEG XL also has too many features (like this animation and patching thing) so maybe just ignore that too.

Ignoring stuff is fine if you make an encoder. When you're making a decoder, it's a big no-go. If implementers of the original JPEG would have implemented the whole spec, we would have 12-bit and lossless JPEGs. Instead we're stuck with the de facto JPEG standard, the subset of the spec that everyone ended up implementing.

libjpeg supports that with a compile time option. Nobody used it because you can't abstract over bit-depth (and sometimes pixel format) without losing all performance, because it means a lot of if statements have to go inside every hot loop, so instead you have to duplicate all related code. Also, there wasn't a way to view them until HDR displays came around recently.

The main issue with implementing all of MPEG-4 is the spec is overdetermined (the same fields exist at different layers and can disagree), but also it's full of nonsense nobody cares about, like the alternate codec for animating faces only.

https://core.ac.uk/download/pdf/207365065.pdf

> When you're making a decoder, it's a big no-go.

I remember one of my first big OO projects was writing a TIFF reader.

What a nightmare.

I was really excited about JPEG 2000 when I first heard about it in the mid 2000s. As is tradition it was pretty much killed by the possibility of patents that weren't part of the industry agreement.

JPEG2000 just wasn't a great format either. Wavelets don't compress well because they get blurry, which isn't pleasant to look at, and it's slow to decode, so sticking with JPEG was a good idea. Similar issues with WebP, it wasn't good enough to move to.

That might've been true at the time. But what about today? Can't we use the higher settings for JPEG 2000? At least speed shouldn't be an issue now.

Hmm I don’t know enough to say, but speed is still important because speed = battery life.

The counterpoint to that is that some things are fast in hardware even if slow in software. H.264 is like this due to some design mistakes but JPEG2K could be the other way round.

Reply on news.ycombinator.com