What’s the best lossless image format?
siipo.la
siipo.la
JPEG XL covers nearly every use case for images, even replacing GIFs with it's animation support.
Existing JPEGs can also be re-encoded losslessly into JPEG XL format/data structure and get significant file size savings. This backwards compatiability is very important in transitioning to web to JPEG XL seamlessly.
What I'm most excited about for JPEG XL is progressive decoding, I had been following the FLIF project for a while and was disappointed with it's lack of adoption. But it's future found itself in JPEG XL.
Without a doubt 5 years now JPEG XL will become like Opus and set the standard for next generation image formats.
I wrote a little X11 screenshot tool last year; one of the reasons I wrote it is because I wanted to save images as WebP rather than PNG that most tools use, since it's quite a bit smaller. Not that I'm running out of disk space, but it just seemed nice; one of those "no, it's not really needed but it's fun and why not?" weekend projects.
Anyhow, I discovered that loads of stuff doesn't support WebP. This was unexpected as it's been around for ages and supported by almost everything, but things like uploading to GitHub, Telegram, and many services doesn't work. It was disappointing and I had to add PNG support just for that.
I fear that JPEG XL will be in a similar situation in the future, where loads of websites can and do use it for their images, but also loads of services don't support it so it's a lot less useful than it could/should be. I hope I'm wrong.
I expect JPEG and PNG to become for images what MP3 is today. And I expect H.264 to become that for video. These formats are too ingrained, whatever their technical limitations.
Technologists consistently underestimate the power of backwards compatibility. Itanium was better than AMD64, DVORAK is better than QWERTY, and I'm sure Esperanto is lightyears ahead of the monstrosity that is English. But backwards compatibility always wins, because it fits what the world was already designed around.
-----
(To be fair to GP, they said Opus is the definitive choice for the web, which may be true for integrated in-browser playback. But in other contexts, well, Amazon sells MP3s, not Opus files.)
No, AMD64 is far superior, Itanium's benefits never materialized. Any BOTH offer backwards compatibility, anyhow.
> DVORAK is better than QWERTY,
Not by enough to matter except in extreme circumstances. I say this as a Dvorak typist.
> I'm sure Esperanto is lightyears ahead of the monstrosity that is English.
It's not. It is needlessly complicated. "Basic," "Simple," or "Technical" English (which came along a few years after Esperanto) is far simpler and quicker to learn.
> But backwards compatibility always wins, because it fits what the world was already designed around.
Besides all the above being incorrect, some examples like the rise of ARM serves as a count-point.
I said in my last post that I expect h.264 to become the MP3 of video files—but if that doesn't happen, I suspect it will be due to the format's lack of HDR support. That's also a difference in kind—something every consumer will immediately notice, if high quality HDR displays become common in the future.
What time, and which class of devices? Certainly it's true of very low-power embedded devices, but those aren't of particular interest... Embedded devices can easily switch between architectures without end users even noticing.
If we are referring to ARM being used for more computationally intensive devices... Like smart phones, tablets, and servers, then x86 has always had competitive options.
The earliest couple Nokia Communicators were x86 based, not ARM. Years before they switched to ARM, the National Semiconductor (later AMD) Geode processors debuted and were surely competitive with ARM, having power ratings as low as 0.7watt. Blackberry phones came years later, and iPhone and Android devices much later yet. The OLPC project using Geode CPUs on their XO-1 certainly proves their viability.
I'm sure it's easy to say that when you are already an English speaker. I personally doubt it very much. Is there some data maybe that supports this point of view?
It might help if you specified exactly what it is you doubt...
It's a simple fact that Basic English has a shorter wordlist than Esperanto, simple rules, and being based on English it omits things like gender for objects.
While perhaps exaggerated, the claim was: "it would take seven years to learn English, seven months for Esperanto, and seven weeks for Basic English."
Some references to start with:
https://en.wikipedia.org/wiki/Esperanto#Criticism
https://englishharmony.com/english-is-easy/
https://academickids.com/encyclopedia/index.php/Basic_Englis...
Just looking over the list of words in your last link, I'm pretty sure that any number of them would trip someone that is a blank slate. For example: "who", "wheel" and "humour" are vastly inconsistent with regards to how they sound. Having to learn these idiosyncrasies, even for 900 words, would be - in my opinion - more difficult than the basic rules of Esperanto (and Ido, which seems even simpler).
I would imagine that coupled with a phonetic transliteration of the common sounds it would be easier but then the language would probably become a different thing all together.
I hope that clarifies a bit.
The amount of exposition varies based on a number of factors, but anything is better than nothing.
Not if you're a programmer, punctuation, which is much more frequent in programming languages than english, is a lot harder to type.
I've heard colemak is better for developers, but as a vim user, relearning touch typing AND my vim muscle memory doesn't appeal to me, so i haven't given it a serious try.
The problem is that there is too much to remap, basically you need every letter on the keyboard. And if you keep positions, mnemonics do not make sense anymore. "Change Inner Word" would become "JC," (on Dvorak).
If you keep the letters (instead of the positions) all commands in muscle memory do not work anymore. I tried to relearn those ... but in the end it is too much effort for too little gain.
These days, whenever I get fancy I just switch the keyboard layout to Neo2 when writing longer texts and switch back when going back to command mode. (I guess there is a way to automate that switch, that would be interesting now that I think of it).
There is this quote from Edward Bernays that I like
> “The great enemy of any attempt to change men's habits is inertia. Civilization is limited by inertia.”- Edward L. Bernays, Propaganda
Early Itanium included a x86 unit. Intel tried everything it could to push it.
> and I'm sure Esperanto is lightyears ahead of the monstrosity that is English
A lot of the complexity in English comes from active use and adapting to new concepts and integrating foreign words. Hopefully Esperanto will never be in a position to suffer the same issue and join the ranks of Itanium instead.
Or AAC-LC. Which is so much better than MP3 while having the 99.9999% compatibility. ( It is pretty hard to find something that support MP3 and NOT AAC )
I thought the consensus was that Itanium turned out to be a significant mistake and represented a misestimate of how we could utilise it in software?
It wasn't really my intention to "make a case"; just an observation/lament/complaint.
I just tried downloading a couple and they seem to work now, but I've grown to hate WebP. Even if they open today, I likely won't keep anything saved as WebP, because I won't trust it will work down the road, where jpg and png will likely work for decades.
The trouble is that you may want Opus, FLAC, and JPEG XL, but someone else wants a different set, and someone else wants yet a different set... then in 3 years everyone changes their mind. There is value to some stability and consistency to these file formats so our media is durable and broadly supported over time.
I'm not sure Apple is the only one holding this stuff back. I just checked out a JPEG XL site [3] and it only shows partial support and it's hidden behind a feature flag. As long as this is the current state of things, Apple isn't holding back anything. It's simply not ready for prime time.
I get the desire for open source standards used for media, but they never seem to be as broadly supported, and for your average user, that's all they care about. "Can I view my image? Can I listen to my music?" If the answer is no, they don't care about anything else. Most users won't know if they are looking at a PNG or JPEG XL, or listing to an m4a file vs Opus.
[1] https://www.youtube.com/watch?v=48j493tfO-o [2] https://www.youtube.com/watch?v=XmRNIGqzuRI [3] https://jpegxl.io/#tutorials
Also, it's really not that interesting of a project as such, but it was/is interesting for me anyway in the sense that I now know more about image processing and X11 ("outdated", allegedly, but works fine for me, so whatever).
As I comment elsewhere[1] it also has an experimental fast mode in tree that is crazy fast, using AVX2, NEON, or fallback.
Hopefully Microsoft patenting the thing someone else invented (ANS)[2] doesn't gum this all up.
Edit: Apparently there's an experimental faster version: https://github.com/libjxl/libjxl/tree/main/experimental/fast...
The time spent by high quality encoders is generally trying different settings to find optimals... decoding should be unaffected.
[1] https://www.hackerfactor.com/blog/index.php?/archives/895-Co...
EXR seems like it does all of the high end pro features of JpegXL and more (including 32 bit color). JPEGXL can do some odd stuff like animated gif type images but that seems more like a web end user feature than something professionals would care about. I can see it replacing Jpeg / GIF but I don't see this becoming an industry standard anytime soon.
I may soon have to recommend a lossy but potentially lossless image format for 3D medical images (with 16 bits channels), would JPEG XL fit this bill?
I imagine the doctors would view these images in multitudes of ways(browsers, operating systems, image viewers) with varying level of support. So encoding in a standard that is yet to be entirely finalized and adopted is a bad move as of now.
You'd be best off with going with JPEG2000 still if that's what you prefer or DICOM.
So unless you expect library availability and/or encoder speed to hurt adoption, go for JXL.
not compressed, but handles the voxel-image space transform which is far far more important and quite complicated.
you can slap gzip on top of it and most libraries/FIJI will transparently decompress
Some of those 9 "apps" include imagemagick, ffmpeg, exiftool, libvips, and Qt KImageFormats.
These libraries power a vast amount of software. Support is also in beta for Firefox and Chrome.
Case in point, Apple making a fuss last Monday over finally allowing users to change file extensions in CandyCrushOS^H^H^H^H^H^H^H^H^H^H^H^H iPadOS 16, a move some 51 years after mv was introduced to Unix on which that operating system is ostensibly based.
Linux has way more than 9 apps that deal with images.
So if you are on linux, practically every app that deals with images will NOT work with JPEG XL.
If it is .jpx, maybe.
Otherwise, no.
(Only partially kidding, unfortunately. Outcomes sometimes hinge on trivial details.)
TIFFs are more in-line with a combination of FLAC/WAV from the audio world. It's meant for raw data used in production/manipulation.
As a professional you would work with TIFFs/RAW photo formats and then master it in JPEG XL for mass-consumption.
[1] A JPEG XL file can be a minimal bitstream or an ISOBMFF container, where the latter can contain the actual bitstream and additional metadata like Exif. The bitstream itself should be enough for decoding.
never heard of Opus for images... must have been sleeping
This works absolute wonders if you are talking about images with a limited amount of colors and without many gradients. I use it to compress screenshots of websites, which, if you think about it, are mostly large blobs of uniform colors with hard edges. I also use it every time I want to include a screenshot from my desktop in some publication or email. The savings in filesize are too good to be true without any apparent loss of visual fidelity.
*Add this to Category:Articles_with_obsolete_information: https://en.wikipedia.org/wiki/Vector-based_graphical_user_in...
Notably fjxl is in the reference libjxl tree. I'm not sure what if any constraints fast mode has, what it takes to use. The article uses cjxl, which does not run the fjxl fast mode, and further, fast mode was added after this article was written[6].
Other notes on jpeg-xl: it has progressive rendering. It has hdr!
The deck on FJXL & FPNGE is epic. Thanks Quote Ok Image (QOI) format for setting the fire on this all!!
[1] https://github.com/richgel999/fpng
[2] https://twitter.com/richgel999/status/1485976101692358656
[3] https://www.lucaversari.it/FJXL_and_FPNGE.pdf
[4] https://github.com/veluca93/fpnge
[5] https://github.com/libjxl/libjxl/tree/main/experimental/fast...
https://github.com/libjxl/libjxl/tree/main/experimental/fast...
The article literally compares it to others. It might not have been finalized at the time of writing, but it's not like the author was unaware of it.
For which application? Otherwise you can only say "depends". Tiff is good if you want to save data fast to disk in Blender. EXR is great if you want 32bit color depth, etc.
Mind that TIFF is only a container format that can contain any arbitrary codec you like; it can be uncompressed pixels, RLE compressed, it can be a PNG, a JPEG XL, even lossy JPEG or WebP if you'd like.
Saying your image format is TIFF is roughly as useful and conveys as much information as saying your video format is MKV.
So it is certainly not as simple as just going for the thing that produces the smallest file in some benchmark that may or may not fit your realworld data.
For this article the context is for use in browsers, and the main metric being measured is compression ratio.
... something that might tell us, given a 3s encode with available technology, at what number of over-the-wire loads / decodes does it become more efficient to use a cheaper codec? Slightly less relevant with lossless, but still.
Did you know that, with the correct SIMD code, you can encode a 1080p bitmap into a 4:4:4 JPEG within 10 milliseconds on a typical consumer PC? Encoding times like this open up an entire dimension of new possibilities.
I do have a side project where I use libjpegturbo to synchronize a frame buffer between server & web client (i.e. 60 FPS real-time). HN may frown on using [m]jpeg for real-time applications today, but in my experience it has proven to be a very robust path. Bandwidth is really the only tradeoff (and it is a big one). This is the very last thing Netflix would want to do (short of sending RAW files to your TV), but it does provide some very compelling attributes in other areas such as streaming gaming.
Our networks are only getting faster over time. Intraframe video compression techniques are really elegant in their simplicity and resilience to motion-induced artifacts (as seen with x264, et. al.). They also can provide lower latency and easier recovery for clients (since every frame is a keyframe).
For real-time applications, I'd happily trade some extra bits per second to have a final result sooner. Especially if it looked better.
If you would transfer raw image data (rgba) you get what for full hd images? Around 7 fps? I don't even want to see the bus for modern smartphone cameras that now seem to casually have around 100 megapixels...
So very fast "on-site" encoding is pretty much mandatory today...
What I really want is to be able to send an initial jpeg keyframe to the client, and then use some application-level heuristic to determine if I should then send a delta-encoded frame (what to change based upon the prior) or another keyframe. For 90%+ of my frames, using a prior frame and indicating deltas would be far more efficient than sending a keyframe each time. Maintaining the previous frames on the server per-client is not a huge deal and would not impact latency if done properly.
I wonder if there is some way I can use jpeg itself to half-ass this sort of approach in the browser. Maybe... encode keyframes at ~80% quality and delta frames at 100% (still not guaranteed, I know). Maybe canvas compositing or simple buffer tricks with bitmaps could get ~95% of the way there. For my application, the pixels don't have to be perfect or accurate to any particular standards.
I'm currently in the process of scanning and archiving lots of photographs as high-resolution 16-bit PNG's and encoding speed is definitely a significant influence on how long this process takes.
The vast majority of use-cases and users barely care about encoding performance. Your use is in the tiny minority. That isn't to say that you don't have a use-case, just that because of how rarely encoding speed matters, it truly is "almost irrelevant" for 99.99% of users 99.99% of the time.
--------------
It definitely would be nice if JPEG-XL also had good encoding performance, though. There's an experimental fast encoder in development currently[1], although before that lands, it would be nice if your scanning tool supported a workflow somewhat like "scan in parallel with image encoding, present encoded images to user, and allow them to asynchronously go back and re-scan/encode/review pages that came out badly".
[1] https://github.com/libjxl/libjxl/tree/main/experimental/fast...
If you're doing this at such a scale that encoding speed matters (like if you're Instagram) the major concern would likely be cost, which you're going to save in bandwidth every time an image is viewed.
How am I going to "throw more CPU power at the problem" when I'm using a scanner hooked up to my laptop? Should I buy myself a new, more powerful laptop? That doesn't sound cheap.
As for "just" waiting... my time is valuable, and I have better things to do with it than wait... and, unfortunately, the process of scanning and encoding needs a lot of babysitting from me, so I can't just dump a bunch of photos in my scanner and come back when it's all over if I want even half-decent results, not to mention archival quality images.
In this real-world scenario, a quicker encoding speed would save me a lot of valuable time, and there's no getting around it short of hiring a skilled and trusted person to do it for me.
The use of intermediate formats is a well proven technique in video editing where encoding real time to AVC/HEVC at high quality is not possible. Codecs like ProRes are used that are much easier to encode to at the expense of storage space.
For context I started a neg scanning project a few years ago, ~150 rolls on an epson v850 (flatbed), and stuck with the default compressed tif after some surface research. There is little chance I would consider another processing step .. unless it was batched on a server somewhere! Very painstaking process, which has been on indefinite hold for a small while now (waiting for the AI to catch up).
In theory, you wouldn't even transmit the SVG directly; you'd zip up the components and send them across the network and then encode them into an SVG on the other end, which would mitigate some of the size increase due to base64 encoding.
Aka if we could find the shortest program that produces the image as output.
Some images obviously would become very small. For example an image that is all blue, a spiral, the flag of the United States, the Mandelbrot set ...
But what about the average portrait for example?
It is worth pointing out that certain formats like AVIF do sort of do this: they use a few different algorithms, see which combination of algo/block split removes the most entropy, and then compress _that_. In practice, this is pretty good for most non-noisy images.
In which case entropy is exactly conserved, unless the encoding is lossy.
Most practical approach is to read the meaning through the respective context and sometimes to ignore the sign...
That said, I believe the parent is correct. Compressed data certainly has a higher entropy. But any additional bit from an image or sound is rarely independent in the first place like Shannon demanded it to be the case for the definition of entropy. That they are not independent is precisely the attack vector of many forms of compression. For example the base frequency of a JPG has more entropy if we use the literal definition than higher frequencies that get removed because they lack entropy in a information technical sense.
For video I personally like Cineform but both ProRes and DNxHD are more widely used
EXR will get you full 32 bit float if needed
edit: Just looked at the specs and JpegXL is definitely marketed at least more as a web end viewing file type. It does higher color depths (up to 16 bit) which is pretty good but will not do 32 bit like EXR. Given that EXR is so widely used I would likely not consider anything else.
Realistically I can see JPEGXL becoming a good DELIVERY format but I highly doubt any industries will be swapping to it for production use (or archiving) given there are very widely adopted formats and standards already that can do the same thing.
I'm almost tempted to say that trying to make ONE format that is meant for both (delivery and production or archiving which are inherently opposites in terms of requirements) is a bad idea just from a marketing and ease of use standpoint. Sometimes its nice to have two clearly separate technologies meant specifically for their purpose.
Likely you get 1/5th of the file size from EXR -- smaller file sizes can improve some web based workflows -- for example when an advertising team is distributed, or partially in work-from-home mode.
Bringing the quality of professional photography to the masses is another thing. Today, mobile phones rarely have too much capacity and many users are fighting with their memory space getting full. There, uncompressed or poorly-compressed formats are not a realistic or cost-efficient option.
I'd imagine the benefits of changing to something more modern/efficient aren't worth the cost/time involved other than in esoteric situations given that most end users have high bandwidth connections and bandwidth costs typically aren't too significant?
So in this case webp was a third of the size of a jpg. Typically, webp will be about 30-50% smaller than an equivalent jpg, which is a pretty significant amount.
Many CDNs automatically serve the best format compatible with the useragent these days!
Also... the bit about the latest version of Chrome is pretty far off. WebP has been usable for 90+% (for my use cases, 99%) of the web for a LONG time. The only thing holding us back was safari 14.0 which is now not on my list of targets!
I wonder how AVIF and JPEG XL would stack up today.
https://patents.google.com/patent/US11234023B2/
https://www.theregister.com/2022/02/17/microsoft_ans_patent/
On lossy JPEG XL wins by 17%: https://twitter.com/jonsneyers/status/1532771586381688833
"Overall for lossy, for the same visual quality, JPEG XL is ~17% smaller than AVIF, which is ~17% smaller than WebP, which is ~17% smaller than JPEG."
Most importantly, Microsoft and Apple don't like the new image format. They are founding members of AOM, but they reject AVIF. Most browsers using Blink engines, including Chrome, support avif, but not Edge. Safari? Of course not. Safari is Apple's version of Internet Explorer. The fact that Apple devices cannot use webp efficiently is why many webmasters and service managers still do not adopt webp.
As a more obvious answer I would still go with png and webp since it is most widely supported.
Framing best in terms of file size or encoding speed is a really use-specific framing, and not ideal for preservation.
[1] https://www.loc.gov/preservation/digital/formats/fdd/fdd0005...
Open Source JPEG2000 libraries:
- Grok, last commit 9 hours ago: https://github.com/GrokImageCompression/grok
- JasPer, last commit 5 days ago: https://github.com/jasper-software/jasper
- OpenJPEG, last commit 8 days ago: https://github.com/uclouvain/openjpeg
I didn't try them, but I think you can probably still read your 20 year old JPEG2000 files today without too much problems.
Say you archive hours and hours and hours of footage and photographs in JPEG XL and then in 5 years the industry moves on to something completely different (maybe even worse in terms of specs) like the beta vs VHS thing. In 20 years it will surely be possible to decode those JPEG XL files but if you just want to send one to a friend and they have to jump through hoops to view it then it becomes a pretty big pain in the butt.