2009/7/8 yahvuu :
> 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 co
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
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 lik
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 outpu
On Wed, Jul 8, 2009 at 7:26 PM, Tobias Ellinghaus 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 they are
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
>
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-develope
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 sam
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 personal
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
compos
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,
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,
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 woul
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 abou
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 Laurenti
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 w
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?
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 rend
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 re
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 additio
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 t
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-develope
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 thin
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 (assu
24 matches
Mail list logo
