A pure go version: https://github.com/xfmoulet/qoi
QOI: Lossless Image Compression in O(n) Time
291–300 of 303 posts
Re: QOI: Lossless Image Compression in O(n) Time
#292This is as cool as it gets. I have a honest question about the source code, a lot of time since I coded anything meaningful in C, but I remember the header files did not have that much code on it, while here I see most of the code is in the header file. Why is this the case? Inline compilation? What are the advantages?
Single header libraries are hugely more ergonomic and easy to use. Just get the file, #include it and you're done! Most C libraries on GitHub prefer this mode of distribution now
Maybe you've been living under the same rock as me. I was under a similar impression untill I decided to learn cmake last week.
I was blown away by its simplicity and power.
You can download almost any C/C++ library from GitHub then add two lines to your cmake file. It will then compile and link with your project.
Blown away.
Cmake can generate project files for Visual Studio, makefiles, and countless other formats. Better yet, you can open a cmake folder directly in Visual Studio. No need to generate a project :)
This comes as no surprise to anybody, I'm sure, but cmake is great.
It was tricky to find good information about it though. It has been around forever, but the nicer features were added recently it seems.
Re: QOI: Lossless Image Compression in O(n) Time
#293Re: QOI: Lossless Image Compression in O(n) Time
#294Earlier quoted context omitted.
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...
What are you even talking about? Using sRGB won't make skin magically orange.
Re: QOI: Lossless Image Compression in O(n) Time
#295Earlier 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.
You are complaining about a format - with the stated goal to be very simple - not supporting some scientific usecase. What...? Use a different format then. That's not what this is trying to be. In fact, it's the exact opposite of what it's trying to be.
Re: QOI: Lossless Image Compression in O(n) Time
#296I really like the format, good job. I've been working on a rust implementation: https://github.com/steven-joruk/qoi
Re: QOI: Lossless Image Compression in O(n) Time
#297Earlier quoted context omitted.
That would be telling.
Or you could be wrong.
It checks for running out of input but, at line 460, will read three bytes beyond the end of the buffer for suitably constructed input. This is technically wrong, but hard to exploit.
Amusingly, if you run out of input too soon, the last pixel is replicated to fill the buffer. So you don't get random memory contents in the output, which would be more exploitable.
Re: QOI: Lossless Image Compression in O(n) Time
#298Earlier quoted context omitted.
ACES (AP0) is an archive format for when you want to be absolutely sure you’re not clipping any colours. As a working space it’s terrible and AP1 should be preferred, either as ACEScg or ACEScc
AP1 is almost the same as rec.2020? I'm not sure what you mean by 'working space' but if preserving all colors was a primary or even secondary goal I definitely wouldn't cut myself down that far.
AP1 is essentially Rec.2020, yes.
By working space I mean a space in which a user manipulates the data in some way, e.g. image editing, grading, compositing or rendering.
Re: QOI: Lossless Image Compression in O(n) Time
#299Earlier quoted context omitted.
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...
What are you even talking about? Using sRGB won't make skin magically orange.
It will if the output is expecting RGB in Rec.2020 or P3 and you give it sRGB data…
Re: QOI: Lossless Image Compression in O(n) Time
#300Earlier quoted context omitted.
> 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…
You're assigning a color profile to the image in your model - the color profile of the display. Hence no color conversion needed, as source and target match. What "red" and "green" are has changed quite dramatically with different display technologies. A display designed to meet Rec.2020 can show colors that other displays literally cannot produce and the deviation between the primaries is so big that everything look…
But if you were forced to always use the same color profile on images? Why allow more than one? Wouldn't that vastly simplify the problem, as then you just have to worry about the device profile, instead of worrying about variation on both ends?