[Cin] OpenEXR 2.4.1 - still with CMake

[Andrew Randrianasulu]

В сообщении от Monday 16 March 2020 19:14:29 Phyllis Smith написал(а):
> Andrew, we forwarded email about the cmake / openexr problem we encountered
> and a response from that team.  Hope it is relevant.

Yes, I see. Autoconf still supported! :} 
I mean, *I* have new enough Cmake locally, but not all distributions you build on 
actually provide updated Cmake, as far as I understand ...

I'll try to add this DWA compression slider, and then try to manually 
update OpenEXR libs in thirdparty, but probably not right now
(my productivity is very low, for some reason)

> 
> 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
> >
>