Checked in tweaked patches from Andrew - EXR, PNG, and TIFF
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg. What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
В сообщении от Tuesday 17 March 2020 23:08:32 Phyllis Smith написал(а):
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg.
What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
Interesting I see comment about png_set_swap not working on Fedora 31 ... Does it bomb at compile time or later? Because without this function 16 bit per pixel PNG files were wrongly-colored (completely) for me ...
It does not bomb. But ffprobe shows no difference so that it did not work - he verified this with the debugger. GG will turn it back on in the next checkin. On Tue, Mar 17, 2020 at 3:58 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Tuesday 17 March 2020 23:08:32 Phyllis Smith написал(а):
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg.
What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
Interesting I see comment about png_set_swap not working on Fedora 31 ...
Does it bomb at compile time or later?
Because without this function 16 bit per pixel PNG files were wrongly-colored (completely) for me ... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Wednesday 18 March 2020 01:38:48 Phyllis Smith написал(а):
It does not bomb. But ffprobe shows no difference so that it did not work - he verified this with the debugger. GG will turn it back on in the next checkin.
It doesn't show difference in ffporbe, perhaps ..but colors are ..interesting https://imgur.com/a/K8N2bMq
On Tue, Mar 17, 2020 at 3:58 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Tuesday 17 March 2020 23:08:32 Phyllis Smith написал(а):
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg.
What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
Interesting I see comment about png_set_swap not working on Fedora 31 ...
Does it bomb at compile time or later?
Because without this function 16 bit per pixel PNG files were wrongly-colored (completely) for me ... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I get that when I have 16 bits frames displayed in 14 bits E On Wed, 2020-03-18 at 01:44 +0300, Andrew Randrianasulu wrote:
It doesn't show difference in ffporbe, perhaps ..but colors are ..interesting
В сообщении от Tuesday 17 March 2020 23:08:32 Phyllis Smith написал(а):
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg.
What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
Also, minor bug: If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate LANG=C cin Cinelerra Infinity - built: Mar 18 2020 00:35:32 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. RenderFarmClient::main_loop: client started int FileList::read_list_header(): /dev/shm/./EXR1002728.exr:no such file int FileList::read_list_header(): /dev/shm/EXR1.exrs: 322 files not found terminate called after throwing an instance of 'Iex_2_2::EnoentExc' what(): Cannot read image file "/dev/shm/./EXR1002728.exr". No such file or directory. Аварийный останов
uh-oh ! Good that you are testing better than we did. GG moved on to another bug but will get back to this. Keep testing ! On Tue, Mar 17, 2020 at 4:41 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Tuesday 17 March 2020 23:08:32 Phyllis Smith написал(а):
The latest GIT checkin consists of mostly patches that Andrew has been working with a couple of tweaks and other small bugs in other areas by gg.
What you will see for Render choices that new: EXR - choices of B44, B44A, DWAA, DWAB PNG - now has added choices in the render video wrench to include Compression level 0-9 and Depth 8/16 TIFF - new choices of LZW, LZWMA, Deflate We have done minimal testing and probably Andrew will test to make sure we got all of his patches correct!
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
LANG=C cin Cinelerra Infinity - built: Mar 18 2020 00:35:32 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra.
RenderFarmClient::main_loop: client started int FileList::read_list_header(): /dev/shm/./EXR1002728.exr:no such file int FileList::read_list_header(): /dev/shm/EXR1.exrs: 322 files not found terminate called after throwing an instance of 'Iex_2_2::EnoentExc' what(): Cannot read image file "/dev/shm/./EXR1002728.exr". No such file or directory. Аварийный останов -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew:
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
Easily reproduced here. GG says OpenExr is doing a "throw" and Cinelerra normally does not "catch". This would be the very first "catch" in Cinelerra if it would be added and that is not the way gg wants to go unless we absolutely have to. This requires the error handling characteristics of the C++ runtime library. If you do that same thing with a TIFF sequence, it passes the error correctly back to Cinelerra to field instead of crash.
В сообщении от Wednesday 18 March 2020 18:57:25 Phyllis Smith написал(а):
Andrew:
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
Easily reproduced here. GG says OpenExr is doing a "throw" and Cinelerra normally does not "catch". This would be the very first "catch" in Cinelerra if it would be added and that is not the way gg wants to go unless we absolutely have to. This requires the error handling characteristics of the C++ runtime library. If you do that same thing with a TIFF sequence, it passes the error correctly back to Cinelerra to field instead of crash.
H, sorry for such suggestion without patch - but can't be OpenEXR sequence file validated before passing it into library? Of course, on multiproces/user system user may delete files right after they passes test of existence .... May be just document it? :}
Andrew, the latest GIT checkin fixes the crash and provides a warning as you suggested. It works on the latest 2.4.1 version as there were some code improvements over the 2.2.1. Try it now.
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
Easily reproduced here. GG says OpenExr is doing a "throw" and Cinelerra normally does not "catch". This would be the very first "catch" in Cinelerra if it would be added and that is not the way gg wants to go unless we absolutely have to. This requires the error handling characteristics of the C++ runtime library. If you do that same thing with a TIFF sequence, it passes the error correctly back to Cinelerra to field instead of crash.
H, sorry for such suggestion without patch - but can't be OpenEXR sequence file validated before passing it into library?
Of course, on multiproces/user system user may delete files right after they passes test of existence ....
May be just document it? :}
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Saturday 21 March 2020 03:39:18 Phyllis Smith написал(а):
Andrew, the latest GIT checkin fixes the crash and provides a warning as you suggested. It works on the latest 2.4.1 version as there were some code improvements over the 2.2.1. Try it now.
Seems to work (tried to launch just-compiled Cin without waiting for opencv build to finish ...) Still, at 5am I have this brilliant idea about adding nasm to thirdparty/ directory :} of course, real fun will be convincing both x264/x265 and libdav1d (and may be even ffmpeg?) to use it. I'm not sure if just altering PATH will be enough. At least x264 seems to look for $AS, so it not hardcoded there? AS="${AS-nasm}" ffmpeg have this config option: --x86asmexe=EXE use nasm-compatible assembler EXE [$x86asmexe_default] and x265 uses something from Cmake. Still, considering list of distros having nasm 2.10 (!) ..... may be it really worth trying (from NASM_levels.txt attached to BT390)
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
Easily reproduced here. GG says OpenExr is doing a "throw" and Cinelerra normally does not "catch". This would be the very first "catch" in Cinelerra if it would be added and that is not the way gg wants to go unless we absolutely have to. This requires the error handling characteristics of the C++ runtime library. If you do that same thing with a TIFF sequence, it passes the error correctly back to Cinelerra to field instead of crash.
H, sorry for such suggestion without patch - but can't be OpenEXR sequence file validated before passing it into library?
Of course, on multiproces/user system user may delete files right after they passes test of existence ....
May be just document it? :}
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (3)
-
Andrew Randrianasulu -
edouard chalaron -
Phyllis Smith