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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer