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.gisq...@gmail.com>: > > Hi, > > > > 2014-08-14 5:01 GMT+02:00 Michael Niedermayer <michae...@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:
hol...@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@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
