New watercolors status
leonardo.giordani at treuropa.com
Mon Apr 3 11:02:19 CEST 2006
My implementation of Curtis's work is goning along: the implementation of the
Kubelka-Munk model and the composing functions work.
The thing to do are now:
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
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
Someone has other ideas to face this problems?
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.
3) Implementation of watercolor behaviour, i.e. the real content of Curtis's
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.
Tele-Rilevamento Europa - T.R.E. s.r.l.
a POLIMI spin-off company
Via Vittoria Colonna, 7
20149 Milano - Italia
e-mail: leonardo.giordani (at) treuropa.com
More information about the kimageshop