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

261–270 of 303 posts

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

#261

Post by junon »

jiggawatts wrote: post #202
junon wrote: post #149

Earlier quoted context omitted.

Yes encoding might benefit of course, I was more considering decoding speed I suppose.

There are some clever tricks that can be pulled with the latest instructions sets like AVX-512. The registers are huge and the instructions available are so varied that there are clever ways to use them in "off label" ways to implement lookup tables and bit-level parsers.

AVX-512 is deprecated and will be removed from future chips, so that's probably not as useful as one might think.

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

#262

Post by giorgioz »

barrkel wrote: post #66
giorgioz wrote: post #24

>I can almost picture the meeting of the Moving Picture Experts Group where some random suit demanded there to be a way to indicate a video stream is copyrighted. And thus, the copyright bit flag made its way into the standard and successfully STOPPED MOVIE PIRACY BEFORE IT EVEN BEGAN. This bit made me laugh out loud :D

I rather wonder if things like this are used to encode a proof of intent. If something is marked as copyrighted, it may be trivial to remove the mark, but at least you had to remove the mark, and that's evidence of intent rather than ignorance.

I was wondering the same with the COPYRIGHT note at the top of all files in a code repo. Clearly someone that have the code can easily remove the COPYRIGHT header but then it will demostrate they had actively red it and decided to remove it. Plus if you add the copyright header in many places it might be forgotten in some.

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

#263

Post by jiggawatts »

junon wrote: post #261
jiggawatts wrote: post #202

Earlier quoted context omitted.

There are some clever tricks that can be pulled with the latest instructions sets like AVX-512. The registers are huge and the instructions available are so varied that there are clever ways to use them in "off label" ways to implement lookup tables and bit-level parsers.

AVX-512 is deprecated and will be removed from future chips, so that's probably not as useful as one might think.

I doubt that. What would be hilarious is if AMD's upcoming Zen 4 supported it consistently, but not all Intel CPU models did.

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

#264

Post by account42 »

amelius wrote: post #126
mkl wrote: post #107

Earlier quoted context omitted.

> Yes, also store the DPI. I don't think that's a good idea. Most images, like photos and screenshots, don't have physical dimensions. Some image tools like to put in bogus default DPI values that are guaranteed to be wrong, and it can be a bit of pain.

How else would you reproduce images at exactly the right size? Without DPI, the format would be useless for many scientific purposes. But I get your worries. As a compromise, DPI could be optional.

Reproducing images at the "right" size is a very niche requirement. Most images don't even have a right size, including all photographs unless they either use an ortographic projection (they won't) or the object is completely flat and parallel to the focus plane (with recilinear projection, which most normal camera lenses come close to). Having this as a standard attribute in a generic image format makes no sense.

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

#265

Post by account42 »

jijji wrote: post #196
superjan wrote: post #173

Earlier quoted context omitted.

Yeah there’s a difference in techniques used for lossy vs lossless. But my point was that in compression research, runtime performance was much less important than compression performance, that was no different for lossy compression.

speaking of runtime performance if you look at lzma for instance it's horrible on runtime performance but it produces some of the best compression ratio of all of them

lzma usually decompresses significantly faster than bzip2, which is what it mostly replaced in e.g. package distribution. It also decompresses fast enough that for slow enough connections download + decompression is faster than deflate. Compression is slow though, yes.

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

#266

Post by account42 »

Const-me wrote: post #229
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.

Videogames don't need color spaces, but they have different compression formats on GPUs, like S3TC, BC7, or ASTC. These things save not just storage, also VRAM bandwidth.

Videogames do need color spaces once you want to do any advanced enough lighting, it's jus that the only ones you want are sRGB or linear (floating point) so it can often be assumed by context.

S3TC, BC7, and ASTC are all lossy compressions so they are really not comparable.

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

#267

Post by account42 »

sam0x17 wrote: post #159
kaetemi wrote: post #153

Earlier quoted context omitted.

For correct editing operations, and correct display. Sadly, it's not pedantry, it's reality. The 0.5 value is not half the brightness of 1.0 in sRGB. It merely means half the power output to your CRT. If you want correct editing operations, you need to work in linear RGB. It gets more fun. What is white? The color of your backlight? The color of white paper under your particular desk light? And what is black? Is it p…

> We're stuck with images stored in the display profile of old CRTs by default, because that was the most practical option at the time. The analogue in photography is photographs lose color clarity and fade as they age. Why should I care if this is the case in images as display technology evolves when this is already a problem with every physical medium? > For correct editing operations, and correct display. Sadly, i…

> The analogue in photography is photographs lose color clarity and fade as they age. Why should I care if this is the case in images as display technology evolves when this is already a problem with every physical medium?

Because with digital data we can do better?

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

#268

Post by BlueTemplar »

alkonaut wrote: post #212
jameshart wrote: post #162

Earlier quoted context omitted.

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.

You don’t need to support a ton of complex stuff, but if an rgb image format doesn’t then it should just have a version marker and the spec can simply say “the rgb data represents sRGB colors”. Just like e.g. some compilers don’t support a lot of source file encodings but their non-support consists of clearly stating that a source file is UTF-8. Note that this requirement is only for an image exchange format. A raw-e…

Of course a closer equivalent here would be a source file only supporting (zero-padded) ASCII... so quite limiting in terms of real world needs !

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

#269

Post by BlueTemplar »

account42 wrote: post #266
Const-me wrote: post #229

Earlier quoted context omitted.

Videogames don't need color spaces, but they have different compression formats on GPUs, like S3TC, BC7, or ASTC. These things save not just storage, also VRAM bandwidth.

Videogames do need color spaces once you want to do any advanced enough lighting, it's jus that the only ones you want are sRGB or linear (floating point) so it can often be assumed by context. S3TC, BC7, and ASTC are all lossy compressions so they are really not comparable.

Why wouldn't they need color spaces ??

A lot of people don't want to play games that look bad - I'd assume that this is going to be a particular issue when a game goes for photo-realistic graphics, only to end with people with orange skin colour on lots of monitors...

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

#270

Post by BlueTemplar »

Dylan16807 wrote: post #256
BlueTemplar wrote: post #245

Earlier quoted context omitted.

How do you explain then that even 10 bits aren't enough for a colour space like Rec.2020, which doesn't even feature all colours ?

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 for backlit displays like the liquid crystal ones, since they have to use the same potential maximum source power for all of the channels.)

Post reply on HN