Contributing our batch sprites export plugin - need pointers

[Nathan Lovato]

Thanks for the detailed reply!

> That should actually be solved, please make a bug report? Or hack this into libkis --

I'll test this, as Razvan faced this issue back in... march or april. We 
haven't tested again since then.

> I have always had the hope that users of libkis would help extending it to fit their needs better :-)
We really want to contribute to Krita. But in this case we would have to 
mess with the scale node image operation. Doing mostly high level 
programming I’m not ready to mess with Krita’s core. That's why we're 
looking to contribute a Python add-on to start with! I hope we can get 
to the point where we can help push parts of the programs we use 
forward. But it'll take time. I have yet to find a Krita instructor to 
work on more tutorials.

> And getting the pixels in and out of the paintdevice doesn't take too much time?

No, PIL is actually 3 to 4 times faster than using the built-in scale 
node op, even if we have to copy the image data out and back in, 
according to Razvan. He was also surprised by this result.

I'll make a branch of the addon to test the builtin scaleNode method, 
see if I can time the two.

On 23/07/2019 10:53, Boudewijn Rempt wrote:
> On zondag 21 juli 2019 16:34:22 CEST Nathan Lovato wrote:
>
>
>> The code currently relies on the Pillow Python imaging library. The user
>> needs to install a local version of Pillow in the add-on’s directory
>> that matches their operating system. Right now, it’s a +/- manual process.
> I've often considered that shipping pillow by default might be a good thing; we haven't had anyone ask for it, but I would not mind at all adding it to the default set of python libraries we ship with Krita.
>
>> We use Pillow for a few reasons:
>>
>> 1. Resizing/scaling the image via Python starts an asynchronous process,
>> but the function returns immediately. We couldn’t find a way to wait for
>> the scale operation to finish before Krita calls Node.save() and exports
>> the image. The only way we could solve this so far was using Pillow.
> That should actually be solved, please make a bug report? Or hack this into libkis -- I have always had the hope that users of libkis would help extending it to fit their needs better :-)
>
>> 2. Pillow is fast. Using it makes export 2+x faster compared to using
>> Krita’s built-in functions.
>>
>> As a bonus, it’s a lot easier to manipulate the image with Pillow than
>> using Krita’s API.
> And getting the pixels in and out of the paintdevice doesn't take too much time?
>
>> It's technically possible to automate the installation of the
>> dependency, to have the right version of pillow bundled with Krita upon
>> building the program.
>>
>> A FEW QUESTIONS
>>
>> About the add-on:
>>
>> 1. Is there a reliable way to transform the layer from Python with
>> Krita, and wait for it to finish before saving the file?  If so we could
>> remove Pillow as a dependency. (code contributions welcome!)
> libkis would have to be fixed for that.
>
>> 2. Would having pillow as a dependency be okay if we contributed the
>> add-on? The library itself is sizeable, and it takes a good 6 megabytes
>> on disk. For a single add-on, I bet it's too big but never hurts to ask. 🙂
> Meh, that's not so big :-) And everyone knows, the bigger the installed footprint, the better the application is :-)
>
>> Python add-on development with Krita:
>>
>> 3. Is there a way to reload Python plugins without closing and
>> restarting Krita? Plugin dev is quite slow because of that right now.
> This is really tricky because a python plugin isn't something separate from Krita. It doesn't run outside the Krita process, but becomes part of Krita's ui, with actions, dockers, dialogs all being in the same situation as c++ plugins.
>