[Cin] Real fix for 16-bit pngs

[Phyllis Smith]

I did try it on my x86 machine and it did not change the result per ffprobe.
This may be misleading since ffmpeg-4.2 does not seem to even look for le.
That is the disturbing feature.  The probes and header data do not include
be.
This means that all that can happen is that it can create bad data that is
not
decodable by most machines.  If it works on your machine, it is an outlier,
not
the normal condition.  You should test the data your machine generates with:
[root at keystone Downloads]# ls -ltr | tail -1
-rw-r--r--  1 root    root        179184 Mar 24 12:09 sixteen_bits_test2.png
[root at keystone Downloads]# cd /path/cinelerra-5.1/thirdparty/ffmpeg-4.2
[root at keystone Downloads]# ./ffprobe /path/sixteen_bits_test2.png
Input #0, png_pipe, from 'sixteen_bits_test2.png':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: png, rgba64be(pc), 720x576, ixt25 tbr, 25 tbn, 25
tbc
[root at keystone Downloads]# xv seen_bits_test2.png
[root at keystone Downloads]# gimp seen_bits_test2.png
I can't tell if the png seen_bits_test2.png is be or le.
On my machine it is dim and see thru (probably incorrect).
Is it supposed to be right or wrong?

This is what I am using:
What is your os? fc31?
what is your arch?  x86_64 ?
what version of png is in use? libpng16 ?
Since most decoders have a header that records the format (png_info
in this case) it would be good to know how the "endianess" is encoded.  I
do not see any definitions that can support it.  That means it always fails
unless user supplied transformation data is included in the decoder open.

gg

On Tue, Mar 24, 2020 at 11:54 AM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

> В сообщении от Tuesday 24 March 2020 20:35:55 Phyllis Smith написал(а):
> > Andrew,
> > GG writes here:  This is weird.  I have looked into this and Little
> Endian
> > / png / swapping in ffmpeg, libpng.
> > see libpng16-src pnginfo.h, no endian or swap or relevant order params.
> > see ffmpeg-4.2 libavcodec/pngdec.c:618 decode_idat_chunk, only 16be
> formats.
>
> Well, _on BE machine_, it seems, there will be no need to call this.
> But I'm on little x86.
>
> > Little Endian format is not supported in ffmpg.  It is not in any png.h
> > header data.  It only seems to be a user specified transform option.   In
> > other words, you have to tell it not to use the default of big endian
> > (network byte order).  Since this only generates the possibility of a
> fail,
> > I think that the best idea is to remove it as a possibility.   Perhaps
> you
> > should investigate why it is the default on the machine you are using.  I
> > do not see any way it could be normally generated using libpng16 source
> > (the current version used by all os vendors).
>
> I take this code from gimp-2.10 git sources, this works for me.
> ORDER of calls is important.
>
>
> https://github.com/GNOME/gimp/blob/mainline/plug-ins/common/file-png.c
>
> around lines 1823-1828:
>
>
>     if (text)
>       png_set_text (pp, info, text, 1);
>
>
>     png_write_info (pp, info);
>     if (G_BYTE_ORDER == G_LITTLE_ENDIAN)
>       png_set_swap (pp);
>
> Try to save 16 bpp PNG with current git, and with this fix. See the
> difference :/
>
>
>
> >
> >
> > On Tue, Mar 24, 2020 at 6:13 AM Andrew Randrianasulu <
> > randrianasulu at gmail.com> wrote:
> >
> > > Sorry, I apparently send wrong patch - 16 bit pngs were still broken.
> > >
> > > I scratched my head a lot (because it was working!)
> > > and realized I swapped order of calls!
> > >
> > > diff relative to commit 8c43913b9f18a3856bbff826aef96587a32f0470
> > >
> > > diff --git a/cinelerra-5.1/cinelerra/filepng.C
> > > b/cinelerra-5.1/cinelerra/filepng.C
> > > index 4df95f1e..c2e1cf6c 100644
> > > --- a/cinelerra-5.1/cinelerra/filepng.C
> > > +++ b/cinelerra-5.1/cinelerra/filepng.C
> > > @@ -229,9 +229,9 @@ int FilePNG::write_frame(VFrame *frame, VFrame
> *data,
> > > FrameWriterUnit *unit)
> > >                                 asset->png_use_alpha ?
> > > PNG_COLOR_TYPE_RGB_ALPHA : PNG_COLOR_TYPE_RGB,
> > >                                 PNG_INTERLACE_NONE,
> > > PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);
> > >  // does not work (gg 2020/03/17 libpng16 fc31)
> > > +                       png_write_info(png_ptr, info_ptr);
> > >                         if( asset->png_depth == 16 &&
> > > BC_Resources::little_endian )
> > >                                 png_set_swap(png_ptr);
> > > -                       png_write_info(png_ptr, info_ptr);
> > >                         png_write_image(png_ptr,
> output_frame->get_rows());
> > >                         png_write_end(png_ptr, info_ptr);
> > >                         result = 0;
> > >
> > > this way it SHOULD work .... Tested!
> > >
> > > Also, hint for ccache:
> > > in .ccache/ccache.conf set for maximum compression
> > >
> > > compression = true
> > > compression_level = 8
> > > --
> > > 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/20200324/01174d34/attachment.html>