Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends

2010-01-20 Thread gg
On 01/19/10 22:51, Liam R E Quin wrote:
 On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
 [...]

 II. Range of actually useful values for IJG quality value

  For GIMP's target users less than half of all possible settings
 are useful:
 possibly - I've often used values as low as 35% or sometimes lower.
 The sweet spot depends hugely on your image and your purpose -
 consider providing a lowsrc alternate image for low bandwidth
 Web users for example, or a thumnail.

 Most of the preview images on www.fromoldbooks.org are saved at 75%
 (usually with smoothing to reduce artifacts a little)


   95
.  no-go: just wastes disk space -- ever heard of XCF?
  100

 Actually I use 97% a lot, and 100% too -- because I want jpeg format,
 not some application-specific thing that won't work for most users.
 Export is about interchange, the end product, you shouldn't ever use
 jpg for a file you're going to edit again, and you shouldn't normally
 use xcf for interchange unless you know they're using (a compatible
 version of) GIMP...

Once a user starts to use jpeg they have to decide what to do with 
quality setting. Bigger number = better quality is not too hard to get 
your head around. A bit of experimenting quickly reveals what works best 
for a particular task.

You quickly realise what ranges don't fit your needs and focus on those 
that do. End of story.

I see no use what so ever in creating some new, grouped setting in its 
place. This would essentially involve exactly the same learning process 
and reduce control and compromise results.




 III. Parameter Triaging

   The Subsampling parameter is more important than its current
   position inside the advanced parameters section suggests.
 Yes - in particular it affects colours, especially reds.

 Liam



I agree , this setting could come out be more visible. It's annoying 
having to dig in there just to check what it is set at.


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


Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends

2010-01-20 Thread Torsten Neuer
 Once a user starts to use jpeg they have to decide what to do with
 quality setting. Bigger number = better quality is not too hard to get
 your head around. A bit of experimenting quickly reveals what works best
 for a particular task.
 
 You quickly realise what ranges don't fit your needs and focus on those
 that do. End of story.
 
 I see no use what so ever in creating some new, grouped setting in its
 place. This would essentially involve exactly the same learning process
 and reduce control and compromise results.

What could be an option is to have named presets.

Right now, you can save the JPG settings for later use in exactly one preset.

Depending on the task, you may want to have different presets, so naming the 
presets and being able to recall them later when you do a similar task could 
perhaps be quite useful.

In such a case, Gimp could also ship with 2-3 default JPG presets which are 
optimized for a specific task, like photo lab image, web image, etc. to make it 
easier for the first-time (or occasional) Gimp user to get started with the JPG 
settings.

  Torsten


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] JPEG quality factor - some remaining odds and ends

2010-01-20 Thread yahvuu
Liam R E Quin wrote:
 On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
 [...]
 
 II. Range of actually useful values for IJG quality value

 For GIMP's target users less than half of all possible settings
 are useful:
 possibly - I've often used values as low as 35% or sometimes lower.
 The sweet spot depends hugely on your image and your purpose -
 consider providing a lowsrc alternate image for low bandwidth
 Web users for example, or a thumnail.

good point -- that proves wrong my claim that there were only a handful of
useful quality settings. Also, further discussion about those 5 values 95
becomes moot, i guess..


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


Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends

2010-01-19 Thread Liam R E Quin
On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote:
[...]

 II. Range of actually useful values for IJG quality value
 
 For GIMP's target users less than half of all possible settings
 are useful:
possibly - I've often used values as low as 35% or sometimes lower.
The sweet spot depends hugely on your image and your purpose -
consider providing a lowsrc alternate image for low bandwidth
Web users for example, or a thumnail.

Most of the preview images on www.fromoldbooks.org are saved at 75%
(usually with smoothing to reduce artifacts a little)


  95
   .  no-go: just wastes disk space -- ever heard of XCF?
 100

Actually I use 97% a lot, and 100% too -- because I want jpeg format,
not some application-specific thing that won't work for most users.
Export is about interchange, the end product, you shouldn't ever use
jpg for a file you're going to edit again, and you shouldn't normally
use xcf for interchange unless you know they're using (a compatible
version of) GIMP...


 III. Parameter Triaging
 
  The Subsampling parameter is more important than its current
  position inside the advanced parameters section suggests.
Yes - in particular it affects colours, especially reds.

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] JPEG quality factor - some remaining odds and ends

2010-01-19 Thread Jon Senior
On Tue, 19 Jan 2010 22:38:40 +0100
yahvuu yah...@gmail.com wrote:

 II. Range of actually useful values for IJG quality value
 
 For GIMP's target users less than half of all possible settings are 
 useful:
 http://yahvuu.files.wordpress.com/2009/08/ijgqualityrange.png
 or, in ASCII:
 
   0
   .
   .  no-go: blocky garbage
   .
  60
   .  if in dire need
  80
  90  the sweet spot
  95
   .  no-go: just wastes disk space -- ever heard of XCF?
 100

Sorry. I use 100 because the photo labs that I use for online printing only 
accept image upload in jpg format. 95 may be good enough, but for 80x60cm 
prints, I don't want good enough.

-- 
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] JPEG quality factor - some remaining odds and ends

2010-01-19 Thread Scott
On Tue, Jan 19, 2010 at 10:38:40PM +0100, yahvuu wrote:
 Hi all,
 
 recent discussion on gimp-user brought up some usuability issues
 of the JPEG export dialog [1]. Actually, there's nothing new to say
 about it... the big JPEG quality thread did cover it all [2].
 However, due to the sheer size of that thread, i think a summary of
 open issues is useful.
 

Can't recall if there was ever a discussion there about the
possibility of entering a starting desired file-size in the dialog,
whereupon the slider would be adjusted, from where it could be tweaked
up or down. Having limited storage space on my server, I am always
doing the quality/size compromise. Would be handy if the default
starting-point could be adjusted to size rather than quality.

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


Re: [Gimp-developer] jpeg quality factor

2007-07-14 Thread gg
On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler [EMAIL PROTECTED] wrote:

I'll try to follow the analogy without this becoming rediculous:


 In this analogy, the new GIMP Hammer would auto-provide a nail
 (since the nail is clearly better).  The carpenter would flip the GIMP
 hammer around and use the other end to drive in the screw.

I think a more correct representation would be the hammer turns it self  
around and refuses all attempts to come back.

  Since carpenters are pretty dextrous - high-end ones anyway  - I think  
 the
 carpenter would enjoy the versatility of the GIMP Hammer.

more likely a sprained wrist.

  No one in this discussion has ever said anything about removing GIMP's
 ability to produce JPEGs.  What (I think) is going on is a discussion
 about whether or not Save is an appropriate command for an action
 that discards data.

We're all agreed we are not targetting mickey mouse users , so why should  
we to treat graphics professionals as idiots?

We all know that jpeg is lossy. You use it with suitable settings in  
relation to the result required otherwise you use a different format.

There seems to be some underlying assumption here that jpeg loss is  
catasrophic. It is not. Sure, if I am going to post about the difference  
between lanczos and catmull-romm filters jpeg will not get a look in.  
However if I am messing with a photo of my solar panel at jpeg-84 I dont  
want some arse telling me I have to first save if in a format that takes  
up 10x more space because I may later want to reopen it and I may lose a  
bearly perceiptible bit of quality.

I dont give a damn for lectured by the interface, let me drive !!


 IMO opinion this pertains more to the newbies
 than anyone else.  Those who've used graphics for some time now
 (should) know what we're doing.
  Chris


I'm in perfect agreement there. This more of an attempt to lecture less  
familiar users that they should not be using jpeg as an intermediate  
storage format than to provide a better tool for high-end users as claimed.

In fact this logic is at complete odds with the vision. So much for the  
input of a professional interface architect.

As Raphael says we should try to cater for all users if possible. The  
suggested first time use message with dont show again option would seem  
best all round.

The minor disruption of a one time go away option for competant users  
and a clear warning to those who are not aware of the issue.

I should also point out the misuse of the import/export paradigm. This  
is used in other software of various sorts to indicate loading/saving data  
in a format which is not handled natively by the program.

It is nonsense to talk of exporting a jpeg to gimp's internal format.

This is surely convert to xcf.

BTW Chris, looks like you got caught out by the mailing list's FROM  
header, your message only had my address and did not go to the list. I  
presume this was not intended to be off list.


/gg

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


Re: [Gimp-developer] jpeg quality factor

2007-07-14 Thread David Gowers
On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Fri, 13 Jul 2007 00:03:18 +0200, Chris Mohler [EMAIL PROTECTED] wrote:

 I'll try to follow the analogy without this becoming rediculous:

[misrepresentation and reactiveness cut]


 We all know that jpeg is lossy. You use it with suitable settings in
 relation to the result required otherwise you use a different format.

 There seems to be some underlying assumption here that jpeg loss is
 catasrophic. It is not. Sure, if I am going to post about the difference
 between lanczos and catmull-romm filters jpeg will not get a look in.
 However if I am messing with a photo of my solar panel at jpeg-84 I dont
 want some arse telling me I have to first save if in a format that takes
 up 10x more space because I may later want to reopen it and I may lose a
 bearly perceiptible bit of quality.

The proposed scheme does not dictate that. The only thing needed to
facilitate your described work flow, with no additional overhead is a
'Quick Export' command that just saves to the last 'non-native'
filename (if I may introduce the idea of assigning both a native
filename and a (possibly empty) render filename to each image; this
would help with a number of things, eg. drawing with oversampling,
quick photo editing, images for web..)

 As Raphael says we should try to cater for all users if possible. The
 suggested first time use message with dont show again option would seem
 best all round.
Yes; just not only that. The full scheme described by Peter plus that.

 I should also point out the misuse of the import/export paradigm. This
 is used in other software of various sorts to indicate loading/saving data
 in a format which is not handled natively by the program.

Gimp only handles XCF; the rest *are* implemented outside of Gimp;
even gzip/bzip2 compression for XCFs is implemented as a plugin.

If you remove all plugins, it's plain to see that Gimp only handles
XCF natively, just like Photoshop only handles PSD natively; It's
generally a Bad Thing for an editor to need to cope with multiple
'native' formats. GIMP's 'parasite' concept allows it to store
arbitrary chunks of data, that may be acquired from importing (eg EXIF
data from a jpeg) without needing to understand the meaning of that
data; I understand how this may give the illusion that GIMP can handle
something not XCF, but it is only an illusion.

I think, highlighting this fact might be quite wise. We should not
annoy the user in telling them this - something as outwardly simple as
a parasite viewer/editor dockable could improve awareness.


 It is nonsense to talk of exporting a jpeg to gimp's internal format.
I agree fully. Nobody has mentioned that*, only the opposite.
1. You load the jpeg. (foo.jpeg)
2. You work on it. Each time you save, it's in XCF format (foo.xcf)
3. You export a jpeg when finished (foo.jpeg, or maybe foo-final.jpeg)

If anything, that says 'automatically import from jpeg' (which is the
current behaviour, minus actually changing the on-disk image format.)
and later 'export to jpeg'.
The addition I suggested earlier in this email would be trivially easy
to implement and use, logically consistent, and would not require the
GUI's concept of Save to remain in its current, broken, state.

I think, in short, this thread is mainly comprised of
miscommunication; People seem to think it implies things that it just
doesn't.

* Maybe Valerie did. I found her post very confusing, so I'm not sure
what she was suggesting.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor

2007-07-13 Thread saulgoode
Quoting [EMAIL PROTECTED]:

 On Tue, 10 Jul 2007 19:21:33 +0200,
 [EMAIL PROTECTED] wrote:

 No. If you want to specify something other than a user-specified
 default for an acceptable level of quality while editing in the GIMP
 (for example, overriding it with an image-specific value), that is
 when you should use Save As.

 Sorry but this is the mistake I have already pointed out , you dont know
 the meaning of the word default.

 If there is an image specific value you do not need a default.
 overriding a default with an image-specified value is a contradiction.


There are, at times, valid reasons to ignore the quality value  
associated with a particular JPEG file. Ignoring that value (and using  
some other methodology) should be available as an option. The user  
should be able to able to specify such an option as the default  
behavior for a non-interactive save operation.

There are sometimes valid reasons to honor the quality value  
associated with a particular JPEG file. Honoring that value (and  
ignoring some other methodology) should be available as an option. The  
user should be able to able to specify such an option as the default  
behavior for a non-interactive save operation.

I fail to see how I have misused the term default in any of this  
explanation.



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


Re: [Gimp-developer] jpeg quality factor

2007-07-13 Thread gg
On Fri, 13 Jul 2007 20:49:49 +0200,  
[EMAIL PROTECTED] wrote:


 I fail to see how I have misused the term default in any of this
 explanation.

Sorry , apparently you missed the other post where I explained this more  
fully, I assumed everyone who was following this was reading the posts.

The point is that default means a value to be used when no defined value  
is available. A value to be used by default.

When an image already has a value for jpeg_quality , or any other  
paramter, replacing this is not providing a default it is a forcing.

Hope that make it clearer.

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


Re: [Gimp-developer] jpeg quality factor

2007-07-13 Thread Raphaël Quinet
On Fri, 13 Jul 2007 22:42:29 +0200, [EMAIL PROTECTED] wrote:
 On Fri, 13 Jul 2007 20:49:49 +0200,  
 [EMAIL PROTECTED] wrote:
  I fail to see how I have misused the term default in any of this
  explanation.
[...]
 When an image already has a value for jpeg_quality , or any other  
 paramter, replacing this is not providing a default it is a forcing.

I hope that you both read the message in which I was suggesting to
use the terms default, original or current depending on where
some values come from.  As I explained in that message, the
original value (read from the file) will usually override any
default value (coming from GIMP or from the plug-in).

However, some plug-ins do not even attempt to read the original
value for some parameters because for some file formats it does not
make sense to re-use the same values as in the original file.

For JPEG quality, I think that it is best to do as in Tor's patch:
if the original value is higher than the default, then use that.
Otherwise, use the default so that the user is not surprised to
have a file saved with a lower quality than expected.

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


Re: [Gimp-developer] jpeg quality factor

2007-07-13 Thread Valerie VK
How about creating the following buttons on the jpeg save console?
- Save at original image compression value
- Save at user-specified compression value (insert current value of
used-specified quality)
- Change user-specified compression value

It can be abbreviated as the following:
Save at the following compression value:
- Original
- User-specified (insert number, so users would know what that value is)

I chose to replace default by user-specified to avoid confusion. 

I'm sorry if I'm repeating what someone else is saying, but all this
cross-talk is leaving me a bit lost. :S


   

Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz
 
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-12 Thread peter sikking
Raphaël wrote:

let's see how short I can keep this.

 We also have to be humble and remember that writing down the current
 vision only took us a couple of hours, not 5 years (basically one hour
 of discussion at LGM plus some e-mail exchanges while we were
 polishing the minutes).

Two hours. The vision has been simmering in the back of the minds of
everybody involved for all the years that they have been working on  
GIMP.

That is was externalised (written down) in such a short time
is the added value _I_ deliver to my customers.

And let me repeat: if the we had not reached this result in these
few hours, I would have interpreted that as the GIMP team having
no clue about what they are trying to achieve, and I would have
not gotten involved.

No vision (or a constantly disputed vision) == no clue ==
no chance in hell for anybody (including pros like me) to
achieve decent interaction == a project I do not need to ruin
my professional reputation on.

 Few? there are millions of users within our vision out there.
 Sorry, but I have to disagree here.  If you just look at the part of
 the product vision that says GIMP is ..., then it could apply to a
 large number of GIMP users.  But if you look at the context of the
 vision (which is not explicitely written in that section, but is part
 of the Targeted user base in the meeting minutes and the user
 scenarios + expert evaluation on gui.gimp.org), then it is clear
 that the vision is targeted at experienced, professional users.

I take the vision as broad as it can be explained (it was phrased not so
specific for a reason), but not broader.
I actually do not like the word professional, it just means earning
money. To sum it up I like to think of 'intense use', you either put
in a lot of hours with GIMP, or you have paid your dues and know what
you are doing.

 This
 is at best a small percentage of the current GIMP users. [...] But
 we have to acknowledge that the vision (or the way we use it) is
 targeted mainly at a minority of users.  This minority is almost
 certainly the most interesting subset o

I do not believe that.

 And I thought that we all understand that there is a
 choice of several free software programs out there for
 users who want to do simple red-eye removal from their
 holiday jpegs.

 Unfortunately, until that choice really exists this is a moot point.

we agreed at the vision meeting that the choice is there.

And I would let Krita, F-Spot, digikam et al. worry about serving
their market optimally, and actually give them a chance by keeping
GIMP out of their markets. Since we are not in it of the money,
we can actually improve our own situation by letting some room
for other software developers.

 This is a slippery slope. If anybody can excuse themselves from
 the vision when they personally do not like the logical outcome
 of applying it to a hairy UI design question, and bang in their
 yeah, but what about me feature into svn, then we are back at
 the headless chickens state.

 Unfortunately, you skipped the part of my message in which I wrote:
 It is always possible for someone to propose someting that goes
 against the current consensus and hopefully convince others that this
 is the right thing to do.

Your wish is my command ^}

Luckily, GIMP has a core and plugins. The core has to be redesigned
according to the product vision. This includes the standard distribution
of plugins.

I will measure anything that has to do with interaction against the
product vision to see if it interferes with it. If it does not bloat
the interface and stays out of the way of achieving the vision then  
it is fine with me. See the following frivolous extra:

http://gui.gimp.org/index.php/Selection_% 
2B_crop_tool_specification#mathematician's%20Easter%20egg

I did not chop its head off.

Any other counter-vision stuff (example: GIMPressionist) must stay out
of the core (distribution) and live happily as a one-click installation
on a web server (even on gimp.org).

 --ps

 principal user 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] jpeg quality factor.

2007-07-12 Thread Sven Neumann
Hi,

On Thu, 2007-07-12 at 13:29 +0200, peter sikking wrote:

 Two hours. The vision has been simmering in the back of the minds of
 everybody involved for all the years that they have been working on  
 GIMP.

If you are now interpreting this vision that way that GIMP is not meant
to be used for the workflow that Raphael described (touching up photos),
then perhaps we need to refine the vision.

 And I would let Krita, F-Spot, digikam et al. worry about serving
 their market optimally, and actually give them a chance by keeping
 GIMP out of their markets. Since we are not in it of the money,
 we can actually improve our own situation by letting some room
 for other software developers.

That is not an argument simply because market shares and such simply
don't matter here. And secondly I think that there is a lot of overlap
at least with Krita. Our product visions are quite similar with Krita
having the focus slightly more on painting. But that's only a marginal
difference.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-12 Thread peter sikking
Akkana wrote:

 I'm seeing an unspoken assumption in this thread that most photos
 are edited in multiple sessions: read into gimp, do a few
 operations, write to disk, read back in (perhaps hours or days
 later), do a few more operations, write back out, repeat.

I was more thinking from the point of it is never finished.
Either as an artist you grow and want to revise your work, or
people you work for ask you for another revision.

'and you just thought that first jpeg was the final result'

So giving priority to saving files in full-fidelity is the way
to go for me.

 If users get the hint
 that opening and saving the same jpeg again and again is a pain (also
 for the quality) and that either adopting a high-end GIMP file  
 workflow
 or moving to another (mid-fi) app to work in their lossy jpeg way.

 Another thing I'm unclear on in this thread: when I first heard the
 idea of forcing Export instead of Save, the plan seemed to be that
 Save would always save XCF, and anything else would require Export.

Writing that a few days ago I realised that that is where you end
up when you systematically apply the argument:
only xcf is full-fidelity.

So you Save (as) in that format, and the rest is exported.

But I thought that would be to hard to swallow at this point in
the current discussion. But the Raphael writes:

 So I think that the statement from Peter that singled out indexed
 image formats and JPEG was slightly misleading (and this triggered
 my initial reaction).  Basically, only XCF would be saved and all
 other image formats would be exported.

Sorry for the confusion then, we all seem to be moving in the
same direction.

 --ps

 principal user 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] jpeg quality factor.

2007-07-12 Thread Raphaël Quinet
Let me also try to keep this (relatively) short.  I'm not good at this. :-)

On Thu, 12 Jul 2007 13:29:49 +0200, peter sikking [EMAIL PROTECTED] wrote:
 I take the vision as broad as it can be explained (it was phrased not so
 specific for a reason), but not broader.

That's certainly fine.  But if you only check the comments that you
have made in the last two days in this thread, you will see that you
have emphasized several times the term high-end.  Specifically:
  'High-end' is the word I want us to focus on.
This means focusing only on a minority of GIMP users.  And as I wrote
earlier, I am convinced that it's the best thing to do as this is the
best way to have real progress.  However, we should still be careful
about what these improvements (or changes, in general) mean to the
majority of our users (those who do not fit in the high-end
definition).

  This
  is at best a small percentage of the current GIMP users. [...] But
  we have to acknowledge that the vision (or the way we use it) is
  targeted mainly at a minority of users.  This minority is almost
  certainly the most interesting subset o
 
 I do not believe that.

You do not believe that this minority is the most interesting subset
or that it is a minority?  Assuming the latter, I am sorry but I
believe that the vast majority of GIMP users are not high-end users.
Most users do not use GIMP every day, probably not even every week.

But the cumulative time that all those users spend using GIMP is
probably much larger than the time that the few experienced users
who need and use the high-end features spend with GIMP.  So I would
like GIMP to focus on high-end features as much as possible
according to our vision.  But if some of the required changes imply
a significant regression for the majority of the users, then we
should think twice about them.  The changes can still be applied
even if they add a cost for some users because it is impossible to
please everybody, but we should keep some balance and not always
focus exclusively on the experienced users.

  And I thought that we all understand that there is a
  choice of several free software programs out there for
  users who want to do simple red-eye removal from their
  holiday jpegs.
 
  Unfortunately, until that choice really exists this is a moot point.
 
 we agreed at the vision meeting that the choice is there.

This was mentioned, but there was some disagreement (well, at least
during the part of the meeting that I attended - I missed the
discussions on the second day).  There was certainly an agreement on
the fact that GIMP cannot do everything for everybody and that some
other programs should fill the niches that we do not cover.  But I
don't think that there was ever an agreement on the fact that the
choice is there (last year during the meeting, or even today).  I
could not agree with that because there is no real choice among free
software for browsing and doing simple adjustments on holiday
pictures.  There is currently nothing that comes close to Photoshop
Elements or even to the various simpler programs that come bundled
with most cameras.

As I wrote, F-Spot is coming close for some features (and some of
the important ones have only been added in the recent months), but it
is still necessary to complement it with GIMP or Krita for some
operations such as correcting some errors with the clone tool, doing
finer color adjustments or just rotating the image a bit.  Nothing
very fancy nor high-end, but this is still something that people use
GIMP for.

This may change in the future if F-Spot or others get better, but I
doubt that it is part of F-Spot's vision to include things such as
our paint tools or transform tools.  Yet this is something that some
users expect to find in Free Software because they can do that with
the free but proprietary stuff that they got with their cheap
point-and-shoot digital cameras.  I just don't want to forget about
these users too early, even if they are not the ones we try to
please first.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-12 Thread Raphaël Quinet
On Thu, 12 Jul 2007 14:31:16 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote:
 Let me also try to keep this (relatively) short.  I'm not good at this. :-)

I could have made it much shorter.  Summary:

1) Our vision focuses on a minority of GIMP users (experienced users, or
   those who need high-end features).  And that's a good thing because it
   helps us to have a clear direction.  But we must still balance that
   with the interests of the majority whenever possible.

2) There are still many simple usage scenarios that are not covered by any
   other program (free software), so there is no real choice besides GIMP
   for many users.

Wow, I can write something in less than ten lines.  :-)

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


Re: [Gimp-developer] jpeg quality factor

2007-07-12 Thread gg
On Tue, 10 Jul 2007 19:21:33 +0200,  
[EMAIL PROTECTED] wrote:

 No. If you want to specify something other than a user-specified
 default for an acceptable level of quality while editing in the GIMP
 (for example, overriding it with an image-specific value), that is
 when you should use Save As.

Sorry but this is the mistake I have already pointed out , you dont know  
the meaning of the word default.

If there is an image specific value you do not need a default.  
overriding a default with an image-specified value is a contradiction.

@Peter

The key issue, it seems, is that a would-be high-end tool should not be  
telling me it knows better than I (the high-end user) how to do what I  
need to do.

GIMP IS A TOOL, NOT A TUTORIAL.

Take an analogy:

A builder needs to nail a piece of wood as a guide but all the nails he  
has to hand are too big. To get round the problem he takes a couple of  
screws he has in his pocket and hammers them in to tack the guide into  
place.

Well we all know you should NEVER hammer in a screw but it gets the job  
done. As a high-end builder he uses the tools and materials to hand to get  
the job done with the minimum of wasted time.

Now imagine he'd just bought the new high-end Gimp Hammer, the high-end  
solution for high-end users.

When he comes to hit his nail he realises the his new high-end hammer has  
a specially crafted end that slips off screw heads because the guy who  
designed it thinks you should NEVER work this way and wants to force his  
work flow to the one and only _correct_ way to do this job.

Well I hope the glazier has not been to the site yet because that high-end  
hammer is going out of the nearest high-end window.

Now can we please stop all this I know best dicatorial design non-sense?  
Especially since the current state of all gimp installations on the planet  
(except for a handful of us who have build snv in that last few days)  
clearly shows that we dont know best.

Let's credit our hyperthetical high-end user with a grain of sense and  
suspect he may actually know what he is doing. Give him a powerful,  
flexible tool that does not try to tell him how to do his job.

Don't get in his way if he decides, for reasons that may be prefectly  
valid in the context of what he is doing, that he wants to save a jpeg.

/gg

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


Re: [Gimp-developer] jpeg quality factor

2007-07-12 Thread Chris Mohler
Sorry - I always forget to Reply-All to this list...


On 7/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[...]
 GIMP IS A TOOL, NOT A TUTORIAL.

 Take an analogy:

 A builder needs to nail a piece of wood as a guide but all the nails he
 has to hand are too big. To get round the problem he takes a couple of
 screws he has in his pocket and hammers them in to tack the guide into
 place.

 Well we all know you should NEVER hammer in a screw but it gets the job
 done. As a high-end builder he uses the tools and materials to hand to get
 the job done with the minimum of wasted time.

 Now imagine he'd just bought the new high-end Gimp Hammer, the high-end
 solution for high-end users.

 When he comes to hit his nail he realises the his new high-end hammer has
 a specially crafted end that slips off screw heads because the guy who
 designed it thinks you should NEVER work this way and wants to force his
 work flow to the one and only _correct_ way to do this job.


In this analogy, the new GIMP Hammer would auto-provide a nail
(since the nail is clearly better).  The carpenter would flip the GIMP
hammer around and use the other end to drive in the screw.  Since
carpenters are pretty dextrous - high-end ones anyway :) - I think the
carpenter would enjoy the versatility of the GIMP Hammer.

No one in this discussion has ever said anything about removing GIMP's
ability to produce JPEGs.  What (I think) is going on is a discussion
about whether or not Save is an appropriate command for an action
that discards data.  IMO opinion this pertains more to the newbies
than anyone else.  Those who've used graphics for some time now
(should) know what we're doing.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread David Gowers
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED]
 wrote:
 
  Really? Let's have a look at the product vision. 'High-end'
  is the word I want us to focus on.

 Please dont distort this by taking one word out of context.

 Gimp's aim to be a high-end image manipulation program does not mean
 everyone has to become a professional graphics artist.

Nor has Peter suggested this. Take your own advice about not taking
things out of context.
What was suggested is essentially to make the 'Save' action more
truthful - in order to
  a) Reduce confusion -- 'wait, every time I edit and resave this jpeg
it gets worse. Why is that?'* -- by providing a standard editing
format.
Throwing away data is a pathological case, which is why GIMP should
only allow this by a plugin, rather than explicitly supporting it; it
should, probably, be considered 'deprecated'.

  b) Reduce corner cases (ie improve interface consistency) -- 'Save'
shouldn't mean 'Lose.' in any case.
  c) Adhere better to the basic Unix tenet of 'Don't throw data away
unless explicitly commanded to.'

What is being proposed is both more effective for the general editing
case, and more flexible.

I appreciate the compression benefits of JPEG for photos, but IMO on
todays multi-gigabyte hard drives, saving a single uncompressed
working image per image you work on is unlikely to be any significant
resource drain.. even for huge images.

I want to mention the necessity of recording the original input image
filename -- and maybe an action to 'Save over original'; I believe it
hasn't been addressed yet, and I expect that someone like yourself
would be satisfied by that. (I still think you should RTFM on the
vision of gimp as high end graphics editor -- it was made by
discussion with the GIMP team in-person.

http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-overview.html
http://gui.gimp.org/index.php/GIMP_UI_Redesign
)

*as someone else already noted, any manipulation of large areas of the
image is liable to cause further compression error, whether the
compression parameters have been altered or not.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Chris Mohler
On 7/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler [EMAIL PROTECTED] wrote:

   I expect the Save command to retain
  *all* data: not just some.

 If you expect that when using jpeg you are wrong and need to see the first
 use warning that has been suggested.

I understand that JPEG drops data.  My point: in most applications,
'save' means save your data.  In the image editing world, 'save' has
come to mean save as much data as you want given the limitations of
the format - here are (or might be) some options.


   Exporting is preferable to a lossy save.

 Says you. This is not always the case. It depends what is required.

It's just my opinion: save != lose


  Just because most image editors throw away
  parts of your file, there's no reason for GIMP to follow suit (anyone
  ever play Lemmings?).

 I dont recall anyone having advanced that as an arguement. I really think
 we should stop exagerating this issue.

It's a non-issue - we have enough experience to dodge the pitfalls of
lossy formats.  It's the status quo, and we live with it.  My source
files stay XCF, TIFF, or PNG and my web files end up JPEG or PNG.
Such is life.  I just wonder if it could be easier.


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Graeme Gill
Chris Mohler wrote:

 I understand that JPEG drops data.  My point: in most applications,
 'save' means save your data.  In the image editing world, 'save' has
 come to mean save as much data as you want given the limitations of
 the format - here are (or might be) some options.

One view is that by the choice of JPEG as a file format, the user
has already stated that their goal for this image is moderate file
size over lossless storage. An application could therefore be considered
to be behaving reasonably in processing such a file, if it introduced
no noticeable additional degradation in quality. Since by the choice of the
JPEG format image information has already been thrown away, a small additional
loss of information is unlikely to be noticeable (ie. retaining similar or 
better
quantization tables) and is consistent with the users implicit goals.

Defaulting to a lossless format when the original file is a JPEG could
be seen as poor application behaviour, since it is contradicting the users
implicit preferences.

Graeme Gill.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread jernej
On Tuesday, July 10, 2007, 8:09:04, Chris Mohler wrote:

 I understand that JPEG drops data.  My point: in most applications,
 'save' means save your data.  In the image editing world, 'save' has
 come to mean save as much data as you want given the limitations of
 the format - here are (or might be) some options.

Maybe GIMP could do it the way CoolEdit (audio editor for windows)
does it - when you save to a lossy format, it pops up a warning
telling you that you shouldn't use that file for intermediate storage,
but only for the final product.

-- 
 Jernej Simončič  http://deepthought.ena.si/ 

Nothing ever gets built on schedule or within budget.
   -- Cheops's Law

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


Re: [Gimp-developer] jpeg quality factor

2007-07-10 Thread saulgoode
Quoting [EMAIL PROTECTED]:

 On Tue, 10 Jul 2007 01:24:40 +0200,
 [EMAIL PROTECTED] wrote:

 If I have
 a Quality setting of 95 and I load an image that was saved with a
 Q=50, I should be very disappointed if the GIMP degraded to that level
 when I have specified that I expect less loss when saving.

 It would NOT degrade it because it already was that quality. Saving it
 a 95 would increase filesize by about a factor of 8 without any gain in
 quality! You would not have less loss.


You presume that I have done nothing to improve the content of image.  
The file saved IS degraded relative to the image I am editing.

 If you want to change the nature of the image format user SaveAs.

 Save should keep things the way they are as near as possible.

No. If you want to specify something other than a user-specified  
default for an acceptable level of quality while editing in the GIMP  
(for example, overriding it with an image-specific value), that is  
when you should use Save As. If file size is your main concern, use  
Save For Web. If honoring the user's expectations with regard to image  
quality is your focus, Save should recognize user-specified default  
settings.


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread peter sikking
gg, my dear agent provocateur,

creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't fudge when the moment is there.

You make hard choices about which features to include and
which not. Which workflows to actively support and streamline,
and which go on the back seat. About beginners vs. Experts.

Sven did not set the product vision, the GIMP team did by
consensus. I only moderated that session. But I am here to
implement that vision on an user interaction level.

That means I make hard choices, based on the vision,
the way thing work technically and our workplace observations.

 --ps

 principal user 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] jpeg quality factor.

2007-07-10 Thread Raphaël Quinet
On Tue, 10 Jul 2007 12:29:23 +0200, peter sikking [EMAIL PROTECTED] wrote:
 creating interaction requires making hard choices, because you
 cannot make an application for everybody. For that you use the
 product vision that you set as a team at the beginning of the
 project. And then you don't fudge when the moment is there.

I would like to temper this a bit (not agent provocateur as gg,
but maybe devil's advocate): a team that is too rigid about its
vision and never adapts it over time runs a real risk of
becoming irrelevant after a while.  On the other hand, having
no vision at all or ignoring it and running like headless
chicken is usually worse.

 You make hard choices about which features to include and
 which not. Which workflows to actively support and streamline,
 and which go on the back seat. About beginners vs. Experts.

But one should always balance the interest of the few who are
targeted by our product vision with the interest of the
majority of the users who are not necessarily part of that
vision.  In other words, a decision that provides a small
improvement for the target users but implies a significant
regression for all other users should be considered very
carefully.

Our current vision is rather elitist.  This is not a bad
thing because this is often the only way to make real
progress.  But we should also be aware of its consequences.

 Sven did not set the product vision, the GIMP team did by
 consensus. I only moderated that session. But I am here to
 implement that vision on an user interaction level.

Again, to temper things a bit: this was only a subset of the
developers present at LGM last year (GIMPCon 2006, see the
minutes at http://developer.gimp.org/gimpcon/2006/ and read
the section GIMP Vision).  I hope that this was a
representative subset of the GIMP contributors (of course it
was, I was there!) but we should also keep in mind that
nobody has absolute authority over the GIMP project.  It is
always possible for someone to propose someting that goes
against the current consensus and hopefully convince others
that this is the right thing to do.

This may be good or bad depending on the context (it should
also be possible to stop useless arguments by saying that
something is out of scope for GIMP).  I am not judging the
merits of the way we work, but just stating that this is
something to keep in mind.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread peter sikking
Raphaël wrote:

 creating interaction requires making hard choices, because you
 cannot make an application for everybody. For that you use the
 product vision that you set as a team at the beginning of the
 project. And then you don't fudge when the moment is there.

 I would like to temper this a bit (not agent provocateur as gg,
 but maybe devil's advocate): a team that is too rigid about its
 vision and never adapts it over time runs a real risk of
 becoming irrelevant after a while.  On the other hand, having
 no vision at all or ignoring it and running like headless
 chicken is usually worse.

I agree that a product vision, like a national policy,
should be reviewed every, say, 5 years. Do realise that
when you chance the the vision, that you restart, from zero,
a process that takes about 5 years. And thanks for saying
that ignoring the vision is worse.

 You make hard choices about which features to include and
 which not. Which workflows to actively support and streamline,
 and which go on the back seat. About beginners vs. Experts.

 But one should always balance the interest of the few who are
 targeted by our product vision with the interest of the
 majority of the users who are not necessarily part of that
 vision.

Few? there are millions of users within our vision out there.
And if we work to make GIMP represent this vision coherently
in the UI, then GIMP will become a viable, natural choice for
the people we want to use it.

And I thought that we all understand that there is a
choice of several free software programs out there for
users who want to do simple red-eye removal from their
holiday jpegs. We cannot make GIMP for them if we want
to make it for the high-end market. One of them has the
priority, and the other can use GIMP at their own risk.

It took me 5 second to agree with the maintainer of Krita
to agree that GIMP and Krita are not competitors, they serve
two different markets, and can happily live side by side.

 In other words, a decision that provides a small
 improvement for the target users but implies a significant
 regression for all other users should be considered very
 carefully.

Actually in this case it the other way around. There is
a significant improvement for target users, with clarification
of image degradation of everyone, and little or no regression
for the lossy-jpeg users.

 Our current vision is rather elitist.  This is not a bad
 thing because this is often the only way to make real
 progress.  But we should also be aware of its consequences.

Well, you have chosen that GIMP is a fast driving machine,
able to compete with the best. Do you mind that I
try to focus us on that when the question is what about
going shopping? or what about taking driving lessons in
our machine?

 Sven did not set the product vision, the GIMP team did by
 consensus. I only moderated that session. But I am here to
 implement that vision on an user interaction level.

 Again, to temper things a bit: this was only a subset of the
 developers present at LGM last year (GIMPCon 2006, see the
 minutes at http://developer.gimp.org/gimpcon/2006/ and read
 the section GIMP Vision).

This is a slippery slope. If anybody can excuse themselves from
the vision when they personally do not like the logical outcome
of applying it to a hairy UI design question, and bang in their
yeah, but what about me feature into svn, then we are back at
the headless chickens state.

Please, do not get cold feet when the law of nature that we
cannot make everybody happy becomes apparent.

 --ps

 principal user 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] jpeg quality factor.

2007-07-10 Thread Michael Schumacher
Von: Raphaël Quinet [EMAIL PROTECTED]

 We also have to be humble and remember that writing down the current
 vision only took us a couple of hours, not 5 years (basically one hour
 of discussion at LGM plus some e-mail exchanges while we were
 polishing the minutes).

... plus the better part of two days during the GIMP usability weekend in 
Essen. And this does still not take Kanila's and Peter's effort into account.


HTH,
Michael
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Michael Schumacher
Von: Michael Schumacher [EMAIL PROTECTED]

 Kanila's

Kamila, sorry for misspelling your name.


Michael


-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Raphaël Quinet
On Tue, 10 Jul 2007 16:32:11 +0200, peter sikking [EMAIL PROTECTED] wrote:
 Raphaël wrote:
  I would like to temper this a bit (not agent provocateur as gg,
  but maybe devil's advocate): a team that is too rigid about its
  vision and never adapts it over time runs a real risk of
  becoming irrelevant after a while.  On the other hand, having
  no vision at all or ignoring it and running like headless
  chicken is usually worse.
 
 I agree that a product vision, like a national policy,
 should be reviewed every, say, 5 years. Do realise that
 when you chance the the vision, that you restart, from zero,
 a process that takes about 5 years. And thanks for saying
 that ignoring the vision is worse.

We also have to be humble and remember that writing down the current
vision only took us a couple of hours, not 5 years (basically one hour
of discussion at LGM plus some e-mail exchanges while we were
polishing the minutes).  Again, I am playing the devil's advocate
here, just trying to counter-balance your argument: I agree with the
vision and I think that we should all follow it; however, I also want
to be realistic and not see it as a sacred thing that is cast in
stone.

  But one should always balance the interest of the few who are
  targeted by our product vision with the interest of the
  majority of the users who are not necessarily part of that
  vision.
 
 Few? there are millions of users within our vision out there.
 And if we work to make GIMP represent this vision coherently
 in the UI, then GIMP will become a viable, natural choice for
 the people we want to use it.

Sorry, but I have to disagree here.  If you just look at the part of
the product vision that says GIMP is ..., then it could apply to a
large number of GIMP users.  But if you look at the context of the
vision (which is not explicitely written in that section, but is part
of the Targeted user base in the meeting minutes and the user
scenarios + expert evaluation on gui.gimp.org), then it is clear
that the vision is targeted at experienced, professional users.  This
is at best a small percentage of the current GIMP users.  As I wrote
elsewhere, our current vision is rather elitist (the vision itself or
how it is usually referred to).  Again, there is nothing wrong with
that because this is usually the only way to have real progress.  But
we have to acknowledge that the vision (or the way we use it) is
targeted mainly at a minority of users.  This minority is almost
certainly the most interesting subset of our users, but it is a
minority nonetheless.

 And I thought that we all understand that there is a
 choice of several free software programs out there for
 users who want to do simple red-eye removal from their
 holiday jpegs.

Unfortunately, until that choice really exists this is a moot point.
Basically, there is currently no good free software alternative to
Photoshop Elements or even to the simple program (proprietary,
Windows-only) that was delivered with my camera and allows one to
quickly browse images, correct red eyes, exposure or color casts,
crop/resize images and view/edit metadata.  F-Spot comes very close to
doing all that, but still has some weak spots that require you to use
GIMP, Krita, mtPaint or Paint.NET for adjustments.  Many of the quick
actions provided in Photoshop Elements (which comes bundled with some
cameras) are not available in any free program yet.

Again, I am not saying that we should do all that and try to solve all
problems in GIMP.  I prefer to stick to the current vision.  I am just
continuing my devil's advocate role and stating that you should not
claim that there is a choice when the choice does not really exist.

  In other words, a decision that provides a small
  improvement for the target users but implies a significant
  regression for all other users should be considered very
  carefully.
 
 Actually in this case it the other way around. There is
 a significant improvement for target users, with clarification
 of image degradation of everyone, and little or no regression
 for the lossy-jpeg users.

We seem to disagree on that, but maybe it is better if I address this
point in a reply to your previous message.

  Again, to temper things a bit: this was only a subset of the
  developers present at LGM last year (GIMPCon 2006, see the
  minutes at http://developer.gimp.org/gimpcon/2006/ and read
  the section GIMP Vision).
 
 This is a slippery slope. If anybody can excuse themselves from
 the vision when they personally do not like the logical outcome
 of applying it to a hairy UI design question, and bang in their
 yeah, but what about me feature into svn, then we are back at
 the headless chickens state.

Unfortunately, you skipped the part of my message in which I wrote:
It is always possible for someone to propose someting that goes
against the current consensus and hopefully convince others that this
is the right thing to do.  The last part (convincing others) is
important.  Making 

Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Raphaël Quinet
On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED] wrote:
 There is also a real benefit in opening a jpeg and then saving
 the result in another (GIMP) file. We see from the explanations in this
 thread that opening a jpeg and then saving it again means a loss of
 information. So overwriting an original is a loss. Working on a
 full-fidelity copy version is preferred.

Note that in the workflow that I described, I never mentioned
overwriting the original.  On the contrary, I said that the final
JPEG file would be saved under another name.


 The early part of this thread is full of misunderstanding at which
 point working with jpeg incurs quality loss. I say it is because of
 the you can work in jpeg myth. I am still confused that you talk
 about saving intermediate results while working on a jpeg. Either
 each save reduces quality (implicit save and reload, ouch) or there
 is a penalty for closing the file and reopening it, because you
 lost the full-fidelity internal (GIMP) representation, ouch.

I am not sure about what others had in mind in this thread, but I
I was mostly focusing on corrections to the source photos such as
correcting the exposure or color balance and making other minor
edits with the clone tool, etc..  These steps can be performed in
a single session without having to save any full-fidelity internal
representation.  When I mentioned saving intermediate results, I
meant saving copies of the image that you are currently working on,
if you want to check how the final output will look like (including
losses due to compression).

If you intend to work further on the image or to re-use some parts
of it in a collage or in a more complex work, then it certainly
makes sense to save the XCF version (or any other lossless format).
The same applies if you work more than a few minutes on the image
and it would cost too much to re-do these changes from the original
in case you decide some weeks later that you need to apply more
changes to the image.

But for the simple workflow that I described (which is or was
rather common for me), in which simple corrections have to be
applied to a large number of images without intending to work on
them further, then it makes sense to have JPEG as input and as
output without wasting time or space with intermediate formats.

 So I see real benefits for a high-end image manipulation program
 that lossy formats are pushed out to the very beginning and very
 end of the workflow. That the working copy of the file is GIMP format,
 in full fidelity, any GIMP operation naturally possible, and with
 no penalty for opening and closing the file.

I am not disputing that.  We should encourage users to use the
lossless XCF format for all things that may need to be edited
later or re-used in other images.  As long as this can be done
without breaking common workflows, then it's fine.

I don't mind if the simple load-edit-save cycle for JPEG images
produces a warning the first time I do that, telling me that
saving in JPEG will result in a quality loss and recommending
XCF for saving any work-in-progress.

But would mind getting this warning every time or being forced
to use a different menu option than the normal Save for the
second and subsequent attempts at saving the image.  This is
how I interpreted your initial reaction.  If I misunderstood
what you meant and you did not intend to break the flow, then
I am sorry for the misunderstanding and we can forget about it
because there is really no issue.

-Raphaël

P.S.: If this issue is cleared and we ignore the arguments for
  the sake of argumenting (my previous message), then I
  think that I have a solution for the original issue
  mentioned in this thread: this is very close to the
  patch proposed by Tor and it also supports JPEG files
  that were not created by libjpeg.  More about that
  later, when my code is ready.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Raphaël Quinet
On Tue, 10 Jul 2007 18:26:38 +0200, Michael Schumacher [EMAIL PROTECTED] 
wrote:
 Von: Raphaël Quinet [EMAIL PROTECTED]
  We also have to be humble and remember that writing down the current
  vision only took us a couple of hours, not 5 years (basically one hour
  of discussion at LGM plus some e-mail exchanges while we were
  polishing the minutes).
 
 ... plus the better part of two days during the GIMP usability weekend in 
 Essen. And this does still not take Kanila's and Peter's effort into account.

I was referring to the vision, not to the use cases.

But you are right that a lot of work was also invested in the usability
aspects derived from the vision, and Peter and Kamila should of course
be credited for that.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Akkana Peck
peter sikking writes:
 But in between, as long as it is not finished, there is no role for  
 jpeg. Only one decompression at the beginning and a compression of the
 end result is defendable in high-end graphics.

I'm seeing an unspoken assumption in this thread that most photos
are edited in multiple sessions: read into gimp, do a few
operations, write to disk, read back in (perhaps hours or days
later), do a few more operations, write back out, repeat.

In my experience, it's much more common to read a jpeg in once and
do a lot of operations on it in one session, saving periodically.
There's no cumulative loss of quality: the intermediate saves are in
case of disaster like a power failure, not a way to quit gimp and
continue the editing process later.

But I think I remember Sven saying recently that Export would be able
to save without prompting each time, after the first time. (I guess
that means there will also be an Export As, in case you need to
change the filename?) So those of us who often work in JPEG could
use it just like we use Save now, and even bind ^S to it.

 If users get the hint
 that opening and saving the same jpeg again and again is a pain (also
 for the quality) and that either adopting a high-end GIMP file workflow
 or moving to another (mid-fi) app to work in their lossy jpeg way.

Another thing I'm unclear on in this thread: when I first heard the
idea of forcing Export instead of Save, the plan seemed to be that
Save would always save XCF, and anything else would require Export.
But now you seem to be telling us that the issue is lossiness, and
the point of Export is to make it more hassle to save to lossy formats,
to discourage use of those formats.  Does that imply that Save will
include PNG, TIFF and other non-lossy formats?

-- 
...Akkana
Beginning GIMP: From Novice to Professional: http://gimpbook.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Raphaël Quinet
On Tue, 10 Jul 2007 09:51:24 -0700, Akkana Peck [EMAIL PROTECTED] wrote:
 Another thing I'm unclear on in this thread: when I first heard the
 idea of forcing Export instead of Save, the plan seemed to be that
 Save would always save XCF, and anything else would require Export.
 But now you seem to be telling us that the issue is lossiness, and
 the point of Export is to make it more hassle to save to lossy formats,
 to discourage use of those formats.  Does that imply that Save will
 include PNG, TIFF and other non-lossy formats?

If you consider the whole image (including layers, metadata, etc.),
then the only lossless image format is XCF.  All other formats drop
some information: PNG cannot save layers, TIFF cannot save all
GIMP parasites, etc.  In fact, even the current XCF loses some
information if you consider that it does not record the full undo
history and the current tool contexts, but this is something that
most users accept.

So I think that the statement from Peter that singled out indexed
image formats and JPEG was slightly misleading (and this triggered
my initial reaction).  Basically, only XCF would be saved and all
other image formats would be exported.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Alexandre Prokoudine
On 7/10/07, Raphaël Quinet wrote:

 GIMP parasites, etc.  In fact, even the current XCF loses some
 information if you consider that it does not record the full undo
 history and the current tool contexts, but this is something that
 most users accept.

They really do?

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


Re: [Gimp-developer] jpeg quality factor

2007-07-10 Thread saulgoode
Quoting [EMAIL PROTECTED]:

 On Tue, 10 Jul 2007 01:24:40 +0200,
 [EMAIL PROTECTED] wrote:

 If I have
 a Quality setting of 95 and I load an image that was saved with a
 Q=50, I should be very disappointed if the GIMP degraded to that level
 when I have specified that I expect less loss when saving.

 It would NOT degrade it because it already was that quality. Saving it
 a 95 would increase filesize by about a factor of 8 without any gain in
 quality! You would not have less loss.


You presume that I have done nothing to improve the content of image.
The file saved IS degraded relative to the image I am editing.

 If you want to change the nature of the image format user SaveAs.

 Save should keep things the way they are as near as possible.

No. If you want to specify something other than a user-specified
default for an acceptable level of quality while editing in the GIMP
(for example, overriding it with an image-specific value), that is
when you should use Save As. If file size is your main concern, use
Save For Web. If honoring the user's expectations with regard to image
quality is your focus, Save should recognize user-specified default
settings.




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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Sven Neumann
On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote:

 For my part I miss save a copy as... which in some programs
 saves the file like Save As but doesn't change the filename of
 what's being edited.

GIMP 2.3 has this feature for quite a while already.

 I wonder if it'd be possible, for gimp 2.6, to consider unifying
 the output plugins a bit, so that you can have a pull-down of file
 formats and see the parameters for each format before you hit save,

Something along those lines has been suggested before. It's rather
difficult to implement but if someone would come up with a decent plan
it would be worth trying.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Guillermo Espertino
So I broke my promess.

 creating interaction requires making hard choices, because you
 cannot make an application for everybody.

I have to agree. A good UI doesn't do what users ask. It does what is better 
for the users. ;-)
This approach of taking the lossy format to an import/export section instead of 
open/save is very interesting and, even though users will have to get used to, 
will define a more robust professional workflow.
For now, the Save as patch is a good temporal fix.
What's very important is that the problem of the arbitrary behaviour of the 
jpeg saving was addressed and users who ignore the whole issue won't be 
wrecking their images anymore.

Thanks!
Gez.




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


Re: [Gimp-developer] jpeg quality factor.

2007-07-10 Thread Liam R E Quin
On Tue, 2007-07-10 at 19:41 +0200, Sven Neumann wrote:
 On Mon, 2007-07-09 at 18:37 -0400, Liam R E Quin wrote:
 
  For my part I miss save a copy as... which in some programs
  saves the file like Save As but doesn't change the filename of
  what's being edited.
 
 GIMP 2.3 has this feature for quite a while already.

Oops, so I missed it but Gimp didn't -- thanks for replying!!

  I wonder if it'd be possible, for gimp 2.6, to consider unifying
  the output plugins a bit, so that you can have a pull-down of file
  formats and see the parameters for each format before you hit save,
 
 Something along those lines has been suggested before. It's rather
 difficult to implement but if someone would come up with a decent plan
 it would be worth trying.

I'll take some time to think about it, in case it is of use, and
will write something up for 2.6.

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] jpeg quality factor.

2007-07-09 Thread Sven Neumann
Hi,

On Sun, 2007-07-08 at 19:15 -0400, guepe wrote:

 In fact, my patch... does exactly that : if defaults settings are
 already saved, jpeg is saved with the parasites one (erasing the
 hardcoded ones). If no settings have been saved, then hardcoded are
 used.

There is another player in the game and that's the last-used values
stored with gimp_[gs]et_data(). And that's what has bitten Guillermo. He
has saved an image as JPEG with low quality settings. Then later, he
saved another image, which didn't have the parasite set. And for that
image, the low quality parameters from the last invocation of the JPEG
plug-in have been used. This is the expected behavior for all plug-ins.
But we might want to make an exception for JPEG because of its
potentially destructive nature.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Sven Neumann
Moin,

On Mon, 2007-07-09 at 00:03 +0200, Sven Neumann wrote:

 The JPEG plug-in should not use the last-used values when being run
 non-interactively from the Save action. It should use the, now
 user-configurable, default values. Of course if the jpeg-save-options
 parasite is set on the image that is being saved, then those values
 should be used. As far as I can see now, this means removing a single
 line in jpeg.c. I will have a closer look tomorrow morning.

I found a better solution. The JPEG plug-in will now prompt the user
with a dialog, even if called from the Save action, iff the image does
not have the jpeg-save-options parasite set. This is basically what
Guillermo suggested earlier. I said it would be difficult to implement
but it turned out that it was quite easy and doesn't require changes to
the file plug-in infrastructure.

The change is in SVN and I think we can settle this issue now. If
someone wants to try to recover some of the JPEG save settings when
loading the JPEG file, feel free.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Mon, 09 Jul 2007 08:14:29 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Sun, 2007-07-08 at 19:15 -0400, guepe wrote:

 In fact, my patch... does exactly that : if defaults settings are
 already saved, jpeg is saved with the parasites one (erasing the
 hardcoded ones). If no settings have been saved, then hardcoded are
 used.

 There is another player in the game and that's the last-used values
 stored with gimp_[gs]et_data(). And that's what has bitten Guillermo. He
 has saved an image as JPEG with low quality settings. Then later, he
 saved another image, which didn't have the parasite set. And for that
 image, the low quality parameters from the last invocation of the JPEG
 plug-in have been used.

That certainly would happen and is part of the issue. Hwvr, in his case  
(confirmed by two other posters) it was a high setting being replaced by  
the default of 85, so it was not even a little bit his fault it was gimp.

 This is the expected behavior for all plug-ins.

Yes in general its good, if I chose png compression of 9 I dont want to  
have to reset that value on very invocation of the dlg.

But two cases need to be destinguished: Save and SaveAs. I would suggest  
that Save should _always_ retain the current settings of the image be it  
jpeg , png or whatever. Save should do just that, not start redefining  
things.

In the case of png this is a minor annoying defect that can be remedied  
later but the same principal applies.

 But we might want to make an exception for JPEG because of its
 potentially destructive nature.


 Sven


OK, so everyone agrees this is unacceptable for jpeg. I would suggest that  
all formats preserve all parameters when in non-interactive , ie Save.  
This means less exceptions and predictable results and common code path.


Where there is a need for special treatment is SaveAs. Because of the  
destructive effects the dlg should come up with the image's existing  
quality param for jpeg o/w the user will never know what it needs to be  
even if he is fully aware and wants it to remain the same.

Other formats it would be nice (usabiliy) to take last used , user's  
default being used when no value is available (that's what default means  
in fact) ie on a new image or on format change.

I think we need to let jpeg lead the dance here since it can be  
destructive and irreversible.

A good way to present all this in a common format with no potentially  
confusing ifs and buts would be to add a radio button choice to all plugin  
dlgs   [ Default | Current | Last-used ]  defaulting to last used as  
dictated by jpeg but the user is never more than one click away from a  
clear choice between the three cases.

I know you dont like more controls but this seems the only to be  
consistant and clear. Making choices that do different things behind the  
users back depending on image format can only be confusing.


Anyway, that is something of side issue. The main defect that need fixing  
directly is the non-interactive case.

I think Save should do nothing fancy and should be the same for all.  
Simple, predictable and non destructive.
It should preserve existing setting for all formats.

We should probably focus on that before discussing SaveAs.

Also minor coding effort , we just need to dig out jpeg_quality from  
somewhere.

/gg


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Tor Lillqvist
Sven Neumann writes:
  If someone wants to try to recover some of the JPEG save settings when
  loading the JPEG file, feel free.

There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate. (Which happens when the loaded image's
quantization tables exactly match the JPEG standard's sample tables
scaled in libjpeg's manner with said factor).

I mean cases where the entire image contents has been replaced with a
fresh (original quality) one. Or if the image has been scaled down. Or
if some filter(s) that modifies all of the image substantially has
been applied to the whole image. In cases like these it perhaps
doesn't make sense to blindly re-use the original jpeg file's quality
factor, but one should let the user decide.

Maybe a good heuristic would be only use the original quality factor
if available to increase the user's default setting, never decrease
it. Show the settings dialog, as in current SVN, and if there is a
guesstimated scale factor from the original image and it is better
than the one in the user's default jpeg settings, use that initially
in the dialog instead of the default.

Anyway, I think that to really be able to to advanced tricks, the jpeg
saving needs to re-decompress the original image while saving the new
version. When it makes sense it should reuse the exact same
quantization tables and subsamplig parameters. Then it could do tricks
like avoid recompression artefacts for blocks that haven't
changed. That would be really cool. One could load and save a JPEG
image as much as one likes, just touching up small parts here and
there (like correcting red-eye), with no quality degradation for the
rest of the image.

BTW, is there any reason to keep the DCT method choice? Why not just
use floating-point always? Is there any significant speed difference
on modern machines?

--tml

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Tor Lillqvist
Sven Neumann writes:
  If someone wants to try to recover some of the JPEG save settings
  when loading the JPEG file, feel free.

I did.

Index: plug-ins/jpeg/jpeg-load.c
===
--- plug-ins/jpeg/jpeg-load.c   (revision 22905)
+++ plug-ins/jpeg/jpeg-load.c   (working copy)
@@ -50,6 +50,61 @@
 gint32   layer_ID_global;
 
 
+static gboolean
+check_table (const JQUANT_TBL *file_table,
+ gint  quant_tbl_no,
+ gint *quality)
+{
+  int i;
+  gboolean all_ones = TRUE;
+  gint q;
+  struct jpeg_compress_struct cinfo;
+
+  /* First do the simple check for quality 100, a table with all ones */
+  for (i = 0; i  64; i++)
+{
+  if (file_table-quantval[i] != 1)
+all_ones = 0;
+}
+
+  if (all_ones)
+{
+  *quality = 100;
+  return TRUE;
+}
+
+  /* Then produce tables for all qualities 1..99 and compare. It's
+   * better to do it this way than to calculate the quality factor
+   * backwards from the table in the file because of rounding errors:
+   * We would never match all quality factors exactly.
+   */
+  for (q = 1; q  100; q++)
+{
+  jpeg_create_compress (cinfo);
+
+  jpeg_set_quality (cinfo, q, TRUE);
+
+  for (i = 0; i  64; i++)
+{
+  if (cinfo.quant_tbl_ptrs[quant_tbl_no]-quantval[i] != 
file_table-quantval[i])
+break;
+}
+
+  jpeg_destroy_compress (cinfo);
+
+  if (i == 64)
+break;
+}
+
+  if (q  100)
+{
+  *quality = q;
+  return TRUE;
+}
+
+  return FALSE;
+}
+
 gint32
 load_image (const gchar *filename,
 GimpRunMode  runmode,
@@ -57,6 +112,7 @@
 {
   GimpPixelRgn pixel_rgn;
   GimpDrawable*drawable;
+  GimpParasite*parasite;
   gint32 volatile  image_ID;
   gint32   layer_ID;
   struct jpeg_decompress_struct cinfo;
@@ -76,6 +132,8 @@
   GimpParasite * volatile comment_parasite = NULL;
   jpeg_saved_marker_ptr marker;
   gboolean found_exif = FALSE;
+  gint q0, q1, q2;
+  gint quality = -1;
 
   /* We set up the normal JPEG error routines. */
   cinfo.err = jpeg_std_error (jerr.pub);
@@ -153,6 +211,32 @@
 
   (void) jpeg_read_header (cinfo, TRUE);
 
+  /* Check if the quantization tables used are produced by libjpeg's
+   * jpeg_set_quality().
+   */
+
+  if ((cinfo.jpeg_color_space == JCS_GRAYSCALE 
+   check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no],
+cinfo.comp_info[0].quant_tbl_no,
+q0)) ||
+  (cinfo.jpeg_color_space == JCS_YCbCr 
+   check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no],
+cinfo.comp_info[0].quant_tbl_no,
+q0) 
+   check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[1].quant_tbl_no],
+cinfo.comp_info[1].quant_tbl_no,
+q1) 
+   q0 == q1 
+   (cinfo.comp_info[1].quant_tbl_no == cinfo.comp_info[2].quant_tbl_no ||
+(check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[2].quant_tbl_no],
+  cinfo.comp_info[2].quant_tbl_no,
+  q2) 
+ q1 == q2
+{
+  /* Yes. Store the quality in a parasite below. */
+  quality = q0;
+}
+  
   /* We can ignore the return value from jpeg_read_header since
*   (a) suspension is not possible with the stdio data source, and
*   (b) we passed TRUE to reject a tables-only JPEG file as an error.
@@ -257,6 +341,14 @@
  layer_type, 100, GIMP_NORMAL_MODE);
 }
 
+  if (quality  0)
+{
+  parasite = gimp_parasite_new (jpeg-original-quality,
+0, sizeof (gint), quality);
+  gimp_image_parasite_attach (image_ID, parasite);
+  gimp_parasite_free (parasite);
+}
+
   drawable_global = drawable = gimp_drawable_get (layer_ID);
   gimp_pixel_rgn_init (pixel_rgn, drawable, 0, 0,
drawable-width, drawable-height, TRUE, FALSE);
Index: plug-ins/jpeg/jpeg.c
===
--- plug-ins/jpeg/jpeg.c(revision 22905)
+++ plug-ins/jpeg/jpeg.c(working copy)
@@ -428,6 +428,23 @@
* over the JPEG encoding parameters.
*/
   run_mode = GIMP_RUN_INTERACTIVE;
+
+  /* If we have stored an estimate of the libjpeg quality
+   * factor used when creating the original image, and
+   * that is larger than the default quality, use it as
+   * default for the dialog.
+   */
+  parasite = gimp_image_parasite_find (orig_image_ID,
+   jpeg-original-quality);
+  if (parasite)
+{
+  gint quality;
+  memmove (quality, gimp_parasite_data (parasite), sizeof 
(gint));
+  

Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Raphaël Quinet
On Mon, 9 Jul 2007 17:32:29 +0300, Tor Lillqvist [EMAIL PROTECTED] wrote:
 Sven Neumann writes:
   If someone wants to try to recover some of the JPEG save settings
   when loading the JPEG file, feel free.
 
 I did.

Thanks for this very nice patch!  It would be even better to do the same
for the chroma subsampling method (easy) and for images that do not use
the standard IJG tables (a bit harder, but it can be guesstimated).

This would provide a better default value in the JPEG Save dialog than
the hardcoded value that we currently have (even if that value can be
customized to some extent).  I also like the fact that it will only use
the estimated value from the file if it is larger than the default.  It
is nice to be able to adjust the parameters in the Save dialog starting
from a value that is reasonably close to the original settings when the
file was created, instead of always starting from a fixed value.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread peter sikking
guys, what a thread.

I say that the solution for all this lies in treating these lossy
(my spell-checker proposes lousy) formats the same we are (gonna)
handle indexed mode:

import + export only.

This would prevent the misunderstanding that there is a continuous
lossless workflow for these type of files, and that it is OK to save
intermediate files in these formats.

The import part means that when you open a jpeg, you get a GIMP file.
original_filename.xcf, it says in the title bar. Press save the first
time after import and you get a 'save as' dialog with the location of
the original jpeg and that original_filename.xcf as defaults.

now you have a workflow in full fidelity.

The export part means that jpeg and other lossy formats are not
available for Save (as), but only under an explicit Export command.

After an export to jpeg, you are still working on the GIMP format file.

I have  hard time believing that the reason a file is jpeg on
your camera memory card is the same as being jpeg at the end of
your workflow in GIMP. Afterwards it is about saving space on your
disk or saving bandwidth on the internet. Different requirements ==
different quality factor, I say.

 --ps

 principal user 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] jpeg quality factor.

2007-07-09 Thread Raphaël Quinet
On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED] wrote:
 guys, what a thread.
 
 I say that the solution for all this lies in treating these lossy
 (my spell-checker proposes lousy) formats the same we are (gonna)
 handle indexed mode:
 
 import + export only.

Eek!  That would significantly break the flow for what must be the
most common image format for photography.  I prefer the current
behavior in SVN, in which you get the dialog for the first time you
select Save, but subsequent saves of the same image (while you are
still working on it) will not force you to pick a new file name and
validate the parameters again.

 I have  hard time believing that the reason a file is jpeg on
 your camera memory card is the same as being jpeg at the end of
 your workflow in GIMP. Afterwards it is about saving space on your
 disk or saving bandwidth on the internet. Different requirements ==
 different quality factor, I say.

Before I started shooting only in raw format (so before I bought
larger memory cards for my camera), I shot a lot of JPEG pictures.  I
kept them all as they came out of the camera.  But some of them
required editing, such as removing red eyes or correcting obvious
color casts.  In these cases, I stored the edited images next to the
originals (with a slightly different file name like
dsc0042_edited.jpg) and I was interested in getting files that were
about the same quality and size as the unedited ones so that they
somehow fit in my collection.  Making them fit (having similar
size/quality tradeoff) is not really a major concern, but I still took
the time to experiment a bit with the sliders until I found out that
for most of my photos, using a setting around 92-94 was reasonably
close to what the camera produced.  This value did not work for all
photos because some of them were shot with different camera settings,
but at least that was a good estimate for most of them.

If the patch provided by Tor was extended to support quantization
tables produced by other software than libjpeg (by finding the
closest match), then it would reduce the amount of guesswork.

Side note: as suggested by Sven in #gimp, I just had a look at
ImageMagick to try and find out how they retreive or guess the quality
settings from JPEG files.  The code is about 100 lines long and can be
found in ImageMagick-6.3.5/coders/jpeg.c, around line 830.  It is
based on a comparison of the difference produced by the quantization
tables in the file with the 100 possible tables produced by libjpeg.
If no exact match is found, then the closest one is selected.  They
use pre-computed hashes and sums for the libjpeg tables in order to
speed up the comparisons.  The license of ImageMagick is compatible
with the GPL so we could even consider re-using their code.  We would
only have to include their license with the jpeg plug-in.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Michael Schumacher
Von: Raphaël Quinet [EMAIL PROTECTED]

 On Mon, 9 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED]
 wrote:
  guys, what a thread.
  
  I say that the solution for all this lies in treating these lossy
  (my spell-checker proposes lousy) formats the same we are (gonna)
  handle indexed mode:
  
  import + export only.
 
 Eek!  That would significantly break the flow for what must be the
 most common image format for photography.  I prefer the current
 behavior in SVN, in which you get the dialog for the first time you
 select Save, but subsequent saves of the same image (while you are
 still working on it) will not force you to pick a new file name and
 validate the parameters again.

This doesn't contradict what peter is suggesting. AFAIK we intend to break the 
flow for anything but XCF(.*). A save should always do what the term save 
claims to do, it should not damage the file. 

Why do you assume that export will ask for all of the parameter settings again?


HTH,
Michael
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Sven Neumann
Hi,

On Mon, 2007-07-09 at 18:42 +0200, Raphaël Quinet wrote:

 Side note: as suggested by Sven in #gimp, I just had a look at
 ImageMagick to try and find out how they retreive or guess the quality
 settings from JPEG files.  The code is about 100 lines long and can be
 found in ImageMagick-6.3.5/coders/jpeg.c, around line 830.  It is
 based on a comparison of the difference produced by the quantization
 tables in the file with the 100 possible tables produced by libjpeg.
 If no exact match is found, then the closest one is selected.  They
 use pre-computed hashes and sums for the libjpeg tables in order to
 speed up the comparisons.  The license of ImageMagick is compatible
 with the GPL so we could even consider re-using their code.  We would
 only have to include their license with the jpeg plug-in.

If it can improve a common workflow, it's probably worth it. Please use
the code from ImageMagick then as it should be well tested already. And
please place this code into a separate file in the plug-ins/jpeg folder.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Guillermo Espertino
 There is another player in the game and that's the last-used values
 stored with gimp_[gs]et_data(). And that's what has bitten Guillermo.
 He has saved an image as JPEG with low quality settings.

No, I haven't.
Since I know the problem I'm using always save as with quality=95 but it's 
still happening when I get an image from the camera and press save.

I know it because I just made a test with the same results.

Gez.


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Sven Neumann
Hi,

On Mon, 2007-07-09 at 09:42 +0200, [EMAIL PROTECTED] wrote:

 Ha, cross post .

Cross post? Huh?

Btw, is it intentional that you are mailing from two (or three)
different accounts and never put your real name in the From field? I
find the use of two accounts annoying and the lack of a real name is
somewhat impolite. If you have good reasons to do this, then feel free
to continue doing it though.

 well that's at least taken the heat off the issue . Less than ideal from  
 interface point of view since it's a dlg every time but at least it's a  
 resolution until we find where to get the quality param.

The dialog should stay even if we can access the quality settings used
when saving the file. Tor outlined the reasons in a different mail in
this thread.


Sven


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


Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread Scott
On Sun, Jul 08, 2007 at 09:59:18AM -0400, Robert L Krawitz wrote:
 
 Think of the quality setting as an indication of expectations rather
 than a specific outcome.  It may not be possible to get the exact same
 outcome (and obviously -- at least to us -- there's no way to
 retroactively improve the result), but the quality setting could be
 treated as the user's expectation for the result.

Just a stupid user here, but interested in this thread since it is something
I do all the time. I have Shift-S configured to change the image size,
and of course Ctrl-S is by default configured to save file. I can't
remember how many times I have hit the Ctrl by mistake, and now am
quite distressed to understand that the image which I uploaded from my
camera and then deleted from the memory card has now been degraded to
a different quality than it was Definitely a bug, not a feature,
IMHO.

Just curious, what would be so wrong with saving the original file as
a backup before doing a destructive save? Emacs only bites me when I'm
*really* stupid

I am so glad that Guillermo stuck by his guns and apparently *finally*
got the developers to realise the illogic of this feature. If more
of us users would be as persistent instead of just going away after
the initial knee-jerk you don't know enough to even be talking to us
response which seems too prevalent here, maybe the Gimp would become
all that it can be.

Scott Swanson

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


Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread Sven Neumann
Hi,

On Mon, 2007-07-09 at 11:36 -0600, Scott wrote:

 Just curious, what would be so wrong with saving the original file as
 a backup before doing a destructive save? Emacs only bites me when I'm
 *really* stupid

There's nothing wrong with that. It's even on the list of things that
the file plug-in library should have. The file plug-in library we would
like to port all our file plug-ins to. If you are so much interested in
this, perhaps want to offer your help with this task?

 I am so glad that Guillermo stuck by his guns and apparently *finally*
 got the developers to realise the illogic of this feature. If more
 of us users would be as persistent instead of just going away after
 the initial knee-jerk you don't know enough to even be talking to us
 response which seems too prevalent here, maybe the Gimp would become
 all that it can be.

If more users would be so persistent, as you call it, then there would
probably not a single developer left who would feel that developing GIMP
is fun. There would probably be noone who would be willing to spend
his/her free time on it.

I don't see the point in your mail. We listened to Guillermo and his
issue was addressed in almost no time. It was absolutely not needed to
stick to any guns.

We are working very hard to finally get 2.4 out and because we are
taking this very seriously, we are in this pre-release mode for a long
time already. It would help a lot if we could concentrate on the
important things now which is to bring out GIMP 2.4. The users could
finally benefit from the hard work the developers have put into GIMP
over the last years. Perhaps than the users would finally realise that a
lot is happening to make GIMP better and easier to use.

Can we settle this now and get back to work? Thanks.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Mon, 09 Jul 2007 19:32:14 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Btw, is it intentional that you are mailing from two (or three)
 different accounts

No it's not intentional. I share this email client which has several  
accounts configured. Occassionally I hit reply and fail to notice that  
it's not posting from my account. These errors dont make it to the mailing  
but do go to any cc . Sorry for any inconvenience that may or may not  
cause.

Having to create three different gg g2 g4 accounts and all the fuss to get  
that rectified was also inconvinient when someone decided I was persona  
non grata without the politeness to even notify me of the decission.  
Neither did I get any explaination or appology it just got unblocked.

Now my gimp messages are spread over three accounts. Some things we have  
to live with.

Thanks for the reminder, it annoys me when I mess it up but it was late  
lastnight and one of the ten or so messages I sent yesterday got the wrong  
account. Will try harder ;)

/gg

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Guillermo Espertino
Scott wrote:
 I am so glad that Guillermo stuck by his guns and apparently *finally*
 got the developers to realise the illogic of this feature. 
Scott: Please keep in mind that I was trying to collaborate, not to fight.
In these cases is very common to see differences of criteria and some 
rough defenses.
Sven and the people working here are using their free time to improve 
gimp, and have no obligation to do what users ask.
I tried to stick in my position because I find this problem to be critic 
(because it implies the undoable destruction of image data).
But remember that Gimp is free software and it grows with collaboration. 
Very frequent conflicts may dilute the enthusiasm of contributors (both 
developers and users).
Anyway I'm glad to have started this thread. I can see that much 
positive things came up, and that was my goal. Not to win, just help to 
address a problem from my non-developer position.

Sven wrote:

 Can we settle this now and get back to work? Thanks.

Yes. This is my last message for this topic. Promess. :-)

Thanks!




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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Mon, 09 Jul 2007 17:54:29 +0200, peter sikking [EMAIL PROTECTED]  
wrote:

 guys, what a thread.
das stimmt!

 I say that the solution for all this lies in treating these lossy
 (my spell-checker proposes lousy) formats the same we are (gonna)
 handle indexed mode:
 import + export only.

I dont think this is a good idea , despite it shortcoming in certain  
respects this is probably the most commonly used format for photo images.  
Not being able to save a jpeg will cause great confusion.

IMHO this is not one of your better suggestions.

 This would prevent the misunderstanding that there is a continuous
 lossless workflow for these type of files, and that it is OK to save
 intermediate files in these formats.

As has been suggested already, a first time warning with a dont show  
again option would be good in making users aware of the issue. After that  
I really object this we know best , you should do it this way so we will  
force you to if you're too dumb. This is the classic Microsoft approach  
and why I changed to OSS over 5 yrs ago. Please dont try to do this to  
Gimp.

Considering Gimp was screwing up jpegs until last nights svn change , ie  
millions of installation on all platforms still does that even on the  
fresh 2.3.16 , we'd better go easy on the arrogant we know better, you  
will do it like this approach.

Some ppl may wish to do one or two saves knowing the limitations and  
choosing suitable quality. Gimp is a tool not a tutorial. We should not  
get in the way.

The only step I see as acceptable here is the warning, this would be a  
great help to less seasoned users who are not aware of this limitation.  
It's simple to add and would be a worthwhile improvement.

/gg

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


Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread Scott

On Mon, Jul 09, 2007 at 08:18:44PM +0200, Sven Neumann wrote:
 Hi,
 
 On Mon, 2007-07-09 at 11:36 -0600, Scott wrote:
 
  Just curious, what would be so wrong with saving the original file as
  a backup before doing a destructive save? Emacs only bites me when I'm
  *really* stupid
 
 There's nothing wrong with that. It's even on the list of things that
 the file plug-in library should have. The file plug-in library we would
 like to port all our file plug-ins to. If you are so much interested in
 this, perhaps want to offer your help with this task?

Well, if I had any development skills, I'd be more than happy to do
so. I used to enjoy writing code for totally text-based programs under
cpm and msdos, and still write some for linux, but graphics-based
programming is a bit beyond me. I tried once to compile the Gimp from
SVN and failed miserably, so I doubt I'd be a good candidate, though
certainly would be willing to help.

 
  I am so glad that Guillermo stuck by his guns and apparently *finally*
  got the developers to realise the illogic of this feature. If more
  of us users would be as persistent instead of just going away after
  the initial knee-jerk you don't know enough to even be talking to us
  response which seems too prevalent here, maybe the Gimp would become
  all that it can be.
 
 If more users would be so persistent, as you call it, then there would
 probably not a single developer left who would feel that developing GIMP
 is fun. There would probably be noone who would be willing to spend
 his/her free time on it.

As I perceived the thread, Guillermo's approach would not take the
fun out of anything. He merely was pointing out a serious problem with
the way Gimp implements the 'save' as regards jpeg files; something a
developer probably never thought of, but something with serious
adverse consequences to a normal user.

 
 I don't see the point in your mail. We listened to Guillermo and his
 issue was addressed in almost no time. It was absolutely not needed to
 stick to any guns.

And it did eventually get addressed, but only after an attempted
brush-off or two. Read the thread.

 
 We are working very hard to finally get 2.4 out and because we are
 taking this very seriously, we are in this pre-release mode for a long
 time already. It would help a lot if we could concentrate on the
 important things now which is to bring out GIMP 2.4. The users could
 finally benefit from the hard work the developers have put into GIMP
 over the last years. Perhaps than the users would finally realise that a
 lot is happening to make GIMP better and easier to use.
 

Don't get me wrong, we users *do* obviously appreciate all of the work
you guys do, or we wouldn't be using the program on a daily
basis. It's just that we often get the perception that when any suggestion
is made on this list that something isn't quite working as it should,
there is a we know better than you do attitude. I'm sure it isn't
intentional?


 Can we settle this now and get back to work? Thanks.
 

Fine by me.

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


Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread Sven Neumann
Hi,

On Mon, 2007-07-09 at 14:07 -0600, Scott wrote:

  If more users would be so persistent, as you call it, then there would
  probably not a single developer left who would feel that developing GIMP
  is fun. There would probably be noone who would be willing to spend
  his/her free time on it.
 
 As I perceived the thread, Guillermo's approach would not take the
 fun out of anything. He merely was pointing out a serious problem with
 the way Gimp implements the 'save' as regards jpeg files; something a
 developer probably never thought of, but something with serious
 adverse consequences to a normal user.

I was refering to your reply which was discouraging and completely
needless. And so was your second reply. The developers think of a lot
more than you can imagine. And we keep listening to our users. A lot of
us are actively monitoring user forums and user mailing-lists. The main
reason that things are the way they are is that no one does the
necessary changes. Asking the users to be more persistent with their
requests is not going to help with that.

And no, Guillermos request wasn't brushed off. It is important to ask
precisely and we have to be careful with changes. The happy user is
silent. If we would do a change every time a user asks for a change,
then GIMP would be a lot more inconsistent and probably also more buggy.
For that reason it is important to double check if a request is valid
and whether a change is really making things better for all users (or at
least the target audience).


Sven


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


Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread Scott
 I was refering to your reply which was discouraging and completely
 needless. And so was your second reply. 

sorry to bother.


 The happy user is silent. 

Is that from the Book of Tao, or what? I like it. I shall remain
silent. The silent user is happy (or unhappy - who knows?).

Scott Swanson

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:

 There are some scenarios in which blindly reusing the quality factor
 guesstimated from loading an image is not a good idea, even if the
 guesstimate is very accurate. (Which happens when the loaded image's
 quantization tables exactly match the JPEG standard's sample tables
 scaled in libjpeg's manner with said factor).
 I mean cases where the entire image contents has been replaced with a
 fresh (original quality) one. Or if the image has been scaled down. Or
 if some filter(s) that modifies all of the image substantially has
 been applied to the whole image. In cases like these it perhaps
 doesn't make sense to blindly re-use the original jpeg file's quality
 factor, but one should let the user decide.


OK let's ignore the repeated blindly reusing which presuposes this is a  
stupid thing to do.

If the entire image contents has been replaced with a fresh (original  
quality) one the user would presumably use saveAs. This seems rather an  
artificial case.

 Or if the image has been scaled down. Or
 if some filter(s) that modifies all of the image substantially has
 been applied to the whole image.

The current choice of jpeg_quality is still a more appropriate choice  
unless the user selects SaveAs.

Seriously guys , let's stop trying to secoond guess what the user should  
be doing and let him get on with it.

Again Gimp is a tool not a tutorial.

Let's concentrate on getting the tool to work propery rather than telling  
the user which hand he's supposed to wipe his backside with.


Tor, since you are looking at this, checkout this code. It's a shareware  
Delphi component for jpeg with sourse. Now it's years since I was in there  
but I bought it and used it for several years. I am pretty sure that it  
picks out jpeg_quality as one of the object properties when it decodes an  
image.

The delphi component is copyright shareware but it clearly states that the  
original IJG C code used is not a payable item. In any case seeing where  
the jpeg_quality comes from may well be useful.

http://www.mwasoftware.co.uk/index.php?option=com_contenttask=viewid=4Itemid=7

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Liam R E Quin
On Sun, 2007-07-08 at 12:19 +0200, Sven Neumann wrote:
[...]
 Due to the way file plug-ins are implemented in GIMP, it is not trivial
 to do this. But you can easily work around it by assigning Ctrl-S to
 Save As. 

I'd advise making ^S to be Quit.  Then you'll be prompted, realise
your mistake, and quickly stop using ^S.  That way when you
install a new gimp and accidentally lose your settings, you
will already have stopped using ^S :)

For my part I miss save a copy as... which in some programs
saves the file like Save As but doesn't change the filename of
what's being edited.

I wonder if it'd be possible, for gimp 2.6, to consider unifying
the output plugins a bit, so that you can have a pull-down of file
formats and see the parameters for each format before you hit save,
and maybe even have printf-like stuff in the filename, e.g. to
name the file mypicture-%Wx%H-%{quality}.%T or whatever.

But I think we can live without it for 2.4, for my part at least :-)

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] jpeg quality factor.

2007-07-09 Thread peter sikking
Raphaël wrote:

 I say that the solution for all this lies in treating these lossy
 (my spell-checker proposes lousy) formats the same we are (gonna)
 handle indexed mode:

 import + export only.

 Eek!  That would significantly break the flow for what must be the
 most common image format for photography.

Really? Let's have a look at the product vision. 'High-end'
is the word I want us to focus on.

I can understand that a high-end workflow can start with a
jpeg because due to a mishap nothing better is available.
I can also understand that a jpeg version can be part of
the final result.

But in between, as long as it is not finished, there is no role for  
jpeg. Only one decompression at the beginning and a compression of the
end result is defendable in high-end graphics.

There is also a real benefit in opening a jpeg and then saving
the result in another (GIMP) file. We see from the explanations in this
thread that opening a jpeg and then saving it again means a loss of
information. So overwriting an original is a loss. Working on a
full-fidelity copy version is preferred.

The early part of this thread is full of misunderstanding at which
point working with jpeg incurs quality loss. I say it is because of
the you can work in jpeg myth. I am still confused that you talk
about saving intermediate results while working on a jpeg. Either
each save reduces quality (implicit save and reload, ouch) or there
is a penalty for closing the file and reopening it, because you
lost the full-fidelity internal (GIMP) representation, ouch.

So I see real benefits for a high-end image manipulation program
that lossy formats are pushed out to the very beginning and very
end of the workflow. That the working copy of the file is GIMP format,
in full fidelity, any GIMP operation naturally possible, and with
no penalty for opening and closing the file.

We need to actively support the high-end workflows, with minimal effort.

Consumer mid-fi workflows (open jpeg, edit the image, save (overwrite)
the jpeg) are still possible, (open, edit, export) and it does not look
like any more effort than the current situation. If users get the hint
that opening and saving the same jpeg again and again is a pain (also  
for
the quality) and that either adopting a high-end GIMP file workflow or
moving to another (mid-fi) app to work in their lossy jpeg way.

 Before I started shooting only in raw format (so before I bought
 larger memory cards for my camera), I shot a lot of JPEG pictures.

Can you relate why you moved up to raw to the requirements of high-end
image manipulation? I can.

 --ps

 principal user 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] jpeg quality factor

2007-07-09 Thread saulgoode
Quoting Sven Neumann [EMAIL PROTECTED]:

 ...  The happy user is
 silent. If we would do a change every time a user asks for a change,
 then GIMP would be a lot more inconsistent and probably also more buggy.
 For that reason it is important to double check if a request is valid
 and whether a change is really making things better for all users (or at
 least the target audience).

I am quite happy that the GIMP uses its own JPEG quality default  
(especially now that it can be modified). I would expect a File-Save  
to use the default I chose, not that attached to the image. If I have  
a Quality setting of 95 and I load an image that was saved with a  
Q=50, I should be very disappointed if the GIMP degraded to that level  
when I have specified that I expect less loss when saving.

IMO, the File-Save command should use the GIMP's default setting;  
but the ideal would be to have that default be one of the following  
options:

a. A specific quality value.
b. The quality value of the original JPEG file, if applicable
c. The greater of 'a' and 'b'
d. The original DCT coefficients, if available

I would not consider any of 'b', 'c', and 'd' to be improvements if  
'a' were not available as an option.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Graeme Gill

On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:

There are some scenarios in which blindly reusing the quality factor
guesstimated from loading an image is not a good idea, even if the
guesstimate is very accurate. (Which happens when the loaded image's
quantization tables exactly match the JPEG standard's sample tables
scaled in libjpeg's manner with said factor).

Why try and merely match the tables ? Use them by default. Only
replace them if the user changes quality settings.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread Chris Mohler
At the risk of lengthening this thread... :)

I agree with Peter - saving in a lossy format is a last-step operation
in a good workflow.   I respect the case of simple tweak and saving,
but in the long run, all users should never being able to choose
save and then lose data.  I expect the Save command to retain
*all* data: not just some.  Just because most image editors throw away
parts of your file, there's no reason for GIMP to follow suit (anyone
ever play Lemmings?).

save != lose

I see recent activity on the 'Save for Web' dialog.  Once completed,
it should offer the user enough ways to publish a lossy image for
end-use while retaining a lossless original image.  Exporting is
preferable to a lossy save.

The solution of presenting the dialog on first save is a Good Thing
(thanks Sven!).  Having a lossless workflow is a Better Thing, and
hopefully the direction of the future.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Tue, 10 Jul 2007 00:46:44 +0200, peter sikking [EMAIL PROTECTED]  
wrote:

 Raphaël wrote:

 I say that the solution for all this lies in treating these lossy
 (my spell-checker proposes lousy) formats the same we are (gonna)
 handle indexed mode:

 import + export only.

 Eek!  That would significantly break the flow for what must be the
 most common image format for photography.

 Really? Let's have a look at the product vision. 'High-end'
 is the word I want us to focus on.

Please dont distort this by taking one word out of context.

Gimp's aim to be a high-end image manipulation program does not mean  
everyone has to become a professional graphics artist.

I see no indication in Sven's vision for Gimp that it becomes an  
exclusively professional tool at the expense of all else.

Neither does starting every phrase with high-end make your arguements  
carry any more weight.


 I can understand that a high-end workflow can start with a
 jpeg because due to a mishap nothing better is available.
 I can also understand that a jpeg version can be part of
 the final result.

 But in between, as long as it is not finished, there is no role for
 jpeg. Only one decompression at the beginning and a compression of the
 end result is defendable in high-end graphics.

That's one way of working for one type of result. I don't see why you  
think you can be so dogmatic, say this is the ONLY way to work and  
therefore wish to force everyone down that road.



 There is also a real benefit in opening a jpeg and then saving
 the result in another (GIMP) file. We see from the explanations in this
 thread that opening a jpeg and then saving it again means a loss of
 information. So overwriting an original is a loss. Working on a
 full-fidelity copy version is preferred.

Again that's preferable in one way when absolute quality is the dominant  
criterium. Disk space and clutter may be another. Again you rather  
arrogantly presume to know what the user wants/needs and are going to shut  
down his options and make gimp do what YOU think is best for the user.

High-end users require powerful, flexible tools not one hand tied behind  
their backs by someone who think he know more about graphics than they do.


 The early part of this thread is full of misunderstanding at which
 point working with jpeg incurs quality loss. I say it is because of
 the you can work in jpeg myth. I am still confused that you talk
 about saving intermediate results while working on a jpeg. Either
 each save reduces quality (implicit save and reload, ouch) or there
 is a penalty for closing the file and reopening it, because you
 lost the full-fidelity internal (GIMP) representation, ouch.

So clearly you can work with jpeg doing intermediate saves (different  
filenames if wished) and maintaining a lossless copy in gimp until the  
final step.

You could also dupe the image and remain working in jpeg.

You can also save with high quality setting and sustain minimal lost where  
appropriate. Your legendry high-end user will know all this of course so  
he does not need you to limit the flexibility of his high-end tools.


 So I see real benefits for a high-end image manipulation program
 that lossy formats are pushed out to the very beginning and very
 end of the workflow. That the working copy of the file is GIMP format,
 in full fidelity, any GIMP operation naturally possible, and with
 no penalty for opening and closing the file.

 We need to actively support the high-end workflows, with minimal effort.

 Consumer mid-fi workflows (open jpeg, edit the image, save (overwrite)
 the jpeg) are still possible, (open, edit, export) and it does not look
 like any more effort than the current situation. If users get the hint
 that opening and saving the same jpeg again and again is a pain (also
 for
 the quality) and that either adopting a high-end GIMP file workflow or
 moving to another (mid-fi) app to work in their lossy jpeg way.


OK, so that's your basic attitude, anyone who does not agree with your  
limited view of the one and only correct way to work should stop using  
Gimp.

Tell 98% of the user base to go away because they're too mid-fi to use  
your super high-end software

I think you should stop this dictatorial approach, you are losing  
credibility as an interface architect.



 Before I started shooting only in raw format (so before I bought
 larger memory cards for my camera), I shot a lot of JPEG pictures.

 Can you relate why you moved up to raw to the requirements of high-end
 image manipulation? I can.

  --ps

  principal user 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

Re: [Gimp-developer] jpeg quality factor

2007-07-09 Thread gg
On Tue, 10 Jul 2007 01:24:40 +0200,  
[EMAIL PROTECTED] wrote:

 If I have
 a Quality setting of 95 and I load an image that was saved with a
 Q=50, I should be very disappointed if the GIMP degraded to that level
 when I have specified that I expect less loss when saving.

It would NOT degrade it because it already was that quality. Saving it a  
95 would increase filesize by about a factor of 8 without any gain in  
quality! You would not have less loss.

If you want to change the nature of the image format user SaveAs.

Save should keep things the way they are as near as possible.

Some here seem to miss the meaning of the word default. It is a value to  
use by default, not all the time, ie when there is no way to get an actual  
value. ie a new unsaved image or jpeg save of another format.

Hopefully Tor's patch from Imagemagick should now provide a good  
jpeg_quality value from the image file.



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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Tue, 10 Jul 2007 01:58:50 +0200, Graeme Gill [EMAIL PROTECTED]  
wrote:


 On Mon, 09 Jul 2007 11:33:34 +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:

 There are some scenarios in which blindly reusing the quality factor
 guesstimated from loading an image is not a good idea, even if the
 guesstimate is very accurate. (Which happens when the loaded image's
 quantization tables exactly match the JPEG standard's sample tables
 scaled in libjpeg's manner with said factor).

 Why try and merely match the tables ? Use them by default. Only
 replace them if the user changes quality settings.

 Graeme Gill.

Yes, I agree. I think that would be an additional improvement to gimp's  
jpeg quality. It may be somewhat more work that just deciding what  
jpeg_quality we should be using. Although futher improvement of the way  
gimp handles jpeg may calm some of the let's stop the user working with  
jpeg crowd.

Certainly it would be prefeable to improve the jpeg quality rather than  
crippling gimp and restricting the user.
(no pun intended)

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-09 Thread gg
On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler [EMAIL PROTECTED] wrote:

  I expect the Save command to retain
 *all* data: not just some.

If you expect that when using jpeg you are wrong and need to see the first  
use warning that has been suggested.

Assuming you do have some knowlege of graphics you will know saving a jpeg  
does not save *all* your data and will make a choice as to whether the  
loss is acceptable or whether creating a much larger duplicate file is  
preferable.

  Exporting is preferable to a lossy save.

Says you. This is not always the case. It depends what is required.


 Just because most image editors throw away
 parts of your file, there's no reason for GIMP to follow suit (anyone
 ever play Lemmings?).

I dont recall anyone having advanced that as an arguement. I really think  
we should stop exagerating this issue.


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino  
[EMAIL PROTECTED] wrote:

  In Gimp, it saves the file directly, without asking for the compression  
 setting. Result: an image over-compressed with artifacts. Smaller size  
 than the original.
 In Photoshop, it shows the quality settings the first time you hit  
 CTRL+S.



I think we're finally getting closer to the truth. There is something non  
standard in the file the camera is producing. It seems that PS knows  
there's a problem and thus prompts for the quality parameter, gimp it  
would seem is either reading this value as the IJG quality when it isn't  
or is applying a not too good default when it fails to read it.

If it's an incorrect value put in by the camera that gimp is correctly  
reading it's not a gimp issue. If it is a missing value gimp should  
probably use it's jpeg default of 85 (or prompt as you suggest) which it  
does not seem to be doing.

If you have imagemagick installed, use the following to see what  
information is in one of your camera images before you affect it with  
either gimp or ps and then again after gimp (and/or PS) does a save on it:

identify -verbose unadulterated_image.jpeg

That should give some info on what is in the jpeg header.

thx.


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Øyvind Kolås
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote:

   the image used in
  the JPEG Generation Loss figure in the example in the following text
  uses an image that
  shows how JPEG compression keeps different aspects of the image intact
  across multiple encode/decode cycles:
   http://pippin.gimp.org/image_processing/chap_dir.html#id2526295
   /Øyvind K.
  --

 yes there does seem to be an issue here. I snipped the generation 0 part
 of that image did File | Save As...
   then reopened the new version and repeated the save several times.

 There is continual degradation. This should not happen with an identical
 image. This seems to suggest that either there is a bug in the compression
 or that the decompression is not producing an identical image from the
 stored data.

This is not a bug but a consequence of how the lossy compression of
JPEG works, hence  you should NEVER should use JPEG as an intermediate
format in your workflow, but only for publishing the end result. It is
theoretically possible, to keep the compressed version of unchanged
parts of an image around, and only recompressing in the neighbourhood
of regions that have actually changed by comparing with JPEG that one
is saving over. But a full decode/encode/decode cycle of JPEG / DV /
MJPEG etc will accumulate more and more errors/artifacts. This
accumulated error would be smaller with a higher default quality
though.

/Ø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] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

On Sat, 2007-07-07 at 22:13 -0300, Guillermo Espertino wrote:

 Back to the topic: I propose to display the quality settings when an 
 image is resaved as jpeg for the first time, if it's possible.
 I don't know how it's done, but when I take my image to PS from my 
 camera, it asks me to adjust the quality when I press CTRL+S for the 
 first time.
 After that it saves normally.

Due to the way file plug-ins are implemented in GIMP, it is not trivial
to do this. But you can easily work around it by assigning Ctrl-S to
Save As. Then you will always be prompted with the dialog asking you
for the save parameters.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 12:10:30 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote:

 But a full decode/encode/decode cycle of JPEG / DV /
 MJPEG etc will accumulate more and more errors/artifacts. This
 accumulated error would be smaller with a higher default quality
 though.
  /Øyvind K.
 --

Obviously what Guillermo is doing is fine as an exercise but his first  
save should be to a non lossy format or if his first save is his final  
save at least use Save As to get the full dlg and save it to the same name  
if that's what he wants.

Personally I would always keep any original image so even a 'first save =  
last save' would get a new name and hence go through the dlg with the  
quality option.


You clearly know more about the detail of this than I do but isn't there a  
direct one-to-one mapping once the original compression is done?

Any deviation from that must be errors in the decoding, so is what you  
posted a symptom of continual rounding errors in the decoding altering the  
image each time?

Then the growing artifacts are a result of the limited colour resolution  
of 8 bits per channel used by gimp.


Thx

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Øyvind Kolås
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 You clearly know more about the detail of this than I do but isn't there a
 direct one-to-one mapping once the original compression is done?

Nope.

 Any deviation from that must be errors in the decoding, so is what you
 posted a symptom of continual rounding errors in the decoding altering the
 image each time?

 Then the growing artifacts are a result of the limited colour resolution
 of 8 bits per channel used by gimp.

Also by the fact that in JPEG greyscale and color information is
decoupled and the color information is stored with lower spatial
resolution than the greyscale data. Thus there is additional rounding
that has to be done to get back to a RGB raster. The bottom line is
that JPEG, DV (for video) and other similar lossy compressions do
introduce generational loss, like mp3 and similar codecs do for audio.

/Ø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] jpeg quality factor.

2007-07-08 Thread Robert L Krawitz
   Date: Sun, 08 Jul 2007 11:44:17 +0200
   From: [EMAIL PROTECTED]

   On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino  
   [EMAIL PROTECTED] wrote:

 In Gimp, it saves the file directly, without asking for the compression  
setting. Result: an image over-compressed with artifacts. Smaller size  
than the original.
In Photoshop, it shows the quality settings the first time you hit  
CTRL+S.

   I think we're finally getting closer to the truth. There is something non  
   standard in the file the camera is producing. It seems that PS knows  
   there's a problem and thus prompts for the quality parameter, gimp it  
   would seem is either reading this value as the IJG quality when it isn't  
   or is applying a not too good default when it fails to read it.

   If it's an incorrect value put in by the camera that gimp is correctly  
   reading it's not a gimp issue. If it is a missing value gimp should  
   probably use it's jpeg default of 85 (or prompt as you suggest) which it  
   does not seem to be doing.

   If you have imagemagick installed, use the following to see what  
   information is in one of your camera images before you affect it with  
   either gimp or ps and then again after gimp (and/or PS) does a save on it:

   identify -verbose unadulterated_image.jpeg

   That should give some info on what is in the jpeg header.

This appears to be the case.  The original image gives me this:

$ identify -verbose /images/dcim/193canon/img_9309.jpg 
Image: /images/dcim/193canon/img_9309.jpg
...
  Filesize: 2.96358mb
...
  Compression: JPEG
  Quality: 98
  Orientation: LeftBottom
  JPEG-Colorspace: 2
  JPEG-Sampling-factors: 2x1,1x1,1x1

However, when I save it out, it's clearly not using the original
quality setting:

$ identify -verbose /tmp/img_9309.jpg 
Image: /tmp/img_9309.jpg
...
  Filesize: 901.654kb
...
  Compression: JPEG
  Quality: 85
  Orientation: TopLeft
  JPEG-Colorspace: 2
  JPEG-Sampling-factors: 2x2,1x1,1x1

If I explicitly save it out using the same settings as what came from
the file, I wind up with a slightly shrunk file:

$ identify -verbose /tmp/img_9309.jpg 
Image: /tmp/img_9309.jpg
...
  Filesize: 2.65972mb
...
  Compression: JPEG
  Quality: 98
  Orientation: TopLeft
  JPEG-Colorspace: 2
  JPEG-Sampling-factors: 2x1,1x1,1x1

Note that GIMP is not the only application that does this; KPhotoAlbum
also changes the quality setting (to 75!).  In this case, I suspect
that it simply doesn't tell the appropriate library what the actual
quality setting is from the original file.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote:

 Note that GIMP is not the only application that does this;

Why should any application do what you suggest? If you open a JPEG file
and save it again as JPEG, then the original quality factor is
completely irrelevant. You are doing a lossy operation, there is no way
to save the file with the same quality again.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 14:35:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote:

 Note that GIMP is not the only application that does this;

 Why should any application do what you suggest? If you open a JPEG file
 and save it again as JPEG, then the original quality factor is
 completely irrelevant. You are doing a lossy operation, there is no way
 to save the file with the same quality again.


 Sven


It would seem reasonable to assume that if the user has selected a  
size/quality trade-off given by a specific value, say, quality=98 he does  
not want to have to explicitly remake that decision every time he touches  
it.

Also this info I part of the header and part of specification of that file  
so arbitarily changing it would seem to me to be a spec violation.

Does your reply indicate you take a this feature not a bug approach here  
and you think is the best way gimp should deal with this situation?

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:

 Does your reply indicate you take a this feature not a bug approach here  
 and you think is the best way gimp should deal with this situation?

Indeed. When you open a JPEG file, then you have a decoded image. The
settings that were used to encode it are irrelevant since encoding it
again as a JPEG file would not yield the same image anyway. Thus it is
better to use the default values. Since we will very soon allow the user
to change these defaults, this should be the best way we can handle
this.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:

 Does your reply indicate you take a this feature not a bug approach  
 here
 and you think is the best way gimp should deal with this situation?

 Indeed. When you open a JPEG file, then you have a decoded image. The
 settings that were used to encode it are irrelevant since encoding it
 again as a JPEG file would not yield the same image anyway.

I'm sorry I find that a rather forced logic. As we have seen the image  
will not be _identical_ due rounding errors and such , that does not make  
the existing choice of jpeg_quality irrelevant. It represents the users  
choice of size/quality trade-off.

I see no justification to discard that choice as irrelevant.

File | Save should save the image as it is. Save_As is there as a means to  
change things.

Gillermo's real world example where the file size shrank by a factor of  
two and the quality took a serious hit can hardly be described a  
straight-forward save. It's doing a major change to the image and changing  
the compression parameters (quality and sampling_factor!), this should  
only happen through the Save_As with a full dlg.


 Thus it is
 better to use the default values. Since we will very soon allow the user
 to change these defaults, this should be the best way we can handle
 this.


 Sven




Allowing the user for redefine the default is fine but I see no bearing on  
this issue. This is not a lifestyle choice it's a per image choice. It's  
irrelevant to this discussion.


I'd always assumed that the default 85 only applied to untitled images on  
the first save not that it was silently forced on an unwary public as some  
sort of hidden gimp knows best feature.

Abritarily throwing away half the image data without so much as a 'by your  
leave' , incredible.

I'm really surprised that you dont see this as a bug.

I would ask you to seriously consider if this is appropriate. Please take  
time to reflect on this before replying and preferable sound out a few  
other opinions.

Thanks for the reply.
/gg

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Sun, 08 Jul 2007 15:12:03 +0200

   On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:

Does your reply indicate you take a this feature not a bug
approach here and you think is the best way gimp should deal with
this situation?

   Indeed. When you open a JPEG file, then you have a decoded
   image. The settings that were used to encode it are irrelevant
   since encoding it again as a JPEG file would not yield the same
   image anyway. Thus it is better to use the default values. Since we
   will very soon allow the user to change these defaults, this should
   be the best way we can handle this.

Think of the quality setting as an indication of expectations rather
than a specific outcome.  It may not be possible to get the exact same
outcome (and obviously -- at least to us -- there's no way to
retroactively improve the result), but the quality setting could be
treated as the user's expectation for the result.

It's certainly true that a couple of iterations of saving at a quality
setting of 85 (say) will yield a substantial degradation, and a couple
of iterations at 65 will yield even more degradation, but a couple of
iterations at a setting of 98 won't yield very much degradation at
all.

By this reasoning, if a user opens a file with a quality setting of
98, her expectation when saving the file is that the quality will
still be very high, while if the quality setting of the incoming file
is only 85, her expectations will be lower.  A single default setting
won't cover all cases.

If the choice really is that arbitrary (and you make a good argument
to that effect), why not simply use the quality setting of the
incoming file as the implied default?  I think it would at least align
better with user expectations, particularly for files shot at high
quality settings on digital cameras.

BTW, on the Canon S3, the Superfine, Fine, and Normal settings
correspond to 96, 90, and 68 respectively.  So anyone who shoots in
one of those two settings and then decides to do a quick edit will get
a rude surprise.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread David Gowers
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

  Hi,
 
  On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:
 
  Does your reply indicate you take a this feature not a bug approach
  here
  and you think is the best way gimp should deal with this situation?
 
  Indeed. When you open a JPEG file, then you have a decoded image. The
  settings that were used to encode it are irrelevant since encoding it
  again as a JPEG file would not yield the same image anyway.

 I'm sorry I find that a rather forced logic. As we have seen the image
 will not be _identical_ due rounding errors and such , that does not make
The image may well be quite unlike the input due to lossy compression
-- see below.

 the existing choice of jpeg_quality irrelevant. It represents the users
 choice of size/quality trade-off.

 I see no justification to discard that choice as irrelevant.

AFAICS, Sven is saying that it is irrelevant, because it is
*impossible* to numerically represent the overall quality of the image
to be saved. The quality setting of the input file, assuming that it
is correctly calibrated to the IJG scale, would be multiplicative:
when you save a jpeg file with quality 75, you are saying 'throw away
a certain amount of the image data' -- and saving it again with
quality 75, you are saying 'discard that much again'.  You can't save
with the same quality, because you've already thrown away much of the
data that was used to create the first JPEG.

Actually getting a quality that is notionally '75% of full detail'
when saving a jpeg output from a jpeg input, is trial and error -- so
really, presenting a preview would improve the situation.

As for the practice of saving jpg outputs from jpg inputs, my personal
experience has been that it's a BD thing; basically the only two
possibilities are
a) Image mutilation
b) filesize inflation (ie. you can preserve quality.. by choosing
something that effectively renders JPEG's compression ineffective
(quality = 96 or above, IME)
-- this often inflates the filesize beyond that of lossless image
formats like PNG.)
About the only thing GIMP could do to help here, is to warn the user
if they are saving a jpeg file and the image was originally loaded
from a jpeg file.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Robert L Krawitz
   Date: Mon, 9 Jul 2007 00:26:21 +0930
   From: David Gowers [EMAIL PROTECTED]

   On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
   
 Hi,

 On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:

 Does your reply indicate you take a this feature not a bug approach
 here
 and you think is the best way gimp should deal with this situation?

 Indeed. When you open a JPEG file, then you have a decoded image. The
 settings that were used to encode it are irrelevant since encoding it
 again as a JPEG file would not yield the same image anyway.
   
I'm sorry I find that a rather forced logic. As we have seen the image
will not be _identical_ due rounding errors and such , that does not make

   The image may well be quite unlike the input due to lossy compression
   -- see below.

The question to my mind is what's going to be closest to the user's
expectations in terms of quality and size, not what's going to be
pixel for pixel identical.  When saving (or, I'd argue, exporting) an
image from a lossless format (png, or even more so xcf) to a lossy
format, we can really only guess, and in that case having a settable
default is good.  However, when we're working with JPEG files, we have
a bit more information about what the user likely wants, based on the
quality setting and perhaps the file size.

the existing choice of jpeg_quality irrelevant. It represents
the users choice of size/quality trade-off.
   
I see no justification to discard that choice as irrelevant.

   AFAICS, Sven is saying that it is irrelevant, because it is
   *impossible* to numerically represent the overall quality of the
   image to be saved. The quality setting of the input file, assuming
   that it is correctly calibrated to the IJG scale, would be
   multiplicative: when you save a jpeg file with quality 75, you are
   saying 'throw away a certain amount of the image data' -- and
   saving it again with quality 75, you are saying 'discard that much
   again'.  You can't save with the same quality, because you've
   already thrown away much of the data that was used to create the
   first JPEG.

Sure, but if the image was originally saved at quality 98, and then
you resave it at 75, you're going to wind up with a lot more
artifacts, which would be a surprising result if you don't understand
how JPEG works.  If the original image was saved at 60, and you resave
it at 98, you might wind up with a much bigger image (I'm less certain
of that), which is also not what I think would be expected.

The issue at hand is a special, but IMHO important, case -- a very
high quality JPEG gets minor edits (perhaps to remove redeye or the
like) and resaved; the result is *markedly* lower quality because the
default of 85 is much less than the original.

   Actually getting a quality that is notionally '75% of full detail'
   when saving a jpeg output from a jpeg input, is trial and error --
   so really, presenting a preview would improve the situation.

   As for the practice of saving jpg outputs from jpg inputs, my personal
   experience has been that it's a BD thing; basically the only two
   possibilities are
   a) Image mutilation
   b) filesize inflation (ie. you can preserve quality.. by choosing
   something that effectively renders JPEG's compression ineffective
   (quality = 96 or above, IME)
   -- this often inflates the filesize beyond that of lossless image
   formats like PNG.)

What about the case where the original quality was 96 or 98, and it's
resaved at the same quality level?  My quick test showed a slight
decrease in file size, but probably very little in the way of image
degradation.

   About the only thing GIMP could do to help here, is to warn the
   user if they are saving a jpeg file and the image was originally
   loaded from a jpeg file.

That would be a good idea, but I believe that there are at least some
common cases where it's possible to do a bit better.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Roel Schroeven
Sven Neumann schreef:
 Hi,
 
 On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote:
 
 Does your reply indicate you take a this feature not a bug approach here  
 and you think is the best way gimp should deal with this situation?
 
 Indeed. When you open a JPEG file, then you have a decoded image. The
 settings that were used to encode it are irrelevant since encoding it
 again as a JPEG file would not yield the same image anyway. Thus it is
 better to use the default values. Since we will very soon allow the user
 to change these defaults, this should be the best way we can handle
 this.

Perhaps not a bug, but IMHO gimp's JPEG handling violates the principle 
of least surprise. I had a quick look at the source code and found out 
that the quality setting (and other parameters) are saved in a global 
variable jsvals, which is initialized with the default values (85 for 
the quality), but gets overwritten after save as:

1. open a.jpg
2. save a.jpg
- a.jpg is saved with the default quality, 85. Fine by me.
3. save a.jpg with save as, with quality say 55
- as expected it is saved with quality 55.
4. open b.jpg
5. save b.jpg
- b.jpg is saved with quality 55 instead of 85!!

Wouldn't it be better if gimp acted in one of those two ways:
1. always save with the default quality, except when save as is used.
2. read the quality when loading a jpeg, and used that to save the image 
(if save as is not used).


-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 19:55:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote:

 2. read the quality when loading a jpeg, and used that to save the image
 (if save as is not used).

 Last time we discussed this (a couple of years ago), libjpeg didn't
 allow us to read the JPEG quality factor that was used to save the
 image. I don't know if that has changed, but I assume that it hasn't.


 Sven


thanks , that explains why it was done this way. Probably ought to be  
checked, hopefully they've made a bit of progress in the intervening time.

imagemagick seems to have no trouble getting this info and it does depend  
on jpeg pkg.

Of course if there is an inadequacy in jpeglib they may have worked around  
it by reading the file header anyway, I'm pretty sure it's readily  
available.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote:

 2. read the quality when loading a jpeg, and used that to save the image 
 (if save as is not used).

Last time we discussed this (a couple of years ago), libjpeg didn't
allow us to read the JPEG quality factor that was used to save the
image. I don't know if that has changed, but I assume that it hasn't.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven  
[EMAIL PROTECTED] wrote:


 1. open a.jpg
 2. save a.jpg
 - a.jpg is saved with the default quality, 85. Fine by me.
 3. save a.jpg with save as, with quality say 55
 - as expected it is saved with quality 55.
 4. open b.jpg
 5. save b.jpg
 - b.jpg is saved with quality 55 instead of 85!!
 Wouldn't it be better if gimp acted in one of those two ways:
 1. always save with the default quality, except when save as is used.
 2. read the quality when loading a jpeg, and used that to save the image
 (if save as is not used).

thanks for digging that out.

is that from todays svn, Sven committed a patch earlier today that may  
affect that.

the default setting now settable by the user (thanks Etienne). see bug  
#63610


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 17:53:59 +0200, Robert L Krawitz [EMAIL PROTECTED]  
wrote:

 What about the case where the original quality was 96 or 98, and it's
 resaved at the same quality level?  My quick test showed a slight
 decrease in file size, but probably very little in the way of image
 degradation.

Thanks,

I suspect that could be the result of some of the less important  
parameters getting a similar default, the encoding method (int/fp) or  
simply the algorithm efficiencies.

eg An earlier post indicated Jpeg:sampling-factor also changed from   
2x1,1x1,1x1 to 2x2,1x1,1x1.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Roel Schroeven
[EMAIL PROTECTED] schreef:
 On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven  
 [EMAIL PROTECTED] wrote:
 
 1. open a.jpg
 2. save a.jpg
 - a.jpg is saved with the default quality, 85. Fine by me.
 3. save a.jpg with save as, with quality say 55
 - as expected it is saved with quality 55.
 4. open b.jpg
 5. save b.jpg
 - b.jpg is saved with quality 55 instead of 85!!
 Wouldn't it be better if gimp acted in one of those two ways:
 1. always save with the default quality, except when save as is used.
 2. read the quality when loading a jpeg, and used that to save the image
 (if save as is not used).
 
 thanks for digging that out.
 
 is that from todays svn, Sven committed a patch earlier today that may  
 affect that.

I first tried with gimp/trunk from svn revision 22893 (from 2007-07-06 
22:47:44 +0200); I now tried it again with svn revision 22902 (from 
2007-07-08 17:34:25 +0200), which presumable includes the patch you 
mention; the behavior I described is still the same.

 the default setting now settable by the user (thanks Etienne). see bug  
 #63610

I haven't tried changing the defaults to see if that changes anything.


-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

Roel Schroeven

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Guillermo Espertino
OMG, at last!

That's what I was trying to say since the beginning.
I know jpeg is a lossy format (I knew that for at least ten years). I 
know, and always knew, that it has generational degradation.
I didn't know that PS compression scale doesn't follow the jpeg 
specification. Thanks for the information, I know it now.
Despite the scale thing, most of the people know that jpeg loses image 
information.
I don't know the internal structure of a jpeg file, but please don't 
tell me. I'm talking from the user perspective here.

What I didn't know (and wouldn't expect) is that Gimp will destroy my 
pictures without warning me.
And that's exactly what I get.
I have a picture taken at 95, open it and save it, and it ends up at 85. 
Why is that?
I'm a professional designer. I'm not using jpeg for professional work. I 
used tiff and PSD with PS and now I'm using xcf.
I know that. Don't try to explain me how to work, because I know it.
But I'm a person too, not just a designer, and use to take some family 
pictures. The camera that I use (an old Nikon Coolpix 800) saves in jpeg 
and tiff format. Tiff format is huge and slow, jpeg is more handy.
During a weekend with my family, I took a couple of pictures. Some of 
them were under-exposed.
It doesn't matter. I open them, tweak the curves a little, and save 
them, for instance.
Nobody will be using other formats for intermediate work in such case. 
It's a single tweaking.
This is a VERY COMMON practice. And if you think that is perfectly 
normal that the program recompresses the images without warning, let me 
tell you that you're wrong. As others already said: One expects that a 
fine quality picture from a camera will be saved with a similar 
quality. Not a half.
If gimp can't read the quality setting from the image, then it should 
display the export settings EVERY TIME you save a jpeg image as jpeg.
Destroyed image data is not a expectable feature.

Sven wrote:

 Why should any application do what you suggest? If you open a JPEG file
 and save it again as JPEG, then the original quality factor is
 completely irrelevant. You are doing a lossy operation, there is no way
 to save the file with the same quality again.

Yes, but if you had a great looking photo you don't expect to have a 
heavily compressed image with lots of artifacts, bad edges and color 
bleeding.
You expect a similar quality.
If once the image is decoded the quality factor doesn't matter anymore, 
why don't you display the export options when saving? It would make 
sense to do that.
The user wants control over the exporting process, but for now Gimp is 
taking the decision for him.

Sven wrote:
 Due to the way file plug-ins are implemented in GIMP, it is not trivial
 to do this. But you can easily work around it by assigning Ctrl-S to
 Save As. Then you will always be prompted with the dialog asking you
 for the save parameters.

The problem is not me. I know the problem now and I won't use CTRL+S for 
mi jpegs anymore.
I'm concerned about lots of users that will learn that too in the hard 
way, destroying some irreplaceable images.

There seems to be a big gap between developers and users here. 
Developers base their opinions on technical issues but seem to forget 
the problems that pop up in the everyday use. I'm a user, I plan to keep 
using Gimp everyday, and this jpeg exporting issue is (from the user 
perspective) definitively a PROBLEM.
From the user perspective, the way that Gimp processes the jpeg images 
now isn't tha obvious.
I had to start this discussion here to find out how it works, and now I 
have it clear. But what happens with the thousands of users out there?


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:

 What I didn't know (and wouldn't expect) is that Gimp will destroy my 
 pictures without warning me.
 And that's exactly what I get.
 I have a picture taken at 95, open it and save it, and it ends up at 85. 
 Why is that?

Because you are using JPEG despite better knowledge that it will do
exactly that. Sorry for the harsh tone, but I am only replying the way
you are putting it.

I already explained that the JPEG plug-in cannot access the settings
that were used to save the file. We can also not easily change the code
to always show the settings dialog because then we would have to do show
the dialog for all file plug-ins. There might be a way out of this, but
there is certainly not an easy one. So please calm down and let the
developers deal with this. After all this is a developer list. Your
harsh comments are not helpful.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Sven Neumann
Hi,

here's what I suggest that we do (short-term). It should be a simple
change and it will avoid that what happened to Guillermo happens to
others in the future.

The JPEG plug-in should not use the last-used values when being run
non-interactively from the Save action. It should use the, now
user-configurable, default values. Of course if the jpeg-save-options
parasite is set on the image that is being saved, then those values
should be used. As far as I can see now, this means removing a single
line in jpeg.c. I will have a closer look tomorrow morning.


Sven


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread gg
On Sun, 08 Jul 2007 23:48:28 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 Hi,

 On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:

 What I didn't know (and wouldn't expect) is that Gimp will destroy my
 pictures without warning me.
 And that's exactly what I get.
 I have a picture taken at 95, open it and save it, and it ends up at 85.
 Why is that?

 Because you are using JPEG despite better knowledge that it will do
 exactly that.

He knew it was potencially a lossy format but he was using a very high  
quality setting, he did not know gimp would arbitarily change down the  
quality and wreck his image. jpeg at 98 looses hardly loses any quality  
visually.

  To be fair you should be accurate, what he did was sensible and should  
not have produced the results it did.

You almost seem to be saying that anyone who uses jpeg is a fool so it  
doesn't matter if gimp destroys their work.


 Sorry for the harsh tone, but I am only replying the way
 you are putting it.

Well he has been very patient and has had to repeatedly post to get us to  
see what he was reporting was not PEBKAC. I would hardly criticise a bit  
of polite annoyance on his part.

It was hard to believe at first that gimp would wreck an image like this.  
Let alone that it should be considered a feature.



 I already explained that the JPEG plug-in cannot access the settings
 that were used to save the file.

That is not accurate. Imagemagick does it , gimp can. If libjpeg still  
cant do this ( to be verified ) then another way to read the file header  
needs to be found. It's not complicated.


 We can also not easily change the code
 to always show the settings dialog because then we would have to do show
 the dialog for all file plug-ins.

Agreed , that's probably not the correct solution.



 Sven



Thanks for bringing this up Guillermo , and thanks for having the  
perseverance to keep posting until we got what was really happening.  
Hopefully we will work out a better way to deal with this.

Once we're all agreed this is not very satisfactory we will certainly come  
up with a solution.

Oof, it's been a busy one. Goodnight!


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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Guillermo Espertino
 So please calm down and let the developers deal with this.
 After all this is a developer list. Your
 harsh comments are not helpful.

I'm not being harsh. At least it wasn't my intention.
In fact, this list is commonly considered to be harsh by many people, 
but now I learn that there's sensitive people here :-)
I'm just trying to explain my point. I just want to help the project 
with my experience as a user, because I can't code.
What makes sense for you, may not make sense for users. You find the 
quality setting of the original file to be irrelevant, but obviously 
it isn't irrelevant for regular users like me.

 Because you are using JPEG despite better knowledge that
 it will do exactly that.

If you say that a user must understand the jpeg internal structure 
before saving a single image, there's no much to talk about. I'll 
uninstall Gimp and will be working with Imagemagick via command line for 
processing my images. :-p
Seriously talking: Gimp is a program with a GUI, it's having great 
useability improvements. It's obviously a program to be used by users, 
not just by developers.
For a user, a non-linear scale and a destructive re-save without a 
warning are not obvious things.

 I already explained that the JPEG plug-in cannot access the settings
 that were used to save the file. We can also not easily change the code
 to always show the settings dialog because then we would have to do show
 the dialog for all file plug-ins. There might be a way out of this, but
 there is certainly not an easy one.
This is very different. If that had been your first answer I wouldn't 
say anything else.
The problem is real, but the solution isn't that easy because it implies 
a complete change in the saving plugins? That's fine.
But don't start saying that the problem doesn't exist or it's 
irrelevant, because it is not.

Anyway, don't think I'm pissed off. I'm cool with all the replies.
We may agree or not, but we all try to take Gimp to a higher level (some 
people coding, some people using it and trying to report problems like 
this).

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Sun, 08 Jul 2007 23:48:28 +0200

   On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote:

What I didn't know (and wouldn't expect) is that Gimp will
destroy my pictures without warning me.  And that's exactly what
I get.  I have a picture taken at 95, open it and save it, and it
ends up at 85.  Why is that?

   Because you are using JPEG despite better knowledge that it will do
   exactly that. Sorry for the harsh tone, but I am only replying the
   way you are putting it.

Sven, I do think you're being unreasonably hard on Guillermo.  Never
mind that using JPEG per se won't do exactly that -- what's really
degrading the quality so badly is GIMP's choice of a quality factor
compared to that of the original JPEG.  Not to mention that I think
Guillermo is being quite reasonable.

A lot of people (particularly folks who just casually want to lighten
a shot or remove redeye) don't know it.  All they know is that they
have a picture that their camera took, they've corrected it, and all
of a sudden the image quality fell apart.  They don't know anything
about JPEG's, or compression (lossy or otherwise), all they know is
that GIMP ruined their photo.  That's not going to be very helpful to
anyone.

   I already explained that the JPEG plug-in cannot access the
   settings that were used to save the file. We can also not easily
   change the code to always show the settings dialog because then we
   would have to do show the dialog for all file plug-ins. There might
   be a way out of this, but there is certainly not an easy one. So
   please calm down and let the developers deal with this. After all
   this is a developer list. Your harsh comments are not helpful.

Well, as was noted ImageMagick is able to access this information, so
it's apparently there.  Maybe this isn't going to be an easy problem
to solve, and that's OK, but I think that this is a real problem, not
simply a user error (and even if it is a user error, wouldn't it be
best to help users not make this kind of error?).

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Tor Lillqvist
Guillermo Espertino writes:
  I didn't know that PS compression scale doesn't follow the jpeg 
  specification.

There is no such specification for a compression scale or quality
factor.

Inside an JPEG image, what actually defines the lossiness of the
compression are a set of so-called quantization tables. A
quantization table is a table of 64 8- or 16-bit integers. (Typically
8-bit values are used.)

Typically, one such table is used for the Y channel (luminance,
i.e. BW information) and another for the Cb and Cr channels (colour
information). These tables are actually stored inside each JPEG image.

(There are not some standard one(s) that would implicitly be
referenced to by some single index that would say use standard table
1 or something like that. In retrospect, that might have been a good
idea I think.)

I.e. what actually determines the lossiness and loss style of the
compression, what information is thrown away, are 128 (or just 64, or
even 192) numbers (!). Not a single quality value.

(It is in fact even possible to use different quantization tables for
different parts of an image, I think. I have no idea how common such
JPEG images are, and if any software in common use produces such.)

The single quality value 1..100 that GIMP uses is passed to libjpeg's
jpeg_set_quality() function. This function is used to scale two sample
quantization tables given in the JPEG specification. But nothing
forces some application to use linear scalings of these sample
quantization tables. I don't know if the sample tables are even
normative in the standard, or just informative.

One might imagine some application even doing a clever analysis of an
individual image to come up with image-specific quantization
tables.

The website
http://www.impulseadventure.com/photo/jpeg-quantization.html seems to
have a good collection and comparison of quantization tables used by
different firmware and software implementations of JPEG compression.

http://markcox.googlecode.com/svn/trunk/jpegdump/jpegdump/ has sources
to a nice program one can dump the contents of a JPEG file, if one
wants to have a look at the quantization tables used.

There is another program with the same name at
http://www.programmersheaven.com/download/17054/download.aspx that is
less useful in general, but has one nice feature: it attempts a guess
at the libjpeg-style quality factor used for the quantization tables.

--tml

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Tor Lillqvist
Sven Neumann writes:
  I already explained that the JPEG plug-in cannot access the settings
  that were used to save the file.

Actually, it shouldn't be that hard to at least try. If the
quantization tables used in an image correspond exactly (or closely
enough) to those produced by libjpeg with some setting of
jpeg_set_quality(), it would be nice if GIMP remembered that as the
default quality to use for the file. Or something like that... One
might even consider keeping and re-using the original quantization
tables instead of using jpeg_set_quality() in case the quantization
tables don't seem to be produced by libjpeg.

--tml

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Tor Lillqvist
Tor Lillqvist writes:
  One might imagine some application even doing a clever analysis of an
  individual image to come up with image-specific quantization
  tables.

http://citeseer.ist.psu.edu/cache/papers/cs/1634/ftp:zSzzSzftp.cs.wisc.eduzSzpubzSztech-reportszSzreportszSz94zSztr1257.pdf/rd-opt-an-efficient.pdf

--tml

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-08 Thread Graeme Gill
Tor Lillqvist wrote:One
 might even consider keeping and re-using the original quantization
 tables instead of using jpeg_set_quality() in case the quantization
 tables don't seem to be produced by libjpeg.

Which is what I understand Photoshop does, thereby giving
users the least level of surprise when they casually open/modify/save
a JPEG file.

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-07 Thread gg
On Sat, 07 Jul 2007 07:19:57 +0200, Guillermo Espertino  
[EMAIL PROTECTED] wrote:

 Se only opened the image from the camera, adjusted the curves, and
 scaled it down (BTW, the downscale code should do oversamplig by
 default. It always breaks a little the edges). Until she saved, the
 image quality was good.
 Then she saved with CTRL+S, without changing the quality factor, and
 the picture turned out like that. Heavily compressed.

Maybe you should try adjusting the compression level on the camera, it  
maybe a simple A,B or C choice and is probably not presented as jpeg  
quality.

Jpeg is a sensible choice for a memory limited device like a camera but  
you have to make a chioce in using it. Once the information is lost it is  
gone for ever. If you wish to readjust you colours and downscale you are  
completely altering the form of the image. This is probalby about the  
worst thing to do between two jpeg compressions. It's really not a case of  
she only did... . I dont think there is anything anomolous about what  
you describe.

Now getting back main point of the thread, gimp vs. PS quality parameter.

Thanks for the detail of the comparison. The jpeg quaility parameter is  
defined in the jpeg standard and its meaning is clear. It is possible that  
since the useful range of values tends to be 60 - 85 (and note this is not  
a percentage ) PS may be mapping this in someway in presenting it to the  
user to give a more intuitive idea of quality which is in any case rather  
subjective and difficult caracterise in a simple two digit number.

I dont use PS but my guess is that there is no real difference in the  
implementation , simply in the way this parameter is presented to the user.

Other programs give a compression parameter which in effect adjusts the  
jpeg compression.

Does that tie in with your experience?

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


Re: [Gimp-developer] jpeg quality factor.

2007-07-07 Thread Michael Schumacher
Guillermo Espertino wrote:

 In Gimp the compression factor is expressed as quality factor. So 100% 
 is the best and 0% is the worst.

GIMP does use the IJG quality scale.

 Well, 70% isn't the same in Gimp and in Photoshop. And it doesn't sound 
 very logical.

Blame Adobe for this. The JPEG FAQ states that differences between
different programs have always been there, some even going as far as
reversing the quality to a compression. See
http://www.faqs.org/faqs/jpeg-faq/part1/

Also, 95% is the highest practically usable quality setting, anything
higher does not have an influence on the pixels anymore (although it
might be useful for researchers who are working on the algorithms).

The patch currently attached to bug
http://bugzilla.gnome.org/show_bug.cgi?id=63610 might help to end the
problem about which setting should be the default - if quality is
persistent, you set it once.


HTH,
Michael

-- 
GIMP  http://www.gimp.org  | IRC: irc://irc.gimp.org/gimp
Wiki  http://wiki.gimp.org | .de: http://gimpforum.de
Plug-ins  http://registry.gimp.org |
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


  1   2   >