On 8/6/07, Guillermo Espertino <[EMAIL PROTECTED]> wrote: > A couple of weeks ago somebody commented about the quality of the > downscaling in Gimp. > iirc there was a patch that improved the quality (that was bumped for > future releases) and there was a discussion about the pertinence of the > different names of the algorithms in the interface. > Well, I know that this kind of requests are not welcome when a new > release is so near, but I've been using Gimp a little more this days for > small images (my previous works were for print or signs, so I didn't > find this issue to be critic), but now I do and I'd like to share my > experiences and my concerns. > I'm working in a website right now, and one of the most frequent > operations is to reduce images. I coudn't get a decent reduction using > the different algorithms. > If you have to reduce a very large image to, say 800 px, you can use > oversampling and you get a decent result, but when you're working on > images for the web, which are frequently smaller than 100px, the results > are very bad. > If you use oversampling, the result is a blurred image. If you don't you > get jagged edges.This is particularly visible when you work with type, > logotipes or high contrast images. You don't appear to be using oversampling, as you say:
> If you perform the transformation just once, the imperfections are > visible. But the big problem comes when you have to perform > transformations a couple of times. Oversampling cancels that out, because the increased resolution minimizes loss of meaningful data. (oversampling == editing at a increased resolution relative to intended final size.) Perhaps you mean supersampling? > And this operations are not rare. It's very common to scale down an > image, rotate it and then tweak the size again. For now, you should rotate before scaling down if possible. > > The last time I mentioned this, Sven replied: > > > I might be wrong but I think the current algorithms are basically the > > same as the ones used in GIMP 2.2. So there's really no point in > > addressing this long-standing but minor issue before 2.4. > > I thought then that it was ok, but I've changed my mind. > It's not minor at all. Since Gimp doesn't support CMYK, it is not a > viable tool for image processing for print, so we have a tool mostly for > screen works. One of the main professional applications for that is > preparing images for the web, and this issue is critic for that kind of > work. > As a little example, I had to create a button for changing a website's > language. I had a high resolution flag of the UK and wanted to reduce it. > I coudn't get the image right, by any means. I had to re-draw it using > single pixels (I know that diagonal lines are difficult to represent in > small sizes, so don't start to call me stupid. I made the same work > before with other software and got better results). This is an artefact of the way downscaling currently works: it examines 2x2 pixels for each output pixel. This means if you're downscaling to less than 50%, some source pixels are ignored. If Cubic was properly implemented for downscaling, it would examine 4x4 pixels for each output pixel, and some pixels would be ignored when scale < 25%. Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.) Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels. Non-destructive transformation is something that would be more sensible to implement after 2.4. > The release of the 2.4 will be a huge event. The program went through > very important changes, and it's becoming a truly professional > application. If you compare 2.3.x with 2.2.x the difference is > impressive. Now Gimp looks and feel professional. > It would be a shame to inherit that limitation from 2.2 series and have > to wait until the next version (which, considering the whole GEGL thing. > won't be ready soon). > Please don't take this comments as another stupid user request. This is > very important and for me is the major issue that obstaculizes my > migation to Gimp. > I'd like to have CMYK, of course, but color management is enough for > now, since CMYK is not a small change. I'm not telling that's a small > change either, but I think it's critic enough to take a look before 2.4 > I've discussed this with several users and they share my point of view. > I'd like to know what you guys think about it, and if it's possible, > revise the situation before 2.4 > > Thanks in advance, > Gez. _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
