Engrave example works, but slowly

[j2l]

Hello,
So great to see this project going on!

I successfully tested the add-on with the example. I can't wait to see nodes. In compositor I guess :)

I noted that Engrave is very slooow. Like +10s for a 1920x1080 basic render image.
I use Ubuntu 19.10 and I wonder if G'MIC 32 bits is used instead of the 64 bits version and it slows down the process.

Might be better to split them in different releases?

Also noted that CTRL+S to save the result, throws a "saved gmic_00001.png" message ,but where?
It's not in /tmp, nor in /home/user/.config/blender/2.83/scripts/addons/gmic_blender or in parent folders.

[myselfhimself]

Hello, I will reply to you tomorrow! Sorry for the delay.

[myselfhimself]

I will compare the Blender gmic-blender speed of engraving and the official gmic command line command for engraving

[myselfhimself]

For 1920x1080 image, blender rendering time excluded, fx_engrave 0.5,50,0,8,40,0,0,0,10,1,0,0,0,1,0 on my super old 64bits linux laptop:

• 38 seconds within Blender
• 19 seconds with gmic-cli

[myselfhimself]

As to the Ctrl+S shortcut, it saves a 0 bytes file on my side in the blender executable's directory, named gmic_000000.png for example.

Enough for diagnostics. Let me troubleshoot both issues (slow gmic-blender) and (empty saving) come back to you in a next command. Thank you very much for reporting that slowness!

Note for now that to save a file in a gmic command string, you have two methods :

• either add no output keyword and provide an empty list variable in second parameter so that it will be filled with the resulting gmic images.. gmic images are in gmic bits format (non-interleaved RRRRRRRGGGGGGGBBBBB etc.. where each value is a 4-bytes float) and RAM-only, they can be output to python bytes. The following will work in a Blender 2.8x console editor type area:

import gmic
a = []
gmic.run("sp earth", a)
a # [<gmic.GmicImage object at 0x7f89b08573f0 with _data address at 0x1c770b0, w=500 h=500 d=1 s=3 shared=0>]
a[0]._data # some big pure-python bytes object
# in upcoming gmic-blender version a[0]._data_str is a unicode string... funky but useful for exporting gui json command definitions if you have patience

• simplest: add "output yourfilename.somefamousimageextension" to the end of your command, and this will save to your drive in your current working directory or elsewhere depending if your output filename is a full path:

import gmic
gmic.run("sp earth output ourearth.png")

[myselfhimself]

Further note on saving to file or buffer, gmic-py's Numpy is being prepared so that images can be exported to a numpy.ndarray buffer or imported from such a type. This is being prepared here but a bit on hold for now: myselfhimself/gmic-py#28

Here are the G'MIC display window's shortcut:

So... - CTRL + S: Save a screenshot of the current view, as a numbered file 'gmic_xxxxxx.png'.
I do not understand why my file is empty for now when saved from blender's gmic display window..

[j2l]

Thank you for testing and drilling this issue!
No problem it takes time when quality in response is here :)
Hope you'll find the solution soon.
A tantôt (dans le sens global, pas juste après-midi, j'étais 4 ans au Havre).

[j2l]

Actually, for me, it worked (Ubuntu 19):

Thank you for pointing me to the blender exe folder. It makes sense.

[myselfhimself]

Thank you!!!
Though this is a bit old school to save files like this... but I am happy that it works on your side.
Applying gmic filters to big images was already raised by Natron's developer as a pain, with a necessity to work on smaller size previews first. I think gmic already has this though...
Do you intend to work on fixed image or for video rendering ?
I was thinking of developing a little iteration further the example operators script, something with dynamic expressions of gmic, in pseudo code like : "gmic engrave <linear/trigonometric parameters related to current frame>"... also the resulting images or video could be opened back in Blender's image window. The idea would be to have "animated nodes", enabled over their own time intervals with varying parameters, but in a scripted way for now, without nodes.

[myselfhimself]

You seem to be the first known user of gmic-blender, what a honour :)
I have been to Le Havre only once...

[j2l]

I hope to use gmic on video.
the local files were just CTRL+S from your example, not useful as is.
I'd love to see reinjection of gmic into Blender!
Nodes will help get more users :)

[myselfhimself]

I forgot to test gmic-py itself. It could prepend a "gmic update" internet update command on "import gmic". This can be nonsense if true. If the 32bits hypothesis were false, the use of debug symbols may be the speed issue, or a non-linking against openMP. Let me come back to you

[myselfhimself]

@j2l could you please tell about your OS setup?

[j2l]

Ubuntu 19.10 (PopOS). GTX 970 and i5

[myselfhimself]

Thanks
@dtschump has pointed me to proper optimization flags for gmic-py itself
Let me come back to you

[myselfhimself]

printing gmic.__spec__ inside Blender's Python console shows that 64bits .so file of gmic-py is loaded on a 64bits linux PC

[myselfhimself]

Updating stats (on personal old 64bits linux laptop):

39 seconds outside Blender (using addon's 64bits .so)
38 seconds within Blender (uses the 64bits .so verified by `gmic.__spec__`)
19 seconds with gmic-cli

I will retry the first two cases with a gcc-optimized .so tomorrow latest

[myselfhimself]

The test script is:

import gmic
from time import time
a=time()
gmic.run("somefile.tga fx_engrave 0.5,50,0,8,40,0,0,0,10,1,0,0,0,1,0")
print(time()-a)

[myselfhimself]

Now with a magically fast computer for 100 engrave runs:

import gmic
print(gmic.__spec__)
g = gmic.Gmic()
for a in range(100):
    g.run("thumb-1920-935998.png fx_engrave 0.5,50,0,8,40,0,0,0,10,1,0,0,0,1,0")

gmic 2.8.4

• unoptimized (gmic-blender v0.0.7): 9m13,392s
• optimized (highest GCC optimizations traditionally used by G'MIC core unreleased yet): 2min39s

There is room for 4x optimization.

I need a few weeks before releasing gmic-py 2.9.0 or 2.9.1 with such optimizations; I will release gmic-blender v0.0.8 in turn embedding a faster G'MIC binding.

[j2l]

Great!

…

On Fri, Jun 19, 2020 at 5:02 PM Jonathan-David Schröder < ***@***.***> wrote: Now with a magically fast computer for 100 engrave runs: import gmic print(gmic.__spec__) g = gmic.Gmic() for a in range(100): g.run("thumb-1920-935998.png fx_engrave 0.5,50,0,8,40,0,0,0,10,1,0,0,0,1,0") gmic 2.8.4 - unoptimized (gmic-blender v0.0.7 <https://github.com/myselfhimself/gmic-blender/releases/tag/v0.0.7>): 9m13,392s - optimized (highest GCC optimizations traditionally used by G'MIC core unreleased yet <myselfhimself/gmic-py#39>): 2min39s There is room for 4x optimization. I need a few weeks before releasing gmic-py 2.9.0 or 2.9.1 with such optimizations; I will release gmic-blender v0.0.8 in turn embedding a faster G'MIC binding. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAP6LN6G3TF4HXBVMGXUJTRXN4W3ANCNFSM4NTLVNGQ> .

[myselfhimself]

Hi @j2l
gmic-py 2.9.0 is released with the expected 2x-4x optimizations, I will package a new addon for Blender soon.
I have started a flipbook project using Blender, we can share experiences further once the new addon is downloadable
Have a nice week-end

[j2l]

@myselfhimself great!
Will see the new package when I have time. Pretty hard right now.
Have a nice week

[myselfhimself]

You can download the new add-on version with a fresher optimized gmic-py here: https://github.com/myselfhimself/gmic-blender/releases/tag/v0.0.8

[myselfhimself]

OK we are good with the 2x-4x promised optimization of gmic-py 2.9.0.

After installing the v0.0.8 release add-on,
make sure that the following works within Blender, to be sure you have the right add-on version:

import gmic
print(gmic.__version__) # 2.9.0

On Linux x64 with Blender 2.80 on my old laptop, I get 37 seconds with v0.0.7 x gmic-py 2.8.4 versus 13 seconds for v0.0.8 x gmic-py 2.9.0, for an engrave operation for a 1920x* render.

Now I am interested in not using the gmic display window to show the result.

[myselfhimself]

Here is my test file
gmic_demo_lgm_2020_performance_test.zip