Cross-application work-flows and document file formats
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Cross-application work-flows and document file formats
Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 20 May 2012 20:02, twfb 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.
Cross-application work-flows and document file formats
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!
Cross-application work-flows and document file formats
Jon Nordby gmail.com> writes:
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.
That reminds me - it would be great if the "save" feature also supported PSD (As opposed to export). I can think of only one showstopper: text layers, which are currently always converted to raster, and a further complication of how to preserve the text data on a text layer that has been modified using another tool.
The reason is that some 3D and video editing programs support PSD natively and even allow importing specific layers, so in some workflows, it is not enough to just have a layered formats - it has to be PSD specifically.
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 9:30 AM, Michael Grosberg wrote:
Jon Nordby gmail.com> writes:
That reminds me - it would be great if the "save" feature also supported PSD (As opposed to export). I can think of only one showstopper: text layers, which are currently always converted to raster, and a further complication of how to preserve the text data on a text layer that has been modified using another tool.
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features. PSD is not a gimp format, it will never be able to do that. Hence PSD will always be an export. One that supports as much as possible of the PS feature set, sure, but still an export. And gimp already natively supports importing/exporting PSD-s...
Cross-application work-flows and document file formats
Alexia Death gmail.com> writes:
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features.
It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN.
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 10:26 AM, Michael Grosberg wrote:
Alexia Death gmail.com> writes:
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features.
It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN.
Even in a fully geglified non-destructive GIMP? It may today, but GIMP changes.
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 11:26 AM, Michael Grosberg wrote:
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features.
It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN.
There is NO need to SHOUT, Michael.
The principle of the thing is that saving and opening should always be safe in terms of access to extra project data.
If you think about it in the long-term (say, non-destructive editing implementation), you'll see that safe saving and opening PSD in GIMP would be hell.
Alexandre Prokoudine http://libregraphicsworld.org
Cross-application work-flows and document file formats
Alexia Death gmail.com> writes:
On Tue, May 22, 2012 at 10:26 AM, Michael Grosberg gmail.com> wrote:
Alexia Death gmail.com> writes:
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features.
It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN.
Even in a fully geglified non-destructive GIMP? It may today, but GIMP changes.
It depends on what features this version will have. Gimp will have to go far to attain the level of non-destructiveness Photoshop currently has. My bet is, whatever feature you can think of in terms of non-destructiveness, Photoshop already has it.
Cross-application work-flows and document file formats
Alexandre Prokoudine gmail.com> writes:
On Tue, May 22, 2012 at 11:26 AM, Michael Grosberg wrote:
This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features.
It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN.
There is NO need to SHOUT, Michael.
writing an single word in uppercase is a way to emulate stressing a word in speech; it's uppercasing an entire sentence that's considered shouting. But I'll use a different convention from now on. is *this* OK?
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 12:21 PM, Michael Grosberg wrote:
Even in a fully geglified non-destructive GIMP? It may today, but GIMP changes.
It depends on what features this version will have. Gimp will have to go far to attain the level of non-destructiveness Photoshop currently has. My bet is, whatever feature you can think of in terms of non-destructiveness, Photoshop already has it.
How cheeky would it be from me to encourage you to actually study what GEGL is? :)
It's a goddamn graph compositing engine. (Sorry, I'm still under impression from the Oatmeal's Tesla comic).
You can take a buffer, pass it thorugh a colorspace converter (rgb2lab), pick a channel and plug it into a specific input of a GEGL operation, then plug the output into another colorspace converter (lab2rgb).
And you expect PSD to store the GEGL graph tree? Really?
No way Jose :)
Alexandre Prokoudine http://libregraphicsworld.org
Cross-application work-flows and document file formats
Alexandre Prokoudine gmail.com> writes:
It's a goddamn graph compositing engine. (Sorry, I'm still under impression from the Oatmeal's Tesla comic).
You can take a buffer, pass it thorugh a colorspace converter (rgb2lab), pick a channel and plug it into a specific input of a GEGL operation, then plug the output into another colorspace converter (lab2rgb).
And you expect PSD to store the GEGL graph tree? Really?
I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it. But it's your project, do what you feel right. Personally I hate node based compositing, but perhaps you have a target audience for it, somewhere among the 3d shader specialists.
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 2:30 PM, Michael Grosberg wrote:
I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it. But it's your project, do what you feel right. Personally I hate node based compositing, but perhaps you have a target audience for it, somewhere among the 3d shader specialists.
Yes, we do intend to keep the ui layer based, but inside it will be a graph, one that is modified by default as layers and operations on those layers. But we fully intent to store the graph and not the facade for further editing.
Cross-application work-flows and document file formats
Michael Grosberg wrote:
I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it.
not to worry, you will not be abducted by boxes and hoses.
GIMP is an image manipulation program, not a 3D or broadcast post processing app. so its UI is designed according to it.
but the full power of GEGL will be at your fingertips...
--ps
founder + principal interaction architect man + machine interface works
http://blog.mmiworks.net: on interaction architecture
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 3:30 PM, Michael Grosberg wrote:
And you expect PSD to store the GEGL graph tree? Really?
I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it. But it's your project, do what you feel right. Personally I hate node based compositing, but perhaps you have a target audience for it, somewhere among the 3d shader specialists.
It's been a while since GEGL last ate anybody's babies :) Goats aren't natural carnivores.
UI to GEGL is quite irrelevant to file format. It's data flow and relations between objects what matters when it comes to storage.
Alexandre Prokoudine http://libregraphicsworld.org
Cross-application work-flows and document file formats
Von: Alexia Death
Yes, we do intend to keep the ui layer based, but inside it will be a graph, one that is modified by default as layers and operations on those layers. But we fully intent to store the graph and not the facade for further editing.
And IIRC we even discussed the possibility that XCF - in its present form - may become a format that can only be imported and exported, and not saved.
Whatever GIMP's capabilities will be, we won't let any file format limit us - not even our own.
I can even imagine a version of GIMP that doesn't need an explicit Save method anymore - because no image data is saved in a heavy-weight file, only the edits and adjustments, and you will be able get Exports/Snapshots (or whatever you may call them) from any point and any time in the processing graph.
Regards, Michael
Cross-application work-flows and document file formats
On 22 May 2012, at 15:36, Michael Schumacher wrote:
And IIRC we even discussed the possibility that XCF - in its present form - may become a format that can only be imported and exported, and not saved.
Whatever GIMP's capabilities will be, we won't let any file format limit us - not even our own.
I can even imagine a version of GIMP that doesn't need an explicit Save method anymore - because no image data is saved in a heavy- weight file, only the edits and adjustments, and you will be able get Exports/Snapshots (or whatever you may call them) from any point and any time in the processing graph.
I totally agree- I could imagine an non-explicit save working something like this in the future, too. Especially in the context of the multiple window situation, which also needs to be looked at and integrated into the UI design at some point (!). Lots of work to do on this line of thought.
Kate
Cross-application work-flows and document file formats
On 12-05-22 02:30 AM, Michael Grosberg wrote:
The reason is that some 3D and video editing programs support PSD natively and even allow importing specific layers, so in some workflows, it is not enough to just have a layered formats - it has to be PSD specifically.
While PSD format *might* support saving all GIMP data, it doesn't currently (text layers are converted to bitmaps IIRC). The XCF file format is subject to change as GIMP evolves. The other problem with this is that the PSD format is mostly undocumented and changes over time.
Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 7:10 PM, Kevin Cozens wrote:
While PSD format *might* support saving all GIMP data, it doesn't currently (text layers are converted to bitmaps IIRC). The XCF file format is subject to change as GIMP evolves. The other problem with this is that the PSD format is mostly undocumented and changes over time.
www.adobe.com/devnet-apps/photoshop/fileformatashtml/
Alexandre Prokoudine http://libregraphicsworld.org
Cross-application work-flows and document file formats
On 12-05-22 11:25 AM, Alexandre Prokoudine wrote:
Thanks, Alexandre. Good to see that the publically available information on the PSD file format has been updated to include something beyond PS6. Let's hope the information always stays public. The information in that page will make it possible for someone to update the PSD plug-in to fully support text layers.
Cross-application work-flows and document file formats
On Wed, May 23, 2012 at 7:33 PM, Kevin Cozens wrote:
Thanks, Alexandre. Good to see that the publically available information on the PSD file format has been updated to include something beyond PS6. Let's hope the information always stays public. The information in that page will make it possible for someone to update the PSD plug-in to fully support text layers.
Or layer groups :) And port the plug-in to GEGL anyway :)
Alexandre Prokoudine http://libregraphicsworld.org
