OpenEXR Intermediate... Thoughts? Alternatives?

Software
1

Tingopix saves a binned debayered output with stabilization cropping (tiff 1904x1300 16bit x RGB ~15MB) or the sensor raw with the embedded sprocket position (tiff 4064 x 3040 16bit ~ 25MB). The idea is to have a workable half sensor resolution rgb straight out of the scanning, or, when better debaryering and more resolution is needed (16 mm for example), saving the raw and batch process the raw files into a debayered rgb. Either way, with a 16bit depth color pipeline.

I have been using uncompressed tiff, and the resulting full-sensor rgb files are huge! 74MB.
AI suggested the alternative of OpenEXR, and the resulting file (slightly cropped for stabilization) is in the 22 to 29 MB range. I used pyexr as currently not doing anything with opencv.

OpenEXR looks very decent, just see that Rawtherapee does not support it, DarkTable does.
Thoughts? other alternatives?

Thanks!

2

I spent some time thinking about this same question a few months ago. JPEG XL (.jxl files) started to look pretty interesting just for cutting the size of these raw reels on disc in half.

Just for some context: JPEG is from 1992, made for the processing power of computers in 1992. The JPEG 2000 standard never seemed to catch on. JPEG XL was released as a standard in 2022 and supports a lot of different use-cases, both lossy and lossless.

They’ve got a kind of marketing/comparison page that does a nice job of extolling the benefits, here. And it appears to be picking up some industry support: Apple and Adobe already support it pretty broadly. The major browsers have either already deployed it or are in the middle of doing so. The group that controls the PDF standard is adding support for the format, etc.

Notably: there is a lossless, 32-bit mode that beats TIFF by around 50%. And the format is already supported in newer versions of OpenCV. Those were my criteria before it was even a candidate. After that, I’d seen those encoding/decoding speed graphs on the page above (showing the format beating most other formats), which really piqued my interest.

I haven’t gotten so far as actually trying it out yet, but it’s definitely on my radar. It seems to be occupying the “latest and greatest” position at the moment.

I also haven’t tried these, but a quick check seems to indicate that Darktable and RawTherapee both have some support for JXL files now.

3 Likes
3

Thanks @npiegdon, great info. Indeed, JPEG XL is a very attractive option.

I was surprised that Davinci Resolve apparently does not yet support XL… hopefully it will not be long before it does.

Meanwhile, here is a clip (no noise reduction) processed with the entire full sensor pipeline.

Tingopix -> [TIFF-RAW Sensor 16bit] -> 
Debayering/sprocket referenced cropping -> [OpenEXR Float] ->
Davinci Resolve 20 -> h264* 
(* I don't have the studio version yet).
4

Picking up from @npiegdon 's comments about JPEG XL (.jxl) - I too am very interested and excited about the possibilities with this format. I’d be curious to know if anyone here in the forum is actively using it in their scanning pipeline.

To understand the format better, I recommend this article, Beyond RGB: A new image file format efficiently stores invisible light data: New Spectral JPEG XL compression reduces file sizes, making spectral imaging more practical by Benji Edwards. The JPEG XL format uses discrete cosine transform (DCT) to efficiently save files, and as the author says, it can create files 10 - 60 times smaller while still retaining a massive amount of spectral data. I wish I didn’t flunk calculus and I could grasp “the how” of it better… :frowning:

Due to the recent software implementations of JPEG XL in common-use software it is starting to get a little bit more traction and buzz. Firefox 152 has now added support for .jxl (must be enabled in Firefox Labs settings) all browser support for it is listed here on Can I Use?, and I also see that XN View can read and write in .jxl. Blender is working on it. I did some digging and looks like the new Davinci Resolve 21 does not yet support it. Krita, however, does support it now and may be a good place to test what it can do. I think I’ll do a little tinkering and testing with .jxl in Krita myself and report back here. To me, the format seems like a real game changer, but still needs a bit more software support all round.

1 Like
5

Thanks for sharing the information. I hope that Davinci Resolve eventually support it.
For a few months I have been using OpenEXR as intermediate.
Scanner → [sensel-raw] → Post-scanning → [RGB-OpenEXR] → Davinci Resolve → [Distribution]

Certainly would add the option for JXL once supported by Resolve. It is apparently supported by Final Cut Pro, so it may not be long until it becomes more popular.

6

Here are some interesting points for consideration.
I implemented the OpenEXR Precision: HALF which stores each channel as 16-bit half-float (2 bytes).

When implementing JXL throught jxlpy, it uses a 16bit integer (not float option), and the results for the same source are not as expected.

TIFF-16 (uncompressed) → 59.4MB
OpenEXR (precision half) → 26.8MB
JXL → 31.6MB

Now to be fair, if one sets OpenEXR to Precision FULL (32-bit float)…
OpenEXR (precision full) → 85.0MB

I would note that JXL takes about 35 seconds in my vintage 2011 i7, compared to about 5 seconds for OpenEXR (full or half).

So I am probably going to stick to OpenEXR for a while.

Edit: corrected library to jlxpy.

2 Likes
7

I’m assuming that jxlpi is a raspberry pi encoder/decoder. As your results show, OpenEXR is pretty clearly the winner when comparing that use case. Hopefully one day soon jxlpi an encode/decode JXL floating-point pixel data on the pi which would make for some worthwhile testing.

BTW, @PM490 someone left a 2017 i5 in the laundry room the other day as a freebee so I put installed RAM an SSD - I’ll race your 2011 i7 any day… :wink: just sayin’…

8

That would be an interesting race!

The library used is JxlPy, corrected my typo.

1 Like
9

Thanks for the correction @PM490 . Admittedly, the misdirection did send me down a rabbit hole of confusion…

I discovered today that VueScan flatbed scanning software (available on linux, mac, windows) has had .jxl support since version 9.8.51, released Feb 5, 2026. The free version has a watermark but good for testing. The timing is good since I want to start using the .jxl format now and getting used to working with it, and building pipelines. I am in the process of scanning family photos so I will do some .jxl versus .tiff comparisons and see which comes out on top.

1 Like