Ok, so I'm 90% sure that this is a feature :-) But let's check, if you inspect the image what is the display dimensions (example below)?

Hmmmm its really strange.

I'm pretty sure it worked in some areas of the site the other day.
Now all images from slimsy are 160 pixels wide.
No matter how they are called (GetResponsiveCropUrl / GetResponsiveImageUrl) or where they are placed...

Ok, i found the problem!

I had a 

div:empty {
   display: none;
}

in my css. That aparrently messes with the image scaling...

Ok perfect, so yes this is Slimmage doing it's thing.

Slimmage watches the computed dimensions of your image and makes new requests for higher resolution images if the display size changes. For example, if your CSS was to change the size using percentages of the image to a point where it was larger then Slimmage would make a new request for a 360x360 pixel image. If you were to look at this on a retina device it would also request a larger image to match the pixel density (example of same image as above on Nexus 10 below).

Does that make some sense?

Yes absolutetly, it makes perfect sense.

Why the css

div:empty {
   display: none;
}

Would make all images from slimage, and only from slimage, 160pixels wide makes no sense though...

It is probably doing something to the computed size, when Slimmage is not able to find the computed size it will always display 160 which is the minimum. Have you tried on a different browser to see if it might be a browser specific issue?

Hello

Great package!

I'm using slimmage for slide images in a boostrap 3 carousel and faced this problem. The first slide image rendered correctly but all other slide images rendered at 160px width due to the container having display:none. The solution (if anyone is interested) was to call checkResponsiveImages when each slide is invoked. Here is my code:

$('.carousel').on('slide.bs.carousel', function () {
    window.slimmage.checkResponsiveImages(1);
});

Initially I was getting an when calling window.slimmage.checkResponsiveImages(1); and this was due to the settings file: slimmage.settings.js. Here is resets the window.slimmage object (window.slimmage = {verbose:true};) so it is undefined and I got this error "Uncaught TypeError: undefined is not a function".

Removing the reference to this slimmage.settings.js file fixed the problem.

@shanem

Thanks just what I was looking a solution to.

Jumping on board this topic as I too have a similar issue occuring with Slimsy within a Bootstrap site.

I have the following code:

I read a few previous posts about making sure that I had the latest Image Processor and ImageProcessor.Web so I installed the latest via Nuget - they are as follows:

Have the same issue as Hugh above? Anyone know if there are problems with bootstrap columns/rows and slimmage?

Is there a demo anywhere I could see? I think the issue is that the empty div that Slimmage creates to measure the computed size is being set to 0 by a stylesheet, that could be bootstrap...?

Unfortunately not. It's on my local machine, but I've had it before on other projects and never got the bottom of it. Do you not use Bootstrap? Here is a snippet of Html, nothing out of the ordinary.

                <div class="col-md-4 col-sm-6 col-xs-6 work-item-holder">
                    <div class="work-item">
                        <img src="@workItem.CoverImage.Url?height=263&width=361&mode=crop" height="263" alt="@workItem.MainHeading" data-slimmage="true" />
                        <div class="info">
                            <h3>@workItem.MainHeading</h3>
                        </div>
                        <span class="mask"></span>
                    </div>
                </div>​

As per Hugh's screenshot. The width and height are set, but when the page loads instead of it being 361px its 480 - The querystring values have been changed so we see @workItem.CoverImage.Url?height=263&width=480 in the chrome inspector?

Hi Lee,

We use ResponsiveBP instead of Bootstrap. The snippet above is not using Slimsy right?

I would to try to recreate the issue to see what's going on, what version of Bootstrap do you use?

Thanks,

Jeavon

Latest version of bootstrap. I thought slimsy was just a package for using slimmage with IP? Or have I missed something?

I've been debating with moving to ResponsiveBP for a while now!

I'd love to say that ResponsiveBP would solve your issue but it won't.

The increase in output image size is due to the way slimmage is using the device pixel ratio of your monitor to calculate the ideal output width of the image. See the last line below. This is being done in order to produce "retina quality images" but it comes at a great cost with regards to bandwidth.

s['getImageInfo'] = function (elementWidth, previousSrc, previousPixelWidth, previousElement) {
    var data = {
        'webp': s['webp'],
        'width': elementWidth,
        'dpr': window.devicePixelRatio || 1,
        'src': previousSrc, 
        'element': previousElement
    };
    //Determine quality percentage
    var high_density = s['webp'] ? 65 : s['jpegRetinaQuality'];
    var low_density = s['webp'] ? 78 : s['jpegQuality'];
    data['quality'] = data['dpr'] > 1.49 ? high_density : low_density;

    //Calculate raw pixels using devicePixelRatio. Limit size to maxWidth.
    var idealWidth = elementWidth * data['dpr']; 

Normally when upscaling images like this you would drop the quality down a long way so that the output size is not extreme. You would rely on the downscaling algorithm of the images in the browser to sharpen the image. Realistically you need a high quality image to start with also.

Slimmage by default doesn't seem to adjust the quality unless you set an initial &quality=val in your querystring:

if (k.match(/^quality/i)) { return d + "quality=" + data['quality']; }

I would adjust your output values by setting the parameter in your output and and also reducing the value of jpegRetinaQuality in the settings config in your JavaScript.

Personally I would be tempted to simply change.

'dpr': window.devicePixelRatio || 1,

So that it always returned 1 because the whole retina image thing was a horribly thought out idea from Apple since there was no way to detect the bandwidth, nor someone's data plan from the browser.

Ah, I think this particular issue was being caused by the height attribute on the img tag, for Slimmage, height and width must be determined by css and the height attribute causes warped computed sizing...

is working on a reply...