Page MenuHome

importing from sYCC image formats clips away extended-range RGBdata
Closed, ArchivedPublic

Description

for sYCC (YUV, YCbCr) images, where the luminance isn't clipped
it is possible for the channels to become so when converting to RGB-spaces

digital-camera images are exif2 JPG examples are examples
color-channel clipping loss is esp evident for blues
since it more likely to hit ceiling for those colors for a given Y(luminance)

if they were processed as a floats similar to HDR's to not waste that data,
also may affect video analysis e.g. motion tracking-accuracy.

since it's a (YCC of a sRGB) should you note the sRGB pseudo-gamma curve and how negative values are handled (color outside 709RGB gamut)
specification info xvYCC: 2006 Standard for Video Systems using Extended-Gamut YCC Color Space
diagrams:

Details

Type
Bug

Event Timeline

This is sadly due to the swscale reliance in FFMPEG. Currently, all buffers loaded from codecs are converted to RGB at 8 bits per channel via the swscale library. This likely won't be changing any time in the near future unless the FFMPEG handling is overhauled to load raw YCbCr and let OCIO handle the colour transforms.

Bastien Montagne (mont29) closed this task as Archived.
Bastien Montagne (mont29) claimed this task.

Well, then, thanks for the report, but this is not something we can work on directly, issue could be reported to ffmpeg I guess (though this is primarily a playback library, so not sure how much they care about HDR type of data, on the other hand some HDR video formats are emerging these days, so maybe they'll have to consider the issue for those as well?).

Handling things totally differently in Blender is always a possibility too, but we get out of bugtracker scope here.