Grayscale Selections

Dmitry Kazakov dimula73 at gmail.com
Sat Jun 25 19:41:54 CEST 2011


Well, I see three usecases for the selection's extents:
1) Using a selection for filtering/composing another paint device. In such a
case we need to know "the area of non-transparent (non-black) pixels inside
the selection".
In this usecase default bounds are mandatory. We just get a selectedRect()
(corrected by KisDefaultBounds) and process the resulting area.

2) Filtering/modifying a single selection. In this case we need to know "the
area of non-default tiles" that we need to process. The processing is done
in two stages: 1) modifying non-default tiles (regions, rects, whatever
granularity you want); 2) processing the default pixel of the selection.
Here we should be very careful, because we cannot use the exactBounds() area
for processing. Otherwise, after we change the default pixel of the
selection, the pieces of the non-default-tiles containing default-areas
(region = extent() - exactBounds()) will *not* change their state. So they
will be left unprocessed.

3) Composition of two selections. This case resembles the second one. We
need to know "non-default areas". The processing is done in two stages: 1)
modifying the union of two regions of non-default tiles; 2) modifying the
default pixel. And we can't use exact bounds as well.

So currently, we do already have the implementation of all the necessary
methods for all the three usecases. The only trouble we have, we need to
ensure somehow (by API, maybe), that the user will not forget to process the
default pixel of the device in the cases 2 and 3.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110625/37b8f88f/attachment.htm 


More information about the kimageshop mailing list