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

QOI: Lossless Image Compression in O(n) Time

phoboslab.org

Post reply on HN
Print view View original

271–280 of 303 posts

Re: QOI: Lossless Image Compression in O(n) Time

#271

Post by BlueTemplar »

Dylan16807 wrote: post #253
BlueTemplar wrote: post #248

Earlier quoted context omitted.

The point is that the average human ""real" color space" has a very weird shape : https://upload.wikimedia.org/wikipedia/commons/a/a9/Visible_... Good luck representing that with only 3 channels, without using "bytes representing 105" (aka imaginary colors), and trying to stay percepetually uniform ! It gets even worse : the real color space is non-Euclidean : it stretches out, parallel lines drift further apart, etc…

> without using "bytes representing 105" (aka imaginary colors) I think you misunderstood my point. I'm saying it doesn't matter if certain byte sequences are invalid and don't correlate to real colors. Imagine you're encoding two digit numbers into bytes. It's not bijective but that's fine, no correct two-digit math will give you an invalid byte. Or imagine you're encoding numbers into bytes the way UTF-8 works. It'…

Right, IIRC it's the "work" color spaces that are trying to go for perceptual uniformity, not the "storage" ones ?

Re: QOI: Lossless Image Compression in O(n) Time

#272

Post by BlueTemplar »

10000truths wrote: post #254
hn_acc_2 wrote: post #223

Earlier quoted context omitted.

The difference will be painfully clear once you try to walk a junior developer through installing and linking new files to a large project in Visual Studio, vs "copy this .h file here and include it". Whether or not a "good build system" should handle it, the fact that single-file libraries are much preferred these days should demonstrate most people don't have such a build system

So much of the C/C++ ecosystem revolves around knowing your build tools that, for most intents and purposes, it should honestly be considered an integral part of the languages. If I ever teach an introductory C/C++ course, I would dedicate at least 1/4 of my time to explaining: * What a translation unit is, and how compiling a translation unit to an object file works * What a linker is, and how the linker combines ob…

Yeah, in our class we had to figure out this mostly on our own, so after it I'm still at the level where I barely manage to make make work, I'll have to look into those other ones, thanks !

Re: QOI: Lossless Image Compression in O(n) Time

#274

Post by Dylan16807 »

BlueTemplar wrote: post #270
Dylan16807 wrote: post #256

Earlier quoted context omitted.

What are you comparing it with? If you compare Rec.2020 with 10 bits per channel and sRGB at 9.5 bits per channel, both of them using the same peak brightness, you should see similar amounts of banding on both. Increasing the maximum brightness can require a lot of extra bits to keep things smooth, but that's a separate thing from which colors are possible.

Ah, I see your point, but I still don't understand this argument, because in practice not only we want extra brightness in colours around the usual white points, but also we need the extra potential physical brightness to extend the colour space itself in terms of "colours only" (not sure that this even makes sense ?) because of the differing needs of different colours. (I'd assume that this is especially relevant fo…

Gamut is affected by brightness but not that much.

Rec.709 has 10 and 12 bit modes too, and it needs them, even though it has the same gamut as sRGB.

The reason 10 bits isn't enough for Rec.2020 is because 10 bits was never enough to fully represent any gamut. Once you add enough bits to properly support a gamut, then extending it to match human vision is a tiny cost.

And to be extra clear, when I initially said "The difference between all visible colors and a more constrained color space", I was talking about taking a color space and expanding its gamut without changing anything else about it.

Re: QOI: Lossless Image Compression in O(n) Time

#275

Post by saagarjha »

makapuf wrote: post #181
kaetemi wrote: post #166

Earlier quoted context omitted.

The sRGB color #ffffff should never mean "the brightest white on this monitor", unless you're using an average CRT. Just imagine you're using an HDR display, where the brightest white is as bright as the sun.

OK but then when will you use that "bright as sun" color? If not, why provide them? If so, what color will you use ?

Do you have a recent iPhone? Try taking a picture with the sun in it: the white of it will appear white as well, but the phone will display it considerably brighter than the white UI surrounding it.

Re: QOI: Lossless Image Compression in O(n) Time

#276

Post by account42 »

Animats wrote: post #217

Lossless avoids all those issues around human perception. Also, if you're storing game assets, some of what you're storing as images is not really imagery. It may be normals or height fields, which lossy image compression messes up. The code is interesting, in that it iterates over the output array, not the input. This helps prevent write buffer overflows. It has read buffer overflows, though. You can craft a compres…

Where do you see a read buffer overflow?

Re: QOI: Lossless Image Compression in O(n) Time

#277

Post by grishka »

amelius wrote: post #73
jiggawatts wrote: post #23

I know you don't like "design by committee" and overly complex formats. Also, the compression algorithm itself is somewhat independent of the "container format" that it's used with. However, if I may make a suggestion: If you do end up rolling your own container format for any reason, always include a way to store the colour space of the image! Treating RGB images as arrays of bytes without further tags is like treat…

Yes, also store the DPI. In general, allow arbitrary key-value pairs to be stored.

This is something I've never understood. DPI only makes sense if you need to accurately represent some physical dimensions in an image. Most of the time, you do not. You would just map it onto screen pixels somehow, most probably dictated by the UI layout around it.

Color profiles however, yes, those are indeed important.

Re: QOI: Lossless Image Compression in O(n) Time

#278

Post by rasz »

makapuf wrote: post #206

for a good simple and fast image compressor look at DXT (decoded natively by graphics cards). No benchmarks for encoder performance though.

Dont you mean Apple Quicktime Road Pizza? S3 ripped off main method (https://en.wikipedia.org/wiki/Apple_Video#Four_color_mode), patented it, and 10 years later successfully sued Apple for using it.

Re: QOI: Lossless Image Compression in O(n) Time

#279

Post by sitkack »

jameshart wrote: post #162
cyber_kinetist wrote: post #47

Earlier quoted context omitted.

I think the author's intending to use this only as a data packing format (ex. for app/game development) and not a general-purpose exchange format. If all you want to do is pack image/texture data for your game then I totally get why they assume RGBA8 storage and leave out metadata such as color space information.

Right - this thread of people asking for colorspaces, dpi data, arbitrary metadata collections… all are exhibiting precisely the ‘expert group’ committee mindset that this format is supposed to avoid. If you want all that, there are formats galore that support it! The point is more: where are the formats for people who don’t need all that? Here is one. Please don’t try to ruin it.

Because this thing looks like it could fill the same need as ProRes while being simpler and open source. For the applications are you are talking about, the format cannot be ruined because it is an internal implementation detail, in the same way that the stb_* libraries can never be ruined. They are yours and everyone's for forever.

The GPs advice about recording color space is spot on. Why design a new container when there are tons of ones off the shelf ones. The collection of files inside a Zip is my goto.

Post reply on HN