cat ~/.bcast5/F_zscale.xml 384 370 <F_ZSCALE w=3840 width=3840 h=2160 height=2160 size="" s="" dither=0 d=0 filter=5 f=5 out_range=0 range=0 r=0 primaries=9 p=9 transfer=15 t=15 matrix=1 m=1 in_range=1 rangein=1 rin=1 primariesin=9 pin=9 transferin=14 tin=14 matrixin=1 min=1 chromal=1 c=1 chromalin=0 cin=0 npl=0.000000 agamma=true param_a=0.000000 param_b=0.000000 threads=0>
Even if I copy your settings, the result doesn't change. The Compositor view turns black no matter what I do. Do you think this is one of “my” problems, or is it related to CinGG's setting? Anyway, zscale isn't really important because there are native plugins that do the same thing. I was just wondering if you could use zscale's color space conversion in the rendering window so you could choose the color space for the final file. Do you think there's any other way to do this? Let me explain why I've been bothering you so much with these silly questions: I thought I could apply Display-Referred color management to the CinGG workflow (which doesn’t have color management). To do this, you need to match the color spaces of the sources (which must be done beforehand and outside of CinGG) with the color space of the Timeline/Compositor (and this can’t be done because, if I understand correctly, only sRGB is visible) and finally with the color space of the rendering file (and I don’t think this is possible either, unless there’s a way to force the color space onto the temporary before starting encoding *). If these three color spaces matched, then we’d be fully in Display-Referred mode, and during color correction, internal conversions and color data loss would be minimized, yielding the best possible result. However, two out of three steps prevent this. Too bad! * One possible approach is to place the native “colorspace” plugin at the end of the plugin chain used for color correction—that is, as the last plugin before rendering.