API Evolution question about paintop, colorspace independent filter (or even tools for that matter) and filter transaction

[BERGER Cyrille]

> > Bah we display a message when the filter convert the data to LAB and
> > that it risk degrading the data.
>
> In many cases that works fine. But: if the user wants to apply a couple
> of those filters after each other, it is better if the conversion to
> lab and back is done only once instead of for every filter.

Or have it as an option, I mean the process function of KisFilter
shouldn't do the conversion, but we add a function called
KisFilter::needConversionTo that return an ID of the colorspace, and
it's either up to the KisFilterManager or whowever is making the chain
to convert before applying the filter.

> > I think it's better (for the user
> > experience) to have as few as possible disabled filter. Because, for
> > instance, I have a filter that requires LMS, so with such a system it
> > will be disabled except if CS==LMS, meaning that the user has to
> > figure out which colorspace to use for a specific filter (through doc
> > or a tool tip ? not very very userfriendly).
>
> If I listen to Larry Marso then users don't have a lot of trouble with
> learning they need to go to LAB for some cool effect. And for many
> nice filters you need to show the channels.
To LAB yes, I suppose most people with some color knowledget know the
value of the LAB colorspace. But what if the filter requires an other
colorspace ?

> > As for the channel selector, it's great, but shouldn't it be lower
> > level ? (I don't know how, maybe we should seperate channels in
> > different tiles ?, but that's lot of work, maybe not really worth it)
> > It would be cool to be able to lock a channel.
>
> No, we should keep the channels together, or so Pippin advised us :-). What
> I'm thinking is to add a QList of bools as an argument to many of
> the colorspace methods, to bitBlt and to the process() method of the filter.
> For now, I'm working on a widget to select channels, but that's a bit hard
> since not all colorspaces have a color associated with all channels, meaning
> I need to work with abbreviations and so on. But a prototype implementation
> should appear as soon as I've got some time to myself.

Wouldn't that be very slow ? That's my main concern about it. But
except for seperating channels I cannot think about something better,
and if pippin says it's a bad idea, I am ready to take his words on
the subject ;)

--
Cyrille Berger