Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread Jakub Friedl
 I said when the new changes were being discussed that the use image file
 quality unless defaults are 'better' was a bad way to go.


I think that use image file quality unless defaults are 'better' is not
thee problem. Problem is inheriting image quality between different images
in one GIMP session. I have a default quality of 85. Then I open DSLR image
with quality 95. Save it with that quality. Then I open and save low quality
cameraphone image. But I am not offered my default nor the original
cameraphone quality (which would be both understandable) but the DSLR
quality of 95. Huh? These images have nothing in common except they have
been opened in the same editor session. Do not mix them up.

Jakub Friedl
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread Alexander Rabtchevich
These are the best words I've heard on UI. A program cannot decide what 
is better for me because _I_have_not_told_it what _I_need_. This is a 
principle - it should be up to user, not a program.
 
In a most common case of saving jpeg files I would like to be able to do 
via advanced mode:
1. See original file settings as numeric values. That includes quality, 
subsampling and DCT  method . 
2. See my  current settings (saving and restoring is OK now in RC1).
3. Have some color flag  showing which ones are better. This can be done 
based on the estimation provided in the tread before. And the better way 
is to show  two progress bars one under another - original vs current  
settings.
3. Decide which one set of settings use  for file save: original or 
adjustable current ones.

[EMAIL PROTECTED] wrote:
 Hi,

 I said when the new changes were being discussed that the use image file  
 quality unless defaults are 'better' was a bad way to go.

 Gimp should not decide what is better because it cannot know what is  
 required so cannot make that choice.

 This sort of surprise behaviour is precisely the kind of thing I was  
 warning against in making covert changes to user data.

 This sort of approach will always lead to unexpected results because it is  
 inconsistant.

 Stop treating the user like a dumby and trying to make choices behind his  
 back about what is best for his files. This would provide a more  
 consistant and predictable behaviour.

 A lot of things are now done a lot better w.r.t jpeg but I think this  
 aspect is still fundamentally wrong. Keeping the quality gleaned from the  
 file would solve this problem and provide more predicatable behaviour.

   


-- 
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] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread Raphaël Quinet
On Thu, 30 Aug 2007 00:57:44 +0200, [EMAIL PROTECTED] wrote:
 Gimp should not decide what is better because it cannot know what is  
 required so cannot make that choice.
 
 This sort of surprise behaviour is precisely the kind of thing I was  
 warning against in making covert changes to user data.

I think that you are trying to shoot the wrong target.  The main
problem that I described in my previous message is not the fact that
GIMP tries to preserve the quality of the original image or decide
what is better.  The problem is that some changes that you make when
saving one file are propagated to all other files that you save later.
The recent updates to the JPEG plug-in make this problem more obvious,
but it also affects all other file plug-ins.

Before jumping to conclusions about where the problem comes from, please
try the following exercise:
- Load or create a GIF animation (2-3 layers should be enough).
- Save it as A.gif and let's pretend that you don't like the speed at
  which that animation runs so you set the delay to 333ms and check
  the box Use delay entered above for all frames.
- Close that image.
- Open or create a new, totally unrelated GIF animation.
- Save that image as B.gif.  Although you probably wanted to keep its
  settings or at least save it with the default values, you see that
  Use delay entered above for all frames is now checked.  The
  settings from an unrelated image that is now closed are used for
  saving your new image.  If you do not want to destroy the timing of
  your animation, you have to pay attention and uncheck that box
  before you save the file.

Does it make sense that two unrelated images influence each other?

But things are even more confusing if you keep some images open.  Try
the following exercise, with PNG this time:
- Load or create a new image.
- Save it as A.png but set its compression level to 0 because you want
  to waste some disk space and disable all other options because you
  do not want to save the image comment, creation date, etc.
- Keep A.png open and load or create another image.
- Save the second image as B.png.  Although you probably wanted to use
  your default settings (which can be customized with the buttons
  Load/Save defaults), you see that the same parameters as A.png are
  now used when saving this image.  You do not like this, so you set
  the compression level back to 9 (you can also check or uncheck some
  of the other boxes) and save the image.
- With both A.png and B.png still open, load or create a third image.
- Save that image as C.png.  Now you see that C.png inherited the
  settings from B.png, the last image that was saved.
- Make some small changes to A.png and save it again using a new name
  such as D.png.  By now, maybe you expect that saving D.png would use
  the same settings as C.png, the last image that was saved?  But no,
  this time you see that D.png keeps the settigns from A.png because
  it was still open.
- Now if you make some changes to B.png and give it a new name E.png,
  then that file will use the settings from B.png.  But if you had
  closed and re-opened B.png, then you would see that E.png is saved
  with the parameters from D.png, not B.png.  Are you confused yet?

If you work on two files in parallel (A.png and B.png) and save them
alternatively as your work progresses, then any new file that you open
and save will inherit the settings from A.png or B.png, depending on
which one was saved last.

And if you are still convinced that all of this makes sense, try to
play with some settings that are enabled or disabled depending on the
contents of the original image.  For example, if the original PNG
image has transparency (alpha channel), then you will be able to check
or uncheck the box Save color values from transparent pixels.  This
setting may be propagated to other PNG images that also have an alpha
channel.  But if you load a PNG image without alpha channel, then this
option will not be available.  After saving that last file, can you
correctly guess if that box will be automatically checked or not when
you load another PNG image with transparency and then try to save it?

I consider the current situation to be broken for all file plug-ins.
Instead of re-using the settings from whatever image was saved
recently, each image should keep its own settings and should not be
influenced by what you do with the other images.  The save settings
should come from the original image or from the user defaults if the
image has never been saved yet.  It should of course be possible for
the user to customize these defaults (currently, this can only be done
for JPEG and PNG, but the old bug #63610 is about extending this to
other plug-ins).

I hope that you are convinced that something is wrong with the
behavior of the file plug-ins.

Now, regarding the JPEG plug-in, I see two ways forward:

1) Do not re-use the values from previous (unrelated) invocations of
   the plug-in.  This ensures that each file 

[Gimp-developer] I would like to write a GAP user manual

2007-08-30 Thread Patrick
Hi Everyone

This is my first post here. My programming skills are still a little 
weak but I was hoping I could contribute by helping to write the Gimp 
GAP user manual. With a 1 1/2 year old child and a 1 1/2 year old 
business I don't have too much time. Things will go slow. I can however 
provide hosting space and indeed a dedicated website for the project.

If the GAP developers/users can help to tutor me I can post my work 
online. I should also be able to do so in a Wiki format so others can 
correct my mistakes or clarify ambiguous statements.

Please feedback as to whether or not this is a good idea, and if it is, 
any comments on the best way to achieve this.

Thanks-Patrick


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread gg
On Thu, 30 Aug 2007 11:07:40 +0200, Raphaël Quinet [EMAIL PROTECTED]  
wrote:

 On Thu, 30 Aug 2007 00:57:44 +0200, [EMAIL PROTECTED] wrote:
 Gimp should not decide what is better because it cannot know what is
 required so cannot make that choice.

 This sort of surprise behaviour is precisely the kind of thing I was
 warning against in making covert changes to user data.

 I think that you are trying to shoot the wrong target.  The main
 problem that I described in my previous message is not the fact that
 GIMP tries to preserve the quality of the original image or decide
 what is better.  The problem is that some changes that you make when
 saving one file are propagated to all other files that you save later.
 The recent updates to the JPEG plug-in make this problem more obvious,
 but it also affects all other file plug-ins.

 Before jumping to conclusions about where the problem comes from, please
 try the following exercise:
 - Load or create a GIF animation (2-3 layers should be enough).
 - Save it as A.gif and let's pretend that you don't like the speed at
   which that animation runs so you set the delay to 333ms and check
   the box Use delay entered above for all frames.
 - Close that image.
 - Open or create a new, totally unrelated GIF animation.
 - Save that image as B.gif.  Although you probably wanted to keep its
   settings or at least save it with the default values, you see that
   Use delay entered above for all frames is now checked.  The
   settings from an unrelated image that is now closed are used for
   saving your new image.  If you do not want to destroy the timing of
   your animation, you have to pay attention and uncheck that box
   before you save the file.

 Does it make sense that two unrelated images influence each other?

 But things are even more confusing if you keep some images open.  Try
 the following exercise, with PNG this time:
 - Load or create a new image.
 - Save it as A.png but set its compression level to 0 because you want
   to waste some disk space and disable all other options because you
   do not want to save the image comment, creation date, etc.
 - Keep A.png open and load or create another image.
 - Save the second image as B.png.  Although you probably wanted to use
   your default settings (which can be customized with the buttons
   Load/Save defaults), you see that the same parameters as A.png are
   now used when saving this image.  You do not like this, so you set
   the compression level back to 9 (you can also check or uncheck some
   of the other boxes) and save the image.
 - With both A.png and B.png still open, load or create a third image.
 - Save that image as C.png.  Now you see that C.png inherited the
   settings from B.png, the last image that was saved.
 - Make some small changes to A.png and save it again using a new name
   such as D.png.  By now, maybe you expect that saving D.png would use
   the same settings as C.png, the last image that was saved?  But no,
   this time you see that D.png keeps the settigns from A.png because
   it was still open.
 - Now if you make some changes to B.png and give it a new name E.png,
   then that file will use the settings from B.png.  But if you had
   closed and re-opened B.png, then you would see that E.png is saved
   with the parameters from D.png, not B.png.  Are you confused yet?

 If you work on two files in parallel (A.png and B.png) and save them
 alternatively as your work progresses, then any new file that you open
 and save will inherit the settings from A.png or B.png, depending on
 which one was saved last.

 And if you are still convinced that all of this makes sense, try to
 play with some settings that are enabled or disabled depending on the
 contents of the original image.  For example, if the original PNG
 image has transparency (alpha channel), then you will be able to check
 or uncheck the box Save color values from transparent pixels.  This
 setting may be propagated to other PNG images that also have an alpha
 channel.  But if you load a PNG image without alpha channel, then this
 option will not be available.  After saving that last file, can you
 correctly guess if that box will be automatically checked or not when
 you load another PNG image with transparency and then try to save it?

 I consider the current situation to be broken for all file plug-ins.
 Instead of re-using the settings from whatever image was saved
 recently, each image should keep its own settings and should not be
 influenced by what you do with the other images.  The save settings
 should come from the original image or from the user defaults if the
 image has never been saved yet.  It should of course be possible for
 the user to customize these defaults (currently, this can only be done
 for JPEG and PNG, but the old bug #63610 is about extending this to
 other plug-ins).

 I hope that you are convinced that something is wrong with the
 behavior of the file plug-ins.

 Now, regarding the 

Re: [Gimp-developer] I would like to write a GAP user manual

2007-08-30 Thread Marco Ciampa
On Thu, Aug 30, 2007 at 05:46:44AM -0400, Patrick wrote:
 Hi Everyone
 
 This is my first post here. My programming skills are still a little 
 weak but I was hoping I could contribute by helping to write the Gimp 
 GAP user manual. With a 1 1/2 year old child and a 1 1/2 year old 
 business I don't have too much time. Things will go slow. I can however 
 provide hosting space and indeed a dedicated website for the project.
 
 If the GAP developers/users can help to tutor me I can post my work 
 online. I should also be able to do so in a Wiki format so others can 
 correct my mistakes or clarify ambiguous statements.
 
 Please feedback as to whether or not this is a good idea, and if it is, 
 any comments on the best way to achieve this.
 
Please contact the gimp-manual team. Perhaps it could be a good idea to
just add a section on the online manual (that could have the side effect to
enable the much useful F1 key contest open help browser).

bye
 
-- 

Marco Ciampa

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Where all developers are?

2007-08-30 Thread Juhana Sadeharju

Last I mailed it was said that there are not that many
GIMP developers. Where are all image processing application
developers have gone? Is there some other open source image
manipulation software which sucks all the developers?

In recent years Siggraph conference proceedings have had
more image processing papers. For example: They are now
making giga size photos with panoramic techniques. They
are using hundreds of tourist photos for making 3D walkthroughs
through city. Google earth and competitors are making 3D
models from photos. And much more.

It looks like today's image processing software needs to be
redefined because there are many new applications for photos.
You may suggest some other application for specific task
as an easy solution but please don't.

Juhana
-- 
  http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
  for developers of open source graphics software
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread Scott
On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote:
 I think that use image file quality unless defaults are 'better' is not
 thee problem. Problem is inheriting image quality between different images
 in one GIMP session. I have a default quality of 85. Then I open DSLR image
 with quality 95. Save it with that quality. Then I open and save low quality
 cameraphone image. But I am not offered my default nor the original
 cameraphone quality (which would be both understandable) but the DSLR
 quality of 95. Huh? These images have nothing in common except they have
 been opened in the same editor session. Do not mix them up.

There are times I definitely *want* to save the settings from a
previous save. A common task for me is to edit ten or so images to
present at 300x225 pixel size on the web. Of course, I don't want to
save exif or thumbnail, so the carrying-over of these choices (and I
don't know if this is fixed in 2.4 or not) is appreciated. Not wanting
to use *too* much memory on my server, I will usually tweak the jpeg
quality factor down to something less than the default 85, and I like
having this carry forward from image to image when I am doing this
task. If one looks too degraded at the new setting, then I can tweak
it upwards, or if one is too big, then I can try lessening the
quality, but I certainly wouldn't like to have each new image return
to the default, or to some value determined by the image itself. I
want to be in control but not have to control too much, if you know
what I mean. I want the software to remember what I am doing.

Couldn't there be a button somewhere to forget previous settings or
begin new task? Actually, that would be helpful in many other
situations, such as the file-save directory (and this is probably a
GTK issue, I suppose). Now, I have to select the directory *every
time*, even though I obviously want to save all 10 images to the
same directory. Sort of like fifty first dates

Actually, the more I think about it, the idea of a begin task - end
task pair of buttons makes sense to me. Perhaps there could be
pre-defined task parameters which the user has set up for different
ones. Such as defaults for the resize-image, crop image, save
directory, etc, etc. Maybe something like this already exists and I
don't know about it. Who knows

scott swanson
just a user.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread gg
On Thu, 30 Aug 2007 23:56:16 +0200, Scott [EMAIL PROTECTED] wrote:

 On Thu, Aug 30, 2007 at 08:56:33AM +0200, Jakub Friedl wrote:
 I think that use image file quality unless defaults are 'better' is  
 not
 thee problem. Problem is inheriting image quality between different  
 images
 in one GIMP session. I have a default quality of 85. Then I open DSLR  
 image
 with quality 95. Save it with that quality. Then I open and save low  
 quality
 cameraphone image. But I am not offered my default nor the original
 cameraphone quality (which would be both understandable) but the DSLR
 quality of 95. Huh? These images have nothing in common except they have
 been opened in the same editor session. Do not mix them up.

 There are times I definitely *want* to save the settings from a
 previous save. A common task for me is to edit ten or so images to
 present at 300x225 pixel size on the web. Of course, I don't want to
 save exif or thumbnail, so the carrying-over of these choices (and I
 don't know if this is fixed in 2.4 or not) is appreciated. Not wanting
 to use *too* much memory on my server, I will usually tweak the jpeg
 quality factor down to something less than the default 85, and I like
 having this carry forward from image to image when I am doing this
 task. If one looks too degraded at the new setting, then I can tweak
 it upwards, or if one is too big, then I can try lessening the
 quality, but I certainly wouldn't like to have each new image return
 to the default, or to some value determined by the image itself. I
 want to be in control but not have to control too much, if you know
 what I mean. I want the software to remember what I am doing.

 Couldn't there be a button somewhere to forget previous settings or
 begin new task? Actually, that would be helpful in many other
 situations, such as the file-save directory (and this is probably a
 GTK issue, I suppose). Now, I have to select the directory *every
 time*, even though I obviously want to save all 10 images to the
 same directory. Sort of like fifty first dates

 Actually, the more I think about it, the idea of a begin task - end
 task pair of buttons makes sense to me. Perhaps there could be
 pre-defined task parameters which the user has set up for different
 ones. Such as defaults for the resize-image, crop image, save
 directory, etc, etc. Maybe something like this already exists and I
 don't know about it. Who knows

 scott swanson
 just a user.
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer



I think what you describe could be put under Save as. It is not Save  
though.

Probably misusing the defaults.

;)
gg
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins

2007-08-30 Thread Scott
On Fri, Aug 31, 2007 at 12:19:23AM +0200, [EMAIL PROTECTED] wrote:
 
 I think what you describe could be put under Save as. It is not Save  
 though.
 
 Probably misusing the defaults.

You're right, of course. Doh. I always use save as. And it works
fine for my purposes (other than the save-to directory which I mentioned),
and I hope it does in 2.4. Sorry to have misunderstood.

Scott Swanson 
--
(or ss - hey, you've given me ideas, except it looks like something
from a notary seal or the nazi era - my middle initial is 'O' - that's
probably not a good idea either.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer