Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Re: [Gimp-developer] jpeg quality factor.
Guillermo Espertino writes: The same image exported as jpeg with the same quality factor (let's take 75% as an example) Where did you get that percent sign from? GIMP doesn't show any percent sign. The quality value is not a percentage of anything. You should just treat it as a number on a nonlinear scale between 1 and 100. (With the usable range being between 70 and 95, say.) (What would it be linear to? File size? Perceived quality, as if that could even be quantized?) It is not necessarily related to corresponding scales in other software at all. The only thing one can know is that the higher the number is, the less compression artefacts one should see (and the bigger the file will be). Both programs calculate the compression ratio differently. That is no surprise, as they use different JPEG software. You shoukd not think of the JPEG quality value as some compression ratio or any other ratio. It is just a number whose exact meaning you will have to check from the libjpeg sources in GIMP's case. It is just a coincidence that both programs in this case happen to use a scale from 1 to 100. --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.
[EMAIL PROTECTED] writes: Here if I can do say 10 re-saves at 85% quality, it produces no discernible changes in picture quality. Presumably you also re-load the image you just saved each time? --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.
Thanks everybody for your replies. It's more clear for me now. - Compression factor isn't linear and in IJG, and that factor doesn't represent a percentage. - Photoshop converted its scale for making it more intuitive, but it has nothing to do with the right IJG scale. Thanks Michael for the link for the jpeg FAQs. It's very clear in the item 5: * Recent Apple software uses an 0-100 scale that has nothing to do with the IJG scale (their Q 50 is about the same as Q 80 on the IJG scale). It's clear that photoshop uses that scale. Tor wrote: It is just a number whose exact meaning you will have to check from the libjpeg sources in GIMP's case. It is just a coincidence that both programs in this case happen to use a scale from 1 to 100. That's the problem: That coincidence. The 1-100 scale is commonly used for percentages, and everybody tends to take it as that. My problem isn't that I can't understand how jpeg works... My problem is that I'm used to take 1-100 scales as a percentage. I'm pretty sure that I'm not the only one. gg wrote: 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. The images I get from the camera are fine. My problem is that if adjust them, scale them and re-save them without explicitly change the quality setting they turn out really distorted. Even though I understand (now) the difference between that scales, I'm still concerned about that quality loss in my images. I repeat: I just open them from the camera and they look great (Nikon Coolpix 800), adjust levels, curves and color (they still look great), scale them down, and save them using CTRL+S. When I re-open them they are distorted. I'm not talking about repetitive openings and saves. 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. That was my whole point. If the quality is presented as a scale between 0 and 100 the user assumes that is the same 0-100% of photoshop and other programs. That happened to me. People is always more comfortable with linear scales, they are easier to understand. If the compression factor isn't linear, photoshop must have linearized it for translating that into a sort of porcentage of quality and make it easier to understand. It goes against the IJG scale, but unfortunately this different scale is now more popular than the right one. Does that tie in with your experience? Yes, it does. I can see you understand my point. We, the users, tend to assume things based on the information we get on screen.It should be considered as a useability factor, imo. Developers see it from the technical perspective, but users don't. Users want to have things done. Now, with all these replies I can understand it, but it won't take too long to see a user complaining for the same thing. It's very clear that Photoshop doesn't use the IJG scale, but it should. Users who came from PS are used to that incorrect scale, and find this difference. I think it should be documented in the Gimp Manual and FAQs. It's not a minor issue. Thanks everybody for your explainations! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
