пн, 14 апр. 2025 г., 15:42 Georgy Salnikov <[email protected]>:
On Fri, 11 Apr 2025, Andrew Randrianasulu wrote:
As far as I understand in this case idea was to embed display profile into media. But few apps outside of Final Cut Pro/quicktime can do anything useful about this info?
It states that instead of more flexible color management video world used few fixed mode monitor color spaces, and whole process was a bit manual if your input image/video was not in one of those.
CMS for photography & publishing is logically coherent. There is input profile, image profile, output profile. The input profiles are that without which it is hardly possible to process RAW input. The profiles embedded into images say nothing about displays, they just are to specify in which colorspace the image data are if they are not in sRGB (and even if it is sRGB, it is common now to embed sRGB into it explicitly). The output profiles are just for the particular output devices (for displays, for printing), they make no assumptions about the nature of the data for their output. Concerning displays, in X11 there are mechanisms long ago to make some color correction, such as xgamma, now it can be done by colord or Argyll, but for the best accuracy the photo processing program itself should do it. Anyway, it is not a big deal: photo processing does not demand real time picture refresh, the math needs not be extremely fast, everything is optimized for highest quality, not for highest speed.
The first problem of CMS for video is the need for the real time visualization, the whole math must be fast. The second is a real zoo of display formats, hardware accelerators, etc.
For example, let's imagine, some external tool like xgamma or colord has the necessary calibration and can, in principle, correct our video on the display.
But what if the user has attached not a DVI monitor, but a real TV to the composite video output, for example, what signal will be generated there by the video card?
These gamma (LUT) corrections are applied through the X11 VidModeExtension. But will they be applied if rendering is done via the Xv extension, for example, or via OpenGL?
Let's imagine, we have implemented some kind of CMS in our program. Then we like, for better efficiency, make use of hardware accelerated video decoding like VDPAU, LIBVA or something like these. Now decoding is done not under control of our implementation, but by some (proprietary) driver/firmware on the video card. And we do not know exactly what happens there.
May be, the safest CMS for video would be to output some good standard picture on the monitor, to adjust it manually for the most precise colors, and then use these adjustments untouched. Like many years ago I ran some tools for adjustments of xgamma, but actually adjusted not xgamma parameters, but the CRT monitor settings themselves.
Perhaps, I am a pessimist...
Well, even well-understood need for photo color management only surfaced in gimp 2.8 (?) in around 2007 or 8, even there it was not very simple task! Booted my imaged self-compiled live cd from around 2007 on qemu and even real hardware, with gimp 2.2 and cinelerra-cv r958, had some fun throwing screencapture mov file between various tools. x264 was so much faster in 2007! ;) Unfortunately there is quite a rift between users who need this functionality and engineers who implement it (I am fairly sure fine people from Blackmagic do not give free advice on the web on how to outdo their main work ;) ) OCIO 2.0 from what I recall can use hw (opencl for accuracy?) acceleration but I think whole ocio way of doing things also different from lcms2. May be I can ask on our big black (with black theme) Linux forum what steps exactly ppl perform if they need color managed video workflow, but we have like <1000 active participants there, looking at various survey results, so question may miss intended audience. _______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected]
_______________________________________________________________________________