Developer creates ‘Quite OK Image Format’ – but it performs better than just OK A developer named Dominic Szablewski has given the world a new file format with a splendid name: the Quite OK Image Format (QOI). The file format might be better than that. Szablewski explained that he decided the world needed a new image format because the likes of PNG, JPEG, MPEG, MOV and MP4 “burst with complexity at the …
I've been contemplating image compression off and on for years, without doing anything really practical about it, and agree entirely with his comments about existing methods. I'm fed up of seeing jpeg compression artefacts on images; I shall have to play with this and see what happens.
I'm all in favour of simple file formats even at the cost of lower compression ratios... have one of these on me -->
You'd likely see quantising noise where a ten-or-more bit per colour channel is reduced to eight-bit RGB(A), but as it looks like it only accepts eight bit input depths then you'd need to preprocess higher bit depth images before compression, which would give you the option to choose the distortion of your choice: bit slicing, dither, smearing, whatever.
On the other hand, it doesn't look too complex to increase the pixel depth to 16 bits instead of 8, with a cost of an extra bit in the header to indicate depth, and a compressed image potentially twice the size... as always, the more depth in the image, the less chance of two identical adjacent bits. Perhaps you'd need a bigger indexed map?
(just thinking out loud here).
Amen: I frickin' hate JPEG artefacts.* People need to be taught about this stuff: never use JPEG for graphs, text, or anything with hard lines (especially company logos on websites... you spent all that money paying the graphic designer/ad agency/consultant, but then went and turned it into a 5kB JPEG? Seriously.). In these cases, go for PNG or similar (TIFF if you need precise colour management, SVG if you can). And reserve GIF for cats.
*Although I have to say, I hate WebP artefacts too, but in a different way: excessive compression with WebP can really make photos look weird (see, for example, most of the images on The Guardian). Just because something is apparently good quality on some metric or other, that doesn't mean it actually looks good.
"Amen: I frickin' hate JPEG artefacts."
I hate obvious compression artefacts, period.
I grew up with analogue TV. When reception was good, it was very good.
The thing is, blocking around similar colours (*) and jagginess around things that ought to be straight lines with contrast... these artefacts leap out of the screen and pound upon my eyeballs like they're little squishy taiko drums.
I can't believe anybody actually thinks that's how broadcast TV is supposed to look.
* - don't even get me started on the horrible shitshow that is Amazon Prime Video in any dark scene.
Watching a MotoGP race (or other race - but this is my experience) on TV is a complete waste of time.
The compression blocks don't even allow you to read the numbers on the front of the bikes, it's that bad.
My TV died 8 years ago and I've not seen anything that would suggest it's worth paying the money to replace it.
I was wondering WTF "I grew up with analogue" was blathering about, because analog TV was absolutely abysmal. ATSC is absolutely amazing compared to NTSC. And then I realized that whatever the Brits had before was probably not as bad as NTSC, and DVB-T is probably worse than ATSC.
UK TV introduced analogue 625 line definition in the 1960s. That eventually also carried the PAL colour. It was fantastic at the Mullard travelling demonstrations prior to the on air service starting. Probably still have the technical document handouts somewhere in my archives.
PAL (Phase Alternating Line) is effectively a colour self-correcting mechanism compared to NTSC.
I secretly enjoyed having issues with the Multiplexer on my old stereo VHS player during the shift from analog to digital. Good, solid sci-fi name.
"Sir! The Multiplexer is offline!"
"Get it back! Adjust tracking to match!"
"No good, sir! Tape speed is too slow!"
"Abort playback! Eject! Eject!"
Depends on what you're comparing NTSC to. For OTA antenna video and marginal signal strength, it just degraded, where digital would have been completely unusable. (I grew up with B&W TV down in a valley, with 2 TV stations visible through heavy snow. It was still good enough to watch Emma Peel.)
> I can't believe anybody actually thinks that's how broadcast TV is supposed to look.
Ah but it's DIGITAL! Anything that's digital *must* be better!!
There was a time around 2012 where you could go to a TV shop and watch an analogue PAL picture next to a DVB-T picture. The quality of the PAL completely wiped the floor with the digital. You realise how extraordinarily good the studio feed is, and how much of it is thrown away for digital TV.
I still can't watch HD on DVB-T2. Every time someone turns their head, it goes into a blur. Mind you, when people are standing still and just their mouths are moving, it's OK.
I was watching some horror movie the other day and the cropped for TV image was obviously cropped after compression because you could see artefacts on the edge of the screen before they moved into visibility. Fortunately the film was too shit for it to make it worse.
conversely, if the film is good, the quality of the image is not so important. I'd rather watch a decent movie on a b/w TV as opposed to some badly-scripted drivel in glorious HD and 10 bit colour (ok i've never actually seen _anything_ in 4k other so how would i know how it feels... but i doubt it can make up for poor content)
I agree, to a point. Sometimes I would watch a good film, but think how much better it would look on a big screen. There again, some films seem to spend the budget on special effects and CGI rather than a plot
Years ago I used to work with a bloke who was a real audio-phile(?), he would spend money on £10 a metre cables connected to golden plugs.
Asked him what music he listened to.
"Michael Jackson"
I grew up with video programmes shot and edited as First Generation original and edited master RGB/YCbCr separated-channel Betacam SP tapes that looked so crystal-clear and had little noise like what TRUE HDTV should have been. On our monster size 36 inch Sony Trinitron BVM TUBE CRTs, the imagery was STUNNING QUALITY even against today's footage and this was in the 1980's!
Only when we went to Sony HDcam-SR video did we get that pure high quality image back!
Now we are shooting 8192 by 4320 pixels (DCI 8K video) at 16 bits per colour channel (48 bit colour) RUN LENGTH ENCODED VIDEO which is essentially FULL RAW on our on in-house cameras so we are FINALLY getting back to pristine colour and almost no noise which we had 30+ years ago!
That Mini-DV, DVcam, MPEG-2/MP-4 imagery in the mid-90's to 2018 REALLY killed colour fidelity and image macroblocking quality compared to back then in the old 1980's analog Betacam SP/HDcam-SR days!
It took until 2020 until we had TRUE image colour fidelity and little noise BACK to what it originally was in the 1980's on colour-channel-separated ANALOGUE tape decks!
OK! I'm truly old now!
V
I have this argument with people all the time about why I still buy blu-rays rather than buying "HD" streaming. Blu ray is losslessly compressed and the interface can handle 20-30mbps. A rapidly moving action scene where a lot of the pixels are changing colour works, while streaming will be a mess of a blur.
Correction: Bluray is definitely not lossless. To my knowledge, there is no lossless distribution format.
Blurays typically use AVC, H.264 video compression. Some old ones used MPEG2.
Even digital cinema files use lossy compression in the form of JPEG2000 frames.
Blu-Ray does not use lossless compression. For example the uncompressed rate of 1920x1080x25 interlaced 8 bit luminance is 51.84 Mbyte/s. Add on the same again for the two colour differences each 2:1 subsampled and you are over 103 Mbyte/s. That is 825 Mbit/s. Far in excess of 20-30 Mbit/s.
It may come close to "visually lossless" but what comes out of the decoder is not exactly the same as what went into the encoder. But pretty good going when you consider the compression ratio.
"I can't believe anybody actually thinks that's how broadcast TV is supposed to look."
I have a Humax Freesat decoder for UK television and a (German) Edision one for Italian television. The basic Freesat SD channels are grotesquely bad for blocks and similar artefacts. The Italian SD ones are sharp and clear. For HD channels, the difference is less, but the Italian ones still win.
Yeah, the Horror Channel takes low quality to a whole new level. The problem is that a transponder has a certain amount of bandwidth available, and the more channels that get crammed into one transponder, the more they all suffer.
Ironically, on 28E (Freesat), it seems the best quality FTA channel is NHK World. Recording stuff off that creates huge files - the bandwidth is rather more than even BBC One HD, though BBC One is an oddity as the bandwidth used can vary greatly from one programme to the next. Last year, recording War Of The Worlds (series) and His Dark Materials; with a similar running time, HDM was nearly half a gigabyte larger.
When at university (more years ago than I'll admit) I was involved with the student TV productions - I learned that getting the sound right was a lot harder than for the picture. Picture glitches are soon forgotten, but sound errors stay longer in the conscious and upset the listener more.
Picture quality rarely bothers me. We have an HD TV but almost never watch HD channels. It's poor sound that gets me! Perhaps it's because I find so little of real interest to watch, I'm rarely watching the screen. There are a few programmes where the picture matters, but far between.
And the pictures are far better on the radio, anyway...
> Amen: I frickin' hate JPEG artefacts
To be fair, that's not the fault of JPEG, in much the same way as it's not the fault of MPEG-2, WebP, h.264 or any of the other mainstream lossy compression systems.
The problem is that bandwidth and storage are expensive, at least when it comes to major content carriers like Google, Facebook, Twitter, digital TV channels, etc.
And so they crank the compression levels to the most they can get away with.
Sadly, that equation is never likely to change, even as we get better compression algorithms. Because there's always going to be a measurable cost saving to be had by tweaking the compression levels to a level which 95% of consumers will accept...
+1 every part of what you said, came in to write more or less this exact comment. Looks really promising, well done. Anything where you control the encode and decode sides (as opposed to something like a browser/server setup) could be converted today and see performance benefits and reduced code complexity. Having worked on the coding side of video software I can also attest to how many bugs would have been dodged and hours saved by a setup like this.
> I'm fed up of seeing jpeg compression artefacts on images; I shall have to play with this and see what happens
It's a nice bit of work, and as other people have said, it's nice having a image-compression spec which is easy to read.
But at the same time, it's pretty much just Run Length Encoding (RLE) with a couple of tricks thrown in. And that means that while it's great for encoding "drawings" (e.g. the Register logo at the top of this page, or a screenshot of my browser), it'll be significantly less good at encoding photographs.
Because photographs very rarely have long sequences of a single colour, unless you perform some sort of lossy transform on them.
Then too, part of the reason for other image formats being so "bloated" is that they have a lot of other useful features. Which admittedly, don't always get used that much. But they do get used.
E.g. PNG has transparency, and an option to create animated images. Which admittedly/sadly, never really got anywhere against the almighty gif.
Similarly, when it comes to JPG, I know few websites use things like the interlaced-progressive download option.
And both PNG and JPG offer metadata features, which can be very useful. E.g. width/height, date taken (both useful when searching in Windows Explorer), camera make/model, image orientation, geo-coordinates, etc.
Also, out of curiosity, I grabbed the test archives from the website, to see how well the compression fares against standard compression tools such as gzip and 72.
I can't comment on the performance, since I CBA compiling up a qoi executable and going through the faff of doing lots of benchmarking tests.
But this is what I got from a few quick tests (assuming I can use lists in El Reg comments):
dice.bmp: 1920138 bytes
png: 349827 bytes (82%)
qoi: 519653 bytes (73%)
gz: 384789 bytes (80%)
7z: 297566 bytes (85%)
qoi_logo.bmp: 394378 bytes
png: 16605 bytes (96%)
qoi: 16488 bytes (96%)
gz: 12132 bytes (97%)
7z: 9950 bytes (98%)
I.e. 7z and gzip are generally as effective if not more so than PNG and QOI!
Admittedly, they're also far more complex to implement, and have the benefits of decades of tuning, but by the same token, reference implementations are far more widely available, and 7z in particular has lots of useful features such as multi-core processing.
For a final bit of fun, I grabbed a recent street-art photo from my phone: it's bright, colourful, lots of details and comes in the shape of a 4.3mb 4000x3000 JPG which decompresses into a 36mb BMP.
And with that image, PNG clocked in at 19mb, and 7z came in at 20.5mb.
Which means that even with the most optimistic "20%" improvement over PNG, QOI would come in at around 16mb, or around four times larger than the JPG. Which most definitely does not have any visible artefacts :)
So, yeah. A small and clever RLE algorithm is a good thing, and that sort of thing definitely has uses in certain niches (e.g. video games, 64kb demo competitions, etc). And the author definitely deserves credit for making it clear, simple and competitive with PNG when it comes to performance and compression ratios.
But it's not a replacement for JPG and it'd arguably need at least some extra features added to be truly competitive with PNG. At which point, the number of lines of code would start to grow...
> RLE? So it's basically a take on PCX, then, which also used RLE
Aye. In fact, at a glance, RLE has been around since the sixties, and Hitachi got a "computer" patent on it back in 1983[*].
https://en.wikipedia.org/wiki/Run-length_encoding
And if you fire up any halfway decent image viewer (e.g. Irfanview, my personal favorite), you'll see dozens if not hundreds of potential image codecs; any which are lossless will almost certainly be using RLE.
QOI has an interesting feature, in that it also includes a couple of "lookback" mechanisms, in which you can describe a pixel relative to the last pixel, using either one or two bytes. I'm guessing this may be one place where it gets it's slight advantage over PNG, though with just one byte (aka 2 bits per colour channel), I'm guessing it only really works for relatively smooth and consistent gradients (e.g. a sunset sky).
Any which way, there's definitely no shortages of RLE-based algorithms out there!
[*] Which doesn't necessarily mean they were the first; Namco got a patent for "playable games on a loading screen" in the 90s on the PSX, despite the fact that there were several examples of prior art on the ZX Spectrum and Commodore 64 (e.g. Joe Blade II)...
"QOI has an interesting feature, in that it also includes a couple of "lookback" mechanisms, in which you can describe a pixel relative to the last pixel, using either one or two bytes."
Amiga graphics aficionados would recognize that technique, which they knew as HAM (Hold-And-Modify. Mmm, ham...) It was their way of getting more colors on the screen than the standard Amiga color palette would otherwise allow.
Amiga HAM mode was more limited because only one of the colour components could be changed at a time meaning that horizontally different sections of an image take up to three pixels to transition from one colour to the other. The fringe effect was quite obvious but often obscured when used with a cheap display which created fringe effects anyway...
Our church had a Kawaii electronic drawbar organ (the same harmonic-mixing system used on Hammond organs and others). Until it died. And then we replaced it with a Hammond "C" model (C2 or C3, I don't know the difference) but it hasn't been fully utilized due to people/drama.
My old physics teacher at school used to repair and move old church organs and we'd sometimes get offered labouring work. Much as I enjoy electronics there is a lot to be said for a 16 footer at full blast in bizarrely shaped stone building that even Mr Hammond never came close to.
But Hammond can also do things which pipe organ can not dream of. Hammonds were intended to emulate pipe organs but they are not really very good at that. They are very good at being Hammonds though. Is like solid-body guitar: original idea was to be like archtop but less feedbacky so can play with loud jazz band. But turned out to be their own instrument (probably Leo Fender was first maker of guitars to really understand this).
Now, of course, we get instruments which try to be Hammonds, including ones made by Hammond. But is not really a Hammond unless it drips oil and is impossible to start unless you know how.
It's absolutely "koi", and the logo is a carp. See the the project page from the article: https://qoiformat.org/
Seeing as Mr Szablewski appreciates a good pun, indicating a refined sense of self-deprecating humour, I have to give this a 10 on the typical decimal scale. We all know a lot of the existing formats are all wet, so a new, sensible, addition will go down just fin.
For Mr Szablewski ->
I'd go for "coo-ee" myself.
Of course, it's an alternative to .png or .bmp. The article doesn't say, but I assume it's an RGB format rather than CMYK (or L*AB), and it might even be HDR. The world seems to be happy enough with alphabet-soup-style names so I don't think that it would be held back even if everyone settles on "queue-oh-eye".
The late great Miriam Makeba!
Actually, it's a misconception that Xhosa is more "clicky" than Zulu - they both have the same three clicks (c, x, q), each of which may be aspirated, nasalised, glottalised and voiced (or not, or in combination), plus an unusual implosive b (as in 'ubuntu', as it happens). I'm from Cape Town, so am pretty familiar with the sound of Xhosa, and also played for a time in the backing band for a Zulu singing and dancing group, so got to hear a lot of Zulu.
But yes, some of the Khoisan languages take it to another level.
https://www.youtube.com/watch?v=5s5AZ52PiZA
I've dabbled with compression over the years and for the most part it's all quite simple. LZW is a bit mind bending in the way it regenerates the dictionary as it decompresses though and I vaguely recall there's one that uses floating point numbers in a really odd way.
My favourite has always been Huffman because that's the first I ever played with although I also have a soft spot for NTFS compression both the way it handles the bit stream (speed over efficiency) and the way it encodes the cluster allocation.
Lol. No I think what I'm talking about is Arithmetic Coding.
"Arithmetic coding differs from other forms of entropy encoding, such as Huffman coding, in that rather than separating the input into component symbols and replacing each with a code, arithmetic coding encodes the entire message into a single number, an arbitrary-precision fraction q, where 0.0 ≤ q < 1.0."
If you can understand all that you clearly have better mathematic skills than me :)
Yes it is absurdly simple, but to be fair parsing PNG is pretty simple too.
Even MP4 is fine if you're just decoding boxes - the "4-byte type, 4-byte length, then data" structure (an ISO format, but unusually for something ISO got its hands on, not shit) fills me with joy when I find the need to write a parser for a new file format, because it's so absurdly easy.
It's also easy to add new box types, which is not the case for this format. Think to the future, Dominic! Plan for extension!
It's the compression scheme where things get hairy, and PNG's Flate is definitely showing its age. But there are better options for speed: LZ4 is standardized, roughly 8 times faster than Zip for decompression, 20 times faster for compression and about 30% larger than Zip for general data. So pretty comparable to his numbers.
Not to rubbish this effort, it's great, but I'm not sure it's earth shattering.
It's definitely nothing special, and the 24/32-bit limitation makes it ok for simple web use, but not much else. You certainly wouldn't be able to use QOI for non-colour map textures in a 3D renderer, for example, and the lack of HDR or more than eight bits per pixel makes it useless for high end graphics work, and regardless of how simple the image format is, I doubt it comes anywhere close to PNG for compression of photos and other complex imagery.
The (very) old sprite engine I wrote back in the mid nineties used a similar compression technique. From what I remember it had a control byte which meant one of three things: Negative value meant skip that many pixels forward (no image data there), a positive value copied the next N pixel values, and zero was end of line. It got reasonable compression rates just through being able to skip spaces and sprites were rendered direct from the compressed data - this was all software based - GPUs weren't a thing back then. But I didn't invent that. That format was basically a rip off of the sprite format that Bullfrog used in all their early 2D games.
Turns out it's Polish notation. (Also Croatian and a few others.)
I would assume that C̀ would be a language using reverse Polish notation.
"why carry an extra device"
When you've been carrying the same calculator around for a few decades, an emulator just doesn't feel the same. At all. Mine's an HP-45 or -55 ... The -35 also still works, but is kept under glass sans batteries (Dad's gift to me, Xmas '72 ... one of the few bits of hardware that I treasure).
According to the docs on Github "Ć is a programming language which can be translated automatically to C, C++, C#, Java, JavaScript, Python, Swift, TypeScript and OpenCL C."
A new one on me, but then I'm very old....
Good question. I once had a colleague who often wrote his C++ all in one line, starting with something like "delete new ...". His overloadment of every available operator bordered on insanity ... at the far end. He was a line count genius but no one wanted to touch his code even with a long well earthed stick.
Yes, I have been unpopular in the past in my Symbian days when reviewing incredibly sophisticated C++, written by incredibly talented engineers (truly) and requesting rewrites because it would be too difficult to quickly understand for the average maintainer. Think complete overuse of C++ meta-programming, etc.
A few points:
Not all compilers optimise the same way, and not all compilers are available on all platforms. One compiler might figure out to use a shift, while another might not. (And "changing compilers" isn't always an option either. Some platforms have one compiler provided by the platform owner/manufacturer. Sometimes you have to just play the cards you're dealt.)
Optimisation only works when the compiler can spot patterns in what you're doing.
Compilers might be good at optimising for built-in types, but they don't always spot the nuances of code or the intention of the programmer when dealing with custom types.
Optimisation by the compiler isn't a given. It's nice when it happens, but you should never assume it's doing the right thing - when it even does something at all - I've seen optimisers give up halfway through functions for no good reason and just leave them as is.
While multiplying by a power of two might be as fast as shifting on some platforms for built-in types, dividing definitely isn't. And I can think of specific instances in my code for custom types where shifting is still faster than multiplying and the compiler wouldn't have a clue how to optimise it.
If you're being asked to use a different style then you're not working by yourself; therefore if the style you've chosen is not canonical but serving a functional purpose, your comments in the code have failed to articulate why. Consider that when complaining that your team members havnt got a clue, it might be because you've done a poor job explaining why you're doing what you're doing.
Contrary to popular belief, if a programmer needs to work in a team, they need to be able to communicate their intent... I've not heard of civil engineers intellectually peacocking by making themselves the only ones who know whats holding the bridge up!
150MB of RAM you say? That's nothing I can do it in 1-line
malloc(157286400); // Just toss this memory away
So number of lines doesn't necessarily correlate with efficiency.
Not to say this is true here, just that I haven't looked at what this person has written in his 300 lines. I should say that most of the earlier image formats weren't that complex to implement - a header and some code to encode / decode bytes. The codec is the complexity and I assume he's produced some kind of codec that is better than RLE but not as optimal as PNG's deflate algorithm and limited the number of bit depths he supports to make it easier.
It's also possible that the code doesn't cope so good with malformed inputs. This is where simplicity is useful on the web. You don't want someone to be able to feed you an image which is 99999999 by -1 dimensions, or exactly 1 byte more than some boundary, or nonsensical encoding bytes. Even so, I expect to protect yourself such things you might still need more than 300 lines to do it safely.
Glanced at the spec. It looks like each colour component is 8-bits only. I think in this day and age there should be an option for a greater colour depth. I can understand he wanted to keep this simple, but sticking to 8 bits prevents using it in some applications. For example, a very simple format like this would be perfect for long-term archiving (no problem including the format spec and decoder source with each volume of images!), but there could really use a greater bit depth.
As someone whose colour vision is rather skewiff, I don't think I can really tell the difference between 16-bit and 24-bit colour. I actually question whether normies can tell the difference between 24-bit and 32-bit colour too,* but then I guess something something dynamic range alpha channel etc.
*10 million colours is apparently oft quoted, so I guess 16.7 million should be enough?
<puts broadcast engineer hat on>
The issue is less with the number of colours which can be differentiated, but what happens when those colours are gradually changing and are adjacent; increasing bit depth allows smaller quantisation gaps and also, courtesy of noise in the image, a better naturally dithered result - so you don't so easily see steps in the picture.
But that said, there are always going to be pathological images which show some unpleasant artefact or other, even in their original uncompressed state.
The broadcast research, back in the day when digital transmission within a broadcast centre was being developed, showed that eight bit colour depth with a few levels reserved at either end of the scale was sufficient for the majority of viewers. Much video equipment used ten bits internally, and CCIR 601 digital video used ten bits, simply to provide some room; a little extra precision that could be either kept or thrown away at the end.
But consider a pathological image: a flat field of a single colour, with luminance changing very slightly across the width of the image... if the difference between the sides is small enough to only be a couple of bits worth of data, you *will* see vertical stripes as the bits flip, unless your bits are so small that they are finer than the eye can resolve. You simply do not see that with an analogue system, even if the change is at the level of the signal noise. The noise acts to dither the signal and smear the change across the picture.
If that sounds an unreal image, it's not: think of a blue sky shading to the horizon...
> think of a blue sky shading to the horizon
I notice it most often in images of a very dark sky (black rather than blue). This especially happens when there is a fade-in from black, where any sky starts off black.
At Quantel we had something called Dynamic Rounding, which added some random jitter to make this sort of effect much less noticeable.
One of the features in Paintbox Graphics was generating graduated rectangles, either horizontal or vertical graduation. By selecting a pair of colours that were fairly similar it was very easy to generate images that showed this artefact.
JPEG too is still stuck at 8 bits - but you're right, most images today have a far larger gamut than 24 bits allow.
Anyway this should be tested with a large sample of images - the one in its site is a computer-generated one, for example, and that has a different pixel distribution than a photo, where there could far more subtler changes among pixels.
Moreover today file formats and image compression algorithms are two separate entities. Many image file formats are actually containers that beyond the image data themselves (and sometimes more than one) need to host other data like image metadata, color profiles, etc.
Anyway this should be tested with a large sample of images - the one in its site is a computer-generated one, for example, and that has a different pixel distribution than a photo, where there could far more subtler changes among pixels.
The tests looks to be done with small images, i.e. images/photo_kodak/kodim04.png 512x768 - a lot of details have been already eliminated by the downsampling of the original image, if it was a far larger resolution. The larger ones I see are about 1 Mpx or little more.
I would like to see the results for a 24 and 50 megapixel image with a lot of fine details.
What we at Quantel found most difficult to compress was neither all-real nor all-CGI images but images that combined the two. Since we were mainly working uncompressed we could show off the different artefacts from different levels of compression and compare with uncompressed. Competitors tended to be all compressed but allowing different levels of compression.
More than 8-bits per channel is really only useful for intermediate formats used during editing to prevent rounding errors accumulating noticeably. It's not very useful for normal colour output. Greyscale, on the other hand, needs more. The encoding given seems like it would be easy to add 24bit greyscale, which is overkill, by using 11111100 and 111111011 (for +alpha) as 8bit flags.
4K monitors usually do allow for a greater gamut than 24 bit - which previously was only the realm of high-end monitors for photo and video editing. And operating systems do allow it as well - for example Windows WCG allows to use wide gamut monitor.
It is not true that "it is not very useful for normal colour output" - it's just that most of the actual hardware has always been limited to 24bit sRGB display.
The thought occurred to me that both the number of planes and the bit depth could easily be variables. For black/white images, one plane and one bit; for monochrome images, one plane and N bits, and so on. Astronomical images sometimes have 32-bit depths; the eventual image shown to humans is reduced, but there can be a large dynamical range between a magnitude 0 star and a magnitude 20 star, so you need those extra bits while processing. For color line drawings, three planes at two bits each would suffice.
And then it occurred to me that rather than doing "look-backs" at the last 64 pixels, you should look at the 8x8 block of adjacent/above pixels; these are more likely to include matches. Switches allowing some degree of lossiness would be easy to do. By default, it doesn't do a thorough job of checking the last 64 pixels; a switch to do so could get better compression at the cost of some speed.
And... by the time you're done with all of this, it all starts ballooning to PNG and JPG library sizes and complexity. So : never mind.
Dearest Mother,
I am sure that you must be startled to find that this falls outside of our usual communication schedule of thrice fortnightly excluding Holy Days of Obligation, but I have encountered with mine own eyes a feat the likes of which the confounded and convoluted telegraph lines of Modern communication have not previously seen – I must copiously reassure you that all remains well at the farm; suffice it to say that my observation has led me to take up quill and correspond with you as a matter of some urgency, and to the extent that I must convey myself without resort to the use of full points! (Is it not clear that I must reserve such humble punctuation for the conveyance of mere mechanical information alike to the status or Mrs Miskin's begonias?) Aware, such as you are, I am sure, of the distressing use of the discrete cosine transform in attempts to impart (with no hope of fidelity) the finest of spatial frequencies, today it seems that we have a resolution, a way forward, a deviation from the turbulence of troubling artefacts – a glorious construction that is nothing short of a Dickensian Christmas miracle! Please find enclosed a Daguerreotype of the a transcription of the folio itself (which was painstakingly illuminated by Brother Michael at the Abbey), and I urge you to instruct Higgins to transpose it to the Colossus that I have kept reserved in the stables for just such an occasion – I give utmost praise to the creator of this miraculous cipher, and I assure you that you will not find yourself disappointed at the startlingly rapid compressive results you will obtain after barely a week of rotations (you will, naturally, have to keep the engine fully stoked in that period, but I suspect Atkins has nothing better to do at this time of year)!
I remain, as ever, your faithful son,
Hubert.
That missive reminds of an episode of Deadwood, in which a character from maybe the 1800's takes time to decry the raising of telegraph wires.
Something to the tune of "...we don't have enough problems down here, now we gotta get messages from the great beyond?"
Cool beans to watch tech evolve little bits at a time.
Seeing as the improvements are largely on the encoding side, this isn't such an issue. Having codecs in hardware will make more of a difference. But, really, decoding bitmaps on a phone is nothing compared to displaying them on screen. And this again is nothing compared to watching videos: network traffic + codec + screen. This is why so much effort goes into video codecs.
It's certainly very interesting work. Note that the decoding takes a third of the time relative to PNG. Encoding takes a twentieth of PNG.
From the article: I don't expect it to appear in web browsers, where compression ratio is much more important, anytime soon.
If your using a VDSL line then the performance increase relative to the minor bandwidth increase in any circumstance; the bandwidth cost is immaterial. It's mobile where the compression ratio would really be most important; most mobile users still have fixed bandwidth limits.
> devices with battery life concerns are an extremely common way to get online
Those mobile devices have monstrously fast processors in them these days. I can't imagine the CPU time to decode a few PNGs is notable at all. Even video decoding in software instead of hardware acceleration results in about 30% reduction in battery life. Screen backlight power consumption almost always dominates.
And smaller file sizes, meaning less power consumption from the cellular radio, could well save power despite the slightly higher decoding requirements.
You seem very invested in this failing (eine Art vorausschauende Schadenfreude, vielleicht?); personally, I'm impressed by it and hope it gets some traction (like PNG eventually did, though it took a long time), at least in some specific applications where it may be useful. In any case, I'm not in the habit of wagering with masked men, but I shall watch its progress with interest.
Very nice is that the project is in the public domain https://creativecommons.org/publicdomain/zero/1.0/ It might eventually take over. But only if the extension name changes to something simple like .ok. By the way, my favorite image format is PPM. Below is a 5x4 pixel picture: first mage format, second dimension, third range, then triples of numbers giving RGB (red-green-blue) values at each point. Might look like nonsense, but it is useful when wanting to write pictures for which one has control over each individual pixel and can not afford to have any artefacts. I have used this format to export pictures from a simple program and then use Imagemagic to convert it into any of the dirty formats.The following picture ok.ppm shows two letters o.k. By the way, the corresponding jpg file has about the same size (lots of overhead). gif is about 10 times smaller. You can copy paste the following lines into an editor, save as ok.ppm, then run convert ok.ppm ok.jpg to get the jpg version.
P3 7 5 255 0 0 255 0 0 255 0 0 255 255 255 255 255 0 0 255 255 255 255 0 0 0 0 255 255 255 255 0 0 255 255 255 255 255 0 0 255 0 0 255 255 255 0 0 255 255 255 255 0 0 255 255 255 255 255 0 0 255 0 0 255 255 255 0 0 255 255 255 255 0 0 255 255 255 255 255 0 0 255 0 0 255 255 255 0 0 255 0 0 255 0 0 255 255 255 255 255 0 0 255 255 255 255 0 0
MNG was NOT "simple" at all. It was removed from Firefox for being huge.
https://bugzilla.mozilla.org/show_bug.cgi?id=195280#c0
In any case, GIF has been largely supplanted by the <video> tag and WebM anyhow, because why wouldn't everyone running a web server want to turn those multi-megabyte GIFs into ~50KB videos instead?
I strongly believe in these simpler, open formats since the "designed by committee" formats are so complex, I'm afraid someone will hijack the spec and sneak a tracking URL or JavaScript code snippet inside an image format enabling three-letter agencies tracking people on the Tor network.
Formats which can be described in a few pages are much preferred over formats like PNG, XPS, PDF and JPEG-X which, besides being vendor specific, are may also be seduced into adding "features" which break security.
ATSC here is different -- the digital multiplex is not owned by whoever then bandwidth sold to the channels -- here, the channel is owned, they run (usually) 1-2 of the old networks (CBS, NBC, ABC, Fox, CW) -- one of these would be what the channel was entirely when it was analog -- and then however many "digital networks" (ones that usually didn't exist when OTA television was analog), usually 4-6 total channels. They run it how they see fit -- one channel here still has fixed bitrate, so the main channel looks great and the rest look like crap -- but the same digital networks from another transmitter only looks bad for a second or two per hour, they run VBR (variable bitrate) so instead of the channel being shorted on bits all the time, it only happens if there's action on too many channels simultaneously. One channel runs a variant I like, instead of looking all blocky in action scenes, it seems to "draw" the screen until it runs out of bits, so instead of picture quality going to hell in action scenes, you have good picture quality except the bottom 10% or so of the picture not updating for a moment or two. Looks odd, especially on scrolling credits, but much better than having the screen go to giant blocks.
Then there's PBS (Public Broadcast Service). Not much to say, except instead of having unrelated channels they have a main and subchannels all PBS channels. Here in Iowa, Iowa PBS (which was recently renamed from Iowa Public Television since having initials IPTV was confusing as hell given the prevelance of internet protocol TV...) for example has a main channel, a arts/crafts channel, a kids show channel, I think a travel channel, and an audio channel that reads books for the blind.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
