![]() Then we do the tonemapping, and because it now has data that falls outside of the 0.0 - 1.0 range, it can do it's thing and start desaturating the colors where it thinks it's needed.Īfter the tonemapping, we use zscale to go back to 'the usual' SDR config of bt709 gamma transfer, and switch to YUV with bt709 colormatrix (the primaries were already in bt709) and we make sure the go to limited range YUV. This is why we first convert to floating point, so this data isn't lost, it's just out-of-gamut. ![]() Because we're changing from bt2020 to bt709, we actually start to clip the data at very saturated colors. According to the zimg documentation changing primaries need to be done in linear space anyway, and this way we make sure the data is linear first. _Then_ do we tell zscale to change the primaries to bt709. ![]() Then comes the format=gbrpf32le to turn it all into floating-point RGB. But the colorprimarie is basically your colorspace). But the colorprimaries are still in bt2020. The first zscale=t=linear turns the YUV format into linear-space-RGB. (after the whole 'setting the correct input format' thing). Zscale=t=linear,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable,zscale=t=bt709:m=bt709:r=tv There might be a simpler method, but what I do: We tonemap the brightness but not much else. That means the primaries are still in bt2020. You / we never change the color primaries and/or the colormatrix. Think I got the desaturation a bit figured out. Still have the feeling it's a bit too desaturated With all 3 of them you clearly see a bit more detail / local contrast in the water in the opening at that 1 minute opening mark for example. y4m file that (just like the Avisynth reader) has no information on what kind of format the yuv stream is in besides the planar configuration.Įdit: Actually, mobius and hable tonemapping options (even reinhard) don't look that bad now. and the linear information can only be RGB (a 'matrix=rgb' is missing but needed for this apparently). If I do it in a single zscale filter instance, I'm hitting issues that the zscale implementation inside of ffmpeg has no way to convert to RGB. But now, the information of what it is is known in the ffmpeg filter chain, so the next zscale=t=linear will now work (and convert it to gbrpf32le apparently). With the first 'zscale' I'm basically doing a sort of no-op, but I'm telling zscale what kind of input data it is, and I'm telling it to convert it to 'the same'. This works! (man that took some time to figure out :S).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |