Merging profiles into colorspaces

[Casper Boemann]

On Sunday 18 September 2005 08:36, Boudewijn Rempt wrote:
> On Saturday 17 September 2005 16:49, Casper Boemann wrote:
> > Hi
> >
> > I've been thinking about our colorspace design.
> >
> > Currently we have profiles and colorspaces, they are matched up in the
> > paint device. But actually a profile is a specialisation of a colormodel.
> >
> > What we currently call colorspace is actually a colormodel.
> > A colorspace is a colormodel plus a profile.
> >
> > Our code should reflect that.
> >
> > I still want colorspaces to be singletons. Or rather "multipletons" if
> > that is a word. That is, only one instance of each colormodel+profile. So
> > a constructor something like KisColorSpace(KisProfile) and the factory
> > like getInstance(KisID)
> >
> > If the colorspace with the same KisID already exists then we don't create
> > it again.
> >
> > It would be much easier to use.
> >
> > I can see lots of advantages, but can any of you see any problems.
> >
> > I would be willing to do the coding
>
> Now I'm a little more rested, I'm seeing a couple of issues apart from the
> points I mentioned yesterday (we still need to be able to have colorspaces
> without profiles, it may solve the problem of distinguishing transforms,
> problems with the memory cache in the colorspace class):
Yes null profiles should be possible. In fact with this change it becomes more 
obvious that you can have a cs without a profile. Because only on request do 
you have to supply a profile.

Anyway, only cs that is not "lcms friendly" (like ws) should be allowed null 
profiles.
All others should use a default profile.

> * We need to keep the user interface as is. The current color management
> user interface is carefully modellen on Some Other App, and I like to keep
> it that way. It fits the way people have been taught to use profiles. That
> means that we're not going to have a KisID for the combination of CS +
> Profile.
No changes planned there.

> * When saving or exporting, we again need to conform to expectations of
> other applications that have separated CS and Profile in different
> entities.
Instead of: save(profile)

I just write: save(cs->profile())

So it becomes transparent

> * We need to check our colorspace conversion functions: do we actually
> convert the pixels when changing only the profile? We should.
No we didn't and yes we should


-- 
best regards / venlig hilsen
Casper Boemann