[Cin] Patches again - filepng, opencv config

Fri Mar 27 22:11:13 CET 2020

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.

On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

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