finalizing the Iterator API
cbr at boemann.dk
Wed Jul 7 11:23:46 CEST 2004
> > And as Boudewijn said up,down.left,right might be nice functions,
> > they don't make sense for a PathIterator. I have had this idea myself,
> > on reflection: when would they really be used.
> Edge detection, for instance.
good point, question is if we should make a special WalkerIterator for this
or just provide those functions in general.
> > Another Iterator I just tought of is an affine transformation, used to
> > scale, rotate and shear images.
> I have a hard time visualizing that, so I'd like to see it... Currently we
> affine transform code I ported from Qt, debugged by Bart, for all this,
> really need bicubic interpolation scaling, as the current scaling is
Well it was only a thought but I was envisioned two iterators a normal and
the transformed. One would then walk the source and the other the
destination. If you always advance() both at the same time you would get a
mapping. All you would have to do is to sample around the source position
and store it at the destination position.
But I havn't thought this one through.
> > 2) it should allow any combination of int8, int12, int32, float,double,
> > bits
> Fortunately, the colour strategies already have the rudiments of a pixel
> description in the ChannelInfo structure. This needs to be extended and
> formalized -- here I really put my foot down. I don't want to have to
> the depth of the image every time I consult the ChannelInfo :-).
> > Anyway , the GOF (p 91 bottom paragraph)
> My offer to provide a copy to people not having that book still stands:
> however, not having the paper version handy, can you give the pattern you
> refer to?
Well it is not a pattern - that's just it. They didn't have a pattern to
refer to. They just talk about sending a base class into a function that
would then have to be cast to a more specialised class. I'm sure that if a
pattern was applicable they would at least refer to it.
It was a sidebar discussion under the abstract factory pattern: The factory
gives a baseclass pointer to the product, but what if you need to do
subclass specific handling.
> I feel convinced. Although -- see the pseudo-code I mailed in response to
> Cyrille's concerns. It seems a bit silly to have to manually ask the
> strategy to parse the data into a pixel. Maybe we can provide a
> that returns the parsed data, for those algorithms that need it that way,
> a PixelDataIterator that returns the pointer, for the algorithms that
> all the real work to the colour strategy anyway.
yes - if you think of letting the iterator ask the colorstrategy for
parsing. No need to do that manually. However only if actually needed in
more than this single example - no need to bloat the interface
More information about the kimageshop