I added a slider in Umbraco so editors can choose the quality of their images. However, I just noticed that the quality is the same regardless of the setting. That is, if I set the quality to 90, I get a 130KB image. If I set the quality to 5, I get the same 130KB image. Here's an example URL (this one with a quality of 5):
After a bit of trial and error, I narrowed this down to the fact that the format is also specified in the URL. When the format is present, the quality parameter seems to be ignored, even when the format is a lossy one (i.e., JPEG). Adding this to the web.config seems to sidestep the issue:
<add key="Slimsy:Format" value="false"/>
When that is in the web.config, the format is not added to the query string, and the image is returned with the correct quality.
I'm not sure if the problem is with Slimsy or with ImageProcessor, but something is amiss.
Who said anything about changing the value on the server side?
I was talking about how Slimmage changes the query string to specify the quality (on the client side).
It does send that to the server side, but I think what you are implying is that I set it somewhere else on the server side.
Perhaps you think I set the URL on the server side, which is true, but it's only half the story, as I realize that Slimmage overrides that quality setting. That's why I modified the JavaScript to retain that query string when Slimmage makes its subsequent request.
Also, keep in mind that I was testing by pasting the URL's with their appropriate quality parameters in the query string into new tabs and navigating to them directly. When I do that, it's perfectly clear that the format query string parameter is interfering with the quality query string parameter.
Perhaps this will make it more clear. Here's is what the image looks like at 5% quality with the "format=jpg" in the query string:
Notice how it does not look like it has been compressed to 5% quality. If I take out the "format=jpg" from the query string, here's what it looks like:
Notice that the image now has a bunch of compression artifacts, which is what should have happened.
I should not have to remove the format from the query string for the compression to work.
Yep, changing the order so format comes before quality does produce the desired results (i.e., the image compressed at the specified level).
I imagine this could be fixed either with Slimsy (by putting the query string in the expected order) or with ImageProcessor (by allowing the query strings to appear in any order). Not sure what the right solution is, but I suspect the easier fix would be with Slimsy (and perhaps a second fix with ImageProcessor for good measure).
Yeah, think this is a Slimsy issue really. But actually it goes a bit deeper in that the Umbraco GetCropUrl method doesn't have a explicit parameter for format (probably an oversight by me long ago) so Slimsy uses the furtherOptions parameter which comes after quality.
There still seems to be an issue with the quality parameter logic. The init settings we use in window.slimmage() limit the max jpegQuality to 55, but there are images that ignore this and have "quality=90" automatically included in their querystrings. This is devastating for our production environment because images are unpredictably getting served at over 4x what their filesize should be.
So far we haven't been able to determine what the root cause of this is, but we've had to workaround it by including our own quality parameter in every image request just to make sure it does exceed the maximum we specified.
Okay, so we determined that this scenario is being caused because the image we tagged for slimmage was contained within a parent container marked with display:table. The image width was reported as 0 or auto so it seems like slimmage does not actually process the image. The img tag only had a data-src attribute and no src. Still, having the quality=90 appended to the querystring parameters despite the init method jpegQuality seems dangerous.
Quality Parameter Ignored When Format is Specified (JPG by Default)
I added a slider in Umbraco so editors can choose the quality of their images. However, I just noticed that the quality is the same regardless of the setting. That is, if I set the quality to 90, I get a 130KB image. If I set the quality to 5, I get the same 130KB image. Here's an example URL (this one with a quality of 5):
http://localhost:50208/media/1008/slide1-2.jpg?center=0.52820512820512822,0.042510121457489877&mode=crop&quality=5&width=1280&heightratio=0.4847222222222222222222222222&format=jpg&slimmage=true&rnd=130984743580000000
After a bit of trial and error, I narrowed this down to the fact that the format is also specified in the URL. When the format is present, the quality parameter seems to be ignored, even when the format is a lossy one (i.e., JPEG). Adding this to the web.config seems to sidestep the issue:
When that is in the web.config, the format is not added to the query string, and the image is returned with the correct quality.
I'm not sure if the problem is with Slimsy or with ImageProcessor, but something is amiss.
Umbraco 7.3.4. Slimsy 1.1.6.
Hi Nicholas,
Slimmage will adjust the quality setting as long as it's present so it doesn't matter what you set it to server side (1 or 100).
You can adjust the values Slimmage uses, there are two settings jpegQuality & jpegRetinaQuality, they configuration options are detailed here.
Jeavon
Who said anything about changing the value on the server side?
I was talking about how Slimmage changes the query string to specify the quality (on the client side).
It does send that to the server side, but I think what you are implying is that I set it somewhere else on the server side.
Perhaps you think I set the URL on the server side, which is true, but it's only half the story, as I realize that Slimmage overrides that quality setting. That's why I modified the JavaScript to retain that query string when Slimmage makes its subsequent request.
Also, keep in mind that I was testing by pasting the URL's with their appropriate quality parameters in the query string into new tabs and navigating to them directly. When I do that, it's perfectly clear that the format query string parameter is interfering with the quality query string parameter.
Perhaps this will make it more clear. Here's is what the image looks like at 5% quality with the "format=jpg" in the query string:
Notice how it does not look like it has been compressed to 5% quality. If I take out the "format=jpg" from the query string, here's what it looks like:
Notice that the image now has a bunch of compression artifacts, which is what should have happened.
I should not have to remove the format from the query string for the compression to work.
I'm with you, for ImageProcessor I think that the format variable has to come before the quality variable, could you try that?
Yep, changing the order so format comes before quality does produce the desired results (i.e., the image compressed at the specified level).
I imagine this could be fixed either with Slimsy (by putting the query string in the expected order) or with ImageProcessor (by allowing the query strings to appear in any order). Not sure what the right solution is, but I suspect the easier fix would be with Slimsy (and perhaps a second fix with ImageProcessor for good measure).
Yeah, think this is a Slimsy issue really. But actually it goes a bit deeper in that the Umbraco GetCropUrl method doesn't have a explicit parameter for format (probably an oversight by me long ago) so Slimsy uses the furtherOptions parameter which comes after quality.
Working on a fix now :)
Ok, I think I've got it working. Would you be able to give it a try? v1.1.7.48 https://ci.appveyor.com/project/JeavonLeopold/slimsy/build/1.1.7.48
That seems to be working! Here's the URL I'm seeing now:
http://localhost:50208/media/1003/630x888-jpeg.jpg?crop=0%2c0.031531531531531536%2c0%2c0.30415642915642915&cropmode=percentage&width=640&heightratio=0.9363636363636363636363636364&format=jpg&quality=5&slimmage=true&rnd=130987936020000000
As expected with your fix, the format parameter now appears before the quality parameter.
That's great, I'll release v1.1.7 tomorrow! Thanks!
v1.1.7 released, thanks Nicholas!
Worked perfectly. My images are now just as crummy as I wanted them to be. Thanks!
There still seems to be an issue with the quality parameter logic. The init settings we use in window.slimmage() limit the max jpegQuality to 55, but there are images that ignore this and have "quality=90" automatically included in their querystrings. This is devastating for our production environment because images are unpredictably getting served at over 4x what their filesize should be.
So far we haven't been able to determine what the root cause of this is, but we've had to workaround it by including our own quality parameter in every image request just to make sure it does exceed the maximum we specified.
Okay, so we determined that this scenario is being caused because the image we tagged for slimmage was contained within a parent container marked with display:table. The image width was reported as 0 or auto so it seems like slimmage does not actually process the image. The img tag only had a data-src attribute and no src. Still, having the quality=90 appended to the querystring parameters despite the init method jpegQuality seems dangerous.
Let me know if I can provide more details! =)
If anybody is curious, that the quality parameter must appear after the format parameter in order for it to work is the intended behavior (i.e., not a bug, as far as ImageProcessor.Web is concerned): https://github.com/JimBobSquarePants/ImageProcessor/issues/436#issuecomment-233904866
is working on a reply...