[Cin] The best strategy to render yuv (mpeg, limited range) from yuvj (jpeg, full range)?

[Andrew Randrianasulu]

вт, 3 сент. 2024 г., 21:36 Andrew Randrianasulu <randrianasulu at gmail.com>:

>
>
> вт, 3 сент. 2024 г., 21:10 Andrew Randrianasulu <randrianasulu at gmail.com>:
>
>>
>>
>> вт, 3 сент. 2024 г., 20:13 Tarantas via Cin <cin at lists.cinelerra-gg.org>:
>>
>>> > > Since you're already fighting color banding, the good thing is to
>>> > > 32-bit colors in Settings -> Format -> Color model: RGB(A)-FLOAT.
>>> > > Note this could slow down your playback and rendering.
>>>
>>> Guys, hold on a second. Unfortunately I just discovered the RGB color
>>> model is required for this recipe. The YUV model causes big color
>>> shifts for an unknown reason. Moreover, I found JPEG mode completely
>>> incompatible with YUV color mode, even without any filters or hacks,
>>> and I lost the track of what's going on already.
>>>
>>> Must be just a bug because nobody tested JPEG mode in years.
>>>
>>> Could you please advise me any tool to detect shifts in color channels
>>> in order to compose a proper bug report?
>>
>>
>> one technique from
>>
>> https://news.ycombinator.com/item?id=20037013
>>
>> make all-white png in say gimp (so each point reads as 255 in all
>> channels) then convert it via tool in question (cinelerra-gg in our case)
>> then measure colour values during playback (via colorpicker).
>>
>> it may be that bt709 conversion does not allow full range by definition?
>> (comment from that thread).
>>
>> you can also try non-default pix-fmt (non yuv420p) for final encoding ?
>>
>> cingg use 4:4:4 non-subsampled YUV in YUV mode, may be swscale lib having
>> trouble doing its job here?
>>
>
> I also found two possible sources of full range video -Playstation 5 (at
> least back in 2023) and some GoPROs and other modern h264 based cameras
>
> https://forum.shotcut.org/t/questions-about-color-range/38647/3
>
> https://github.com/HandBrake/HandBrake/issues/2561
>
>
> but may be sticking with artificial images is easier for debugging full =>
> full encoding, then with full = > limited conversion step added on top of
> that.
>


and a bit more, apparently (at least in 2021) ffmpeg's prores encoder was
able to stuff full range yuv data, but official apple decoders might assume
tv range anyway ...

https://www.liftgammagain.com/forum/index.php?threads/full-range-or-head-range-workflow.15933/

so, while prores in general might be good idea, for full range workflow it
may not work with official decoders?


>
>>
>> All I could do now is just to
>>> screenshot the difference between the compose window and render results.
>>> --
>>> Cin mailing list
>>> Cin at lists.cinelerra-gg.org
>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240903/f8f564ee/attachment-0001.htm>