Re: [Gimp-developer] Cross-application work-flows and document file formats
On 12-05-22 11:25 AM, Alexandre Prokoudine wrote: www.adobe.com/devnet-apps/photoshop/fileformatashtml/ 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. -- Cheers! Kevin. http://www.ve3syb.ca/ |Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful! #include disclaimer/favourite | --Chris Hardwick ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Jon Nordby jononor at 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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 9:30 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: Jon Nordby jononor at 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... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexia Death alexiadeath at 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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 10:26 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: Alexia Death alexiadeath at 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. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Alexandre Prokoudine alexandre.prokoudine at 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? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Von: Alexia Death alexiade...@gmail.com 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 smime.p7s Description: S/MIME cryptographic signature ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Cross-application work-flows and document file formats
Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm On 20 May 2012 20:02, twfb twf...@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
