From kde-kimageshop  Thu Nov 17 23:28:13 2005
From: Cyrille Berger <cberger () cberger ! net>
Date: Thu, 17 Nov 2005 23:28:13 +0000
To: kde-kimageshop
Subject: Re: Data access in scripting
Message-Id: <200511180028.13197.cberger () cberger ! net>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=113227012608028

> * 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 ---
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop