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

[Jon Nordby <jononor gmail com>]

Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or
.png hmmmmm

On 20 May 2012 20:02, twfb <twfb09 gmail com> wrote:
> 1. Large complex, multilayered collage type images aiming for close to
>   photorealism. Often painting shadows etc.
> 2. Adjustments to photographs, curves, sharpness, size perspective corr.
> 3. Lo res images and graphics for websites.
> 4. Preparation of images for use as textures, bumpmaps etc for 3d
>   visualisation software. I mainly use Blender and Luxrender.
>
> The thing is that of all those tasks only no 1 could potentially benefit
> from the safety feature of xcf only save. But even there it actually
> gets in the way. I've never accidentally lost work due to saving in the
> wrong format. And I'm in my mid 30's having done graphics for ever ;)

Thanks for bringing the workflows/tasks you have do into the
discussion. That makes it much easier to have a fruitful discussion.

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

> As mentioned I really like Gimp and I'm grateful for your hard work. I
> understand that the vision is for Gimp to become great at complex tasks
> as no 1. I'd just like to emphasize that in my case, and I believe it
> will be the same for others, way more saves (and opens) will be to
> jpg,png etc than to xcf.

I think your cases highlights one important thing: users will often
(always) use GIMP as part of a bigger work-flow. They import zero or
more documents, produce a new document there in GIMP and then will
pass this document on to another application.

For us to be able to significantly improve such work-flows, we need to
optimize the entire chain of activities (and the interfaces between
them). We cannot just focus on the activity inside GIMP in isolation.
This is especially true when the fraction of the total activity time
spent in GIMP is small compared to the time spent in the other
activities, or when moving between activities makes up a significant
amount of time.

Does such work-flows exist in the valid user scenarios for GIMP? I
would love to see the user scenarios we have already also include the
context in which GIMP is used, and how the usage of GIMP is related to
activities done in other applications.

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

-- 
Jon Nordby - www.jonnor.com