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
Attention students and mentors,
the midterm surveys for Google Summer of Code 2009 have begun.
Mentors: the results will decide about the fate of student's projects.
Please log in to http://socghop.appspot.com/ and follow the survey links in the
navigation bar on the left.
The deadline for
Oh
interesting topic!
To decide for a good "composition rendering strategy" I would suggest
to take a look at some verry similar applications like motion
compositig software.
This type of software is used to do non destructive image editing to
motion picture sequences in a way like GEGL
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:
Oh interesting topic!
To decide for a good composition rendering strategy I would suggest to
take a look at some verry similar applications like motion compositig
software.
very interesting input, indeed!
IMHO to render is exactly the word describing whats
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:
The spec is here:
http://gui.gimp.org/index.php/Save_%2B_export_specification#exporting_files
Quick version:
The default export path needs a settings switch for whether the original file
path (number 3) is higher-priority than the most-recently-used paths (numbers 1
and 2). This would support
On 07/08/2009 03:45 PM, Danko Dolch wrote:
3. If You create highend sophisticated GEGL graphs that take long long
to render even on you brand new Intel Beckton 16 core workstation ;-)
it would be handy to insert precalculated proxy nodes into the GEGL
node graph to speed things up by
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
Am Mittwoch, 8. Juli 2009 schrub Omari Stephens:
[...]
Thus, it seems like both ways of handling this default ([1, 2,
3] priority as well as [3, 1, 2] priority) are viable and useful. This is
why I suggest having a setting to switch between the behaviors.
What about providing some kind of
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
20 matches
Mail list logo
