[Cin] OpenEXR 2.4.1 - still with CMake

[Andrew Randrianasulu]

Not sure if reposting those news actually good idea or not 
but I have their github open next to Cin bugtracker

I remember OpenEXR 2.3.x was reverted due to cmake build system conversion
[it was 2.4.0, wrong memory!]

At 2.4.x  they  still with CMake, but at least some bugs were fixed:

 https://github.com/AcademySoftwareFoundation/openexr/blob/master/CHANGES.md#version-241-february-11-2020
     

Version 2.4.1 (February 11, 2020)

Patch release with minor bug fixes.
Summary

    Various fixes for memory leaks and invalid memory accesses
    Various fixes for integer overflow with large images.
    Various cmake fixes for build/install of python modules.
    ImfMisc.h is no longer installed, since it's a private header.

from changelog ...

Fix overzealous removal of if statements breaking all builds except win32 
Re-enable Boost_NO_BOOST_CMAKE by default, document, clean up status messages 
Take DESTDIR into account when creating library symlinks

Version 2.4.0 (September 19, 2019)
Summary

    Completely re-written CMake configuration files
    Improved support for building on Windows, via CMake
    Improved support for building on macOS, via CMake
    All code compiles without warnings on gcc, clang, msvc
    Cleanup of license and copyright notices
    floating-point exception handling is disabled by default
    New Slice::Make method to reliably compute base pointer for a slice.
    Miscellaneous bug fixes

ah, 2.4.0 was exactly reverted in september, 2019 for CinelerraGG.

So, I'm doing more experiments with image sequences.

It seems PNG is limited to 8-bit per pixel + alpha (at least in current Cin)
In theory PNG supports 16 bit per sample integer formats ...
http://www.libpng.org/pub/png/spec/1.2/PNG-Contents.html

JPEG is also 8-bit only
But both of above  compiles fast! And they exactly use a lot of CPU in parallel, writing
their index file (*.jpgs) at last moment, just as I hypothetized earlier.

TIFF can create 32-bit per pixel floating-point images, they can be viewed in Gimp 2.10.18
but they are HUGE, like 32 MB for 1920x1080 image!

It seems libtiff can compress with few algos, but not sure how many other apps
can support those?

https://www.awaresystems.be/imaging/tiff/tifftags/compression.html
COMPRESSION_PIXARFILM = 32908;
 COMPRESSION_PIXARLOG = 32909;
 COMPRESSION_DEFLATE = 32946;
 COMPRESSION_ADOBE_DEFLATE = 8;

something to experiment with, too!

OpenEXR compressions:
compression: pxr24 is slowest, at least for me.
7-10 min for 300-344 fullHD rgba-float images!
around 3Mb per file

compression: piz
up to 4, 4.5 Mb per file
but faster - 4 min (4 min 16 sec on second try))
for 344 images at 2.6 Ghz!
cpu util: around 140%

compression: zip
So far up to 4.1 Mb per file
7 min 48 sec for 344 fullHD files at 2.6Ghz, 4-way 

compression: zips
easily up to 6Mb files!
8 min 01 sec!

compression: rle
nearly as big as TIFF, nearly 32 Mb per file!
It seems my tmpfs will be overflooded
with 344 of them, and ..
yeah CinGG gives NO WARNING about 0-sized OpenEXR files, 
so speed is irrelevant. (2 min 38 sec, but only 84 files
written, for 2,693,421 Kbytes! )

Possible BUG! Shouldn't user be warned about data loss?


It seems CinGG tries to compress 2 OpenEXR files at a time,
by looking at directory with images via midnight commander 
(I can see briefly two 0-sized  files). This is on 4-cpu machine.

Yet, CPU utilization just hovers around 120% ..may be I need
restart after upping image cache value from 16 mb to 256?
(16 was clearly not enough for fullHD rgba-float frame)

Utilization was up to 150% with rle OpenEXR compression,
but for me this one hardly compress. may be on synthetic/rendered iamges ....

Note, those numbers were done with CinGG's version of OpenEXR libs, NOT
2.4.1! I only announced my find of this release at the very start.