Re: [Gimp-developer] Save + Export proposal
photocomix wrote: i knew that Peter Sikking (or somebody else from Gimp UI brainstorm staff)replied but the message get lost for technical problems (full storage disk) yes, I am (by default) the Gimp UI brainstorm staff, and I had about 3 threads going on here before the list collapsed. I am very interested to know the content of that reply,i hope you may send again now here we go: OK, I waited with replying because I wanted to think about this carefully. that is because quite a few issues are combining here. first two fundamental issues: 1) let's face it: this is a new feature request. it is not that we broke something in this 50 pictures a day (10 minutes each) workflow. actually, on balance things got a bit better for this with clear saving and exporting. 2) an even bigger picture: does GIMP has to solve this problem? since part of what you want is a no-brainer conversion from png to jpeg. sounds like a job for a batch tool. this way you would save your GIMP file, then ctrl-shift-E, return, return, and GIMP does remember if you wanted TIFF or png all the time. run the batch job at the end of the day. so why not add it anyway, doesn't hurt no? yes it does: - by associating 2 or more export files, Export to foo.png (ctrl-E) has to be redesigned and never be as good as now. - you have coupled saving to exporting of multiple files, hard. in general these things do not happen at the same time, saving work is a different thing then delivering. write times go up by a factor of 1+N, where N is the number of export formats. - so it is easy to set (well, you will have to 50 times a day) but how to stop it for a file? it was in the Save dialog, but to get there again? Save as? - UI also needs to be not-error-inducing and give a clear model to users to how things work. this proposal here is one of several to get a litle bit of export back into the Save dialog. each of these creates _a_ way to export, that users may figure out as _the_ way to export, because they are migrating from 2.6 to 2.8. No, it does not help that we have clear Export on the File menu. we simply cannot let these models of export develop. so that is why I am against this. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
On Tue, Oct 20, 2009 at 11:02 AM, peter sikking wrote: so that is why I am against this. --ps Even that said, anyone is free to develop a save and export plugin and offer it up for public consumption. It may not make it into the core, but assuming it is worthwhile, it will find use. -Rob A. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
[Looks like every time I post, I kill the list. My apologies; reposting] On 2009-10-05, photoco...@gmail.com for...@gimpusers.com wrote: So why do not offer a chance to speed up the workflow, save time and patience achieving both result simultaneusly ? A image is worth 1.000 words ,to avoid misunderstunding i invite to give a look to this mock up http://farm3.static.flickr.com/2653/3981269891_998c2f513b_o.jpg Suppose you do this. You edit something, and press C-s. What would happen? Ilya ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
Hi, On 10/05/2009 02:10 AM, photoco...@gmail.com wrote: But even if conceptually different in practice , both operation are always needed for the every edited image: is needed to Save the original AND to export as jpg or png . This assumption is wrong. Complex compositions will need to be refined for weeks. All work is done in XCF. Before final delivery there is only an occasional need to export to some other format. / Martin -- Latest blog post Sunday, October 4, 2009: Single-window mode progress report My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
On Mon, 2009-10-05 at 22:24 +0200, Martin Nordholts wrote: Hi, On 10/05/2009 02:10 AM, photoco...@gmail.com wrote: But even if conceptually different in practice , both operation are always needed for the every edited image: is needed to Save the original AND to export as jpg or png . This assumption is wrong. Complex compositions will need to be refined for weeks. All work is done in XCF. Before final delivery there is only an occasional need to export to some other format. Actually the two statements don't contradict each other -- it's fair to say that the most likely workflows are (1) load image (jpeg. png, tiff, cr2, etc) work on image maybe save image in proprietary format temporarily, between sessions eventually, do at least one of . save in archive format (tiff, png) . export to jpeg or gif or .mov or whatever . print (2) create new image, and rest as above. And in most cases you'll need to export the image at some point, for every image. It's got a little harder to track what you've done, now, because you need to know if the export filenames are up to date as well as the xcf filenme, and right now you can't tell. E.g. an image file history panel showing save status, or adding save export events to the undo history (even though you can't undo them they are part of the history) might help. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + Export proposal
photoco...@gmail.com wrote: ::snip? SNIP!:: As you may see the idea is not to replace the Export dialog, but to offer a handy option from the Save dialog, to simultaneously export , with same name and in the same directory in other file formats Wouldn't this be fairly straightforward to do as a plugin/python-fu/script-fu? Adding code makes things slower. If this isn't something that would benefit the vast majority of GIMP users (and I'm not sure it would), it seems better to offer it as an option for those who want it, rather than to add extra code for the users who won't touch it. --xsdg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save/Export Patch
On Wed, Sep 16, 2009 at 1:16 PM, James Hughes wrote: Hello, Can someone advice me the best place to start in making a patch to the UI to revert the 2.7 version to using the 2.6 style save dialogue. If someone would kindly point me in the right direction of which files I need to change would really appreciate it. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html Sticking a fork into GIMP was never successful. Most everybody who tried didn't get as far as picking a knife with the other hand. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save/Export Patch
On Wed, Sep 16, 2009 at 1:32 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Sep 16, 2009 at 1:16 PM, James Hughes wrote: Hello, Can someone advice me the best place to start in making a patch to the UI to revert the 2.7 version to using the 2.6 style save dialogue. If someone would kindly point me in the right direction of which files I need to change would really appreciate it. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html Sticking a fork into GIMP was never successful. Most everybody who tried didn't get as far as picking a knife with the other hand. 10pts for good humor. To the fork operator, in all seriousness tho, look at git. Relevant commits are clearly marked. However, the remark above is 100% true. Just stick to 2.6 if you like that so much. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save/Export Patch
On 09/16/2009 11:16 AM, James Hughes wrote: Hello, Can someone advice me the best place to start in making a patch to the UI to revert the 2.7 version to using the 2.6 style save dialogue. If someone would kindly point me in the right direction of which files I need to change would really appreciate it. Hi James, The first work regarding save+export was merged to git master in commit cd8829b91b3a. Type gitk cd8829b91b3a in your GIMP git repo and you'll see the initial commits. After that, development has happened incrementally directly in git master so you'll need to manually browse the commits and identify the relevant ones. HTH, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save/Export Patch
On Wed, 2009-09-16 at 10:16 +0100, James Hughes wrote: Can someone advice me the best place to start in making a patch to the UI to revert the 2.7 version to using the 2.6 style save dialogue. If you can bear it, I'd say wait a little longer - the design is still evolving, and I think it's improving. Also, you can of course say what about the new design is making things harder for you, and maybe that will help. For me the hardest thing left is that GIMP doesn't remember the right directory to export images, and that's already being fixed, or at least the design is in place now. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote: One notable change is that Ctrl + E is now bound to File-Export by default instead of View-Shrink Wrap. Hopefully this change will not be too much of a pain. We may need to consider finding a new keyboard shortcut for View-Shrink Wrap. From what I remember both Inkscape and Scribus use Ctrl+Shift+E for exporting. Why not be consistent with them and don't have to look for a new shortcut for View-Shrink Wrap? :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Alexandre wrote: On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote: One notable change is that Ctrl + E is now bound to File-Export by default instead of View-Shrink Wrap. Hopefully this change will not be too much of a pain. We may need to consider finding a new keyboard shortcut for View-Shrink Wrap. From what I remember both Inkscape and Scribus use Ctrl+Shift+E for exporting. Why not be consistent with them and don't have to look for a new shortcut for View-Shrink Wrap? :) there is a couple of things I know for sure: - both Export and 'Export to org.file' need a shortcut. - one of these shortcuts needs to be a shift variant of the other. - 'E' is too good of a shortcut not to use for both of them. so shrink wrap and fit image in window are looking for new shortcut. deciding which one should be ctrl-E and which shift-ctrl-E is a rational vs. feeling kind of struggle with many factors. after checking out Inkscape and Scribus, I think Alexandre just added another valid factor, which means that the balance just tipped the other way: Export should be shift-ctrl-E 'Export to org.file' should be ctrl-E --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
peter sikking wrote: after checking out Inkscape and Scribus, I think Alexandre just added another valid factor, which means that the balance just tipped the other way: Export should be shift-ctrl-E 'Export to org.file' should be ctrl-E Makes sense, I'll swap the shortcuts. It is quite ironic though that Inkscape has something similar to Shrink Wrap on ctrl-E :) / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Martin Nordholts wrote: Hi I have been working on implementing the Save + export spec [1] for a while. And I have also merged the base work to GNOME master now, so to try it out all you have to do is git pull. There is still work to be done (see the merge commit message) but we are definitely ready for some broader testing. One notable change is that Ctrl + E is now bound to File-Export by default instead of View-Shrink Wrap. Hopefully this change will not be too much of a pain. We may need to consider finding a new keyboard shortcut for View-Shrink Wrap. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Michal wrote: This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is: a file is only safe when it is Saved (in xcf) this means that export is never the solution to unsaved changes and Export and Export to foo.png cannot be there in the dialog as ways to resolve the situation. O.K., but I may not care if file is safe or not. All I want is to have that changed file on my disk. I don't mind if it's saved or exported. Why make things complicated for this kind of users? we currently have a mess and it needed straightening out by a clear separation of save and export. the clear separation is destroyed for users as soon as there is one hint that and export is also save/safe. Next: It's not clear what will happen to my foo.png file after I choose Save image as 'Untitled.xcf'. Will my foo.png be changed as well? Will my foo.png disappear because it's now safe as 'Untitled.xcf' and I don't need it any longer? foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. to answer your question: foo.png is not touched on disk unless you use Export to foo.png in the file menu. easy, no? Maybe it'd be better to completely rearrange that dialog to something like: If you close the image, changes from last minute will be lost. You can either save image as 'Untilted.xcf' or export it to any other format CLOSE CANCEL SAVE EXPORT sorry, not a hint... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Hi all, peter sikking schrieb: foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. that's a really good idea! Regarding export/import, GIMP's document model is much like Inkscape's, with the difference that for the latter, it is immediately understandable why... Still, i very much hate to send users into one-way streets, and for the open=import case, this is not planned. I wonder if we can't somehow ease the case where export=save? Perhaps via a shortcut like 'export to PNG close document discard data'? When export is just a branch in the workflow and editing continues on the GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG save backup'? just a rough thought, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
peter (yahvuu) wrote: peter sikking schrieb: foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. that's a really good idea! Regarding export/import, GIMP's document model is much like Inkscape's, with the difference that for the latter, it is immediately understandable why... Still, i very much hate to send users into one-way streets, and for the open=import case, this is not planned. right, that is an obvious optimisation. I wonder if we can't somehow ease the case where export=save? Perhaps via a shortcut like 'export to PNG close document discard data'? When export is just a branch in the workflow and editing continues on the GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG save backup'? it is absolutely a design goal that after we have helped users so much to open(/import) foo.png, make some edits and do a 'Export to foo.png' in one click, without dialogs, users must be fully aware that they are throwing away the GIMP document (LGM discussion result: call it a composition) that they used to reach their goal. we cannot have accident with GIMP compositions not being saved because we offered a too-clever-by-half shortcut. and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: of course all my work is in project-type files. enough said. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? peter sikking wrote: and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: of course all my work is in project-type files. enough said. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Wed, May 13, 2009 at 9:57 AM, Alexander Rabtchevich wrote: Pleasant interactive cropping In fact tools like Lightroom or Rawstudio beat GIMP for me when it comes to cropping of photos -- for reasons multiple times explained to GIMP developers. and scaling, required for web are enough reasons. Red eyes reduction sometimes... All of the above including cropping can be perfectly done in tools like Rawstudio or F-Spot or digiKam or even in Darktable (which is becoming GEGL based btw). This is why they are (becoming) *workflow* tools. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Alexander Rabtchevich wrote: Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? The solution to this is to provide a, probably GIMP maintained, plug-inable component that can do the thumbnailing. Since the current XCF format is tightly coupled with the GIMP internals this is a bit messy but will likely become much easier once we do our rendering with the GEGL library. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
I suspect thumbnailing will not be enough. Let's see an example of high end workflow for photography. One has taken a bunch of RAW images. He has to browse them and compare, delete the bad ones. Then the images need conversion with desired comparing at that stage and the selection goes on... Some of them need postprocessing. And _after_ postprocessing they need scalable up to full-size browsing. Not thumbnails, but full-size preview. No thumbnail would replace large image when selecting which to print, handle, convert to flat format or delete. So the library should be able to make full-size preview. Martin Nordholts wrote: Alexander Rabtchevich wrote: Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? The solution to this is to provide a, probably GIMP maintained, plug-inable component that can do the thumbnailing. Since the current XCF format is tightly coupled with the GIMP internals this is a bit messy but will likely become much easier once we do our rendering with the GEGL library. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Michal wrote: first of all, thanks for trying it out and commenting. My comments and observations: 1. When I try to save and I change extension to (for example) .png, GIMP message appears: You can use this dialog to save to the GIMP XCF format. Use File- Export to export to other file formats. I think it'd be better: You can use this dialog to save only to the GIMP XCF format. Use File-Export to export to other file formats. you added only to the string. I actually find that negative thinking, like we are sorry we are only able to do that for our users. 2. When I open image foo.png, do some changes and close it, GIMP message says: Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost. There are options: Close without Saving, Cancel, Save As. I think it'd be very useful to have option: Export and even Export to foo.png. Obviously in this case GIMP message should be different as well. This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is: a file is only safe when it is Saved (in xcf) this means that export is never the solution to unsaved changes and Export and Export to foo.png cannot be there in the dialog as ways to resolve the situation. 3. I have file foo.png in bar folder, I try to save image foo as foo.png in that folder (I changed xcf to png manually) GIMP message appear: A file named foo.png already exists. Do you want to replace it? The file already exists in bar. Replacing it will overwrite its contents. Options are: Cancel and Replace. I choose Replace and GIMP message says: You can use this dialog to save to the GIMP XCF format. Use File- Export to export to other file formats. I think the second message should appear straight after when I choose Replace because first message suggests that I can save foo.png anyway, which if not true. true, you have found a bug. like you say, the you can use this dialog... message should appear straight away. 4. In Save Image dialog there's in bottom-right corner button, where you can choose what you see: all images, all files, gimp XCF Image Although all images is selected, you can see only xcf files. that looks like another bug to me. it is still useful to see all images (to steal there filenames) in the dialog. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained. 2. When I open image foo.png, do some changes and close it, GIMP message says: Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost. There are options: Close without Saving, Cancel, Save As. I think it'd be very useful to have option: Export and even Export to foo.png. Obviously in this case GIMP message should be different as well. This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is: a file is only safe when it is Saved (in xcf) this means that export is never the solution to unsaved changes and Export and Export to foo.png cannot be there in the dialog as ways to resolve the situation. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Alexander Rabtchevich wrote: While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained. that would mean we needed two indicators, one that is is saved, and one that it is exported. but that again would deceive users that export is nearly the same as saving. it is not. maybe it is better to try it out (for a month) first. because I am sure that the new clarity of when the work you see on your screen is really safe (only in xcf) will change users thinking and behaviour about how to secure their work and when it is a good time to export. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
I think you are too biased towards xcf as an everyday storage format. It is not needed very often, at least for now. May I provide my usual workflow? 1. I take pictures in RAW. 2. I convert the pictures I liked in UFRaw and save the result in jpg with maximum quality (1:1:1, floating point, 100%). The tests I made before showed there was no difference with png but the file sizes were less. If a photo requires cropping, resizing, retouching I process it in GIMP. And here is the main point: I save xcf only if I have made complex actions, including layers, which could take too much efforts to repeat. I store intermediate results as invisible layers as possible starting point for future modifications. Look: the final aim is jpg or any other common format (web, printing, etc.). I only save in xcf if I think it can happen I will need to edit it once more. Storing data in xcf is not so convenient as image viewers do not understand all its nuances. So in most of cases I need 2 things: original untouched RAW as an untouched in any sense source and a result, which is flat image format. This is rather common workflow I guess. If the situation with lossless editing and third-party image viewers changes I think the things with final format will change also. But currently the final format is flat image, not xcf. It is so for printing in a photo lab, web and so on. Storing additional large files or having to convert them to jpg each time they are needed to be handed to someone is not a good thing, at least for a person which has and stores RAWs. My 2c. peter sikking wrote: Alexander Rabtchevich wrote: While I haven't tried the new behavior, I would like to be able to see either I have made any changes after the export in the title bar or not. Now it is indicated with a star. I prefer to see it remained. that would mean we needed two indicators, one that is is saved, and one that it is exported. but that again would deceive users that export is nearly the same as saving. it is not. maybe it is better to try it out (for a month) first. because I am sure that the new clarity of when the work you see on your screen is really safe (only in xcf) will change users thinking and behaviour about how to secure their work and when it is a good time to export. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Alexander Rabtchevich wrote: I think you are too biased towards xcf as an everyday storage format. It is not needed very often, at least for now. May I provide my usual workflow? I read your workflow and I am confident that when you try it out you will find that we support it well with the Export command and even repeated exporting during your editing session with the 'Export to your file.jpg' command. The initial critique on the specification made us focus hard to re-evaluate and improve these parts of the spec. The indicator I cannot do because its price (confusion) is too high. I simply have to make a trade-off between your kind of use and high-end use that (also for photo) always includes layers and other GIMP specific stuff. The high-end simply has a higher priority, and your kind of use is well supported. This change has been discussed for a long time (like at last year's lgm), but before I came up with the 'Export to ...' solution we would have not dreamed to put this in. Exactly because your kind of secondary workflow would have been badly supported. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Peter, I think you (or me :) ) will be surprised if know the statistics on the percentage of photos which really need complex retouching or complex actions with layers. The most common cases I can give are face retouching, repairing of a photo with too high dynamic range or correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion. peter sikking wrote: I simply have to make a trade-off between your kind of use and high-end use that (also for photo) always includes layers and other GIMP specific stuff. The high-end simply has a higher priority, and your kind of use is well supported. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Tue, May 12, 2009 at 9:16 PM, Alexander Rabtchevich wrote: correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion. And therefore there is no need to use GIMP. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Tue, May 12, 2009 at 6:16 PM, Alexander Rabtchevich alexander.v.rabtchev...@iaph.bas-net.by wrote: Peter, I think you (or me :) ) will be surprised if know the statistics on the percentage of photos which really need complex retouching or complex actions with layers. The most common cases I can give are face retouching, repairing of a photo with too high dynamic range or correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion. Such adjustments will at some point in the future conceptually be layer-like as well. White balance, exposure control, unsharp-masking and noise reduction, cropping and rotation will be done non-destructively and be possible to tweak later, perhaps even when you re-open your GIMP composition (xcf, xcf2, OpenRaster or whatever,. native GIMP document). If you want to share the resulting image you might as well export it as a JPG, or perhaps even in some other format suited for some particular use. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Pleasant interactive cropping and scaling, required for web are enough reasons. Red eyes reduction sometimes... Why should one use something other if the tool he uses most of the time is convenient and powerful? The above mentioned actions are not too complicated to be reproduced in one minute. Do they worth storing their result in xcf? I think it is so only in the case the format is _well_ understood by third-party applications like image viewers and like. Alexandre Prokoudine wrote: correcting perspective distortion. If a photo is properly exposed, has not excessive noise and is not a portrait of a person you need to improve, there is no need to retouch it after proper RAW conversion. And therefore there is no need to use GIMP. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote: I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize I built a Windows installer with this yesterday, and the comments I got so far are: - i don't have to try a stupid idea to say that it's a stupid idea - That's bizarre... - eww so they going to do it after all? - why the hell did they do that -- Jernej Simončič http://eternallybored.org/ Nature will tell you a direct lie if she can. -- Darwin's Observation ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Quoting Martin Nordholts ense...@gmail.com: I have been working on implementing the Save + export spec [1] for a while. : : Comments very much appreciated! I haven't GITified my development yet and thus have not tried your implementation. If your request for comments is only on the implementation and you are not expecting comments on the export spec itself, I apologize for the following question: Shouldn't the Save a copy... menu item be eliminated since its functionality can be entirely attained by exporting to the GIMP native format? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts ense...@gmail.com wrote: Hi I have been working on implementing the Save + export spec [1] for a while. Since it will affect the workflow for basically everyone it would be nice with getting some testing and comments before we finalize, merge and push to GNOME master. The patches are attached to the bug report http://bugzilla.gnome.org/show_bug.cgi?id=581655 . Quick-guide to apply and test: cd ~/source/gimp tar -zxvf save-plus-export-2009-05-06.tar.gz git checkout -b save-plus-export-2009-05-06 master git am save-plus-export-2009-05-06/* this will create and switch to a new branch based on top of your local master branch, and apply the patches to that branch. Then you build and install as usual. This doesn't seem to work -- patch #0010 fails: Applying app: Add an 'export' mode to the file save dialog error: patch failed: app/dialogs/file-save-dialog.c:138 error: app/dialogs/file-save-dialog.c: patch does not apply Patch failed at 0010. The patch appears to be offset by about 10 lines. I applied it manually, and then ran git-am --skip Patch 0011 applied ok, Patch 0012 had problems: Applying app: Improve save and export error messages error: app/dialogs/file-save-dialog.c: does not match index Patch failed at 0012. Applied that manually, Patches 013..017 applied OK. 018 says : Applying app: Remember last export URI for each image error: app/dialogs/file-save-dialog.c: does not match index error: patch failed: app/file/gimp-file.h:27 error: app/file/gimp-file.h: patch does not apply Patch failed at 0018. Done manually, 019 fails similarly, done manually, same for 020, 021 022 applied ok. It's possible that I didn't understand how to 'resolve' a problem ( now I think it is, apply the patch manually, 'git add' the relevant files, and 'git am --resolved') I'm now trying to build it.. Trying it out.. This works REALLY well! I 3 it! It behaves much more comfortably than the old setup, I anticipate no longer needing to awkwardly 'save copy' so frequently simply to get a web-usable version of the image. I like how, if I hit 'revert', it properly reverts to the source image (eg 12.gif rather than the working document 12.xcf) I was confused by how 'export to foo.png' was only usable once the image became dirty (ie. I changed it ). If that is considered appropriate behaviour, then your ability to 'save' should also depend on the dirtiness of the image David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
2009/5/7 David Gowers 00a...@gmail.com patch #0010 fails: Did you pull from GNOME master before you applied the patches? I should have said that the patches requires latest GNOME master. If you apply the patches on top of commit 9c2aae1281d.. you should be fine. This works REALLY well! I 3 it! It behaves much more comfortably than the old setup, I like that you like it :) I was confused by how 'export to foo.png' was only usable once the image became dirty (ie. I changed it ). If that is considered appropriate behaviour, then your ability to 'save' should also depend on the dirtiness of the image Hmm this seems to work properly for me, I can 'Export to' repeatedly also after having saved, it doesn't seem to depend on dirtiness. Maybe you resolved some patch conflict in the wrong way? Could you try to reapply on top of latest GNOME master? If you still have problems, what are the step-by-steps? / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
2009/5/7 saulgo...@flashingtwelve.brickfilms.com If your request for comments is only on the implementation and you are not expecting comments on the export spec itself, I apologize for the following question: Shouldn't the Save a copy... menu item be eliminated since its functionality can be entirely attained by exporting to the GIMP native format? I figured the best way to form an opinion on the spec is to try it out live but you are of course free to have an opinion on the spec also without having played around with an implementation of it. Allowing to export to the GIMP native format would introduce ambiguity: If I export to .xcf, will my document be considered saved? Will the document - URI association be updated? And so on. Keeping Save a copy allows us to avoid this ambiguity altogether. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Thu, 2009-05-07 at 17:08 +0200, Jernej Simončič wrote: [...] Show me one person outside GIMP developer community that thinks this is a sane change. I don't think many people think it's a sane change, but that's not the right question. The question is, will the resulting interface be good? People (including me) were very doubtful about the empty image window, and whilst I'm not 100% happy, I'm 99% happy, and it worked out much better than I had feared. So I'm willing to see what happens here. If you want something different though, you'll need to do more than say the proposed change is insane. You'll need to supply a new proposal that fits in with the vision of GIMP as an xcf editor, or, persuade Peter and others to change the vision slightly. Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials
Show me one person outside GIMP developer community that thinks this is a sane change. Totally irrelevant comment, if you ask me; this is a patch on a development version. Not many users will have tried it. Sure, there's the windows installer, but it remains a development version and an early snapshot of an unfinished feature. I am not part of the GIMP developer community, yet I like every bit of the spec I read. -- Auria ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On 9 Mar 2009, at 1:06, David Gowers gave gg a washing. and then... Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file. thanks for bringing that up. looks like for something like png GIMP is already good at that. if GIMP can gather all the details on non-lossy files, then it should in the Export to abc.png case use those settings. but we also know from a loong thread here that things are not that trivial for lossy formats like jpeg. open a jpeg @ 50% quality, edit and export back. at 50 or at default 85% ? I could not tell you. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. yes, there is an unsaved xcf sitting in that main window. and we cannot read users minds if they are doing this secondary use case or a primary one... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote: first, Copy visible as new image could easily turn out too smart, but since the bottom Background layer prefers to be one without alpha, I can see something like: when ‘visible’ has effectively universal full opacity, then omit alpha in the new image. also the export step can wise up a bit and complain less when there is universal full opacity. We just don't have a good way to figure this out currently. Copy Visible makes a copy from the projection and the projection always has an alpha channel. Perhaps we can make use of the tile-row-hints here. I'll investigate a little if this is a possibility... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Sat, 2009-03-07 at 16:03 +0100, peter sikking wrote: no, squeezing these export options in the save dialog is not possible. I think there is a misunderstanding here. What people suggested is not to put the export options into the Save file-chooser but into the dialog that the save plug-in shows. Not all save plug-ins do this, but for those that do it seems to make a lot of choice to integrate the export questions there. The Save as GIF dialog for example would have a toggle to decide if the image should be merged or if an animation should be saved. That would also make the dialog somewhat simpler as we could make all the animation-specific choices insensitive if the user decides to save the merged image. that Ignore button has to go. what has to be supported is turning layers/channels/masks into documents, that then can be saved/exported. OK I am still tending against a never show this again checkbox. even with a reset in the preferences. OK. That makes it also a lot easier to implement. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Sun, 2009-03-08 at 11:15 +0100, Sven Neumann wrote: Not all save plug-ins do this, but for those that do it seems to make a lot of choice to integrate the export questions there. That was supposed to read ... it seems to make a lot of sense Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Sven wrote: On Sat, 2009-03-07 at 16:03 +0100, peter sikking wrote: no, squeezing these export options in the save dialog is not possible. I think there is a misunderstanding here. OK, I looked to much at that attached mock-up. What people suggested is not to put the export options into the Save file-chooser but into the dialog that the save plug-in shows. Not all save plug-ins do this, but for those that do it seems to make a lot of choice to integrate the export questions there. it would certainly be an improvement to get these two (or in general: all export interaction) together in one dialog in an orderly way. The Save as GIF dialog for example would have a toggle to decide if the image should be merged or if an animation should be saved. That would also make the dialog somewhat simpler as we could make all the animation-specific choices insensitive if the user decides to save the merged image. I tried out how this works right now. integration into one dialog would work like that. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Sat, 2009-03-07 at 18:27 +0100, peter sikking wrote: first, Copy visible as new image could easily turn out too smart, but since the bottom Background layer prefers to be one without alpha, The first basic assumption is wrong...so maybe what build on that need reconsideration A Alpha channel in the background layer do not create problems or disadvantages of sort A example if you open a png you get exactly that : a image with a background layer that has a alpha channel ,that do not create any complication ,not when editing, not when saving Problems come only in the contrary case. Gimp now allow other layers to be without alpha channel, before that was possible only for the BG layer(not because BG layer is better without alpha,but because for the BG a a alpha layer is not strictly needed) So now is easy have , without noticing , a layer on top without alpha channel and that will react in a weird way to most layer mode,(when were implemented layer modes , layer(s) to merge were supposed to have alpha) And obviously then also tools as eraser will also give unwanted results if the alpha is missed I hope i didn't went too OT, my point is a alpha channel in the BG do not create problem ,neither slow the workflow. but a NOT-BG layer without alpha that may well create problems ,will be better if layer with no alpha were more clearly marked then now __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
yahvuu wrote: what an inspiring post. peter sikking schrieb: I must also point out that this save + export change is also a change in attitude for GIMP. it clearly supports that our high-end users work in no-loss xcf all the time (if they want to store results) and that also means avoiding doing things like merging, flattening, applying masks, reducing colours. that is all part of the export scenario. what about using the same mechanism for export as it is planned for managing the GEGL tree? I'm referring to http://gui.gimp.org/index.php/GEGL_analysed, especially your quote ah, GEGL will solve that. wow, that is ages ago I wrote or read that... That means for the user, all export functionality could be represented by a tiny GEGL tree/list which provides operations for flattening, color reduction, background creation, writing files and so on. This tree gets executed anytime the user exports her image. what is interesting is your idea to use an operation chain to automate the export. I say chain because for users this GEGl graph stuff will be represented as a linear list. I say automate because it has elements of script/macro creation in it. one important thing to remember is that just getting GIMP to export a png should not involve having to set up a macro. that should just work in its improved dialog click-y way. another thing we are seeing is that whenever there is a reduction in fidelity (colour-bits or resolution) there is a need for users to do optimisation (sharpening, corrective painting). my rough plan for supporting that looks like overlaying the image with a projection screen (lets not call it a layer) that simulates the lowering of fidelity. then this projection screen itself could contain several layers of optimisations and corrections that users may want to take. the high fidelity image data is still available for further development. bonus: that recent ars technica review had a really clarifying metaphor for cymk for print workflows. along the lines of: the cymk file is the LP pressing of the rgb master tape. seeing this cymk conversion as a fidelity reducing (colour gamut) 1-way conversion, it looks like the projection screen plan above could be the beginning of a working cymk support solution. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
peter sikking wrote: Liam wrote: I had a careful look at this: My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin 2. crop if needed 3. save as 306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png 6. spend up to an hour cleaning up the scanned image, under the same name I guess you realised by now that with the new attitude GIMP prefers that you do all this in xcf, so we can fully support you. Then you can Export to something you consider archival/future proof. Hi, there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. All I require is open: edit: save , in original format with original options. currently I have to jump through hoops and probably delete an extranious xcf that got created along the way because of a temporary save I did to preserve an edit. This is uncomfortably close the MS approach of we know best so you'd better fall into line. Can't this be made less intrusive? regards. 7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed 7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes. So I don't want to have to re-enter the filename 10 times. we are helping you by keeping the same filename filled in as default in the export. you remind me here that we can even help you for the first export by filling in the filename of the xcf. you also remind me that it is not specified what the default file type should be for export (it cannot be xcf...) it is easy to define it as ‘same as last time’ but what will be the very first default? some truly open format? It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the * a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously undo would have to skip over them, you can't undo a save with most file systems!). the * can only help you when saving, that is to xcf. although Save and Export cannot be real undo list items (they are not targets or undoable), I can be convinced to annotate the undo history with the Save and Export moments. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hello, On Mon, Mar 9, 2009 at 10:09 AM, gg g...@catking.net wrote: there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG - in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately. Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here. All I require is open: edit: save , in original format with original options. Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
David Gowers wrote: Hello, On Mon, Mar 9, 2009 at 10:09 AM, gg g...@catking.net wrote: there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG - in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately. Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit. IIRC, before (circa 2.2 ?) I could open a png/jpeg ... and save it, with the caveat of the flatten layers nag/warnings. Yes, it seems that in making it explicit it is becoming more cumbersome. Implicit had some merits. I get the feeling that all this import/export business is in danger of making heavy weather of it. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here. All I require is open: edit: save , in original format with original options. Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file. Sounds good. If exporting to original name with original options is readily accessible from a top level menu without having to retype the name that would be pretty good. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. maybe if the xcf was never saved as such and the work was saved to it's original name, the in memory xcf data could be regarded as an expendable buffer rather than a document that needs to be saved. Thanks for your reply. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
gg (g...@catking.net) wrote (in part) (on 2009-03-08 at 20:55): Sounds good. If exporting to original name with original options is readily accessible from a top level menu without having to retype the name that would be pretty good. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. maybe if the xcf was never saved as such and the work was saved to it's original name, the in memory xcf data could be regarded as an expendable buffer rather than a document that needs to be saved. Maybe a check-mark on the beefed up dialog being discussed: [x] Close in-memory image after export? and remember this setting for next/subsequent exports of other images until turned off? (implicit in this would be a automatic [Yes] answer to the Don't save popup that would otherwise be shown for dirty images. Perceived advantage is that it makes clear the primacy of the XCF in memory image vs whatever it was when originally imported. No reason not to also support this if original import (or XCF opened image) is now being exported to a different format. -- Regards ... Alec (bura...@gmail WinLiveMess - alec.m.burg...@skype) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Sven wrote: Let's have a look at the capabilities that the save plug-ins announce: thanks for this overview, good for reference. I saw yesterday how these questions get combined in one dialog. that is a good thing. now that with the new spec the Export part is explicit, I want to make one change: all those questions that can turn up in this dialog with only one possible answer: just omit them. with a bit of luck there are no questions and no dialog. just a reminder that there are some bug reports about this topic that might be worth looking at: Bug 75328 – Add skip this question to export dialog boxes. Bug 75459 – Add persistent defaults for the Export dialog Bug 119545 – Merge Export features into the Save dialog Bug 164709 – Export dialog should not allow to ignore mandatory export actions to answer some of the big questions in there: no, squeezing these export options in the save dialog is not possible. that Ignore button has to go. what has to be supported is turning layers/channels/masks into documents, that then can be saved/exported. I am still tending against a never show this again checkbox. even with a reset in the preferences. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Sven wrote: PS: In your particular workflow, basically you are already doing the export conversion yourself. What's breaking your workflow is the fact that Copy visible as new image introduces an alpha channel. To improve your workflow we should have a look at that and try to figure out a way to avoid that. first, Copy visible as new image could easily turn out too smart, but since the bottom Background layer prefers to be one without alpha, I can see something like: when ‘visible’ has effectively universal full opacity, then omit alpha in the new image. also the export step can wise up a bit and complain less when there is universal full opacity. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
I know this thread is already getting long, but I'd prefer to see Export behave similar to: 1. Create a new, multilayer XCF 2. File-Export 3. Name it something.png, click Next 4. Set options, click Save At no point do I want to be nagged about layers, masks, or anything else. If there were a small warning icon (with maybe a turn-down triangle to display the actual warnings) on the bottom of the option dialog in step 4, that would be nice - but not necessary. I know PNG does not support layers - I do not need the reminder every time. 5. Close the XCF file At this point I should be prompted to save the XCF master file, since I've only done an export and never saved the original. I based this on PNG, but I'd like to see this workflow on all non-natives. GIF for instance should have the choice to save as animation displayed on the GIF option dialog - not in the warning dialog. IMO, the warning dialog should die ;) Just $0.02 Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Liam wrote: I had a careful look at this: My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin 2. crop if needed 3. save as 306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png 6. spend up to an hour cleaning up the scanned image, under the same name I guess you realised by now that with the new attitude GIMP prefers that you do all this in xcf, so we can fully support you. Then you can Export to something you consider archival/future proof. 7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed 7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes. So I don't want to have to re-enter the filename 10 times. we are helping you by keeping the same filename filled in as default in the export. you remind me here that we can even help you for the first export by filling in the filename of the xcf. you also remind me that it is not specified what the default file type should be for export (it cannot be xcf...) it is easy to define it as ‘same as last time’ but what will be the very first default? some truly open format? It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the * a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously undo would have to skip over them, you can't undo a save with most file systems!). the * can only help you when saving, that is to xcf. although Save and Export cannot be real undo list items (they are not targets or undoable), I can be convinced to annotate the undo history with the Save and Export moments. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Rob Antonishen wrote: Read this with intrest (as a user) what is the intrinsic difference between save a copy and save as? I am assuming the working document changes in the save as case to the new saved as file. In the save a copy case I assume the working doment is unchanged. yes it works like that in the current version. One suggestion in the revert...would it be possible introduce an timed auto backup feature (I have implemented one using a scheme script I invoke with a hot key, currently) and have the revert offer up any of the automatic backups as well as the open state as a revert option? I think that needs its own little project. thinking through reverting after a crash is not trivial. Jon Senior wrote: As a user, I like it. I like the separation of saving native format and exporting to non-native formats. Am I right in thinking that Save back will only appear in the use case where a non-native file is opened? yes, that is the point where ‘Save back’ becomes available. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Fri, 2009-03-06 at 11:50 +0200, Alexia Death wrote: Does this mean that the annoying pop-up asking If I want to export will go away if I choose export? The dialog does not really ask you if you want to export. It informs you that the image can't be saved because the format you have chosen can not handle some aspects of the image (transparency, multiple layers, ...). It also offers you one or more ways to deal with this situation. As far as I can see the new spec does not really change this. We should definitely try to straighten this dialog (as Peter already wrote). Part of that is probably that the dialog remembers the last made choice (per format or per image?) and perhaps it should even offer a choice to skip it entirely when exporting this image to this format again. I will have to think about how this fits into the current export functionality. As it is implemented on the plug-in side, it may turn out to be difficult to change it. But first it would be good for us to know how it should look and feel ideally. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Quoting peter sikking pe...@mmiworks.net: we have discussed this intensely before, the ambiguity of what you really got in your document window after opening--or saving to--a non-GIMP-type image (e.g. jpeg, png). : : So here is a short spec: http://gui.gimp.org/index.php/Save_%2B_export_specification If you are accepting feedback on the spec, I should like to submit the following: Under the section exporting files, the command names Export..., Save back, and Save as template are confusing. For the latter two, using the word save runs counter to one of the main purposes of this exercise -- that is to say, we don't want the user to think that exported data is safe so why would we use the word save when exporting. Save back in particular is confusing. Not only does employment of the term save lead to expectations of data safety and behavior consistent with the other Save commands, but back is ambiguous and generates more questions than it answers (what is being saved, a back?, or if back is a place, where?, how far back?). Would it not be preferable to substitute Export for the spec's 'Save Back' command label, and to substitute Export As... for the spec's 'Export...' command. I don't see the reasoning behind the name juggling -- why deviate so dramatically from the logic underlying the naming of the Save and Save As... commands? Excepting for the name/status handling of the image, the correlation should be Save=Export and SaveAs...=ExportAs... I also think that it must be possible to export to GIMP file types. This is necessary so that more than one version of GIMP data files can be supported. (ie, GIMP 4.0 might still need to create GIMP 2.x compatible files). In fact, Saving should be limited to the latest preferred GIMP-native file format, while requiring that deprecated formats should be Exported. It may also be useful if this export capability permitted the saving of single-layers, layermasks, channels, or eventually groups/branches of layers (under GEGL) to native GIMP formats. Such may not be, or ever become, useful but nonetheless I see little benefit to prohibiting exportation to native GIMP formats. Of course, exporting to GIMP-native should not alter the saved status or file name of the image. Not only does this maintain consistency with other export operations, but exporting to a deprecated GIMP format will likely mean a loss of image information. There was much I liked about the specification, and feel it is especially important that GIMP users realize the potential of losing image data when using non-GIMP formats. This is a recurring problem for beginning users and while I don't think it is necessary to dumb down the GIMP interface for them, I do think that the terminology of the menu commands should be as consistent as possible. Regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Friday 06 March 2009, Sven Neumann wrote: So we probably need to add specific actions to save a layer, a channel or a layer mask. If that (plus to save all of a kind, e.g. all layers) could go into the generic save dialog, we would have another 10% questions less on irc :) Daniel signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Fri, 2009-03-06 at 07:33 -0500, saulgo...@flashingtwelve.brickfilms.com wrote: I also think that it must be possible to export to GIMP file types. This is necessary so that more than one version of GIMP data files can be supported. (ie, GIMP 4.0 might still need to create GIMP 2.x compatible files). Can we please discuss that when a new file format has been introduced? So far there is only XCF and we don't need to make this discussion more complex than needed by talking about imaginary file formats that might be added in the future. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Sven wrote: Alexia wrote: Does this mean that the annoying pop-up asking If I want to export will go away if I choose export? The dialog does not really ask you if you want to export. It informs you that the image can't be saved because the format you have chosen can not handle some aspects of the image (transparency, multiple layers, ...). It also offers you one or more ways to deal with this situation. right. one thing I have no overview of is how many ‘topics’ there are for which there are dialogs. Up to now I have seen layers, transparency, bit-depths. As far as I can see the new spec does not really change this. exactly. We should definitely try to straighten this dialog (as Peter already wrote). Part of that is probably that the dialog remembers the last made choice (per format or per image?) and perhaps it should even offer a choice to skip it entirely when exporting this image to this format again. I will have to think about how this fits into the current export functionality. As it is implemented on the plug-in side, it may turn out to be difficult to change it. But first it would be good for us to know how it should look and feel ideally. looks like remembering as default per file type is the right thing. the as-is situation of showing only once per time that the image is open (should also be for export, I will add that to the spec) looks just about right to me: both the source document and the export destination determine what the right information reduction method is. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Fri, 2009-03-06 at 14:17 +0100, peter sikking wrote: right. one thing I have no overview of is how many ‘topics’ there are for which there are dialogs. Up to now I have seen layers, transparency, bit-depths. Let's have a look at the capabilities that the save plug-ins announce: typedef enum { GIMP_EXPORT_CAN_HANDLE_RGB = 1 0, GIMP_EXPORT_CAN_HANDLE_GRAY= 1 1, GIMP_EXPORT_CAN_HANDLE_INDEXED = 1 2, GIMP_EXPORT_CAN_HANDLE_BITMAP = 1 3, GIMP_EXPORT_CAN_HANDLE_ALPHA = 1 4, GIMP_EXPORT_CAN_HANDLE_LAYERS = 1 5, GIMP_EXPORT_CAN_HANDLE_LAYERS_AS_ANIMATION = 1 6, GIMP_EXPORT_CAN_HANDLE_LAYER_MASKS = 1 7, GIMP_EXPORT_NEEDS_ALPHA= 1 8 } GimpExportCapabilities; This results in a variety of possible dialogs: The image has more than one layer but the plug-in can't handle layers. - Flatten Image or Merge Visible Layers (for plug-ins that need alpha channel, the Flatten Image option is omitted) (for plug-ins that can't handle an alpha channel, the Merge option is omitted) The image has a single layer but that layer is of a different size than the image, it is offset and/or it has an opacity != 100. - Merge Visible Layers The image has more than one layer and the plug-in can only handle this if it treats those as frames of an animation. - Merge Visible Layers or Save as Animation - Flatten Image or Save as Animation (for plug-ins that don't support transparency) The image has a layer with an alpha channel but the plug-in can't handle transparency. - Flatten Image The image has layer masks which the plug-in can't handle. - Apply Layer Masks The image has a layer without an alpha channel, but the plug-in relies on one. - Add Alpha Channel And of course there are the various image mode conflicts that are handled by offering to convert to the mode that the plug-in supports: Convert to RGB Convert to Grayscale Convert to Indexed using default settings (Do it manually to tune the result) Convert to Indexed using bitmap default settings (Do it manually to tune the result) These can be combined as options if the destination format supports several modes. The gory details can be looked up in libgimp/gimpexport.c in the function gimp_export_image(). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Fri, Mar 6, 2009 at 3:53 PM, Sven Neumann s...@gimp.org wrote: This results in a variety of possible dialogs: And? If I save to a format it can be assumed that I know its limitations. Being warned once about the information loss is good enough. Mind, gimp does not even do that right now. Loss of vector layers and text data goes unannounced. So how about doing it by letting the user per file type (once if user so chooses), its capabilities. Export makes information loss implicit anyway. And of course there are the various image mode conflicts that are handled by offering to convert to the mode that the plug-in supports: Convert to RGB Convert to Grayscale Convert to Indexed using default settings (Do it manually to tune the result) Convert to Indexed using bitmap default settings (Do it manually to tune the result) These can be combined as options if the destination format supports several modes. Image mode conflicts are a separate problem IMHO. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
great this gets tracked down. One minor suggestion, a simple renaming: Export...= Export as... Save back= Export this way, 'Export' resembles 'Save' as a one-click-action and 'Export as...' parallels 'Save as'. Additionally, the association between 'Save' and safe is kept consistent. (Otherwise a user touching up a JPG might wonder why he is served a nag-screen on closing the image - despite of having saved back before) greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
oops, just recognized i'm replicating a previous post, sorry yahvuu schrieb: One minor suggestion, a simple renaming: Export...= Export as... Save back= Export ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
yahvuu wrote: One minor suggestion, a simple renaming: Export...= Export as... Save back= Export this way, 'Export' resembles 'Save' as a one-click-action and 'Export as...' parallels 'Save as'. That sounds good to me. Save back would be something I've never seen in any other program to date. It doesn't give me any hints what it is doing other than it is supposedly some type of file(?) save operation. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Fri, Mar 6, 2009 at 5:49 PM, Sven Neumann s...@gimp.org wrote: Hi, On Fri, 2009-03-06 at 17:37 +0200, Alexia Death wrote: And? If I save to a format it can be assumed that I know its limitations. Being warned once about the information loss is good enough. That is not what GIMP is doing. It tells you that it can't save to that format without modifying the image beforehand. And quite often it needs to ask you what to do because there are several possibilities. But it does not modify the image I am working on, it converts the image into a save result that I never see in gimp. Neither will I expect it to alter my image If I initiate my action with export. If you knew about the limitations of the file format you are saving to, then you had converted the image beforehand and you wouldn't see the Export dialog at all. Why would I convert it beforehand? Why would a user need to do a bunch of actions that serve no purpose, are mostly 100% automatic and even hinder when I want to follow the export action up with a native save? --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Fri, 2009-03-06 at 18:03 +0200, Alexia Death wrote: Why would I convert it beforehand? Why would a user need to do a bunch of actions that serve no purpose, are mostly 100% automatic and even hinder when I want to follow the export action up with a native save? Because they are not 100% automatic. There is user choice involved. If there wasn't, we wouldn't have that dialog. The dialog basically tells you that you forgot to do one or more important steps in your export workflow. And it helps you to do them. It does so in the hope that next time you will do them yourself. I do almost always convert my image to the final state before saving it to a format such as JPEG or PNG. I can hardly remember how the Export dialog looks like because I never get to see it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Hi, On Fri, 2009-03-06 at 17:24 +0100, Jon Senior wrote: Just to present the opposing case. My workflow is: 1) Open raw image via the ufraw plugin. 2) Retouch as necessary, saving as xcf file. 3) Copy visible as new image 4) Resize new image for print or web + sharpen as neccessary. 5) Save result to jpeg file. I don't mind being warned that step 5 will result in a loss of data (although it'd be nice to be able to do the export silently). But I don't want to have to think about the processes required to export my image to a jpeg for publishing. I just want to do it and get back to editing my xcf file with its nice layers. Sure, we all just want the computer do do what we want, without being asked. But unfortunately mind-reading devices are not yet available. So the only thing we can do is to ask you if you want to flatten the image because you can't save it as a JPEG file as JPEG does not support transparency. I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do. If saving a multi-layered image as GIF, is she trying to save an animation or has she forgotten to merge the layers? If saving an image with transparency as a JPEG file, is that really the correct background color so that automatically flattening the image will give the desired result? IF saving an RGB image as GIF, does the user just don't care about the conversion to Indexed Colors or has she forgotten to do it? Sven PS: In your particular workflow, basically you are already doing the export conversion yourself. What's breaking your workflow is the fact that Copy visible as new image introduces an alpha channel. To improve your workflow we should have a look at that and try to figure out a way to avoid that. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
Apologies. I think I hit reply, not reply-all. On Fri, 06 Mar 2009 17:40:36 +0100 Sven Neumann s...@gimp.org wrote: Sure, we all just want the computer do do what we want, without being asked. But unfortunately mind-reading devices are not yet available. So the only thing we can do is to ask you if you want to flatten the image because you can't save it as a JPEG file as JPEG does not support transparency. Granted. What I was trying to show was that I would prefer to have export manage everything (and simple tell me that I will lose data), than to be expected to modify the workflow in order to prepare images for export. An example might be when gimp is ultimately capable of 16-bit editing. I will edit my photo in 16-bit to reduce the damage caused by applying curves etc, but I will still want to export to 8-bit jpgs. I might not want to resize so I just hit export. You were saying that you view the warning when exporting as a reminder that you should have already done that work yourself. I view it as a reminder that the exported file format is a compromise. At the minute, this makes no difference to the end result, but it is a differing mindset which could come into conflict depending on the reworking of the menu items so I felt it worth mentioning. I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do. If saving a multi-layered image as GIF, is she trying to save an animation or has she forgotten to merge the layers? If saving an image with transparency as a JPEG file, is that really the correct background color so that automatically flattening the image will give the desired result? IF saving an RGB image as GIF, does the user just don't care about the conversion to Indexed Colors or has she forgotten to do it? I agree that it can't be 100% automatic and I wasn't suggesting that it should be. The point I was trying to make is better expressed above. PS: In your particular workflow, basically you are already doing the export conversion yourself. What's breaking your workflow is the fact that Copy visible as new image introduces an alpha channel. To improve your workflow we should have a look at that and try to figure out a way to avoid that. Interesting. I gave that as the extreme example. Sometimes I just use Save a copy direct from the xcf image. It all depends on what I need the exported file for. -- Jon Senior j...@restlesslemon.co.uk ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Fri, 2009-03-06 at 17:40 +0100, Sven Neumann wrote: [...] I am all for improving this situation. But so far no one has come up with a good idea how this could be done. We can't just guess what the user might want to do. We could do better than today. E.g. export to tiff should be probably able to handle layers. My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin 2. crop if needed 3. save as 306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png 6. spend up to an hour cleaning up the scanned image, under the same name 7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed 7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes. So I don't want to have to re-enter the filename 10 times. Why do I not work in .xcf? Because it's not a published standard, and most other programs can't handle it, e.g. to show me a thumbnail, and even GIMP might one day not be able to open the old xcf files. I do sometimes save as xcf in step 5, to save time, as saving in PNG often takes several minutes. It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the * a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously undo would have to skip over them, you can't undo a save with most file systems!). So, I want Export to make the star go away, if Save As will no longer save as PNG. Otherwise, GIMP sits there for several minutes and I go off and do something else, and when I come back, how do I know it did anything? I'll forget whether I saved the file or not. For anyone wondering -- I use gimp to rescale and make multiple versions of engravings, and imagemagick in a script for photos, because scanned engravings are so much harder to rescale and often need some touchup. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
On Thu, 5 Mar 2009 23:36:52 +0100 peter sikking pe...@mmiworks.net wrote: Hi all, we have discussed this intensely before, the ambiguity of what you really got in your document window after opening--or saving to--a non-GIMP-type image (e.g. jpeg, png). The discussion returned on the irc this Monday, and I realised then that some remaining nagging use cases could be solved elegantly, and that rationalising the whole situation does not look to be a tour de force. So here is a short spec: http://gui.gimp.org/index.php/Save_%2B_export_specification As a user, I like it. I like the separation of saving native format and exporting to non-native formats. Am I right in thinking that Save back will only appear in the use case where a non-native file is opened? -- Jon Senior j...@restlesslemon.co.uk ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer