<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">ср, 16 апр. 2025 г., 10:42 Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">gamberucci.andrea@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The ICC/color space relationship is not clear to me (maybe ICC is just<br>
the same color space but more precisely defined and adapted to the<br>
device), however, again for the sheer pleasure of talking about color<br>
without any other purpose, I think that good color management can be<br>
simplified in 4 steps:<br>
1) input with its own Color Space (or ICC). Typically it is the camera<br>
that records in raw (pro), log and ProRes (prosumer) or h264/5<br>
(consumer). All types are profiled; pro and prosumer have multiple<br>
profiles to choose from and can be profiled manually or with LUT. This<br>
is referred to as ICC in the manual case or support for the various<br>
color spaces in the menu-driven case. Consumer cameras have only<br>
encoded the working color space in hardware and you can read it in the<br>
metadata of the produced files. This is because the sensor is always<br>
and only linear (and raw), so in order to have an evaluable and<br>
workable output it is internally transformed into the desired signal<br>
(also via the transfer function or gamma). I think that CinGG users<br>
(interested in color) just need to consider the mediafiles (sources)<br>
we upload having their own color space; it doesn't matter where they<br>
came from and how they were processed (if they don't have any visible<br>
in the metadata it would be better to give them one ourselves before<br>
processing). This is because CinGG has no color management and<br>
therefore cannot customize the input in a specific way (i.e., do color<br>
space transformations automatically). This way is inaccurate because<br>
knowledge of the generic color space does not get to the detail of<br>
profiling, but it is the norm in the consumer environment.<br>
2) Program color space, the result of which is seen in the Compositor<br>
window. It should be as wide as possible to ensure preservation of all<br>
source color data (no clipping). A gamma should also be applied if the<br>
input is log type. In CinGG you might consider transforming the color<br>
space (better with the ffmpeg plugin than the native one, because it<br>
offers more color spaces) to one from “intermediate,” that is, as<br>
large as possible. Then apply all the correction filters we want and<br>
finally we reapply in the effects queue the plugin to transform the<br>
space to that of the display (usually Rec709 with gamma 2.4). It is<br>
independent of the camera and display color spaces; so you have a true<br>
CinGG color management. In Resolve this is done with the CST (Color<br>
Space Transformation) plugin.<br>
3) Display color space. Important because it is what we see in the<br>
Compositor and often it is also what is delivered (but not<br>
necessarily!). It is important that the display is calibrated. I think<br>
there is the same problem as for cameras: is the monitor color data<br>
taken from the EDID or is it better to use profiling? Is the former<br>
case for consumer monitors and the latter for pro monitors?<br>
4) Export the project with a codec and color space suitable for the<br>
destination (delivery). For example, for FullHD TVs (Rec709; 2.4) or<br>
4k (BT2020; 2.4); for monitors and the Internet, the classic Rec709,<br>
2.4 is recommended (if it was the same as set as the program color<br>
space, there will be no color space transformation during rendering);<br>
for cinema, DCI-P3; etc.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">There was idea on l.o.r to put Resolve and cingg to test.</div><div dir="auto"><br></div><div dir="auto">If you come up with step by step how to import example file, apply ffmpeg  chain of (3d)lut, colorspace, colorspace filters to get footage into viewable/workable condition, then tweak render profile so it literally deliver HDR(ish) file, even if as tiff sequence - we will have our end of possible comparison  test covered. It probably will be not fast, due to  cpu only transforms, but hopefully it will serve as proof of concept?</div><div dir="auto"><br></div><div dir="auto">if you have libplacebo installed and system ffmpeg picks it up and it work there - may be it can be convinced to work inside cingg? I do not have working vulkan driver .... while I might check proprietary nvidia driver one more time. </div><div dir="auto"><br></div><div dir="auto">This is long time request, so do not rush ;)</div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>