that seems really powerful to me, and I hope to see some form of visual
node representation beside the classic layer view some day... (yes the
one in Blender is great ;-)
Today a motion compositor is sometimes the better tool to do a complex
non destructive still composit because of things
hi,
Danko Dolch schrieb:
A node view is your friend and sould not be hidden from the user - just
entry level users have a better understnding from a physical pipeline
based view than a complex layer tree...
But Rome wasn't build in a day either - I know - first things first ;-)
well,
2009/7/8 yahvuu yah...@gmail.com:
Nicolas Robidoux schrieb:
At start-up, the user could be presented with a list of unfinalized
workspaces, and asked whether to finalize each, or open each.
just for clarification: by workspaces you're referring to nip2 workspaces,
which roughly translate to
hi,
Nicolas Robidoux schrieb:
At start-up, the user could be presented with a list of unfinalized
workspaces, and asked whether to finalize each, or open each.
just for clarification: by workspaces you're referring to nip2 workspaces,
which roughly translate to GIMP compositions, correct?
hi,
Martin Nordholts schrieb:
On 07/07/2009 01:35 PM, yahvuu wrote:
I see two poles for the rendering strategy, both of which have downsides:
- eager rendering: render as soon as possible, latest when
saving the composition
Hi yahvuu
I don't see why the whole
Peter:
just for clarification: by workspaces you're referring to nip2 workspaces,
which roughly translate to GIMP compositions, correct?
Yes. (More or less, a (possibly unfinalized) tree.)
(I suppose composition sounds a little more artistic ;-)
Nicolas Robidoux
Universite Laurentienne
Am Mittwoch, 8. Juli 2009 schrub yahvuu:
[...]
The user sends a JPEG to a colleague for review -- takes 2 hours to render.
The image is OK, the user creates a TIFF for the print shop -- takes 2
hours again.
I think in this case, the user would be better off if he had some
control about
hi,
Tobias Ellinghaus schrieb:
Am Mittwoch, 8. Juli 2009 schrub yahvuu:
[...]
The user sends a JPEG to a colleague for review -- takes 2 hours to render.
The image is OK, the user creates a TIFF for the print shop -- takes 2
hours again.
I think in this case, the user would be better
Hi Peter!
yahvuu wrote:
hi,
Tobias Ellinghaus schrieb:
Am Mittwoch, 8. Juli 2009 schrub yahvuu:
[...]
The user sends a JPEG to a colleague for review -- takes 2 hours to render.
The image is OK, the user creates a TIFF for the print shop -- takes 2
hours again.
hi,
Danko Dolch schrieb:
What about taking the cache with you? e.g. switch to another workstation
- would be cool to have an option to store the cache external too...
cool, yes. But even more corner cased than the case of very expensive
compositions already is for GIMP.
yahvuu wrote:
Hi Peter!
yahvuu wrote:
hi,
Danko Dolch schrieb:
What about taking the cache with you? e.g. switch to another workstation
- would be cool to have an option to store the cache external too...
cool, yes. But even more "corner cased" than the case of very expensive
Am Mittwoch, 8. Juli 2009 schrub Danko Dolch:
[...]
I've a screenshot for you - showing a layer tree and a node based view
side by side. The node view is more pleasing to read if you try to
understand whats going on.
http://www.dolchonline.net/prj/gimp/combustion_scr01.jpg
I personally
hi,
Tobias Ellinghaus schrieb:
[..] Thus the cool things like several sources or forward
edges (think of a bumpmap on a layer which uses the same layer as source) are
not possible.
GEGL has a 'clone' operation that should enable what you're seeking.
Have a look at the example with the same
On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote:
And AFAIK GEGL
uses trees of nodes.
This is wrong, GEGLs image processing structure is a directed acyclic
graph, one output node can be connected to several input nodes.
/ Martin
___
Gimp-developer
On 07/08/2009 08:45 PM, Martin Nordholts wrote:
On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote:
And AFAIK GEGL
uses trees of nodes.
This is wrong, GEGLs image processing structure is a directed acyclic
graph, one output node can be connected to several input nodes.
/ Martin
Make that
On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaush...@gmx.de wrote:
Am Mittwoch, 8. Juli 2009 schrub Danko Dolch:
I personally love the node editor of blender and would like to see something
like that in GIMP. The only problem with these node setups (like the one in
your screen shot) is that
Am Mittwoch, 8. Juli 2009 schrieb Martin Nordholts:
On 07/08/2009 08:45 PM, Martin Nordholts wrote:
On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote:
And AFAIK GEGL
uses trees of nodes.
This is wrong, GEGLs image processing structure is a directed acyclic
graph, one output node can be
hi all,
with GEGL's ability to only render what is visible on the screen
(and ideally in that very resolution) we are comfortably spoilt
for choice by when to render a composition to full resolution.
While saving the user's work -- which amounts to the GEGL tree -- can
be done quite quickly
Peter:
The best solution i've found so far is to first save the GEGL tree
to make shure the user's work is safe. After that, rendering will
start, and the image window gets overlayed by a lightbox displaying
the rendering progress and a button 'schedule rendering for later'.
I don't think
Nicolas Robidoux writes:
I am not sure that I have a better suggestion. Save workspace vs
Save image?
... but it makes lots of sense that the tree be saved just before
rendering unless this is overridden by the user.
Nicolas
___
Gimp-developer
hi,
Nicolas Robidoux schrieb:
I don't think that using the word rendering in a menu will be
self-explanatory for non-sophisticated users when used in a save
context.
oh yes, indeed. 'Creating full resolution...' is probably less suspicious
but won't solve the problem. The ugly part is that
yahvuu writes:
Another alternative is to go with lazy rendering and introduce
a 'finalize image' command that optionally renders to full resolution.
This way, the save/render distinction won't show up until it is really
desired by the user.
I like finalize image.
The additional
Nicolas Robidoux writes:
The additional command may be required anyway as a means to reduce file
size by dropping some non-destructiveness. See last image in
http://gimp-brainstorm.blogspot.com/2009/04/version-control.html
The way nip2/vips deals with a somewhat related
On 07/07/2009 01:35 PM, yahvuu wrote:
I see two poles for the rendering strategy, both of which have downsides:
- eager rendering: render as soon as possible, latest when
saving the composition
Hi yahvuu
I don't see why the whole composition would have to be rendered
24 matches
Mail list logo
