GNOME Bugzilla – Bug 553390
Downscaling is not properly performed
Last modified: 2014-03-09 22:09:04 UTC
I attach to this bug two photos. The was obtained from one source; this was 1723x1145 pixels tiff file. 50.jpg was obtained by scaling with the scale 50% (Lanczos interpolation) of the initial photo. The quality is really great! 49.jpg was obtained by scaling with the scale 49% (Lanczos interpolation) of the initial photo. This is really ugly picture! The behavior of downscalers in the GIMP seems to be very unpredictable now.
Created attachment 119217 [details] Image scaled with 50%
Created attachment 119218 [details] Image scaled with 49%
I just have checked gimp 2.4: both images (50% and 49%) are quite good in the last case!
Created attachment 119224 [details] initial image converted to jpeg
It is completely pointless to file such bug reports here. We always appreciate help with the code and we would love to see your patches. But what you are pointing out is not a bug. It is something that could be improved. And we already know that this is the case. There has been plenty of discussion on the mailing-list about how the decimation routines can be improved.
Sven, I am sorry for not reading the mailing list before posting this bug. I have read it now and know there was a long discussion concerning this point. For me the problem is that current downscaling code gives really ugly results (for all type of interpolation) for scale factors ~ 0.4 <= s < 0.5 at least for small enough images (like photos being prepared for web). And this is definitely a regression comparing to 2.4. For practice, this means that preparing photos for web have became to be a really difficult problem. I think that preparing for web is most common task for GIMP users, so many GIMP user will be concerned. The workaround for scaling by 0.49 is to scale by 0.98 and then scale by 0.5. In last case the resulting image is quite good. But I think that scaling algorithm must do the similar thing internally. Again, sorry for spending your time (in the case if you already know all these problems).
Scaling by 50% is done in one pass, scaling by 49% in two passes. The first pass scales down to 50% using a box filter and then the Lanczos interpolation is used in the second step. This method can introduce some blurring. But the current Lanczos implementation can not scale down by a factor smaller then 0.5, so a two-pass approach is needed. We know that this is not ideal and we would like to see this improved in the next development cycle.
As far as a user doesn't know it, that should be written in a release notes: Do not use Lanczos when scaling down more than by 2! In other case scaling looks horrible and simply kills the result.
Alexander, what you are claiming there is not true. First of all, the same multi-step scaling is done for all interpolation methods, not only for Lanczos. Second, the results look very good, except for a few corner cases. And in these cases, you just need to sharpen the result a little. Now, please, do not use this bug report for your uneducated guesses and leave it as a platform for the developers who want to discuss changes in order to improve this for 2.8. Otherwise we will have to close this report again.
We definitely need to do something about this. The current approach of using interpolation for downscaling is inherently broken.
Can't this be fixed already in 2.6.x? Scaling is an essential core function of any image related program and if it's broken it's a _massive_ show stopper - and it's not like the scaling quality was like that already in 2.4.x, it became WORSE with 2.6. I'm currently copying images to a different program for downscaling and copy & paste them back afterwards because the results of GIMP are so bad.
The workaround is do pre-scale to (requested size)*2^^n, and then do final scale. This works much better than scale in GIMP 2.4. I wrote a small script, which can do it
Created attachment 128395 [details] scale with workaround
This needs to be fixed for every user. I mean, there are books and press articles out there which recommend GIMP as alternative to Photoshop and such a basic functionality is broken. If I could code, I'd take a look at how ImageMagick (for example) does it and supply a patch, but maybe some dev is reading this. Just a suggestion.
drwu, what version are you using? We have considerably improved scaling in the 2.6 series. And that workaround from comment #13 is not needed because that's exactly what GIMP 2.6 is doing internally.
I just checked 2.6.4 with the same image as before. The problem still presents and the workaround gives much better result. Before you said that gimp at first do scale with factor 2^^n, and then, at final step, pre-scale with factor < 0.5: 0.49=0.5*0.98 In my workaround I do the same with opposite order: 0.49=0.98*0.5 This yields clearly better results
> drwu, what version are you using? 2.6.3 (Windows & Linux) I've compared the downscaling results of ImageMagick, IrfanView and Photoshop which look virtually the same, with GIMP's, which are worse and that wasn't the case in the 2.4.x series. If you want I can upload a few samples.
No thanks. we are aware of the issues. That's the reason of this bug report. Now please stop adding comments here. The only thing we are interested in are patches to improve the situation for GIMP 2.8.
Sorry if this isn't helping, but what is the reason or advantage for having different resizing methods or multiple passes for different scaling factors? Surely the same method can be used regardless of the scaling factor? How do other programs do it, because they always get it spot on IMO. I have been trying to find why some images were resizing badly and others weren't, and it seems the images come out *worse* when using a "round" scaling factor, i.e. when the target size divides the original size such as 500->100 pixels. I posted an example in this GimpTalk thread: http://www.gimptalk.com/forum/viewtopic.php?f=2&t=38072 (I have also tested in ImageMagick and KolorPaint, I always get a smooth result whatever the scale.)
Scott, what you are showing in this thread is a bug that has long been fixed in the GIMP 2.6 series. If you would upgrade from 2.6.1 to at least 2.6.3, then you would get much better results. And please stop posting comments to this bug-report. This is not a help forum.
Note that you just need to add intrepid-backports to your Ubuntu package sources to get the official update to 2.6.3 (see http://packages.ubuntu.com/search?keywords=gimp&searchon=names&suite=all§ion=all). Perhaps someone should file a bug report at the Ubuntu bug-tracker asking them to update gimp in the intrepid repository?!
*** Bug 579956 has been marked as a duplicate of this bug. ***
We won't have time to work on this for 2.8 if we want a release in 2010. Moving off milestone. We can put it back if someone magically starts giving us patches.
The result of this discussion is one big FAIL. 4 years from bug reporting passed and bug is still present. Gimp is presented like a Photoshop alternative, but "oops, it can not properly scale images down. Basic functionality of image processing editor. We are all sorry, but 'we have no time' :}". Such a shame.
We don't present GIMP like an alternative to anything, and we don't owe you anything. This is all done in free time here. It's a shame that you have such an entitlement attitude. Remind us how much you paid for our services, please?
*** Bug 688300 has been marked as a duplicate of this bug. ***
I wonder if we should get rid of this bug alltogether. 2.10 will use GEGL and thus entirely different code.
I'm not your mum, so I sometimes say something unpleasant but true. Sorry. In fact, I was expecting something like "It's free, so it can be shitty". It's very frequent argument of open source developers. It's their defense how to do things wrong. Ignore me and delete my posts, if you can. I have no claim on anything.
Oh I antagonized you, nice. Telling the truth and being an ass are two entirely different things. Please leave.
Ok. Shame on me. Now to the point. Do you have this bug repaired already? :P
Hm... should we resolve it as obsolete, or fixed for 2.10?
@vaclav: Usually I'd say "vote with your code" or "patches accepted". In this case however I fear that you needn't bother because all the bridges are burnt already. Being abusive and obnoxious often enough makes other people who could help you want to not help you. @schumaml: depends on if such a change in behavior would be even acceptable in stable. If not, and if it's fixed with the use of gegl ops in 2.9/2.10, then yes. If git master doesn't have better scaling results, then no, and if patches for this are principally acceptable for 2.8, not so sure.
Ok, one more reaction from me. Let me to explain some things, please. In my first comment here I wrote, that to have such bug in one of the essential functions of image editor for 4 years is a shame. I bet that downscaling of images is one of the mostly used functionality in Gimp. New, same as old users encounter with scaling everyday I believe. There is need to downscale pictures for web design, as well as photos for sending by email. Tons of images are affected with this bug, if user doesn't try to fight and find workarounds. So I called it shame. Yes, I wrote it directly, without some beautification, because I feel it so. I didn't have any requirements, no word about somebody owes something to me. And then I read in the first reply, that I paid nothing so I cannot to request/ask/scold to something? So you believe that quality comes with money? Free software cannot be first-class, precise and polished? Why to work on open source software, when first argument to disappointed user is "where are your money?". This is a stupid philosophy and I hate it. It's right in the opposite of my philosophy "When you cannot do it right, don't do it at all". Even if you do it for millions or for free. So this reactions are like stirring up a hornet's nest to me. I apologize to all whom I have hurt.
Nils, I doubt that this will be fixed in 2.8. And if the gegl-based scale does not perform better, then a new bug should be opened, IMO.
Thanks Vaclav for the explanation, let me explain some things too. We are less than 10 active developers. Much less. Everybody does this in their free time. People are donating their time, and try to do the best. Can you imagine how many severe defects we know of? Maybe downscaling sucks, but other things suck too, big time. Everybody simply works on what they do best. Remember the far than 10 developers, how much can they do? What do they consider important? I don't think you got the point of my first reply. It's about your tone. You simply can't expect any sane response to that, and "you feel so" is no reason to talk to volunteers in an arrogant way. Essentially, somebody is dontaing their time to the public, much like to a charity, and you complain that they didn't donate enough, using words like "FAIL" and "shame". That's unacceptable and is treated as such. That said, I appreciate your explanation, you are welcome to contribute and share your opinion, but please in a reasonable tone.
We're not going to exchange the scaling code in 2.8 at this point, and this bug doesn't apply to git master because we're using GEGL there. Closing as OBSOLTE.