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

[Boudewijn Rempt]

On Fri, 28 Apr 2006, BERGER Cyrille wrote:

> Hello,
> I have three concerns about our API right now (the first two appears
> when working on heal/distortion duplicate, and the last with
> colorspace conversion for filters) :
> 
> 1) currently we can't really have configuration widget for paintop, I
> mean, we have configuration widgets that depends on the input device
> and which appears in the toolbar, but what I need for the duplicate
> tools, is a bigger configuration widget like those of the tools, so
> the question is what the best way to do that ? (for 1.6, as duplicate
> is in fact a tool, I will extend the current hack of having the
> configuration set by the tool and saved in KisPainter).

I've been thinking about this too. The big problem with the duplicate
tool as a paintop is not the configuration widget but the interaction.
Paintops cannot do things like "ctrl-click to select distance". So,
let the duplicate tool remain a tool -- for now, but perhaps it'll have
to remain that way. 

As for the tool option widgets, I'm starting to think we should move from
a widget in a tab to a strip under the menubar, with popdowns possible
for bigger option widget like the curves widget. This is one area where
I hope to be able to find the time to make a mockup for us to discuss.

> 
> 2) I remember from the thread
> http://lists.kde.org/?l=kde-kimageshop&m=112992472325754&w=2, and
> especially http://lists.kde.org/?l=kde-kimageshop&m=113009729431330&w=2
> that we could have complex filters written for XYZ or LAB, but then
> the idea of having functions to facilate that was dropped because
> converting from rgb 8bit to XYZ was degrading the image. But I think
> we really need those function (fromLAB and toLAB at least).

Yeah -- an in fact, we silently convert to and from lab quite a bit 
already. I'm not sure: didn't we find the cause of the degradation?

> Because, a number of algorithms (like color transfer) are only working
> with LAB, so at some point you need to convert data to LAB. 

Another possibility is making those filters only available when the mode
is LAB16 -- users can convert to lab and back themselves. That would
be a good possibility for specific filters. And, in fact, some
things can only be done in lab like sharpening just the L channel. (I was
working on extending the filter configuration with a channel selector
so that filtering on just one channel would become easy.)

> When you
> are working on all the data of the KisPaintDevice, it's not a problem
> to convert the paint device to LAB and working on it and then go back
> (in fact it is a problem as you are also changing the value of
> nonselected pixels). But when working with smaller images, I think
> it's cumcumbersome to copy the data you want to convert in a
> KisPaintDevice before converting them.
> (but maybe you all agree we need those functions, and the reasons they
> weren't add is because no one did it, so if it's a case, I would loike
> to add them to krita 1.6).

Casper was thinking of something along these lines: I am not sure whether
his thinking has already reached the concrete proposal stage :-).

> 3) In Filter manager, we create a KisTransaction, but in fact we would
> need to start a macro there, and the question is how do I cancel a
> macro ? (when the filter is interrupted)

Why the need for a macro? Are you planning to allow people to select
a sequence of filters to apply at once? Actually, to cancel a macro,
I think you need to unexecute all commands in the macro, backwards.
Doesn't the macro class already offer that functionality?

Boudewijn