Re: [Gimp-developer] Cross-application work-flows and document file formats

[twfb <twfb09 gmail com>]

On 03:26 Mon 21 May, Jon Nordby wrote:
> Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or
> .png hmmmmm
> 
> You say that only task 1 can potentially benefit from saving as xcf.
> XCF is the only format that can store what you have done to the image
> in a non-destructive way, and allow you to go back and change these
> decisions. In your work-flows 2-4, do you never go back to an image
> after having modified and saved it? Do you, like many others, keep an
> original .png and export the modified version as a .png with a
> different name, so you can always get the original?
> For instance when preparing textures and bump-maps, do you ever go
> back to tweak the textures after having used them in a Blender render
> (after looking at the initial result)?

For many of the cases above saving separate versions makes more sense as
you can then immediately reverse your changes by selecting the other
image. When the image is a layered one you have to go back to export
etc. I more or less always go back ;) multiple times. All those
workflows are highly iterative.

> To make this more tangible again, consider the case of creating
> textures as part of creating a still render of a photorealistic 3D
> scene. This is based on my  limited understanding of how 3d content
> creation works, so do correct any false assumptions.
> * [create-texture] A texture is created in GIMP either based on
> existing resources (i.e. off the web or from company or artist stock),
> or by starting from scratch (i.e. hand-painted or generated
> procedurally). The same techniques as when starting from scratch may
> also be applied when starting with a stock resource.
> * [use-texture] The texture is used in Blender as part of a 3d scene.
> The texture is put in after the objects in the scene have been
> modeled, potentially before the camera setup and definitely before
> lighting and compositing setup. The texture will be one of many
> textures used in the scene.

I'd just like to emphasise that the process is iterative and the order
at which various things are done is by no means pre-determined. The
texture will always be tweaked and replaced. The same is true for
photographs to be used in publications etc. 

> * [try-render] A render is produced from the 3d scene using Blender.
> If the output is not satisfactory, altering or changing the texture
> may be needed. This can happen simply because the texture does not
> look good enough, or a change in camera setup may give new
> requirements for the texture. In rarer cases the objects in the scene
> that the texture was used for might be replaced or removed entirely.
> In all of these cases, this would mean going back to the
> [create-texture] activity in GIMP. This process might be repeated
> several times.
> 
> Currently you likely save your texture as .png file and import that
> into Blender. But there are no intrinsic benefits of using a PNG file
> in this work-flow. So I would argue that optimizing PNG export in GIMP
> is the wrong place to optimize. Instead I propose the following steps
> to improve it:
> 1. Make Blender be able to render the .xcf as a texture. Benefit: .png
> export of .xcf or destructive .png save no longer necessary
> 2. Make Blender be able to "link" the texture to the original
> document, and to have a "Edit texture" option that would open it up in
> GIMP. Benefit: No longer necessary to re-establish the connection
> between the two documents when iterating between changing the texture
> and evaluating the render.
> 3. Make GIMP expose the documents it is currently working to Blender,
> and let Blender provide a UI for importing these. Benefit: No longer
> necessary to find the file on disk, or even know that it is an .xcf
> file
> 4. Make GIMP expose changes to the active documents, and let Blender
> automatically update the texture when it has changed. Benefit: Don't
> have to explicitly refresh the texture inside Blender.
> 5. Implement 2-4 for GIMP itself. Benefit: When the texture is a
> derivative work of other documents, those links will also be easy to
> establish and maintain.
> 
> > Task no 1 is often based on images prepared using 2,3,4 beforehand. This
> > means that a *vast* majority of saves and opens fall into categories
> > where xcf seriously slows you down.
> Point 5. above would directly address that as well.
> 
> There are some technical challenges to implement these steps, but they
> are all doable. And I believe that they have a much higher potential
> to improving this work-flow (and similar ones) than making it easier
> to save PNG files.

People have individual preferences but I feel rather strongly that the
"unix way" is a good one. Ie have specific tools for specific jobs. The
advantage of using png, jpeg or tiff is that all software you might
conceivable want to use are capable of opening, *previewing* and saving
the formats. I highlight previewing as thumbnails are a critical part of
all these workflows. When the number of files grow they are critical.

Also my experiences from the proprietary world is that the complex image
formats are much more likely to break in curios and inexplicable ways.
Saying that not even jpg's are safe and can cause undebuggable problems
in layouts etc. Issues like these are a big no no when working on a
tight deadline. Using sane, well known formats as interchange files is
way safer and more predictable. The utility of being able to open files
in all software can not be over stated when the use case goes beyond
spending all your time in Gimp. I do also wonder which use cases pure
Gimp, can really think of any myself.

As mentioned elsewhere in the thread many of the problems could be
eliminated by somehow getting rid of "overwrite" and replacing with
"export".The thing is though that still adds multiple dialogs to simply
saving a change to a flat image. As mentioned perhaps allowing simple
save *only* for flat images is a fair compromise. I still preferred the
software trusting me to do the right thing though. 

Again thanks for a great piece of software that I use alot!

-- 
TWFB  -  PGP: D7A420B3