Preferably in Python and preferably on Linux (I do not care one iota about this working on Windows).
For example, color managed programs somehow know how to convert colors to your monitor’s profile before sending images to the screen, but where are they getting that?
Is there a standard place that the display profile is kept? What about when you move the window to another monitor?
The PIL library on Python has an experimental function for getting the display profile but it doesn’t work on my system. I’d like the program I’m running to display a properly color-managed view and while I know how to hard-code in my own monitor profile I don’t know how to find it generically.
In rawproc I use LittleCMS and the C interface. LittleCMS will read an icc profile from either a file or a memory blob into its internal format, then allow you to do transforms with it either as a source or destination profile, depending on if the profile supports the desired direction. The memory blob alternative allows you to extract an embedded profile from an image and pass it to LittleCMS as if you had opened it as a profile file.
That project appears to be dead (its bitbucket is a 404), but I’m willing to give it a try. Do you know how to get the display profile though? I can already get an image’s embedded profile (or open and close profiles on disk) with ImageCms. What I need is to know what the ICC profile of the monitor is so I can write a color-managed application.
It’s limited to 8-bit color (16-bit monochrome). colour is what I use for color work, it goes up to double precision. The function RGB_to_RGB converts to/from just about any RGB color space you can think of, and you can generate custom ones from the chromaticities of the primaries and white point (and CCTF functions if any).
But what I really need is some way to know what the monitor’s ICC profile is so I can convert to that when displaying an image.
In rawproc I just load the display profile directly from a directory where I keep all the ICC profiles I use. If you want to use the OS color management facilities, someone else will have to weigh in, I’m not familiar with them.
You mean your own personal display’s profile? Or is your software meant to run on a system that always puts the in-use profile files in a particular directory? Or something?
Okay, so I make my own display profiles. I put the profile files in a directory with all the other ICC profiles (camera, export, etc) I want my program to access, and I put the profile filenames in the appropriate property setting in my software. So, when the software renders an image to the display, it transforms it from whatever color/tone is assigned to the image to the display color/tone for rendering on the screen.
This is NOT what the operating system would have you do, it would maintain the display profiles in its own directory and provide their path to the program when requested. I decided early on to just do my own profile management, and make sure I’m rendering straight to the screen, no intervening OS shenanigans…
Because I do the whole thing, soup-to-nuts, in my software. Particularly, I do the color transform that turns the image from its internal gamut to the display gamut, then I rely on the image render functions of wxWidgets to blat the pixels to the screen, without further modification.
To my knowledge, X11 “color management” simply supplies the file name/path of a display profile to the application software, and it’s the app’s responsibility to do the transform. I guess I could use that mechanism, but I want my software to also work with Windows (which looks like it does the same as X11), so I just do it one way in my software. The display profile
path is contained in the property display.cms.displayprofile*, so every time my software renders the display image, it does color transform to the appropriate display profile.
Wayland worries me, as I think it wants to assume doing this display transform. Don’t feel like figuring all that out…
* For multiple displays, I later added display.cms.displayprofile:N, where N is the wxWidgets display number, so for my dual-display desktop I have two properties, one for each display.
I’m still confused by how you actually control the display profile through your own code, I thought that was a system level change that ordinary programs couldn’t do.
There may well be a standard directory for X11 where the display profile is kept but I want to be Wayland compatible since that’s the future (it just recently got good enough to work well for me without crippling issues).
I don’t care about supporting Windows, since my project is primarily for my own use. I have to do that at work and I don’t like it. I don’t like having to make all those little exceptions to the code because DOS decided to be different forty years ago. No offense but I don’t know why anybody would voluntarily use Windows as their working OS for programming work if they weren’t forced to by their employer, it’s so ill-suited to programming. It only recently got a halfway decent shell, but WHATEVER, it’s their choice. I could understand if all of their programming was strictly in a self-contained environment like MATLAB or Mathematica, but otherwise…
That’s actually somewhat of a problem: programs can do their own colour management, or the system can do it. In itself, each option is viable (not all programs need colour management, so doing it per program saves some cycles where it’s not needed).
BUT: you have to avoid getting the output profile applied twice (which can happen when both program and system do colour management)…
In X11, that’s easy because X11 relies on the application to do the display transform. All I’m bypassing in that is from where I get the display profile to do that transform.
Wayland, however, I’m not so sure. That’s because my reading of their literature has been spotty, no time to really dig into it. What it appears the protocol supports is, if the application gives the colorspace information to Wayland through some sort of tag mechanism, Wayland will do the display transform; if the application doesn’t provide that, Wayland just displays the image “as-given”, no Wayland transform. THAT is a very hairy supposition, and I welcome anyone more knowledgeable to correct or clarify it.
I’ve actually wanted to ask that particular question for quite a while; most of the discussion about it is in the weeds, hard (for me, anyway) to understand the fundmental mechanism.
Oh, and for @Preimage: I use the LittleCMS library to do the actual transform. Highly recommended…
