<div dir="ltr"><div class="gmail_default" style="font-size:small">Andrew, we forwarded email about the cmake / openexr problem we encountered and a response from that team. Hope it is relevant.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 15, 2020 at 7:25 AM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Not sure if reposting those news actually good idea or not <br>
but I have their github open next to Cin bugtracker<br>
<br>
I remember OpenEXR 2.3.x was reverted due to cmake build system conversion<br>
[it was 2.4.0, wrong memory!]<br>
<br>
At 2.4.x they still with CMake, but at least some bugs were fixed:<br>
<br>
<a href="https://github.com/AcademySoftwareFoundation/openexr/blob/master/CHANGES.md#version-241-february-11-2020" rel="noreferrer" target="_blank">https://github.com/AcademySoftwareFoundation/openexr/blob/master/CHANGES.md#version-241-february-11-2020</a><br>
<br>
<br>
Version 2.4.1 (February 11, 2020)<br>
<br>
Patch release with minor bug fixes.<br>
Summary<br>
<br>
Various fixes for memory leaks and invalid memory accesses<br>
Various fixes for integer overflow with large images.<br>
Various cmake fixes for build/install of python modules.<br>
ImfMisc.h is no longer installed, since it's a private header.<br>
<br>
from changelog ...<br>
<br>
Fix overzealous removal of if statements breaking all builds except win32 <br>
Re-enable Boost_NO_BOOST_CMAKE by default, document, clean up status messages <br>
Take DESTDIR into account when creating library symlinks<br>
<br>
Version 2.4.0 (September 19, 2019)<br>
Summary<br>
<br>
Completely re-written CMake configuration files<br>
Improved support for building on Windows, via CMake<br>
Improved support for building on macOS, via CMake<br>
All code compiles without warnings on gcc, clang, msvc<br>
Cleanup of license and copyright notices<br>
floating-point exception handling is disabled by default<br>
New Slice::Make method to reliably compute base pointer for a slice.<br>
Miscellaneous bug fixes<br>
<br>
ah, 2.4.0 was exactly reverted in september, 2019 for CinelerraGG.<br>
<br>
So, I'm doing more experiments with image sequences.<br>
<br>
It seems PNG is limited to 8-bit per pixel + alpha (at least in current Cin)<br>
In theory PNG supports 16 bit per sample integer formats ...<br>
<a href="http://www.libpng.org/pub/png/spec/1.2/PNG-Contents.html" rel="noreferrer" target="_blank">http://www.libpng.org/pub/png/spec/1.2/PNG-Contents.html</a><br>
<br>
JPEG is also 8-bit only<br>
But both of above compiles fast! And they exactly use a lot of CPU in parallel, writing<br>
their index file (*.jpgs) at last moment, just as I hypothetized earlier.<br>
<br>
TIFF can create 32-bit per pixel floating-point images, they can be viewed in Gimp 2.10.18<br>
but they are HUGE, like 32 MB for 1920x1080 image!<br>
<br>
It seems libtiff can compress with few algos, but not sure how many other apps<br>
can support those?<br>
<br>
<a href="https://www.awaresystems.be/imaging/tiff/tifftags/compression.html" rel="noreferrer" target="_blank">https://www.awaresystems.be/imaging/tiff/tifftags/compression.html</a><br>
COMPRESSION_PIXARFILM = 32908;<br>
COMPRESSION_PIXARLOG = 32909;<br>
COMPRESSION_DEFLATE = 32946;<br>
COMPRESSION_ADOBE_DEFLATE = 8;<br>
<br>
something to experiment with, too!<br>
<br>
OpenEXR compressions:<br>
compression: pxr24 is slowest, at least for me.<br>
7-10 min for 300-344 fullHD rgba-float images!<br>
around 3Mb per file<br>
<br>
compression: piz<br>
up to 4, 4.5 Mb per file<br>
but faster - 4 min (4 min 16 sec on second try))<br>
for 344 images at 2.6 Ghz!<br>
cpu util: around 140%<br>
<br>
compression: zip<br>
So far up to 4.1 Mb per file<br>
7 min 48 sec for 344 fullHD files at 2.6Ghz, 4-way <br>
<br>
compression: zips<br>
easily up to 6Mb files!<br>
8 min 01 sec!<br>
<br>
compression: rle<br>
nearly as big as TIFF, nearly 32 Mb per file!<br>
It seems my tmpfs will be overflooded<br>
with 344 of them, and ..<br>
yeah CinGG gives NO WARNING about 0-sized OpenEXR files, <br>
so speed is irrelevant. (2 min 38 sec, but only 84 files<br>
written, for 2,693,421 Kbytes! )<br>
<br>
Possible BUG! Shouldn't user be warned about data loss?<br>
<br>
<br>
It seems CinGG tries to compress 2 OpenEXR files at a time,<br>
by looking at directory with images via midnight commander <br>
(I can see briefly two 0-sized files). This is on 4-cpu machine.<br>
<br>
Yet, CPU utilization just hovers around 120% ..may be I need<br>
restart after upping image cache value from 16 mb to 256?<br>
(16 was clearly not enough for fullHD rgba-float frame)<br>
<br>
Utilization was up to 150% with rle OpenEXR compression,<br>
but for me this one hardly compress. may be on synthetic/rendered iamges ....<br>
<br>
Note, those numbers were done with CinGG's version of OpenEXR libs, NOT<br>
2.4.1! I only announced my find of this release at the very start.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>