[Cin] OpenEXR 2.4.1 - still with CMake

[Phyllis Smith]

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:
>
>
> 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
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20200316/6ee07266/attachment-0001.html>