Autolayer merge done

[Boudewijn Rempt]

On Wednesday 12 January 2005 22:28, Michael Thaler wrote:

> I really think there should be methods to get the width and the height of
> an image. Both the raindrops filter and the oilpaint filter are not ideal
> because they use the iterators to read the whole image to a QUANTUM array.
> In principle one can solve this by making the filters use the iterators
> directly.

I really want Casper's input on what's the best way to go about this, but
my intuition is to make KisPaintDevice have to methods:

parentWidth()

and

parentHeight()

or something similar that return the w and h of the image; that's the area
we want filters to apply to anyway. I guess... Maybe the actual area covered 
with pixels is a better bet -- but then we need methods to get that rect.

Either one or both...

>
> However, there are two big issues: first, not providing width() and
> height() makes it very hard to port existing filters that work on QUANTUM
> arrays. I rather see some not so ideal filters that convert the whole image
> to a big array first, then to see only a few filters because it is (at
> least for me, and probably for other people that have not that much
> programming experience) hard to convert filters to use the iterators
> directly.

I've made a start providing methods to read and write blocks of pixel data -- 
note, not pixels! -- in the data manager. However, this data should really be 
converted to KisPixels before working with them.

So, if you don't want to use the iterators that return KisPixels, you get 
something like:

QValueVector<Q_UINT8> * bytes = readBytes(1, 1, 100, 100);
QValueVector<Q_UINT8> * dstBytes = new QValueVector<Q_UINT8>(100 * 100 * 
							depth);
Q_UINT8 * sptr = bytes -> pointer();
Q_UINT8 * dptr = dstBytes -> pointer();

QValueVectory
for (each chunk-of-bytes-representing-one-pixel until the end) {

	KisPixel * p = new KisPixel(pointer);
	// My algorith only works with rgb
	QColor c;
	p -> colorStrategy() -> toQColor(pointer, &c);
	// mess with c
	p -> colorStrategy() -> nativeColor(&c, dptr);

}
delete bytes;
writeBytes(dstBytes);
delete dstBytes;

Or something like that :-).

>
> But there is a more important reason to have width() and height(): to
> implement progress info, you must know the width and the height of an image
> before the calculation. It is actually quite easy to implement progress
> info with the current filter framework:
>
> just add a function
>
> inline KisProgressSubject* progressSubject() { return m_subject; };
>

Sounds like a plan.

> to kis_view.h. You can easily use this in the filter to implement progress
> info in the filters, if you have the width and the height of the image. I
> see no way how to implement progress info without widht() and height()
> functions in kis_paint_device (the filter work on a layer, not on an image,
> so getting width and height from an image does not help here).

No, that's hard to do.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050112/b5880995/attachment.pgp