Ticket #1106 (closed enhancement: worksforme)

Opened 15 months ago

Last modified 14 months ago

10 bit RGB DPX file identified as rgb48le

Reported by: dericed Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: dpx gbr10
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

These DPX image files as 10 bit RGB; however ffmpeg identifies them as rgb48le rather than gbrp10le.

Sample here:  http://www.archive.org/download/Sample10BitRgbDpxFile/00255.dpx

ffmpeg -i 00255.dpx
ffmpeg version N-35294-g2d38081 Copyright (c) 2000-2012 the FFmpeg developers
  built on Mar 12 2012 21:13:33 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-libfreetype --cc=/usr/bin/gcc-4.2 --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libass
  libavutil      51. 42.100 / 51. 42.100
  libavcodec     54. 10.100 / 54. 10.100
  libavformat    54.  2.100 / 54.  2.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 64.101 /  2. 64.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  7.100 /  0.  7.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, image2, from '00255.dpx':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: dpx, rgb48le, 2048x1556 [SAR -1:-1 DAR 512:389], 25 tbr, 25 tbn, 25 tbc
At least one output file must be specified

Change History

comment:1 Changed 15 months ago by cehoyos

  • Status changed from new to open
  • Reproduced by developer set
  • Component changed from undetermined to avcodec
  • Priority changed from normal to wish
  • Keywords dpx gbr10 added
  • Type changed from defect to enhancement

The dpx file is packed RGB and has 10 bits per component and is correctly identified (and transcoded).
At the time the decoder was written, the only colourspace that could save information was RGB48.
This could now be changed to planar GBR10, but I don't think it makes much sense to convert from packed to planar, so I will close this ticket.

Last edited 15 months ago by cehoyos (previous) (diff)

comment:2 Changed 15 months ago by cehoyos

  • Status changed from open to closed
  • Resolution set to worksforme

comment:3 follow-up: ↓ 4 Changed 15 months ago by dericed

When I convert the DPX to raw rgb48le then there is random data in bits 11-16 for each channel. Is the conversion of this DPX to raw rgb48le not a lossless conversion? Where does this extra data come from?
...
OK, looking closer it seems that bits 11-16 are a copy of bits 1-6, so the 10 bit DPX sample decodes to bit:1,2,3,4,5,6,7,8,9,10,1,2,3,4,5,6. Is there a way to prevent this, as it seems to just add noise in the lesser significant bits?

comment:4 in reply to: ↑ 3 Changed 14 months ago by michael

Replying to dericed:

When I convert the DPX to raw rgb48le then there is random data in bits 11-16 for each channel. Is the conversion of this DPX to raw rgb48le not a lossless conversion? Where does this extra data come from?
...
OK, looking closer it seems that bits 11-16 are a copy of bits 1-6, so the 10 bit DPX sample decodes to bit:1,2,3,4,5,6,7,8,9,10,1,2,3,4,5,6. Is there a way to prevent this, as it seems to just add noise in the lesser significant bits?

The bits replication is needed to maintain pure white and pure black. Consider 1bit mono to be converted to lets say 8 bit without replication it would become gray/black.

Note: See TracTickets for help on using tickets.