[Cin] "Unbounded" floating point image manipulation

[Andrew Randrianasulu]

чт, 3 апр. 2025 г., 21:39 Andrea paz <gamberucci.andrea at gmail.com>:

> Sorry to belabor my requests, but color is a topic that has always
> interested me, from the days of Photoshop 3.0 and then Gimp...
> The following link is interesting:
> https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html
> However, it is more suitable for image manipulation than for video
> editing, where there are complications. So it is not appropriate in
> our discussion.
>
> However, when I was asking about the operation of the Color Space
> plugin/Tool, it was to know if CinGG uses the “std formulas” used in
> video productions. I will elaborate, but first I would like to pay
> attention to the color models (RGB, YUV, and HSV) which are infinite
> (although in fact artificially limited to the possibilities of human
> vision) and the color spaces which are a fraction of that. The limits
> of color spaces arise from the need not to exceed the hardware limits
> of the devices (gamut). These limits have become std and consequently
> so have the formulas for conversion between color spaces. Not that
> there are not infinite other formulas, but often, for example for
> YCbCr --> sRGB, the same formula is mainly used (see Poynton:
>
> https://wangwei1237.github.io/shares/Digital_Video_and_HD_Algorithms_and_Interfaces_2nd_ed.pdf
> ).
> Here, I was wondering if CinGG uses these std formulas that are also
> the basis of the LUTs used in CMSs, or does it have its own. If it
> used the same formulas, I would dream of one day getting to color
> management inside CinGG.
>



I think original Cinelerra get floating point modes for exactly avoiding
clipping ussues in pipeline, among other things. No  CMS, but everything
was in linear gamma (so no gamma compression as in sRGB, it really breaks
compositing, from my understanding of thread I linked) Then when overlay
modes were added in cingg assumption that you must clip to defined 0-1.0
range sneaked in. We removed some of it lately, but run into problem when
such limiting might be unavoidable due to ways algorithms work.

So, simplest manual "CMS" probably will  be just lcms2 plugin working in
32fp and picking up display icc profile, and may be file input icc profile
(so you apply it manually at input first and at very end of compositing
second).

But so far no one wrote such plugin!

And of course ffmpeg was feeding us at best 16bit integers, so already
pre-clipped to some range (if decoding in principle capable of producing fp
values .. like MLV format? ), but may be it will be adjustable in future
ffmpeg versions?

Unfortunately, I am not very convincing/knowledgeable person, so my
attempts to bring this to ffmpeg devs attention  failed.

Some parts of puzzle now should be there in ffmpeg-git, but I haven't tried
to rebuild cin  on top of that, yet.

Fighting with official pre-made  Arch qcow hdd image, so far I chrooted
into it from livedvd under qemu (there is problem with APIC for some
reason? noapic to kernel command line fixed that), run into keys problem,
run "pacman-key --populate archlinux " after pacman-key --init, updated
with pacman -Syu, installed bunch of packages with pacman -S packagename,
verified I have cmake 4.0.0 ... and learned there is no startx yet! Right
now I work via VNC to qemu machine running Arch in framebuffer console
mode, probably will retry from real X session on host because default
screens resolution a bit too big for portraint-oriented tablet screen!


So ... Some steps done, more to do!

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20250404/7abaa918/attachment.htm>