Closed exebar closed 12 years ago
So I have a point of reference, are you referring to the white trim at the top of the screen (below the black bezel) as the most obvious example of jaggies?
When I scale the original 500x500 image with GIMP using Cubic as well as Lanczos3 the 250x250 result you linked (-S) looks almost identical; the same level of stair-stepping is seeing in that top trim line.
Here is a side-by-side comparison of all the different methods: http://i.imgscalr.com/viKirLdIt.png
Can you give me an example of the output you were expecting?
EDIT: I'm referring to the jagged top border of the bezel, the black and the white lines are both jagged.
EDIT 2: Actually, if you look the images closely, the keyboard gets jagged too.
I noticed the same effect using GIMP too. I was hoping for something like this:
The image is resized using Mac's stock imaging app.
The result using imgscalr was this:
I was checking the references you had on the imgscalr page and found out that Image.getScaledInstance() supports scaling hints, I haven't had time to try those out.
Mac's does look nice; I need to know what operations they are using.
I did a comparison to Windows 7 standard image resize and even that looks the same as imgscalr's quality/AA result.
I've been doing some research this morning on pre-applying AA as a possible visual optimization (REF: http://www.cambridgeincolour.com/tutorials/image-resize-for-web.htm) but the results were too similar to the existing impl so as to be almost indistinguishable.
I've also been doing some hunting for a more optimal AA kernel possibly providing the results you are looking for (REF: http://assassinationscience.com/johncostella/magic/) with no luck ({ .25f, .75f, .75f, .25f } provides a gamma-blown out result).
I'll continue doing some research to see if I can find something to help improve this result; it would help a lot to know what the Mac resize util is actually applying to the image.
I know this doesn't help much, but I got a better result with GIMP when I resized the image in 50px steps until it was 200px wide and then used few 25px steps. Though, it would be stupid to do real image scaling like that (not really efficient)...
EDIT: The program on Mac was:
Preview Version 5.0.3 (504.1)
EDIT 2: Just an idea, if the Preview's algorithm can't be found elsewhere, these might help :)
if the algorithm is a known one, those might be useful.
That does help actually; I tweaked the incremental scaling algorithm to step down by 1/7ths instead of 1/2 each time and sure enough the result looked less jagged and a bit softer.
When I bumped that up to 10 it looked too soft.
This is the result: http://i.imgscalr.com/whEWgsTZt.png
had imgscalr given you this out of the gates, would you have been happy or is your target still exactly what Mac produces?
(I am thinking this might justify an "ULTRA" quality scale method...)
I have been a happy imgscalr user until now, your library retains details really well!
With that picture I would have been happy. Though the result does look a bit softer and the top part of the bezel is not "straight", but I can blame Mac for giving too good example :)
The ULTRA scaling method sounds like a really good idea, I hope that I could help you with that, because I fear that I will bump into another "misbehaving" picture, I will post a new one here if I find more...
Btw, are you planning to make a new release now or after the ULTRA setting? I could just try out your modification by applying the patch...
Here are some side-by-side comparisons of different progressive step amounts I would consider for an "ULTRA" scale method. http://i.imgscalr.com/QNHUzJDIN.png
I think 1/7 is the sweet spot; The bezel line in 1/9th looks straighter, but at the expense of the entire picture looking too soft (keeping in mind that someone could still apply OP_ANTIALIAS to the 1/7th result if they wanted it software, where as the 1/9th result forces it to be software even if they might not want that)
Also note that these steps aren't an evenly distributed chunks of 1/7th the original size; each time the picture is resized smaller, that resulting size is paired down again by a 1/7th of that new size; so the diff in each step gets smaller and smaller.
When I tried the same approach with uniform steps down (say 1/10th size reductions) the result was significantly worse.
If you agree that the 1/7th is a good default for ULTRA, I can cut you a custom build of 4.2 to test out with any number of images you are working with and see how it looks with them.
Labelled as a feature request.
This issue is justification for an ULTRA_QUALITY Method. Just waiting on feedback on the comparison graphic before deciding how many steps the scaling should use.
Sorry for taking so long, we had a national holiday yesterday and I was offline.
I agree that 1/9ths looks a bit softer than 1/7ths, but the 1/9ths has a straight top bezel and because of that I prefer 1/9ths version, after all it should be ULTRA_QUALITY :)
I uploaded few more test images, that I found after image googling for a while:
If you want, you can but together a new version of the step amount comparison image using those images, or I can test the 4.2 version of imgscalr on my own...
EDIT: Resize dimensions for uploaded images.
Thank you for the test images; I will be away for a few days but when I get back I'll do some tests with them and others I find online to make sure that 9 isn't too soft.
I agree that in this particular test, 9 gives the straighter bezel line, but if that is at the expense of all images (even pictures of cats, or paintings, or screenshots, etc.) looking too blurry, then I'll have to default to 7 and hope that it is still 3.5x better of a sampling than the original 2.
I'll get back on this next week. Thanks for all the help!
Great!
Just an idea... it would be great if you could provide an easy way to customize the parameters. So, the 1/9ths could be used instead of ULTRA_QUALITY, if someone needs more customization (extending the class might be an overkill in that case).
exebar, I have to do some more testing, but your suggestion of a user-customizable number of iterations is exactly on the right track.
I've been mulling over how to do this, unfortunately the way the API is designed now makes it nasty to try and add an int argument to any of the resize methods to specify the number of iterations.
Instead I was thinking of going with a properties constant used to adjust exactly how many iterations the "ULTRA_QUALITY" quality enum actually translates to. Something like:
-Dimgscalr.ultraQuality.iters=9
Would this fit your requirements? Would you be able to utilize this to accomplish what you want?
Hmm, the property thingy might work, another solution would be a static member in Scalr-class and provide a static getter/setter/reset -methods.
I downloaded the 159d0c7 changeset and tried it out with 1/9ths, but it resulted in too soft images. I don't know if 1/7ths results in too jagged images (for example the iMac image was a bit too jagged).
EDIT: Just an idea, I saw another lib (http://code.google.com/p/java-image-scaling/wiki/Introduction) that has an option to use unsharpen filter, I don't know if something like that could help with the image getting too soft...
Fixed in 4.2
ULTRA is currently set to rescale in steps of 1/7th - it is currently not configurable as additional testing and A/B testing on different images on my machine have always shown 1/5th to not be enough and 1/8th or more to be too soft.
I want to make the smallest/safest change first (hard-code it to 1/7th) and if it becomes a very popular feature I will look at making it configurable via a system property.
When I went to implement that I realized that doesn't jive with any of the other aspects of imgscalr (none of the rest of it is configurable via system props except debugging) so it felt wrong to have this one hidden aspect of the API.
So baby-steps first and want to make sure people like the setting before reconsidering how these are implemented. If a new use-case for imgscalr arises, I may consider bigger changes for 5.0.
Need to wait and see how adoption goes.
Looks like exposing the number of iterations as a property of UTLRA_QUALITY method could help with the issue I just submitted at https://github.com/thebuzzmedia/imgscalr/issues/92.
@pioterj Before I released the ULTRA_QUALITY addition I tested with a slew of different kinds of images and beyond the number I hard coded in the library, the results start to get blurrier (not what I expected) otherwise I would have made it configurable.
I tried to resize pictures using the imgscalr library, code:
Using Scalr.OP_ANTIALIAS resulted in a bit blurred image, but the edges of the display remained jagged.
The original image is 500px * 500px and the result was 136px * 136px.
The same behaviour can be seen on imgscalr CDN service: