From kde-kimageshop Mon Jul 26 13:38:02 2004 From: Boudewijn Rempt Date: Mon, 26 Jul 2004 13:38:02 +0000 To: kde-kimageshop Subject: Re: Back Message-Id: <200407261538.02623.boud () valdyas ! org> X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=109084909312573 On Monday 26 July 2004 14:37, Cyrille Berger wrote: > > KisPaintDevice { > > private: > KisTileMgrSP data() { return m_data; }; > public: > KisIterator iterator() { return KisIterator( m_data ); }; > > private: > KisTileMgrSP m_data; > > }; The only problem with this scheme that I see is that you need a factory function for every type of iterator -- for the rest, okay. I was working on outdate assumptions. > > > * I'd like to have a richer set of iterators: over rects, over tiles (for > > speed), and so on. Lines/pixel are okay. > > anyway, I don't see any differences between iterators over rects and over > tiles. A rect isn't the same as a tile. A rect can be any rectangle within a layer, cobbling over tiles if necessary, or fitting within one tile. > I think we should have two "basic" iterators : > - rects (walking on the image tile after tile) > - line/pixel (walking on the image line after line) I see a need for the following iterators: * Rect -- Walk over a rect intersecting with (or all of the image by default) pixel by pixel. The user can make assumptions about the order of the pixels presented. * Fast -- Walk over the pixels of an image in the fastest possible way. This'll mean that the user cannot make assumptions on the order of the pixels presented, and thus does not know where his next pixel is located. Useful for things like histograms. I really don't see much use in first iterating over lines, and within the lines over pixels. I don't mind those iterators to be present, but I probably wouldn't use them, since it makes my code more nested, and thus more complicated. And I mean, how often in all the filters you've created until now have you had the need to skip lines? The things you want to do often boil down to: for pixel all pixels in layer/selection/region composite pixel/channel blend pixel/channel make pixel/channel more/less transparent count pixel/channel copy pixel/channel to another layer mess with pixel/channel's color values render pixel/channel to 8-bit RGB (i.e. convert pixel/channel to other representation) get pixels in 3x3 matrix around this one, and compute new value for this pixel. Which is one degree easier than: for line in all lines: for pixel in line: doStuff > > * Oh, and I'd like a hint on what's going wrong in kis_histogram.cc. But > > that probably has to do with the return type. > > there was two times ++pixelIt. Ah, okay. Now when I get Krita to compile again, I can see whether my histogram has survived the holiday's little bit of coding. -- Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop