'Quite OK Image' Format (QOI) Coming To a Graphics Program Near You? (phoboslab.org) 103
Slashdot reader Tesseractic comes bearing gifts — specifically, news of "a new image format that is lossless, gives much faster encodes, faster decodes and roughly comparable compression compared to what's in use today."
Quite OK Image format (or QOI) is the brainchild of developer Dominic Szablewski, who complains current image formats like PNG, JPEG, MPEG, MOV and MP4 "burst with complexity at the seams," the Register reports: "Every tiny aspect screams 'design by consortium'," he added, going on to lament the fact that most common codecs are old, closed, and "require huge libraries, are compute hungry and difficult to work with." Szablewski thought he could do better and appears to have achieved that objective by cooking up some code, floating it on GitHub, and paying attention to the 500-plus comments it generated.
While Szablewski admits that QOI will not compress images as well as an optimized PNG encoder, he claims it "losslessy compresses images to a similar size of PNG, while offering 20x-50x faster encoding and 3x-4x faster decoding." Most importantly, to Szablewski, the reference en-/decoder fits in about 300 lines of C and the file format spec requires is just one page long.
"In the last few weeks QOI implementations for lot of different languages and libraries popped up," Szablewski wrote on his blog, with Zig, Rust,Go, TypeScript, Haskell, Ä, Python, C#, Elixir, Swift, Java, and Pascal among the options.
Quite OK Image format (or QOI) is the brainchild of developer Dominic Szablewski, who complains current image formats like PNG, JPEG, MPEG, MOV and MP4 "burst with complexity at the seams," the Register reports: "Every tiny aspect screams 'design by consortium'," he added, going on to lament the fact that most common codecs are old, closed, and "require huge libraries, are compute hungry and difficult to work with." Szablewski thought he could do better and appears to have achieved that objective by cooking up some code, floating it on GitHub, and paying attention to the 500-plus comments it generated.
While Szablewski admits that QOI will not compress images as well as an optimized PNG encoder, he claims it "losslessy compresses images to a similar size of PNG, while offering 20x-50x faster encoding and 3x-4x faster decoding." Most importantly, to Szablewski, the reference en-/decoder fits in about 300 lines of C and the file format spec requires is just one page long.
"In the last few weeks QOI implementations for lot of different languages and libraries popped up," Szablewski wrote on his blog, with Zig, Rust,Go, TypeScript, Haskell, Ä, Python, C#, Elixir, Swift, Java, and Pascal among the options.
Is this a solution to a non problem? (Score:5, Interesting)
I'm not sure that image compression/decompression speeds are of a big concern these days. Sure, I can see this be used in a niche use case where a compromise between storage size and raw processing speed might be useful on a backend platform, something like Pixar's image storage systems they use for their movies for example, but considering jpeg is still the standard for lossy pictures while newer formats have existing for almost decades, I don't see how this one will dethrone PNG.
PNG gained popularity because we strongly needed a lossless format with more than 256 colors (gif) and jpeg was not good for that, the addition of transparency really sealed the deal.
Obligatory: https://xkcd.com/927/ [xkcd.com]
Re: (Score:2)
It could be useful for embedded systems where you want to process images quite fast, and don't want to include a large library like libpng that may have vulnerabilities and require updates.
Compression algorithms for filesystems lzo, lz4, snappy, zstd, do not produce best compression ratio, but are very fast decompressing and improve the throughput of ssd, and their implementation is small enough to be included into an OS kernel with low risk of introducing bugs. For images the linux kernel can read good old
Re: (Score:3)
PNG uses DEFLATE for compression, which is basically an LZ77. LZ4 is as well.
Sounds like PNG anticipated your post by about thirty years.
Re: (Score:2)
Embedded systems usually use custom formats since they're working with custom data and processing requirements, so the formats are tuned towards meeting those requirements.
In fact, without wanting to rain on the developer's parade, I can't actually think of a single genuine reason why we need yet another new image format alongside the, oh, four million existing ones that have been standardised and around for years. Sure, every new whatever is always going to be claimed to be more cromulent than everything
Re: (Score:2, Troll)
If it lives up to the hype, it could be useful in digital cameras, to replace jpeg. But I think a lot of the impetus behind it is revealed in the reasoning for it, with the comments such as "designed by committee" etc: Namely, an attitude of a snotty upturned nose and "well, *I* don't need those features, thus noone else does either!"
Re: Is this a solution to a non problem? (Score:2)
Where digital cameras are replacing or providing alternatives to JPEG, they're choosing HEIC. Especially in the higher end cameras. This looks a little late to the game as an alternative to PNG.
HEIC for the win (Score:2)
Re: HEIC for the win (Score:3)
I work in scientific computing where compression artifacts can be mistaken for data, so we prefer lossless. Medical photography, mapping, satellite imagery, high-speed chemical reaction photography⦠plenty of domains need lossless. Even some movie shoots benefit because of the amount of post-processing that will happen, you want to start with as much of the image detail as possible.
Re:HEIC for the win (Score:4, Interesting)
legal purposes.
https://www.dkriesel.com/en/bl... [dkriesel.com]
Imagine if this affect important safety in building plans, or medication doses, or election results...
lacking features (Score:2)
If it lives up to the hype, it could be useful in digital cameras, to replace jpeg.
No, it wont, or only for very limited use (consumer entry-level point'n'shoot camera. Which anyway don't store raw/lossless data. And whose niche has been completely replaced by smartphones by now). Because among others it doesn't support anything but 8-bits per pixel, and RGB colors (either linear or sRGB).
But I think a lot of the impetus behind it is revealed in the reasoning for it, with the comments such as "designed by committee" etc: Namely, an attitude of a snotty upturned nose and "well, *I* don't need those features, thus noone else does either!"
Yup, exactly that.
Some programmer who just wanted to store a simple bitmap and wasn't interested in the full specs of PNG.
Thus they came up with a simple bitmap storage, that can't encore anything fancy.
Re: (Score:2)
No, digital cameras use JPEG and HEIC for their "quick photo" mode where you can take a memory card and send the photo off to your friends instantly.
Pro photographers shoot exc
Re: Is this a solution to a non problem? (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
What if you were making a game, and wanted user-generated content?
Like, thumbnails for save files, exportable character images, etc.
Making games faster to load/save would DEFINITELY be a benefit - and not just on handheld consoles.
More bandwidth means more ability to have more ways of using such features, like making new features using dynamically changing textures and being able to save the most recent state with the game load, instead of resetting it each time.
Each little bit of improved bandwidth has a w
Re:Is this a solution to a non problem? (Score:5, Informative)
Being a professional videogame developer, I suppose I can speculate a bit on it's usefulness to our industry.
Images (textures) are typically pre-processed into a native format the graphics card will understand. So, games are typically not spending a lot of time, if any, decoding PNGs or JPEG images.
So in practice, image decompression is probably not going to be a loading bottleneck for most games. Disk size is actually more of a factor. In many cases, whatever sort of compression reduces the size by any amount tends to be a win, because CPU power has long ago outstripped disk IO speed, and gaming devices typically have multiple cores to use. And in these cases, total compression is more of a factor than compression or decompression speed. For examples, some mobile games transmit JPEG images across the network, then transform them to a GPU-native file format locally. Again, this sort of format would not really be of any benefit here.
As you indicated, there may be some edge cases where user data is saved or loaded, but it seems much more likely that JPEG or PNG would be used, with not much downsides to those.
One possible future benefit I could see is that, due to it's simplicity, this might have a chance at being directly supported by GPU texture units. In that case, this could then gain life as a native videogame file format (with some extensions), similar to how Ogg Vorbis is very popular for videogame audio. But in this case, it's simplicity and limited feature set may work against it. It doesn't support pre-multiplied alpha, or greyscale textures, for example. And it would need to support mipmaps, etc. So it's likely a new image format would be needed, and only the compression algorithm would be used.
It's a cool new format (check out the specs - very slick), but I don't see many game developers pining for a new image format. It has a reasonable place in libraries like SDL which have built-in image loaders/converters. I mean, the more images supported, the better. But overall... not terribly practical for most use cases I can think of.
Re: (Score:3)
Re: (Score:2)
That's a good point about the GPU format. I should have thought a bit more about the RLE nature and how that's not very GPU friendly. Well, I guess that's why I'm not a graphics programmer.
So... yeah, probably not very useful at all to game developers then. It's a clever format, but just doesn't seem to fill any immediate niche.
Re: Is this a solution to a non problem? (Score:1)
Re: (Score:2)
From the header file, which contains the specs:
The color channels are assumed to not be premultiplied with the alpha channel
("un-premultiplied alpha").
So as you said, there's apparently just no support for it in the metadata.
Don't get me wrong - it's a neat file format, and a clever algorithm. It's just that I don't see a use for it when we have PNG, which compresses better, has a wider variety of features, and is plenty fast on modern hardware. This would have been an awesome format to have around the time we needed a true-color replacement for gif, although honestly, given how limited the feature set is,
Re: Is this a solution to a non problem? (Score:1)
Re: (Score:2)
There's already a format poised to dethrone PNG: WebP. It's complex, yes - but it absolutely wipes the floor with PNG on lossless compression ratio,and in web use transmission time is far greater than decompression time. It's got the backing of a tech industry superpower, Google, to push support. And already is supported by all the web browsers worth mentioning. It also has a lossy mode which is, at worst, comparable to JPEG in performance - and usually quite a lot better. And it can combine them - lossy im
Re: (Score:2)
It's complex, yes - but
You're missing the point of QOI. It's a reaction to what many people see as needless complexity.
Besides, with more people tinkering with small computers, it's the perfect time for a simple and fast image format like this. I'm a big believer in doing as much as you can yourself, especially when it comes to hobby projects.
Re: (Score:3)
I hate webp because it's new enough that basically nothing but web browsers supports it, and too many web servers automatically transcode to it when a web browser claims to support it, so if I want to save an image as a file, it saves as a useless blob. Ask for a .jpg, get a webp. Ask for a .png, get a webp. I have to fall back to using wget to NOT get a webp file.
And now someone wants to create ANOTHER image format?
Re: (Score:2)
Re: (Score:3)
Screw WebP. Just getting the image dimensions out of a file is a nightmare that requires you to parse practically the whole file since that information may not be in the first chunk. Even then, Google chose to use this idiotic 14-bit format for values requiring you to do bit shifts, unless you have a version of the format that doesn't do it that way or uses the alternate header format or...
WebP is a trainwreck. I hate it. There's a reason why it's been around for more than a decade and you can't get any
Re: (Score:2)
I can't really see much use for it either. Less computation saves energy on mobile devices, but that will likely be offset by the need to download more data.
The only place I can see it having some utility is on microcontrollers with limited RAM. I've written a few custom formats for those over the years, mostly based on the pixel format of the LCD. For some reason there is no standard with graphic LCDs, they all do something different and usually weird. Simple run length encoding, which is what this thing u
Re: (Score:2)
Re: (Score:2)
I'm not sure that image compression/decompression speeds are of a big concern these days.
For general purpose computing? No. But that's not the only place images are used.
Re: (Score:3)
Re: (Score:2)
I don't see how this one will dethrone PNG.
JPEG-XL, though, on the other hand... Is going to wipe the f***ing floor with PNG.
Re: (Score:2)
I'm not sure that image compression/decompression speeds are of a big concern these days.
I'm currently looking into it (haven't read much yet) because we need a way to efficiently store lots of high resolution images for road condition surveys. Currently we use JPEG for that but compression artifacts have become an issue.
Re: (Score:2)
And there are existing formats that are much better than standard JPEG for lossy compression, or are much better at compressing lossless than QOI can ever be.
I don't think the compression/decompression speed is a greater concern than size in your case, unless you get something super slow. I suspect that for lossy HEIC could be good enough for your needs, but you could try JPEG-XL which offers strong compression in both lossy and lossless formats but can be slow.
Here is a relatively recent article that cover
Wait what? (Score:5, Funny)
Re:Wait what? (Score:5, Funny)
a dandy $350.000 nft of the first cat pic ever compressed with qoi should restore your slashdot faith. yw.
Re: (Score:2)
You don't really need hundredths of a cent when the cents is already .00.
Re: (Score:1)
I'm assuming the poster was German and he really meant $350,000
Re: (Score:1)
You don't really need hundredths of a cent when the cents is already .00.
Your education is lacking.
What did he skip? (Score:4, Interesting)
What he calls complexity could be useful features. Color space is RGB or RGB+alpha, so at least transparency is supported. No monochrome option though. 8 bits per channel, no option to change color depth. No CMYK.
Re: (Score:1)
I think it's the usual snotty upturned nose and "well, *I* don't use those features, thus noone else needs them either!" attitude providing a lot of the idea behind it, though it could be useful for digital cameras as an alternative to jpeg copies of RAW data.
Re: What did he skip? (Score:2)
What exactly does it offer for people who shoot in RAW? I usually have RAW+JPEG enabled, but thatâ(TM)s mostly for a backup and normally end up deleting the JPEGs as a waste of space. This thing offers PNG level compression, which will make it bigger than JPEG, but for what benefit? If Iâ(TM)ve got the RAW then I can create any image format I want without additional loss and have the benefits of being able to fix white balance or exposure, etc.
Re: (Score:2)
Three times the file size probably, since it doesn't support anything but RGB.
Re: (Score:2)
Re: (Score:1)
QOI on digital cameras? Nope, I haven't seen a digital camera with an 8bpc image sensor since last century. Image sensors today commonly have 12, 14 or 16 bits per channel thus being completely unusable with QOI.
Re: (Score:2)
Does it use a pixel cache? If so, there might not be much benefit from monochrome.
Re: (Score:2)
I'm not sure what the right term is... PNG doesn't do it, WebP does. Sort of fancier move-to-front encoding, that assigns shorter codewords to recently-seen color values.
Re: (Score:3)
The easiest to understand use is when applied to an unsorted list. The most frequently accessed items will tend to stay near the front, so the runtime performance of searching that list improves, and for the same reason, if items near the head of the list are more likely than items near the tail, then its easy to give them shorter code words.
In compression practice, move to front is often done via splay tree.
Optimally a code words leng
Re:What did he skip? (Score:5, Interesting)
In addition to not supporting things like grayscale, more or fewer than 8 bits per pixel, more color spaces than sRGB / sRGB-alpha, a number of color planes other than 3 or 4, all of which limit the domain for a new encoding, there are some observations to be made ...
Fun fact: he's using Goedel numbers in the hash function.
Also fun fact: he uses a running index of previously seen colors to create a localized cache, essentially a sliding-window indexed encoding with each pixel a reference to a recently seen indexed value, a delta from the previous pixel, or a run-length duplication of a previous pixel. Decoding *must* use the same cache size, which is fixed at 64 entries. Encodings like this implicitly assume that images have more low-frequency information in them than high-frequency (which is generally true, but not taking into account actual spectral profiles is tantamount to leaving a lot of compression on the table).
Another fun fact: there appears to be no redundancy in the encoding, so that if a single pixel is corrupted in transmission or storage, it can affect the entire rest of the image.
Final fun fact: he ignores opportunities for compression in 2D, by considering images only along scan lines.
OK, one more fun fact: paying attention to lots of suggestions as part of a development process is quite reminiscent of design by committee.
Re: (Score:2)
Also fun fact: he uses a running index of previously seen colors to create a localized cache, essentially a sliding-window indexed encoding with each pixel a reference to a recently seen indexed value, a delta from the previous pixel, or a run-length duplication of a previous pixel.
It sounds like you are describing an encoder from the LZ family, only with the word 'dictionary' replaced by the word 'cache'.
Re: (Score:2)
That would hardly be surprising since PNG also uses an LZ encoder. It sounds suspiciously like someone stripped the features out of PNG that he didn't personally see a use for.
Re: (Score:2)
paying attention to lots of suggestions as part of a development process is quite reminiscent of design by committee.
\
Let's see if I can explain the difference.
Design by committee is all about compromise. That's why designs tend to get bloated with questionable features and hampered by confusing design decisions. It's the intersection of a lot of competing interests, with a little extra weight given to the loudest voices. It'll give you something ugly, complex, but generally good enough. (Take a look at OpenType to see how absurd compromise can get.)
This was designed by a single person with input from a community. T
Re: (Score:2)
Just had a quick look at the source code [github.com]. Oh dear Ghod, he takes an existing file, e.g. PNG, decompresses it, wraps it up in an exquisitely homebrew set of headers that, as others have pointed out, won't deal with 99% of the requirements of people out there, and then uses some first-year student... can't be bothered devoting the cycles to figure it it since it's all uncommented code littered with magic numbers but it looks like there's some run-length coding and delta/differential encoding going on.
This i
Re: (Score:2)
I dont understand the spin being put on this, because there is no way in hell this format can replace much.
But its wholly true that image compression in generalized formats is quite complex. A programmer unfamiliar with how information theory is applied in practice, down to the very last pigeon holed encodable value, has no chance at all. Even something like huffman encoding is not something that can be described in a single paragraph.
If you dont need to support one of the generalized formats, the
Re: (Score:2)
Maybe we don't need every file format to do every possible thing?
"Simple and fits most use cases" is a good thing. Most people don't need anything outside of RGB24 and RGBA32, after all, so why make them use a large, complex, and slow image format (which usually means including a do-everything library) when something smaller, simpler, and faster will do instead?
If that doesn't work for you, that's fine. You can just use something else. It's not like other formats go away.
Re: (Score:2)
Everything's going 10-bit HDR these days so RGB24 is already obsolete.
Re: (Score:1)
Obsolete? That's the most ridiculous use of the word I can imagine. I can guarantee that in 10 years time, sRGB will still be more common that 10-bit or higher color. Think about it. We've had cameras that support 12 and even 14 bit color for a long time and sRGB is still the standard.
It has value in it's niche, sure, but that's where it'll stay. It's the same reason a lot of photographers will pick 12 over 14 bit when they have the option. The quality just isn't worth the extra space.
Re: (Score:2)
I convert my photos to sRGB out of necessity because JPEG has a lot of inertia. So these days sRGB is only useful for final publishing, not for capture or as an intermediate format.
Re: (Score:2)
What he calls complexity could be useful features.
If people need useful features there are other formats you can use. The useful feature here is the speed and lack of complexity which is a feature in itself. Take your examples for ... err example. The overwhelming majority (easily greater than 99%) of images in current use and distribution are 8bits per channel, don't support alpha channels, have no option to change colour depth, and don't have a CMYK colour space.
But really the use case here isn't for your professional printing company which cares about t
You can never have too many (Score:3, Interesting)
Re: (Score:3)
Simplicity tends to improve security, since there's much less code to audit. Even so, I was glad to see someone hooked the decoder up to a fuzz library. This IS brand new C code, after all.
You're correct that nearly every existing file format decoder has had some security problem. It would be impressive if this were the first to actually be secure out of the gate. But I'm not holding my breath.
Re: (Score:2)
Zawinski's Law compliant?
People want to know (Score:1)
Sounds great (Score:2)
Now we need to update the billion plus systems, including embedded systems to be able to make use of this new codec.
It's going to take many years to see any kind of widespread adoption of this, not to mention PNG is good enough to the end user.
What? No Lenna?! (Score:2, Insightful)
I was surprised their test examples [qoiformat.org] don't have Lenna [wikipedia.org] in there.
Re: What? No Lenna?! (Score:3)
There has been a bit of a âoedebateâ about it:
https://github.com/phoboslab/qoi/issues/35
Re: What? No Lenna?! (Score:4, Informative)
Wow, I had actually missed this whole issue. From what I read now, even the model herself doesn't understand what the big deal is, especially since it is to the shoulders. And people calling it a "crop of a pornographic image" when we are talking about just Playboy is a bit... I don't know, maybe because I grew up in Europe where people are not irrational pseudopuritans?
Re: (Score:2)
Nah, she doesn't want to be involved in these test images and she's made that quite clear. https://www.losinglena.com/ [losinglena.com] There's nothing particularly special about that photo so we can find equivalent test images.
Re: (Score:2)
From the Wired [wired.com] article where they met her and had a chat:
The photo, she said, doesn’t show very much—just down to her shoulders—so it was hard for her to see what the big deal was.
I’m really proud of that picture
Her son works in tech, and he has occasionally tried to explain to his mother how her image is used and to what ends. “He works with pixels,” she said. “I don’t understand, but I think I’ve made some good.”
There's nothing special about that photo EITHER WAY. Our world is too fucked up for people to get worked up about non-issues. If the subject of the picture had a problem with it, I'd understand.
Re: What? No Lenna?! (Score:3)
Didn't you hear? Anyone using Lenna now is sexist and therefore cancelled.
Even she (Lenna) says she doesn't want the image used anymore...which I think is a perfectly legitimate request, as long as she pays back the money she received - plus interest - to have the picture taken in the first place.
Something seems off (Score:5, Insightful)
Ok, so first we have: "Every tiny aspect screams 'design by consortium'," he added
Then: "Szablewski thought he could do better and appears to have achieved that objective by cooking up some code, floating it on GitHub, and paying attention to the 500-plus comments it generated"
Is that not "design by consortium"?
Re: (Score:3, Interesting)
Re: (Score:2)
Re: Something seems off (Score:3)
Not when thereâ(TM)s only one person saying yes or no to each bit of feedback. Committee designs have to make compromises to build consensus and get buyin from multiple approvers. This is just one person trying to get educated and make decisions accordingly. As a result, all the trade off options are being decided toward the one personâ(TM)s use cases. Itâ(TM)s not necessary bad, not necessary good â" just a different way to encode.
Re: (Score:2)
Is that not "design by consortium"?
It is not.
How does it work? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:How does it work? (Score:4, Interesting)
So I guess the basic idea is something like... store each 24 or 32 bit pixel in:
I wonder if compression could be improved ever so slightly if the extra bit in the 16-bit format was moved to the green channel from the red channel, since brightness information mostly ends up as green. No idea if that would help or not. (Nevermind, I see that's already been done in the updated spec.)
I work in a 2D animation environment, and most of the images that we generate are 8-bits-per-channel. (For post-processing they often switch to higher bit depths so that they can push colours around without loss of fidelity, and because they're often working in video/legal range instead of pc/full range which makes 8bpc suck just enough to really notice it in gradients.) That's just starting to change with broadcasters wanting HDR, but presumably this format could be extended to 16bpc pretty easily.
Having only sRGB and linear colour spaces is a bit limiting, though. Perhaps I could propose an extension to the spec...
Re: (Score:2)
Skimming through the spec, seems like it's a sort of combination of run-length encoding and pixel-to-pixel diffing to make the run last a little longer?
Delta encoding doesnt make runs longer. Delta encoding makes more runs.
0,1,2,3,4,5,6,7 has no runs
but apply delta encoding to it:
0,1,1,1,1,1,1,1 has a run of 7 1s
Any even stepping of values, such as seen in gradients, therefore also has runs.
Re: (Score:2)
Re: (Score:2)
It's a question of perspective. I would say that 1,2,3,4,5,6,7,8 has eight runs, each of length 1.
QOI sucks (Score:2)
In short let's forget about it.
How about with compression? (Score:3)
I actually looked at the how the image is encoded and the basis of it is that most basic concept is that many pixels aren't a large change from the pixel before it. As such, it provides four different operations (selected by the last two bits in a byte) and then provides the remaining six bits to compute the new pixel value from previous pixel value. The various operations are...
* palette index: six bits select from a palette of 64 colors
* channel value diff: two bits per channel that are added to the previous values
* luma value diff (two bytes total): six bits for the green channel and then four bits for red and blue that modify based on luma values relative to the green channel.
* repeat previous pixel: six bits determine the number of times the pixel should be repeated (1 to 62 times because 63 and 64 conflict with bellow)
** special values 0xFE and 0xFF are used to indicate a new pixel value, RGB or RGBA and the next 3 or 4 bytes are channel values.
I can see why this is attractive option for embedded system programmers (it's elementary math done per pixel in order) but I do wonder if the resulting encoded images would benefit from DEFLATE or LZMA compression. If so then it might be worth adding this (or a similar type) of encoding to the PNG format as a new kind of "filter algorithm".
Does compact source run faster? (Score:2)
lots of metrics on code length reductions. What IF compiled code that is shorter runs slower?
It a hailed achievement in programming but no measures other than size-only comparisons like smaller is better.
I have no wish to learn yet another... (Score:2)
Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised. "What did you do that for?" exclaimed the novice. "I have no wish to learn another editing program," said the master. And suddenly the novice was enlightened.
And so it is with yet another image format.
I've read the PNG Spec; it's great. (Score:3)
Now let me start saying jpeg is a giant pile of crap that couldn't be fully implemented by anybody but PNG is actually great. It's simple, highly extensible, lets you ignore stuff, has different bit structures, outsources the compression and is perfectly easy to understand. There is literally nothing in this format that isn't already part of PNG. And even putting JPEG and PNG in the same realm is in error, PNG is superior in literally every way. But, saying this Qoi format is as good is both wrong and seriously problematic. You can quite literally write a PNG writer in like 7 lines of code.
return b"".join(
[
b"\x89PNG\r\n\x1a\n",
png_pack(b"IHDR", struct.pack("!2I5B", width, height, 8, 6, 0, 0, 0)),
png_pack(b"IDAT", zlib.compress(raw_data, 9)),
png_pack(b"IEND", b""),
]
)
Also, the biggest deficit here is that it's focusing on the original code writer for the library not for the user of that library. I don't care what's in the magic stuff Pillow does to process .save("myfile.png") -- I care that it's not lossy, I care that you could extend it to include other things not originally given in the spec, but somebody is going to write that code 1 time, and people are going to use the features in that code a million times. --- Making the former improved at the cost of the latter is a serious problem. We would be much better off if we could focus our efforts and killing non-png type formats.
Re: (Score:1)
Seems to me png doesn't support images of type movie. So no mp4 or MPEG compatibility.
Re: (Score:2)
You'd be wrong. It's so extensible that all you'd need to do is add another block type for mPeG that would contain the mpeg data and you're fine. You could easily use a png to store that type of data. This is the kind of joke that only somebody who didn't read the spec would make. It's totally within spec to make different block types that contain other data.
Useless format (Score:3)
Re: (Score:2)
Re: (Score:2)
Developer: "[X] is too complex. I have created [Y]”
Community: "That is great but can you add [feaure 1] and [feature 2]? We really need it."
Developer: "Ok but no more."
Years and many features later. . .
New developer: “[X] and [Y] are too complex. I have developed [Z]."
And the circle of life begins again. . .
Re: (Score:2)
Sometimes such cycle is meaningful because old use cases may be obsoleted or people found better structural design so that current use cases are better integrated into the infrastructure and less hacked on.
But QOI is not those cases.
Meh... (Score:2)
QOI and then a second pass (Score:1)