В сообщении от 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 < [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 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