On Mon, 3 Apr 2006, Leonardo Giordani wrote:
> My implementation of Curtis's work is goning along:
the implementation of the
> Kubelka-Munk model and the composing functions work.
Cool! I've been doing some work on the substrate part of
it, but I need to hack
KisImage for that, and I'm not sure I should do that in 1.6
already. Although it
would be good to have watercolor in 1.6, and I can do most
of the work in a plugin.
>
> The thing to do are now:
>
> 1) Blitting
>
> Given the KM parameters of a pigment I can easily
compute reflectance and
> trasmittance (R and T); then I can compose two layers
computing the total R
> and T. BUT at this point I can not revert those values
to KM parameters
> (explanation below).
>
> This means that when I blit two pixels I start with two
structures containing
> KM parameters and end with a structure with RT
parameters.
>
> So my idea is: I can stack KM pixels in a vector when
blitting, and when
> converting to a QColor and QImage, collapse them
computing the total R and T.
>
> Sadly I cannot characterize pixels with R and T,
becouse they depends on the
> thickness of the layer (and thus on the water content
and so on).
>
> The question for you C++ gurus is: can I define a
"cell" that is a vector of
> stacked pixels and save it as a vector of bytes as done
in bitBlt and
> fromQColor, then retrieve it with the usual
reinterp_cast<> in toQcolor and
> convertToQImage?
>
> Someone has other ideas to face this problems?
I need to think on this, and perhaps chew on some actual
code. Have you been developing
against 1.6? Maybe you could just checkin what you have but
keep it out of
the default compile. Oh, I'm not the C++ guru here, so
maybe someone else has a bright idea.
>
> 2) Color selection
>
> At the very beginning I would use the same watercolor
pallette widget
> developed for the wet colorspace, but later I would let
the user create
> colors as Curtis suggests in the paper: this means a
widget with two color
> selection wheels (I don't know the correct name), one
for the color over
> white and one for the color over black.
> Furthermore it must be possible to select the amount of
pigment and water.
That should be doable.
>
> 3) Implementation of watercolor behaviour, i.e. the
real content of Curtis's
> paper.
>
> I hope to solve the blitting problem (and a strange bug
in
> toQColor/fromQColor) during this week; after this I
will move to point 3,
> recycling the wet widget.
It sounds very hopeful  .
Boudewijn
_______________________________________________
kimageshop mailing list
kimageshop kde.org
http
s://mail.kde.org/mailman/listinfo/kimageshop
|