Pen-And-Ink illustration

[Boudewijn Rempt]

On Mon, 10 Apr 2006, BERGER Cyrille wrote:

> Hello,
> I am working on a new colorspace for drawing pen-and-ink illustration.

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?

> But I came across a big problem. The rendering part of the colorspace
> need to know the coordinate of a pixel. I mean the color of a pixel
> depends of the color and substance of this pixel and of the position
> of the pixel in the image.

I don't think I follow you here, but I'm very curious :-).

> So I have three solutions to solve this problem :
> - change of the API to have toQColor(), convertToQColor receive the
> coordinate (but this is a big change for something not really wanted)

Ugh! Not a good idea, I think.

> - store the coordinate of the pixel as two channels... (ugly, isn't it ?)

That's not going to fly either, you would have find a way to update those
when pixels are displaced, for instance by moving.

> - have convertToQColor display the "raw" data (it would still be a
> nice idea if convertToQColor has the coordinate anyway) and use an
> adjustement layer to convert the raw data to the final render.

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. 

> My favorite solution is the number #3, it allow more flexibility (you
> can choose the renderer, I have at least two in minds, you can watch
> the raw data), but I have two problems, one : isn't it a problem if
> the adjustement layer isn't created when the pen-and-ink layer is
> created ?

You can create the adj. layer automatically when the pen-and-ink layer
created -- maybe we should make something analogous to the starting
of long-running filters whenever a paint device of a certain colorspace
is created, or Bart's hack that I cannot find anymore for the wetness
visualization.

>  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.

Boudewijn