KisPixel

[Casper Boemann]

> And compositing layers of different types. One thing I'm working on
> currently -- stalled a bit because I'm waiting for the iterators to get
> finished and four your work on auto-extending layers is selections.
> Currently, I model a selection as a layer with a 256 bit grayscale colour
> model. Composite this with a user-settable opacity, and you have a very
> clear way of representing discontinuous selections. I hope. But for that,
> it's necessary to be able to mix colour models in one image. The groundwork
> has been done, but I still need to do a lot for that.

That is one big project if you want to be able composite arbitrary modes, 
However an alpha layer (an more generic form than a selection layer) would 
indeed be nice and needed.

> > 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.
>
> Hm. There are a lot of different possibilities to mess with pixels that we
> cannot all foresee, nor want to add to the colour strategy. For instance:
>
> * darken/lighten pixel/channel
> * composite
> * copy from x,y to x',y'
> * compute a value for x,y from the surrounding pixels (for instance when
>   scaling or convolving)
> * compute something from two different pixels
> * create a whole new, exciting pixel to put in place of the current pixel

Well most of those things can be done by compositing with an alpha value.

As for darken/lighten only the colorstrategy would know, but it could give us 
the Lab which we could manipulate and put back in for the colorstrategy to 
convert back. 

> For some computations, a colour must be converted to HSV and then back, I
> believe.

As I said. - except that HSV is such a poor model. It lacks in so many 
respects.

> You don't want to push the actual operations that a filter wants to
> implement into the colour strategy -- except for the composition, I think
> -- because that has the following disadvantages:

No, wasn't suggesting that either

> Now if we could define a basic set of building blocks that makes it
> possible to build any imaginable image operation, we should put the
> building blocks into every color strategy.

Exactly what I envision.

> If that proves impossible, we 
> need to expose the raw channel data to the outside world. And that'll mean
> that there will be, once we start building 16-bit channels and the like,
> plugins that cannot work with every colour strategy.

Yes, but we can go a long way before that is needed, by being clever with the 
above strategy. However you might be right

the KisChannel you propose would indeed give uniform acess to the data, but 
the problem lies not in access but in interpreting the values. The math you 
would need to write would have to know what it is dealing with. Which brings 
us back to the point where a filter *might* have to know the meaning after 
all, but lets try to avoid that. 

> > 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)
>
> koColor doesn't fit the bill yet -- but might be expanded, and we can make
> do with it for now. koColor supports (with some bugs):
>
> indexed,
> 8 bit lab,
> 8 bit rgb,
> 8 bit hsv,
> 8 bit cmyk
>
> Which should suffice for our first release.

yes for now - sure. And if the rest of the KOffice team don't mind us changing 
things I would love if we could improve the koColor for the benefit of all  
ko apps.

> > 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.
>
> We can nick a cmyk colour picker, or at least the guts, from Scribus.

yes scribus is another app that needs to be very precise on color if they want 
it to be used professionally. Ideed scribus could provide lots af advice if 
not actual code.

> You won't be able to mix colours realistically without some sophisticated
> stuff; the papers I have read have sampled paint with a spectrometer,
> isolated about 100 frequencies and then reduced the number of frequencies

Well for this flighsimulator of mine I'm fiddling with I have done exactly 
that to model the light through the atmosphere, to give realistic blue and 
red sky depending on altitude,the sun and direction of sight.

I'm also thinking that in the future a colormodel with quantisized spectrums 
would be a nice showoff for krita.

As for the palette - yes it would indeed be challeging but not impossible.

> (By the way, it might even be nice to have, in the future, virtual
> iterators, i.e., iterators that generate a pixel value for a region of
> pixels, or for a virtual pixel that lies between two (or four) pixels.)

nifty, and easily accomplished by weighing the surrounding pixels. The 
aforementioned composition of a alpha value with any kind of pixelrep (by way 
of a colorstrategy) is again just what we need to do this and indeed any kind 
of sampling without actually knowing what the channels mean (or even how many 
channels there are)

-- 
best regards
Casper Boemann