Hi
Øyvind Kolås wrote:
Would it make sense to break down the processing chain of the modules in two parts? One part that is attached to the image, and one that is attached to the display
projection -> image filter -> display filter -> frame buffer
It's a possibility, but I think it's probably making things unnecessarily complicated. Since we presumably want to avoid having two sets of filter modules to maintain, the display filter would have to be a special case of the image filter (or vice versa)?
I also think that for maximum flexibility, if we have a single global color-management filter outside the image filter chain, we need to be able to disable it if a color-management image filter is enabled. And we still need to get an image parameter into the filter modules :)
A proof-of-concept image filter (based on the existing proof module) is now attached as a patch to bug #78265. Configuration is currently done through View->Display Filters - it needs to be made persistent, and parasites are looking like the best way to do it.
I envisage it working something like this:
Fetch working profile from global parasites. Fetch monitor profile from global parasites. Fetch proof profile from global parasites.
if(we have an image)
{
if(we have an override-working-profile image parasite)
Fetch overridden working profile from image
if(we have an override-proof-profile image parasite)
Fetch overridden proof profile from image
}This IMHO avoids too much unnecessary complication while providing the flexibility I'd need to use it at work: I'd want to scan an image, and rather than convert the image to sRGB, just tag it with the scanner's profile, and have the display filter use that as the source profile.
This method also allows for proofing transforms to be enabled on specific images.
As always, comments, criticisms and suggestions welcome :)
All the best, -- Alastair M. Robinson
