About evaluating OpenEXR for high-speed images grabbing application scenario.

[huskier]

Hi, Gonzalo,

We use Optronics cameras to grabber images through CoaXPress interface at 500fps rate with the resolution of 2048 by 2048, and we want to save all the images into a single file during grabbing. We've investigated several file formats, such as AVI(Audio Video Interleave), MOV(QuickTime File Format), DPX(Digital Picture Exchange) etc. We've found that OpenEXR is promising, but we are quite unfamiliar with OpenEXR. We would appreciate your suggestions whether the OpenEXR is suitable for our application scenario. If not, do you have any recommendations on file formats for our scenario?

BTW, do you have multipart OpenEXR example images?(#2) Could you please share the files for us?

[ggarra13]

We've found that OpenEXR is promising, but we are quite unfamiliar with OpenEXR.

OpenEXR is a float or half float format HDR image format with a wide choice of compression algorithms. It offers a full-featured C++ API and a faster, not yet complete, C API. OpenEXR is an image format with layers, not a file format to store multiple images under a single file like you specified, thou.

We would appreciate your suggestions whether the OpenEXR is suitable for our application scenario. If not, do you have any recommendations on file formats for our scenario?

You were not very clear on your requirements: if you need to store float or HDR images and whether you want to keep the data uncompromised. If you do, then OpenEXR is indeed your best choice. Saving half floats is probably what you'll want. You will need to evaluate what compression algorithm you choose based on your requirements. None or RLE will not compress much but will be the fastest ones and lossless. DWA/DWB compression will be slower but will give you the smallest file sizes for streaming, for example, as they are lossy (data is lost). PIZ, ZIP(S) are a lossless compromise and will probably be in the middle ground in terms of speed/file size. You can play with mrv2's Save OpenEXR to see the difference of each compression format.

Also, if you want the fastest speed with OpenEXRs, you may want to use its C API instead of the C++ API. Note that the C API currently does not offer all the bells and whistles of the C++ API, so again, it is a compromise.

If 8-bit or 16-bit images are good enough, saving/loading PNGs may probably still beat OpenEXR in terms of speed, albeit with today's machines' speed, I would probably no longer recommend them. And if you need to stream them, PNGs would soon loose their benefit too.

If you truly need a single file, then looking at movie formats is your only choice. The format of the container (.mov, mp4, .avi, .mkv, etc) does not matter. What matters is what codec you choose. Currently, your best choices are:

• H264
• libvpx
• AV1
• ProRes or Cineform (if you need to keep the least quality loss)

They all offer tradebacks between speed and quality. You may want to play with ffmpeg with them or use mrv2 Save Movie as a starting point for experimentation. Note that H264 and libvpx are currently supported by modern graphics cards for both encoding and decoding, so that's also your best choice for performance (albeit using the CUDA backend is a pain as you have to agree to a LICENSE).

BTW, do you have multipart OpenEXR example images?(#2) Could you please share the files for us?

Sure. Here are some samples:

a multipart, multi-layered sample: https://mega.nz/file/begQSDaC#cYRJGozYob8QvtUesvOxhOTN6R-kdFtBY-w7EWzWxKc

a multipart, multi-layered sample with moving data box: https://mega.nz/file/baginJRL#9uQRitsCF_EIpgvEDJwE-RKWlsJvdz5WM-HLnVFraRo

You can use mrv2 to view them and see their data/display window.

[huskier]

Thank you very much for your comprehensive reply. The information is too much for me to digest. I think I need to do more homework.

Indeed, we have to store the every single bit grabbed by the camera for later investigation. We must keep the data lossless. Our camera image is grayscaled 8-bit depth data. We could save the images in PNG format; however, the hard disk will soon be flooded with the captured PNG images, and it's a messy.

I've checked the multipart OpenEXR sample files provide by you. They are not as my expectation. By multipart, I think that there are multiple parts in the file, and every part can be a normal image. In my opinion, I could save the image sequences into the parts in a single OpenEXR file. In this situation, I think it looks like a container. I am still interested in OpenEXR, and I am keeping open for it.

In the meantime, I am studying the movie formats and the codecs.

[ggarra13]

Indeed, we have to store the every single bit grabbed by the camera for later investigation. We must keep the data lossless.

Okay, then, most movie formats are not what you want, as they loose data. Only a couple of them are lossless. You may find more information of which ones provide lossless codecs here:

https://www.ffmpeg.org/ffmpeg-codecs.html#Video-Encoders

I've checked the multipart OpenEXR sample files provide by you. They are not as my expectation. By multipart, I think that there are multiple parts in the file, and every part can be a normal image.

That's exactly what they are and indeed every part can be a different image (usually, it is a different image layer for compositing which were my examples). With multiparts OpenEXRs, you are limited, to a single integer (int) as maximum number of parts you can have. If you are grabbing 500fps, you might reach its maximum limit.

[ggarra13]

For real-time encoding of grayscale 8-bit images into a single file, you might consider the following codecs:

Motion JPEG-2000: This codec supports lossless compression and grayscale.

ffv1: This is another common option for lossless compression.

NOTE: Neither of these codecs is supported by mrv2.

[huskier]

Thank you for your guidance.

[ggarra13]

I'm curious. What format or codec did you choose in the end? Just send me the info to my ggarra13@gmail.com email if you want to keep private.

[huskier]

Right now, we've chose Norpix Streampix proprietary sequence file format, and we've wroten a homemade C++ class for reading and writing sequence file.

Before this thread, I've also started another thread for suggestions and recommendations. We've learned how to construct multipart EXR files and how to view the individual part in the multipart EXR files. When it comes software ecosystem and the sustainable or on-going developement of the file format, we prefer the OpenEXR format for image sequences saving. We consider to save the images into a multipart EXR file next step.

Thank you for your help for the understanding of the OpenEXR format and also the suggestios/recommendations.