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] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: I'm not totally against the idea of a project, but I wonder if it's really necessary to create a project folder with assets considering that XCF is intended to store all that stuff in a single file. The reason is that a GIMP project may contain more than one finished product; XCF only collects data relevant to *one* image. For example, I may want to produce various sized versions of a logo. In addition, XCF does not contain information about how GIMP windows and tools were organized around the related collection of output images. A project would, in my mind, collect everything: related images and GIMP configuration. ___ 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
Re: [Gimp-developer] Problems with brushes
Date: Mon, 21 May 2012 20:12:09 +0200 From: martin...@gmx.ch To: strata_ran...@hotmail.com CC: gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] Problems with brushes hi Richard The opacity problem (stroke opacity vs dab opacity) can be fixed mathematically. Grep for OPAQUE_LINEARIZE in the mypaint source code. The last time I reported it (bugzilla #588984) I was told Not A Bug but also discuss on mailing list. I did not have access to said mailing list that time ago - but I do now. So yes, let's. If I set my tool to 50% opacity I want the visible end result of a single (non-overlapping) stroke to be 50% opacity. Whether or not I have incremental mode enabled should make absolutely no difference in this context; it should only make a difference when parts of a stroke overlap or intersect each other (such as shading one area back-and-forth). -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 05/22/2012 08:05 AM, Nicolas Robidoux wrote: On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: I'm not totally against the idea of a project, but I wonder if it's really necessary to create a project folder with assets considering that XCF is intended to store all that stuff in a single file. The reason is that a GIMP project may contain more than one finished product; XCF only collects data relevant to *one* image. For example, I may want to produce various sized versions of a logo. Seems to me a project is a superstructure whose character is broadly independent of the nature of the tasks it contains. A project incorporates tasks, resources, status, sometimes even schedules -:-) - and when opened presents the entirety of the project scope. Kinda eclipse-like. -- Burnie ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] feature: Set exclusive layer visibility within groups
I have a little gripe about setting exclusive visibility (shift+click a layer's visibility icon) in an image. Now that we have layer groups in GIMP 2.8, it only functions on the top level of the layer stack -- it seems impossible to toggle exclusive visibility inside a group. Since a layer group can itself be a complex combination of layers (apparently including other layer groups!), we should have some ability to toggle exclusive visibility with respect to other members in that group only. For example, the current behavior could be expanded from a simple on/off toggle to an iterative loop somewhat like this: 1 - When toggling exclusive visibility, first note the full path from image root to the selected item (inclusively) and begin iterating through it. 2 - IF at any point along this path there are any visible sibling items, THEN hide them, leaving only the selected item visible, and break and return. 3 - Otherwise, if we have traversed the entire path without finding any visible siblings, then selected item is the only visible item in the whole image. (Whether the selected item is itself a layer or group is irrelevant.) Therefore, traverse the selected path again and ensure that any and all sibling items at any point along the path are made visible. This would establish a toggle chain of all items - selected group - (subgroup, etc.) - selected item in group - all items. It could also be reversed; all items - selected item in group - selected group - (parent group, etc.) - all items, but I'm not exactly sure how that logic would pan out. Note that in the simple case of an image with no layer groups, this quickly reduces to the current behavior of all items - selected layer - all items. (This also applies when setting exclusive visibility on a top-level group, because in that case we DO want to act on the group as a whole). -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
