cbr at boemann.dk
Mon Jul 26 22:06:06 CEST 2004
> 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
> For some computations, a colour must be converted to HSV and then back, I
As I said. - except that HSV is such a poor model. It lacks in so many
> 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):
> 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
> > 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)
More information about the kimageshop