[Verse-dev] GIMP stuff

[Toni Alatalo]

On 28.4.2006, at 12:37, Emil Brink wrote:

> This might be of interest mainly to Brecht and/or Jiri, but I thought
> I'd share with the list at large anyway.

good thinking.

> * Sven said the work needed inside GIMP should be smaller than the
>   work needed to write the plug-in as it stands now (I linked to the
>   code during the discussion). Brecht can probably comment here, as as
>   far as I've understood, he's started looking into patching GIMP.

same seems to be often true with the Blender py API as well, i always 
try to convince ppl to fix api probs they are encountering instead of 
working around the limitations..

but to the point:

> <tml> emil:is there some X extension to look for that? do you need the 
> actual gimp layer-level change information, or just that the view of 
> the image on screen changes?
> <emil> tml:  the latter, just the final display-ready pixels ... but I 
> would prefer not to depend on X

i think you were wrong there: like i wrote to the orange report draft, 
based on what Matt and Basse were pointing out, multilayered image 
support and dealing with image layers is certainly interesting at least 
for texturing/materializing work.

like the Proog material textures used in the demos this week, is 
actually one gimp file - textures/proog.xcf - then the used bitmaps are 
there as layers: color, bump and spec as their own. what would be great 
for the workflow we were looking at would be to have Verse Gimp and 
Blender etc. tools be able to work with that - e.g. having the gimp 
layers show over verse in other tools as separate bitmaps

Jiri addresses this in his proposal about dealing with that layer 
information with Verse, Proposal of Image Auxiliary Specification, 
http://e-learning.vslib.cz/~hnidek/verse_spec_proposal/ - that i refer 
in the docu (only Ton has the latest version of it now)

> <neo> but if you really only want to share the projection, just use 
> VNC or something similar

so that is exactly not what we want. no projection, but data, and 
preferrably all data and nicely structured (i.e. all layers separately 
and perhaps info about the layer structure).

one thing i've been thinking that might be interesting would be writing 
a simple paint tool from scratch with optimal verse integration in 
mind, to experiment with how the integration to that functionality can 
be made (and how not). (i would write the paint tool in py of course, 
have actually made some company internal paint tools earlier for other 
purposes and it's quite fun :)

~Toni