<div dir="ltr"><div class="gmail_default" style="font-size:small">Well, gg looked every where he could think of to obviously include libpng and could find absolutely no place where the "endian"ness was stored. Still confused here.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):<br>
> Andrew,<br>
> We have not given up on this yet but really do not understand the png<br>
> little endian issue. When gg looks through the png code it is very<br>
> insistent that with the meaning of png being Portable *Network* Graphics.<br>
> The emphasis on Network does not allow for little endian.<br>
> ------------------------------<br>
> ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses<br>
> the<br>
> ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian,<br>
> ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian,<br>
> ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order<br>
> (big-endian,<br>
> -----------------------------<br>
> Sorry for our confusion; I hope we can get this figured out but all<br>
> indications on our computers and in the code is only Big endian.<br>
<br>
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for <br>
those newly-introduced 16 bit per color channel format, at least in my tests!<br>
<br>
Did you tried to look at Cin PNG output in both cases? <br>
(8 bpc default, 16 - when you select it)<br>
<br>
*Actually, I wish to test on qemu-system-ppc, but this take a lot of time<br>
- because emulated Mac is only single-core ..... and full emulation <br>
easily can slow down your Instructions per second 10x down!<br>
<br>
So, it will be 4x slower by being single core, and 10x at least slower<br>
again due to system emulation (kvm can't help here).. so, 1 hour<br>
will become 40!<br>
<br>
> <br>
> On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu <<br>
> <a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br>
> <br>
> > Sorry for insisting on this filepng part - but it was my work,<br>
> > and I dislike to ship broken feature!<br>
> ><br>
> > I actually tested Cinelerra git on Ubuntu Live DVD, and<br>
> > _16 bit_ pngs were broken there without it.<br>
> ><br>
> > It was as simple as<br>
> > 1) opening the video<br>
> > 2) setting project to rgba-float color format.<br>
> > 3) trying to save png (from non-black area of timeline)<br>
> > and set options to "with alpha, 16 bits".<br>
> ><br>
> > By default Cin adds encoded results into resources and on new tracks -<br>
> > you clearly can see it will be black/broken. 8-bits PNGs are OK.<br>
> ><br>
> > Ubuntu image I used:<br>
> > <a href="http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/" rel="noreferrer" target="_blank">http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/</a><br>
> > xubuntu-18.04.4-desktop-amd64.iso<br>
> > <<a href="http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso" rel="noreferrer" target="_blank">http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso</a>><br>
> > - 1.4 Gb<br>
> ><br>
> > Then I created 4 Gb file in tmpfs, formatted it with btrfs with<br>
> > compression, and booted Live image:<br>
> ><br>
> > guest@slax:/dev/shm$ wget<br>
> > <a href="http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso" rel="noreferrer" target="_blank">http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso</a><br>
> > --2020-03-25<br>
> > <<a href="http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25" rel="noreferrer" target="_blank">http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25</a>><br>
> > 13:55:42--<br>
> > <a href="http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso" rel="noreferrer" target="_blank">http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso</a><br>
> > Распознаётся <a href="http://mirror.yandex.ru" rel="noreferrer" target="_blank">mirror.yandex.ru</a>… 213.180.204.183, 2a02:6b8::183<br>
> > Подключение к <a href="http://mirror.yandex.ru" rel="noreferrer" target="_blank">mirror.yandex.ru</a>|213.180.204.183|:80... соединение<br>
> > установлено.<br>
> > HTTP-запрос отправлен. Ожидание ответа… 200 OK<br>
> > Длина: 1534459904 (1,4G) [application/octet-stream]<br>
> > Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»<br>
> ><br>
> > xubuntu-18.04.4-desktop-amd64.iso<br>
> > 100%[==============================================================================================================>]<br>
> > 1,43G 8,26MB/s за 6m 40s<br>
> ><br>
> > 2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso»<br>
> > сохранён [1534459904/1534459904]<br>
> ><br>
> > guest@slax:/dev/shm$ qemu-sy<br>
> > qemu-system-aarch64 qemu-system-i386 qemu-system-mips<br>
> > qemu-system-nios2 qemu-system-riscv64<br>
> > qemu-system-sparc64 qemu-system-xtensaeb<br>
> > qemu-system-alpha qemu-system-lm32 qemu-system-mips64<br>
> > qemu-system-or1k qemu-system-s390x qemu-system-tricore<br>
> > qemu-system-arm qemu-system-m68k qemu-system-mips64el<br>
> > qemu-system-ppc qemu-system-sh4<br>
> > qemu-system-unicore32<br>
> > qemu-system-cris qemu-system-microblaze qemu-system-mipsel<br>
> > qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64<br>
> > qemu-system-hppa qemu-system-microblazeel qemu-system-moxie<br>
> > qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa<br>
> > guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on<br>
> > -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso<br>
> > qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate<br>
> > memory<br>
> > guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on<br>
> > -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso<br>
> > guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on<br>
> > -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm<br>
> > -smp 3<br>
> > guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on<br>
> > -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm<br>
> > -smp 3<br>
> > guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M<br>
> > 4194304+0 записей получено<br>
> > 4194304+0 записей отправлено<br>
> > 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s<br>
> > guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on<br>
> > -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm<br>
> > -smp 4 -hda 4Gb<br>
> > WARNING: Image format was not specified for '4Gb' and probing guessed raw.<br>
> > Automatically detecting the format is dangerous for raw images,<br>
> > write operations on block 0 will be restricted.<br>
> > Specify the 'raw' format explicitly to remove the restrictions.<br>
> ><br>
> > in just a hour I had compiled Cinelerra (by copying git tree from host<br>
> > BEFORE launching qemu)<br>
> ><br>
> > Note, in such mem-restricted VM you want to use zram (not default in this<br>
> > ubuntu flavor):<br>
> > as root<br>
> > modprobe zram<br>
> > echo 1000000000 > /sys/block/zram0/disksize<br>
> > mkswap /dev/zram0<br>
> > swapon /dev/zram0<br>
> ><br>
> > this will create 1Gb sized compressed swap in ram<br>
> ><br>
> > I even send email from this virtual setup, but it apparently was stuck in<br>
> > moderation<br>
> > due to size (over 750 kb).<br>
> ><br>
> > NOW, I found something really weird!<br>
> > Patch as attached worked on 64-bit Ubuntu,<br>
> > but for my system I *must*<br>
> > place this call to png_set_swap(png_ptr); differently, not before<br>
> > png_write_info(png_ptr, info_ptr);<br>
> > but AFTER! I actually left both there ....<br>
> ><br>
> > Still, this is something strange, I'll try to contact libpng author about<br>
> > this.....<br>
> ><br>
> > Also, I attach my current OpenCV tweaks - trim out unneeded stuff,<br>
> > fixing two typos, adding -stdc++11 line for my odd system.<br>
> ><br>
> > I still use opencv-20180401.tgz<br>
> ><br>
> > I also have two lame (mp3lame) patches, but will send them separately.<br>
> > --<br>
> > Cin mailing list<br>
> > <a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
> > <a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
> ><br>
> <br>
<br>
<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>