+- Makestation (https://makestation.net)
+-- Forum: Technical Arts (https://makestation.net/forumdisplay.php?fid=45)
+--- Forum: Technology & Hardware (https://makestation.net/forumdisplay.php?fid=29)
+--- Thread: JPEG 2000 - The best format that never took hold (/showthread.php?tid=2967)
JPEG 2000 - The best format that never took hold - Darth-Apple - April 30th, 2020
So, of course we're all aware of the JPEG compression format. One of my assignments is to actually do this process. As we know, JPEG takes a fairly large image and compresses it down to only a small fraction of the size. Often, almost native levels of quality can be perceived at 1/10 to 1/20 of the size. But, as it turns out, JPEG is a format from the early 90s, and it's still pretty inefficient. In recent years, we've figured out ways to do much better.
JPEG's secret (even in the 90s) is in how it encodes its data. In a gross simplification, it chops up the image into 8x8 blocks of pixels. It then creates a mathematical formula for these 64 pixels, trying to get a relatively similar output to the original block. With 64 pixels in each 8x8 block, you won't find a tiny formula that represents them perfectly, but you might find one that gets close.
When you increase your image quality settings, you're actually giving the encoder more room to encode a larger "formula". The encoder doesn't have to throw out as much detail to get the encoding to fit within the size constraints. This is actually done using a method called discrete cosine transformation, and is the same method used to encode Ogg Vorbis files (but the technical details here are something I'll discuss on another post). In short, there is quite a lot of science and math behind it. However, the downside is that when you're working with 8x8 chunks, there's still a lot of efficiency that's lost.
JPEG 2000 is quite a bit better than JPEG, and it does this by using a completely different algorithm entirely. Rather than taking 8x8 blocks, it takes the entire image, chops it up into arbitrary blocks, and stores the differences between them. I'm still researching this currently. I'm not entirely sure how this works as well as it does, but the video below is all you need to get a feel for just how powerful this compression actually is. The top right is the corner you want to look at. Voodoo magic at this point. Absolutely amazing how well it does, even at ~15KB file sizes.
Make sure you turn it on HD! Slow it down to 0.25x speed to truly get a good feel. To whoever did this video, you did it justice.
Sadly, JPEG 2000 is not widely supported. Most photo editing programs do support it, but web browsers are hit or miss. Chrome doesn't support it at all, which pretty much puts the nail in the coffin.
RE: JPEG 2000 - The best format that never took hold - Lain - April 30th, 2020
https://talosintelligence.com/reports/TALOS-2016-0193/ (the most important one)
https://talosintelligence.com/vulnerability_reports/TALOS-2019-0945
https://blog.talosintelligence.com/2017/04/vulnerability-spotlight-irfanview.html
https://talosintelligence.com/vulnerability_reports/TALOS-2019-0814
https://talosintelligence.com/vulnerability_reports/TALOS-2019-0815
yes such a shame it never took off, can't quite figure out why...
RE: JPEG 2000 - The best format that never took hold - Darth-Apple - April 30th, 2020
I agree, it's a shame. I suppose they determined that the standard 90's JPEG was enough. And honestly, it really is with the storage constraints we have now, until you start dealing with the web. On the internet, it's worth saving every kilobyte you can.
I took a look at the vulnerabilities. Do these still exist more or less out in the wild? If JP2 was used more often, I would think these sorts of things would be less of a concern.
RE: JPEG 2000 - The best format that never took hold - Lain - April 30th, 2020
i mean they can't exist in the wild when so little actually supports it lmao
but yeah, i mean literally all of those vulns was 'in the wild' at some point in their lifespan.
cisco talos is something else, man. serious CIA shit that goes down there.
thing is, it's typically the codec that causes the problem, not as much the program using it. no one really makes their own codec implementations anymore, hence why the only main one is from 2016 which has (iirc) been patched. anything else in the codec itself would probably just cause it to not parse properly, throw an error and end of story, but when implemented (like the nitroPDF issues), that malformed header now has a way to NOP sled itself in a static environment within the process, leading to the potential for much more damage like RCE
i do know that the jpg2000 codec only actually became truly open/free around 2016 when its first vuln came out. the jpg/png/anything else formats were already really well documented, meaning that anyone could even go as far as writing their own implementations, but to parse jpeg2000 files, you'd need to buy a license from the creators or whatever. I'd imagine that's the main reason it got nowhere. no one wants to pay just to open a goddamn image.