Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Jan 31, 2016 @ 01:30
    Nicholas Westby
    0

    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:

    <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.

    Umbraco 7.3.4. Slimsy 1.1.6.

  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 01, 2016 @ 13:08
    Jeavon Leopold
    0

    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

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Feb 01, 2016 @ 15:58
    Nicholas Westby
    0

    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.

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Feb 01, 2016 @ 17:59
    Nicholas Westby
    0

    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:

    not compressing

    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:

    correctly compressing

    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.

  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 01, 2016 @ 18:59
    Jeavon Leopold
    0

    I'm with you, for ImageProcessor I think that the format variable has to come before the quality variable, could you try that?

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Feb 01, 2016 @ 19:15
    Nicholas Westby
    0

    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).

  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 01, 2016 @ 19:26
    Jeavon Leopold
    0

    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 :)

  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 01, 2016 @ 19:43
    Jeavon Leopold
    0

    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

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Feb 01, 2016 @ 20:24
  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 01, 2016 @ 20:44
    Jeavon Leopold
    100

    That's great, I'll release v1.1.7 tomorrow! Thanks!

  • Jeavon Leopold 3005 posts 13196 karma points MVP 7x admin c-trib
    Feb 03, 2016 @ 15:17
    Jeavon Leopold
    1

    v1.1.7 released, thanks Nicholas!

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Feb 04, 2016 @ 03:46
    Nicholas Westby
    1

    Worked perfectly. My images are now just as crummy as I wanted them to be. Thanks!

  • Chris 47 posts 127 karma points
    Jul 12, 2016 @ 17:27
    Chris
    0

    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.

  • Chris 47 posts 127 karma points
    Jul 12, 2016 @ 20:58
    Chris
    0

    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! =)

  • Nicholas Westby 1950 posts 6608 karma points c-trib
    Nov 14, 2019 @ 17:33
    Nicholas Westby
    0

    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

Please Sign in or register to post replies

Write your reply to:

Draft