<div dir="ltr"><div class="gmail_default" style="font-size:small">I did try it on my x86 machine and it did not change the result per ffprobe.</div><div class="gmail_default" style="font-size:small">This may be misleading since ffmpeg-4.2 does not seem to even look for le.</div><div class="gmail_default" style="font-size:small">That is the disturbing feature.  The probes and header data do not include be.</div><div class="gmail_default" style="font-size:small">This means that all that can happen is that it can create bad data that is not</div><div class="gmail_default" style="font-size:small">decodable by most machines.  If it works on your machine, it is an outlier, not</div><div class="gmail_default" style="font-size:small">the normal condition.  You should test the data your machine generates with:</div><div class="gmail_default" style="font-size:small">[root@keystone Downloads]# ls -ltr | tail -1<br>-rw-r--r--  1 root    root        179184 Mar 24 12:09 sixteen_bits_test2.png</div><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="font-size:small">[root@keystone Downloads]# cd /path/cinelerra-5.1/thirdparty/ffmpeg-4.2<br></div></div><div class="gmail_default" style="font-size:small">[root@keystone Downloads]# ./ffprobe /path/sixteen_bits_test2.png<br>Input #0, png_pipe, from 'sixteen_bits_test2.png':<br>  Duration: N/A, bitrate: N/A<br>    Stream #0:0: Video: png, rgba64be(pc), 720x576, ixt25 tbr, 25 tbn, 25 tbc<br>[root@keystone Downloads]# xv seen_bits_test2.png <br></div><div class="gmail_default" style="font-size:small">[root@keystone Downloads]# gimp seen_bits_test2.png <br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="font-size:small"> I can't tell if the png seen_bits_test2.png is be or le.  </div></div><div class="gmail_default" style="font-size:small"><div class="gmail_default" style="font-size:small">On my machine it is dim and see thru (probably incorrect).</div><div class="gmail_default" style="font-size:small">Is it supposed to be right or wrong?</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">This is what I am using:<br></div><div class="gmail_default" style="font-size:small">What is your os? fc31?<br></div><div class="gmail_default" style="font-size:small"> what is your arch?  x86_64 ?<br></div><div class="gmail_default" style="font-size:small">what version of png is in use? libpng16 ?</div><div class="gmail_default" style="font-size:small">Since most decoders have a header that records the format (png_info</div><div class="gmail_default" style="font-size:small">in this case) it would be good to know how the "endianess" is encoded.  I</div><div class="gmail_default" style="font-size:small">do not see any definitions that can support it.  That means it always fails</div><div class="gmail_default" style="font-size:small">unless user supplied transformation data is included in the decoder open.</div><br><div class="gmail_default" style="font-size:small">gg<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 11:54 AM 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">В сообщении от Tuesday 24 March 2020 20:35:55 Phyllis Smith написал(а):<br>
> Andrew,<br>
> GG writes here:  This is weird.  I have looked into this and Little Endian<br>
> / png / swapping in ffmpeg, libpng.<br>
> see libpng16-src pnginfo.h, no endian or swap or relevant order params.<br>
> see ffmpeg-4.2 libavcodec/pngdec.c:618 decode_idat_chunk, only 16be formats.<br>
<br>
Well, _on BE machine_, it seems, there will be no need to call this.<br>
But I'm on little x86.<br>
<br>
> Little Endian format is not supported in ffmpg.  It is not in any png.h<br>
> header data.  It only seems to be a user specified transform option.   In<br>
> other words, you have to tell it not to use the default of big endian<br>
> (network byte order).  Since this only generates the possibility of a fail,<br>
> I think that the best idea is to remove it as a possibility.   Perhaps you<br>
> should investigate why it is the default on the machine you are using.  I<br>
> do not see any way it could be normally generated using libpng16 source<br>
> (the current version used by all os vendors).<br>
<br>
I take this code from gimp-2.10 git sources, this works for me.<br>
ORDER of calls is important.<br>
<br>
<br>
<a href="https://github.com/GNOME/gimp/blob/mainline/plug-ins/common/file-png.c" rel="noreferrer" target="_blank">https://github.com/GNOME/gimp/blob/mainline/plug-ins/common/file-png.c</a><br>
<br>
around lines 1823-1828:<br>
<br>
<br>
    if (text)<br>
      png_set_text (pp, info, text, 1);<br>
<br>
<br>
    png_write_info (pp, info);<br>
    if (G_BYTE_ORDER == G_LITTLE_ENDIAN)<br>
      png_set_swap (pp);<br>
<br>
Try to save 16 bpp PNG with current git, and with this fix. See the difference :/<br>
<br>
<br>
<br>
> <br>
> <br>
> On Tue, Mar 24, 2020 at 6:13 AM Andrew Randrianasulu <<br>
> <a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br>
> <br>
> > Sorry, I apparently send wrong patch - 16 bit pngs were still broken.<br>
> ><br>
> > I scratched my head a lot (because it was working!)<br>
> > and realized I swapped order of calls!<br>
> ><br>
> > diff relative to commit 8c43913b9f18a3856bbff826aef96587a32f0470<br>
> ><br>
> > diff --git a/cinelerra-5.1/cinelerra/filepng.C<br>
> > b/cinelerra-5.1/cinelerra/filepng.C<br>
> > index 4df95f1e..c2e1cf6c 100644<br>
> > --- a/cinelerra-5.1/cinelerra/filepng.C<br>
> > +++ b/cinelerra-5.1/cinelerra/filepng.C<br>
> > @@ -229,9 +229,9 @@ int FilePNG::write_frame(VFrame *frame, VFrame *data,<br>
> > FrameWriterUnit *unit)<br>
> >                                 asset->png_use_alpha ?<br>
> > PNG_COLOR_TYPE_RGB_ALPHA : PNG_COLOR_TYPE_RGB,<br>
> >                                 PNG_INTERLACE_NONE,<br>
> > PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);<br>
> >  // does not work (gg 2020/03/17 libpng16 fc31)<br>
> > +                       png_write_info(png_ptr, info_ptr);<br>
> >                         if( asset->png_depth == 16 &&<br>
> > BC_Resources::little_endian )<br>
> >                                 png_set_swap(png_ptr);<br>
> > -                       png_write_info(png_ptr, info_ptr);<br>
> >                         png_write_image(png_ptr, output_frame->get_rows());<br>
> >                         png_write_end(png_ptr, info_ptr);<br>
> >                         result = 0;<br>
> ><br>
> > this way it SHOULD work .... Tested!<br>
> ><br>
> > Also, hint for ccache:<br>
> > in .ccache/ccache.conf set for maximum compression<br>
> ><br>
> > compression = true<br>
> > compression_level = 8<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>