Data access in scripting
Cyrille Berger
cberger at cberger.net
Fri Nov 18 00:28:13 CET 2005
> * I'm opposed to trying to hide Qt from the scripting api, if only because,
> with Krita being GPL, that would be futile. Giving script writers access to
> the image data in QByteArrays would be possible. Indeed, that's what I
> intend for the dcop bindings. Those will be close wrappers of the
> interfaces and objects Krita exposes to plugins, with QByteArrays around
> all pointers. Writers of dcop scripts would then pass the QByteArray to
> colorspace functions to get results.
Well, true, but we will then to have our own binding (we cannot expect that
the qt/kde binding will be available for all scripting engine, for all
distributions, all the time, qt/kde bindings are still very very
experimental), and I don't see what QByteArrays brings us ?
> * We still need a way to alert the user about filters, tools and scripts
> that only work with a subset of colorspaces, such as 8-bit rgb. There is
> enough support in Krita's api for 8-bit rgb scripts: not just the to and
> from QColor, but also the QImage conversion functions would work out there
> -- a script could simply call convertToQImage and convertFromQImage and the
> script language wrappers around QImage and QColor to do its thing.
>
> * Limiting the scripting interface to 8 bit rgb would be a mistake.
true, it was not my intention.
> * If we add a type describer to the channel descriptor, then it would be
> easier to get the correct datatype for a particular channel, and if we can
> somehow make a difference between a painterly colorspace, a colorspace like
> rgb and a colorspace like hsv (Casper knows the right terms, I'm sure), it
> may be possible, with a lot of effort, to write a script that can handle
> stuff the right way.
well I am not sure if you mean "lot of effort" for script writter or for us,
if it is for script writter I think it's a bad idea
> Now, how I would like to write a script would be something like:
>
> cs = device.colorSpace();
> for pixel in device.getPixels(10,10,100,200):
> # invert the pixel first, just for fun
> cs.invert(pixel)
> # now, if the colorspace is wet, make it wetter
> if cs.name == "WET":
> pixel.channel("WET")++;
> else:
> # Increase luminance for that wet look
> labPixel = pixel.toLab()
> labPixel.l - labPixel.l * 0.2
>
> Or something like that.
so do I, but as I said on irc, I think most people will want to work with rgb,
so the important question is : what do we do ? prevent their script to work
if it try to work, for instance, with a cmyk layer, or make the conversion ?
> Be creative, don't limit scripts to 8 bit rgb
it has never been my intention.
--
--- Cyrille Berger ---
More information about the kimageshop
mailing list