[Cin] OpenEXR 2.4.1 - still with CMake
phylsmith2017 at gmail.com
Mon Mar 16 17:14:29 CET 2020
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 <
randrianasulu at gmail.com> 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:
> Version 2.4.1 (February 11, 2020)
> Patch release with minor bug fixes.
> 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
> Take DESTDIR into account when creating library symlinks
> Version 2.4.0 (September 19, 2019)
> 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
> In theory PNG supports 16 bit per sample integer formats ...
> 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
> can support those?
> 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
> Cin at lists.cinelerra-gg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cin