#1106 closed enhancement (worksforme)
10 bit RGB DPX file identified as rgb48le
Reported by: | dave rice | 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 (4)
comment:1 by , 13 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | dpx gbr10 added |
Priority: | normal → wish |
Reproduced by developer: | set |
Status: | new → open |
Type: | defect → enhancement |
comment:2 by , 13 years ago
Resolution: | → worksforme |
---|---|
Status: | open → closed |
follow-up: 4 comment:3 by , 13 years ago
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 by , 13 years ago
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.
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.