[FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

[Michael Niedermayer]

On Sat, Aug 16, 2014 at 11:39:44AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2014-08-14 11:48 GMT+02:00 Christophe Gisquet <christophe.gisquet at gmail.com>:
> > Hi,
> >
> > 2014-08-14 5:01 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> >> On Wed, Aug 13, 2014 at 10:21:54AM +0000, Christophe Gisquet wrote:
> >>>      case 50081:
> >>> +        avctx->pix_fmt = AV_PIX_FMT_BGR24;
> >>> +        break;
> >>
> >> this possibly breaks decoding of
> >> checkerboard_1080p_nuke_bigendian_8bit_noalpha.dpx
> >> the cross in the middle is displayed as cyan while the other samples
> >> have it yellow
> >
> > And DLAD_8b_3c_big.dpx has the reverse :-(
> >
> > I don't know what additional information is missing to correctly
> > decode them, nor if it's an encoder bug.
> >
> > Note: -1994 spec is marked as V1.0 and -2003 one as V2.0, but both
> > specify the scan line boundary thing.
> 
> So I dug a bit more and tried to compare the data. In all cases, image
> data starts at 0x2000.
> 
> In the following, XX is just a placeholder for alignment/readability purpose.
> BE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 94 95 XX 94 95 95 95
> LE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 95 95 XX 95 94 95 94
> BE RGBA:  95 94 95 00 94 95 94 00 95 94 95 00 94 95 94 00
> LE RGBA:  95 95 95 00 94 95 95 00 95 94 94 00 94 95 95 00
> 
> Are those files supposed to be the same data? The RGB24 and RGBA

i did not create these files, so i dont know.
but theres a txt file that says this:

    all the samples in this archive were created by the software Nuke from TheFoundry (http://www.thefoundry.co.uk/products/nuke/).
    they cover all the possible variations of the following settings that Nuke offers:

    - 8/10/12/16 bit
    - big endian / little endian
    - with alpha / without alpha

    i offered those files to Georg Lippitsch in the thread "[PATCH] dpx: fix some stupid typos" on the ffmpeg-devel mailing list to help him work on the dpx decoder. but they will hopefully be useful for other developers, too.

    in case of any issues/questions regarding this upload, just drop me a mail: holger at celluloid-vfx.com

i added hoger to the CC


> versions do not match. When comparing a LE and a BE version, the
> pixels do not seem to match either. How come BE/LE RGBA start with the
> same data for 12 bytes, but then diverge, if they are of opposite
> endianness?
> 
> Am I missing something or are those files somewhat broken anyway? Case
> in point, the reading code doesn't account for endianness and always
> goes through av_image_copy_plane, for all 4 images.



> 
> -- 
> Christophe
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140816/b58519cf/attachment.asc>