Andrew, we forwarded email about the cmake / openexr problem we encountered and a response from that team. Hope it is relevant.
On Sun, Mar 15, 2020 at 7:25 AM Andrew Randrianasulu < [email protected]> wrote: > 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. > > > > > > > > -- > Cin mailing list > [email protected] > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
