Hi Sven,

Sven Neumann wrote:

What we didn't talk about yet is whether the profiles are filenames
that specify what ICC color profile to load or whether they are
pointers to color profiles loaded into memory.

I suggest that we use filenames here and let the modules deal with
loading the profile. Is loading a profile using lcms an expensive task
or is the file just mmap'ed? If it turns out to be a problem we could
consider to add a color profile cache that is shared by all display
filters and color selectors. The profiles would be identified by their
filename so the struct that I suggested should be good enough.

I'm in full agreement over passing filenames instead of blocks of memory. There's a bit more to opening a profile than a simple mmap() - there's a header that much be parsed, and endianness issues taken into account - but it's not that expensive. What is quite expensive is creating a transform from a pair of profiles, so if we could cache the transforms it would be worthwhile.

The other possibility is to have a single instance of the display filter used across all images and the colour-selectors, and then allow an image parasite to disable it. Advanced users could then set up through the View->Display Filters dialog any custom transforms that they require. This would more or less guarantee that inexperienced users won't accidentally end up with mismatched color-spaces, while still providing enough flexibility for advanced users.

For image-specific profiles, I suggest that we continue to do what
we've been doing so far and that's attaching the loaded profile to the
image using the "icc-profile" parasite.

Agreed. Upon image load, if this parasite exists and the user wants to transform to the working space, then a plugin will transform from this binary profile to the working profile, after which this parasite can be flushed. If the user doesn't convert to the working profile, the parasite will remain, and will be available to the display filters if the user subsequently sets up a custom transform.

All the best,
Alastair M. Robinson
Gimp-developer mailing list

Reply via email to