[Cin] Colour profiles in photo

[Andrew Randrianasulu]

чт, 4 авг. 2022 г., 14:36 Andrew Randrianasulu <randrianasulu at gmail.com>:

> https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html
>
>
> It seems not all icc profiles are the same ...
>
>
> 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)
>
> 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.
>
> 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 ...
>
> 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 ..
>
> I'll try to find simpler lcms2 examples ...
>



Does this example count as useful tutorial?

https://stackoverflow.com/questions/22561176/lcms2-convert-cmyk-to-rgb-through-profiles-in-c-help-on-input-output-values

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 ....

I also was reading ninedegreesbelow.com articles on color spaces and it
seems some of our trouble with blend modes with text and fades caused by
(missing?) linearization, see

https://ninedegreesbelow.com/photography/test-for-linear-processing.html

I did some hack for normal blend mode using code from stackoverflow and
code posted in our bugzilla

See
https://www.cinelerra-gg.org/bugtracker/view.php?id=559

So, in theory this (fast) linearization step should be added to all modes,
or at image-reading stage only?

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 ...



> 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 ...)
>

http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/250398.html


> 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?)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220805/b2fc5777/attachment.htm>