<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><a href="https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html" target="_blank" rel="noreferrer">https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html</a><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">It seems not all icc profiles are the same ...</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I think for cin-gg it makes sense converting from biggest rgba-float (32 bit floating point value per color channel) , and for CVE from 16 bit/channel int format .... (I think back in time Adam deleted int 16 formats from Cinelerra 2.0 as opposed to cin 1.2 saying they were not as good as true 32 fp)</div><div dir="auto"><br></div><div dir="auto">I put some emphasis on opengl output because it offloads some of per-pixel math to graphics hw, but slower sw only mode probably will work as proof of concept.</div><div dir="auto"><br></div><div dir="auto">As far as I understand you even can have colord daemon monitoring hot-plugged output devices incl. monitors and providing associated profile via some api (?) yet I only compiled it and newer used ...</div><div dir="auto"><br></div><div dir="auto">It seems at least two display pathes needed, one for traditional 8 bit displays and another for newer 10 bit ones. i thought because color profiles known and used ever since 1996 or so, 8 bit output can be done first ..</div><div dir="auto"><br></div><div dir="auto">I'll try to find simpler lcms2 examples ...</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Does this example count as useful tutorial?</div><div dir="auto"><br></div><div dir="auto"><a href="https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-through-profiles-in-c-help-on-input-output-values">https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-through-profiles-in-c-help-on-input-output-values</a></div><div dir="auto"><br></div><div dir="auto">It uses rgb to cmyk and two profiles, but hopefully one just can call this with one real and one built-in profile? It was nice to know you can do scanlines with lcms, too ....</div><div dir="auto"><br></div><div dir="auto">I also was reading <a href="http://ninedegreesbelow.com">ninedegreesbelow.com</a> articles on color spaces and it seems some of our trouble with blend modes with text and fades caused by (missing?) linearization, see</div><div dir="auto"><br></div><div dir="auto"><a href="https://ninedegreesbelow.com/photography/test-for-linear-processing.html">https://ninedegreesbelow.com/photography/test-for-linear-processing.html</a></div><div dir="auto"><br></div><div dir="auto">I did some hack for normal blend mode using code from stackoverflow and code posted in our bugzilla</div><div dir="auto"><br></div><div dir="auto">See</div><div dir="auto"><a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=559">https://www.cinelerra-gg.org/bugtracker/view.php?id=559</a></div><div dir="auto"><br></div><div dir="auto">So, in theory this (fast) linearization step should be added to all modes, or at image-reading stage only?</div><div dir="auto"><br></div><div dir="auto">Also, good way to put lcms transform code in our rgb2rgb function (somewhere in guicast? ..but in cingg some of this code python-generated and I do not know python at all ..), just with additional parameters like pointer to in and out profiles? If any of them null then just not execute transform call ...</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Adding profile to some video container hopefully will be not very hard task (i forgot about this patch for ffmpeg's mov muxer from 2019 i talked about in cingg bug ...)</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><a href="http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250398.html">http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250398.html</a></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Input side hopefully already covered by ffmpeg.git patches (input image format icc profile only should matter at decompressing into some pixel array? Because further processing will alter those pixels ...or I am wrong and input media profiles must be somewhat combined during track  compositing?)</div><div dir="auto"><br></div><div dir="auto"><br></div></div>
</blockquote></div></div></div>