Re: [Gimp-developer] Save + Export proposal

2009-10-20 Thread peter sikking
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

2009-10-20 Thread Rob Antonishen
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

2009-10-20 Thread Ilya Zakharevich
[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

2009-10-05 Thread Martin Nordholts
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

2009-10-05 Thread Liam R E Quin
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

2009-10-04 Thread Omari Stephens
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

2009-09-16 Thread Alexandre Prokoudine
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

2009-09-16 Thread Alexia Death
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

2009-09-16 Thread Martin Nordholts
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

2009-09-16 Thread Liam R E Quin
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

2009-05-18 Thread Alexandre Prokoudine
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

2009-05-18 Thread peter sikking
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

2009-05-18 Thread Martin Nordholts
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

2009-05-16 Thread Martin Nordholts
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

2009-05-13 Thread peter sikking
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

2009-05-13 Thread yahvuu
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

2009-05-13 Thread peter sikking
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

2009-05-13 Thread Alexander Rabtchevich
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

2009-05-13 Thread Alexandre Prokoudine
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

2009-05-13 Thread Martin Nordholts
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

2009-05-13 Thread Alexander Rabtchevich
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

2009-05-12 Thread peter sikking
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

2009-05-12 Thread Alexander Rabtchevich
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

2009-05-12 Thread peter sikking
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

2009-05-12 Thread Alexander Rabtchevich
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

2009-05-12 Thread peter sikking
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

2009-05-12 Thread Alexander Rabtchevich
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

2009-05-12 Thread Alexandre Prokoudine
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

2009-05-12 Thread Øyvind Kolås
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

2009-05-12 Thread Alexander Rabtchevich
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

2009-05-07 Thread Jernej Simončič
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

2009-05-07 Thread saulgoode
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

2009-05-07 Thread David Gowers
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-05-07 Thread Martin Nordholts
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-05-07 Thread Martin Nordholts
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

2009-05-07 Thread Liam R E Quin
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

2009-05-07 Thread M Gagnon

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

2009-03-09 Thread peter sikking
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...

2009-03-08 Thread Sven Neumann
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...

2009-03-08 Thread Sven Neumann
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...

2009-03-08 Thread Sven Neumann
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...

2009-03-08 Thread peter sikking
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...

2009-03-08 Thread Alchemie foto\grafiche



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

2009-03-08 Thread peter sikking
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...

2009-03-08 Thread gg
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...

2009-03-08 Thread David Gowers
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...

2009-03-08 Thread gg
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...

2009-03-08 Thread Alec Burgess


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

2009-03-07 Thread peter sikking
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...

2009-03-07 Thread peter sikking
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...

2009-03-07 Thread Chris Mohler
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...

2009-03-07 Thread peter sikking
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...

2009-03-06 Thread peter sikking
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...

2009-03-06 Thread Sven Neumann
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...

2009-03-06 Thread saulgoode
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...

2009-03-06 Thread Daniel Hornung
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...

2009-03-06 Thread Sven Neumann
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...

2009-03-06 Thread peter sikking
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...

2009-03-06 Thread Sven Neumann
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...

2009-03-06 Thread Alexia Death
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...

2009-03-06 Thread yahvuu
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...

2009-03-06 Thread yahvuu
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...

2009-03-06 Thread Kevin Cozens
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...

2009-03-06 Thread Alexia Death
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...

2009-03-06 Thread Sven Neumann
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...

2009-03-06 Thread Sven Neumann
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...

2009-03-06 Thread Jon Senior
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...

2009-03-06 Thread Liam R E Quin
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...

2009-03-05 Thread Jon Senior
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