cberger at cberger.net
Mon Apr 10 10:54:28 CEST 2006
> Isn't that just grayscale + wetness + height of the ink deposit? (If you use
> the new substrate thing I'm working on now, you don't need to keep the paper
> height in the colorspace itself.) Or are you working on something that
> takes, say, a photograph and renders it as pen and ink?
hum neither :) It's more
http://grail.cs.washington.edu/projects/int-illus/ (again ;) )
For each pixel, you choose : tone, direction and texture. Of course
your paper things will be nice to have too, but it will come
automaticaly for all colorspaces, right ?
> An adjustment layer is the right solution, I think. Although I still think
> that to/fromQColor shouldn't need the coordinates of the pixel they are
> working on.
well I was thinking to not implement those function, they have no
sense in that case anyway. But what about convertToQImage ? it would
be nice, because I was thinking to show direction for "zone" with an
arrow (like in the paper I mention above) rather than with a color for
> > And two : is it a good idea if a filter change the
> > colorspace of the paintdevice ?
> Hm... Don't see why that should be bad -- of course, you have to keep in
> mind that compositing a heterogenous layer stack is slower than one
> with only one colorspace presented.
Don't know either :) But as it doesn't stricly follow our logic "all
filters should work with all colorspaces", I wonder if it could cause
any problems ;)
More information about the kimageshop