[Verse-dev] GIMP stuff

[Emil Brink]

Toni Alatalo wrote:
> 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..

Yeah, I guess it's the now classic issue most often found when trying
to get an existing application to "speak Verse"; existing apps are in
general not prepared for it. In such cases, rearchitecting the app is
better than hacking and kludging, if possible. With the GIMP, it sounds
as if it is, indeed, possible.

> 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.

Yes, that is true I understand. I'm just not sure how that maps onto
Verse, I was thinking with the current "core" Verse image model in mind.

> 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

Hm ... Not sure I follow, here. Jiri seems to talk mostly about the
opposite of how I read that, i.e. representing several layers of a
"richer" image format (such as in the GIMP, or PS) as layers in a
single Verse bitmap node. Do you mean that, or do you want to split
them out into separate Verse 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)

Right. That's interesting stuff, but I'm not sure if it is in the
future for Verse ... Haven't talked to Eskil about it, but I would
*suspect* that exposing a full image composition system for each
bitmap is not quite where he would like to take things. Normally,
Verse is more about sharing the result in some lowest-common deno-
minator, than the all the steps a given tool took to get there.

The material node's operator graph structure might look like evidence
to the countrary, but ... I can't think of any obvious way to represent
the "end result" of a 3D shader. For bitmaps, there is always the
final composited result available, though.

If Verse bitmaps were to support such things like layer operators at
the bitmap level, then writing e.g. a textured model renderer just
becomes twice as hard, since you'd need to integrate bitmap operations
and material operations into the same rendering pipeline.

>> <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).

Yeah ... I'm not sure I'm with you about structure, but it should be
possible to map other layers than just "color" into Verse layers. So
you could have an image that contains both e.g. color and bump and/or
reflection values, and have it export as a single Verse node with an
appropriate set of layers, just as Jiri describes.

A few minor points on Jiri's text, by the way (long overdue, sorry):

 > "color_space:would be VN_TAG_BLOB tag storing string"

I think that's a typo, should probably be a VN_TAG_STRING tag.

 >  * R_channel name of verse layer containing red channel
 >  * G_channel name of verse layer containing green channel
 >  * B_channel name of verse layer containing blue channel

These seem like a rather radical departure from the existing standard,
which is to use "color_{r,g,b}". I'm not sure I understand why. Btw,
many tools are currently lagging here, and using the older "col_{r,g,b}"
names instead. I aim to address that shortly.

> 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 :)

Heh. I had that thought too, during the review. It should not be too
hard I guess, except for coming up with a decent architecture for doing
paint tools in a nice way. It was many years since I did something like
that. Unfortunately, I don't think I have the time now. Also, reinven-
ting wheels is probably not something I can do officially. :)

Regards,

/Emil