KisPixel

[Casper Boemann]

> > ok that will do for now - everybody please feel free to answer
> >
>
> I think I do agree with all of your points: they are more or less design
> requisites. I'm going to draw up a number of use cases: pseudo client code
> that performs image manipulation activities using iterators. We are going
to
> go over that pseudo code until we have something that's easiest to write.
> This client code then defines the interface of the definitive set of
> iterators. At this point in time, I care only about ease-of-use and
> flexibility, not about efficiency or speed.

Ok moving on then. As I see it there are a number of places where internal
pixeldata needs to leave the confines of the colorstrategy:

1) Display on screen (obviously), and I think the current way is right on
the money. But we need to extend it to handle invisible channels.

2) Infodocker (showing on screen in numbers what the value under the
cursorpointer is). This could be accomplished by returning it as a string.
That way any kind of channel could be shown, since it would be up to the
colorstrategy to format the string.

3)Histograms. Hmm tricky in the general, since a channel could be anything
(even bitflags perhabs, though that could outwardly be shown as seperate
channels). On the other hand absolutely no gui should go into the
colorstrategy, so what to do? Perhabs a function to extract a channel as a
double (should preserve all scalar values even longs with full precision).
How does the histogram function the decide the number of bins. Well
obviously we cannot have 2^32 bins anyway as that would take up 16 gigs of
memory. For gui purposes 256 bins should suffice. Functions telling the
theoretically range of values of the channel should also be provided then.
That would return 0-255.0 or 0-1.0E256 or something like that. The
colorstrategy might know that even though it's a double only values 0-1.0
are valid, and so that is returnend

4) Filters and Scripts. I think they should be limited to the compositions
and other general functions (eg colordistance) we might come up with. But
perhabs this is not enough for some kinds of manipulation. I don't know what
might be needed. Insights anyone? please be specific.

5) ChannelDocker. Showing the names of channels, visibillity status and
more. Although not exactly individual pixeldata, it should still be shown in
an independant manner. I think ChannelInfo does that right?

6)Mode change (say from rgb to cmyk). Should go through a single mediator.
Be it a Lab colorstrategy or perhabs just koColor (not sure if koColor fits
the following requirements though). The important thing is that no lowering
of gamut should be imposed by the mediator (only the to and from modes).
Also it should be colorspace aware (there are unlimited number of rgb
spaces, so handling one rgb space is not enough - thats why we need lcms)

7)Colorpicker. Again no restriction of gamut. Should also be colorspace
aware. The standard ko/kde/qt things may not be enough. We may need to do
our own. Also a true palette (like in the real world) would be nice, so the
need for our own gui is also needed for other reasons. This is a
paint/color/imagemanipulation application after all, so things that work for
a normal office application probably is not enough for us. The best way in
my opinion is again to go throught a mediator like Lab or xyz

any other places - anyone ?

best regards
Casper Boemann