YUV / YCbCr to RGB Histogram Gaps?

[troy_s]

When attempting to create an RGB conversion from YUV / YCbCr AVI file, the resultant image appears to exhibit gaps in the histogram values.

The most rudimentary attempt from a YUV encoded H264 series fails to provide a smooth histogram and results in approximately 35 notable gaps in the channels:

Code: Select all

convert MVI_0000.AVI[0] out.tiff

More complicated attempts including use of a colorspace component also deliver gap filled histograms. It seems no amount of sampling or depth can provide smoothed histograms:

Code: Select all

convert MVI_0000.AVI[0] -colorspace ycbcr -sampling-factor 4:4:4 -depth 16 -size 1920x1088 -interlace plane out.ycbcr

Even raw decomposing and recomposing in compositing software exhibits these gaps:

Code: Select all

convert MVI_0000.AVI -colorspace ycbcr 

Resultant images appear to exhibit this behavior in all situations, despite more accurate representations achieved via other tools.

Is it possible that all of the YUV / YCbCr transforms make the (erroneous) assumption that the data is pre-clamped to analog 16-235 values and stretching the 16-235 values to 0-255?

If this is the case, is there a flag to assert that unclamped maximum / full range is extracted? In theory, there should be 10 effective bits of data available in 4:2:2 data, and as such, it would seem logical to be able to extract all of the available data, perhaps more so considering the extremely deep bit depths that Imagemagick can account for? What about deeper YCbCr bit depths such as 4:4:4?

Apologies in advance if I have made a gross mistake.

[magick]

Post a URL to MVI_0000.AVI so we can download it and reproduce the problem. We'll investigate and report back.

[troy_s]

Thanks for the fantastic response time.

I have the original source file as well as a -vcodec copy AVI version. There is zero difference aside from wrapper, but it is a required step as Imagemagick can only ingest AVI wrappers.

The files are 1920x1088 in resolution. Note the 1088 which is a nuance of the Canon 7D and 5D lines. They are also ~20 megs each, so perhaps not the greatest file to download if you are a mobile data restrictive plan.

The original source MOV - http://sample-images.s3.amazonaws.com/MVI_2266.MOV
The -vcodec copy AVI wrapper shifted version for Imagemagick ingestion - http://sample-images.s3.amazonaws.com/MVI_2266.AVI

It should be noted that this issue appears to be restricted only from AVI extraction, as it is possible to get better results from RGB still images via conversion to YCbCr.

[magick]

We're seeing a reasonable continuous histogram from MVI_2266.AVI. Which version of ImageMagick are you using? Older versions of ImageMagick include a native AVI decoder. Recent versions rely on the external ffmpeg delegate program. Post your ImageMagick version and image histogram here so we can compare against our results. Also post the output of this command:

• identify -verbose out.tiff

We get:

• Channel statistics:
  Red:
  min: 5 (0.0196078)
  max: 255 (1)
  mean: 178.44 (0.699766)
  standard deviation: 55.2693 (0.216742)
  kurtosis: -0.567618
  skewness: -0.603145
  Green:
  min: 18 (0.0705882)
  max: 255 (1)
  mean: 158.816 (0.622808)
  standard deviation: 51.4183 (0.20164)
  kurtosis: -0.860158
  skewness: -0.127285
  Blue:
  min: 0 (0)
  max: 255 (1)
  mean: 129.82 (0.509097)
  standard deviation: 52.0386 (0.204073)
  kurtosis: -0.979564
  skewness: -0.00629673

[troy_s]

http://img17.imageshack.us/img17/7922/histqt.jpg

From the above analysis, it should be clear that there appears to be some stretching appearing in Imagemagick's transform.

The source appears to be treated as a clamped 16-235 series of values. The resultant transformation to 16-235 is being stretched into the 0-255 domain, which is according to most standard display guidelines I believe. However, the error is in the assumption that the source is 16-235, which in this case is an incorrect assumption. The histogram should provide a smooth distribution.

If IM is using ffmpeg under the hood, the attribute should be AVCOL_RANGE_JPEG to assure full range extraction I believe. I believe it also must assert that the proper colour space is applied for the transform to be accurate. This may include colour primaries.

Further still, I don't believe ffmpeg can extract greater than 8 bits of information per channel, which should likely be reflected in depth requests in Imagemagick.

[troy_s]

Apologies. Tested against SVN 3220.

[magick]

Try this command:

• convert 'MVI_2266.MOV[0]' histogram:'MVI_2266.gif'

We get a smooth histogram. If it shows discontinuities, check your release of ffmpeg. We're running version SVN-r24044.