mirror of
https://github.com/blender/blender
synced 2026-10-25 03:07:01 +03:00
VSE by default uses sRGB color space, and was immediately converting everything into it. In some cases that created redundant colorspace conversions. Now, all images are converted into sequencer (default sRGB) color space only "when needed", which is these cases: - Strip has non-default color multiplier or color saturation setting, - Strip has "make float" option on, and input is not already float, - Image is an input to a non-compositor effect, - Image needs to be blended with result of lower channels, - Non-compositor modifier *without* using "linear modifiers" option. Note: this is not 100% backwards compatible change, because strip scale or rotation does *not* cause it to get converted to sequencer color space. This only affects strips where images are not already sRGB; now the pixels will be filtered in their current color space. Arguably when that color space is linear, that is *more correct* result than previously, but it can change the result ever so slightly (example image in the PR). Performance (Ryzen 5950X / RTX 3080Ti, Linux): Scenario A: 100 4K resolution EXR images (1.8GB), just render out this sequence as H.264 movie, no effects, transforms, nothing: 51sec -> 48sec. Scenario B: several simple compositor effects stacked on a strip, plus that is blended with a compositor based procedural texture strip. Playback FPS with GPU compositor: 5.5FPS -> 6.2FPS. Pull Request: https://projects.blender.org/blender/blender/pulls/156281 |
||
|---|---|---|
| .. | ||
| media | ||
| reference | ||
| hdr_input_hlg_12bit.blend | ||
| hdr_input_pq_12bit.blend | ||
| sdr_input_p3_aces_10bit.blend | ||
| video_color_precision.blend | ||
| video_color_spaces_420.blend | ||
| video_color_spaces_444.blend | ||