On 11/05/15 12:32, Moritz Barsnick wrote: > On Mon, May 11, 2015 at 10:59:45 +0100, tim nicholson wrote: >>>> identify -verbose dpx-HD-0001.dpx >>> Image: dpx-HD-0001.dpx >>> Format: DPX (SMPTE 268M-2003 (DPX 2.0)) >>> Geometry: 1920x1080 >>> Class: DirectClass >>> Type: true color >>> Depth: 8 bits-per-pixel component >>> Channel Depths: >>> Red: 8 bits >>> Green: 8 bits >>> Blue: 8 bits > > My age-old identify from ImageMagick says: > [...] > Type: TrueColor > Endianess: MSB > Colorspace: RGB > Depth: 16-bit > Channel depth: > red: 16-bit > green: 16-bit > blue: 16-bit > [...] > > I used this to create the file similar to what you did: > $ ffmpeg -loglevel debug -f lavfi -i testsrc,format=pix_fmts=yuv422p10le > -frames:v 1 -c:v dpx ~/tmp/test.dpx -y
Using that same command line I still get a file that GraphicsMagick claims is 8 bit, *but* like you ImageMagick says 16bit! > >> 25 tbn, 25 tbc" but as graphicsmagik is pretty good I am wondering if it >> is a case of 8 bit in 10bit becoming 8 bit in 16bit. However i would >> expect the padding to be in the lsb not msb or the pictures would be >> very dark. > > "identify" shouldn't worry about whether only 8 MSBs or 8 LSBs of > available 16 bits are used, it should be your own problem if the image > is extremely dark. Unless the format has flags to indicate such usage. > Quite, but I was concerned that the somewhere in the process the image was being down converted to 8 bit. However it looks like its GraphicsMagick at fault here (I've tried BE and LE with same results). Interestingly if I execute "convert -depth 16 ...." ImageMagick gives me a 16bit file from the original , but GraphicsMagick reduces the file to a real 8 bit one! So its definitely got issues. Thanks for the confirmation that it s not ffmpeg. > Moritz > _[..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
