Furthermore the original image size is 540 x 720 px and with the core Image Cropper I have defined an Image Crop with the size 220 x 220px with the alias "normal".
With the core GetCropUrl method I got an image size og 220 x 220 px, but when I use GetResponsiveCropUrl method the crop is upscaled to 1286 x 1286px. In my opinion it should be scaled larger than the original size?
Considering I wrote them both you would think they would be consistent, however I think we got the Core one wrong and it should have been the same as Slimsy but it was too late to change once it's in there!
I think it makes sense like this because of the overload options:
GetResponsiveCropUrl(cropAlias)
GetResponsiveCropUrl(cropAlias,propertyAlias)
Opposed to
GetCropUrl(cropAlias)
GetCropUrl(propertyAlias, cropAlias)
Totally agree on the up-scaling, I will adding upScale:false to all Slimsy methods in the next version of Slimsy, thanks!
Yes okay.. I just wondering if there was specific reason, but one just have to be aware of this if changing from the core methods to the ones in Slimsy.
Is it because of the upscale Slimsy in my case scale it larger than the specified crop size?
Ok, well with responsive imaging your 220x220 actually only determine the ratio (except in the case of a user with no JS). So in your case your ratio is 1:1. Now Slimmage will adjust the actual image size by using the calculated size in the DOM (to the nearest 160 pixels) also taking into account pixel density of the device. So you need to ensure that your image element is being sized correctly by CSS styles and in percentages, Slimmage will take care of the rest. Also make sure that you have included slimmage.js in your template and it is loading correctly.
If you would like to see a good example have a look at the slider image in the homepage here and how it's sized with CSS percentages.
Okay, so the css style define the max-width you want to use.. ? .. or the different widths at each breakpoint.
I'm not sure if it's because of the upscale, but with a defined crop size of 220 x 220 and I get 1286 x 1286 px as output.. and because the original size or the image on 540 x 720 px, it's becomes a lower quality..
Yep, use different widths at break points or make it fluid.
You're right on the over sizing, it's largely pointless and I will change it in the next version.
You could do <img src="GetResponsiveCropUrl(cropAlias, propertyAlias)&upscale=false"/> in the meantime
It's true to say that you most likely won't see the original image size in your crop unless you turn off JS. These dimensions are used to calculate the image ratio and for the no js fallback.
and adding this in the css I get max 220 px (as I would max use this size).
.profile-photo {
max-width: 220px;
}
The crop url from Slimsy look like this: /media/1001/bjarne.jpg?crop=0.093726494922903414,0.066769109627679624,0.078894791274914708,0.31269685502068395&cropmode=percentage&quality=90&width=320&heightratio=1&slimmage=true&rnd=130525887470000000&upscale=false
where the width parameter has a value of 320 .. in the url I can change the value to 220 and I get pretty much the same crop as when using the core method.
can I change the value with GetResponsiveCropUrl) method? if I add &width=220 after &upscale=false it's just added to the end of the url, but the other width=320 still exists and the crop is generated from this value. Because the image at 320 x 320 px is 15,3 KB and the one on 220 x 220 is only 9,13 KB (same size as the 220 x 220 I get from the core crop method) .. and I don't need to load a larger image than needed :)
The core crop method does also have an overload to specify width, height, quality, property alias where it doesn't use crop alias otherwise it use the sizes from the specified crop.
It confuse me a bit that GetResponsiveCropUrl() method doesn't use the specified crop size, here 220 x 220 and instead returns 320 x 320.
It's not actually the Slimsy method that's changing it here if you view source it will be 220, it is Slimmage that is changing the width parameter, this is what makes it adaptive responsive, by default it steps every 160 pixels which is why you are seeing 320. If you were to use a iPad it would request 640 to display in 320 due to the pixel density of the iPad being 2.
You can change the default step of Slimmage if you really want to, I will find that and post it for you later as I don't gave it to hand. It's set to 160 as that means you would roughly only have 5 size requests per image to be cached server side, so be aware that reducing it will mean more server side resizes maybe be generated and cached.
I just use css media queries and it will still only load the crop size of 220 x 220 px? or will Slimsy take over and load the generated 320 x 320 crop?
Ok, let me see if this makes sense. Imagine you have the following sizes of a single image on the server 160, 360, 480, 640, 800 (the multiple of which is determined by the widthStep setting). Slimmage.js job is to look at your media queries and request the size that is equal to or above the size you want to display based on your media query.
So if you change the widthStep to 100 you would have 8 server side images, compared to a widthStep of 160 having 5 server side images. Slimmage is going to be able to request a closer sized image to what you want with 8, but you need to weigh this up against having 8 images on the server compared to 5 for every image on your website.
Of course we have ImageProcessor generate either the 8 or 5 resizes but still the cached versions of these are stored on the server requiring disk space.
Signature of crop method
Is there any reason why not keeping the signature of the crop method simular to the core method for getting an image crop with Image Cropper?
E.g. I had this with the core method:
<img src="@Model.Content.GetCropUrl("profilePhoto", "normal")" alt="" class="profile-photo" />With Slimsy I should change it to:
<img src="@Model.Content.GetResponsiveCropUrl("normal", "profilePhoto")" alt="" class="profile-photo" />Furthermore the original image size is 540 x 720 px and with the core Image Cropper I have defined an Image Crop with the size 220 x 220px with the alias "normal".
With the core GetCropUrl method I got an image size og 220 x 220 px, but when I use GetResponsiveCropUrl method the crop is upscaled to 1286 x 1286px. In my opinion it should be scaled larger than the original size?
/Bjarne
Hi Bjarne,
Considering I wrote them both you would think they would be consistent, however I think we got the Core one wrong and it should have been the same as Slimsy but it was too late to change once it's in there! I think it makes sense like this because of the overload options:
Opposed to
Totally agree on the up-scaling, I will adding upScale:false to all Slimsy methods in the next version of Slimsy, thanks!
Jeavon
Hi Jeavon
Yes okay.. I just wondering if there was specific reason, but one just have to be aware of this if changing from the core methods to the ones in Slimsy.
Is it because of the upscale Slimsy in my case scale it larger than the specified crop size?
/Bjarne
Hi Bjarne,
Ok, well with responsive imaging your 220x220 actually only determine the ratio (except in the case of a user with no JS). So in your case your ratio is 1:1. Now Slimmage will adjust the actual image size by using the calculated size in the DOM (to the nearest 160 pixels) also taking into account pixel density of the device. So you need to ensure that your image element is being sized correctly by CSS styles and in percentages, Slimmage will take care of the rest. Also make sure that you have included slimmage.js in your template and it is loading correctly.
If you would like to see a good example have a look at the slider image in the homepage here and how it's sized with CSS percentages.
Please let me know if this makes sense or not?
Jeavon
Okay, so the css style define the max-width you want to use.. ? .. or the different widths at each breakpoint.
I'm not sure if it's because of the upscale, but with a defined crop size of 220 x 220 and I get 1286 x 1286 px as output.. and because the original size or the image on 540 x 720 px, it's becomes a lower quality..
In the example you linked to this image http://www.keuco.co.uk/media/1053/emotional1.jpg?center=0.31333333333333335,0.71573604060913709&mode=crop&quality=90&width=800&heightratio=0.76171875&slimmage=true&rnd=130431731150000000 has a size of 800 x 609 px... won't it be a lower quality than the original image: http://www.keuco.co.uk/media/1053/emotional1.jpg which is a bit smaller (742 x 565 px) ?
Am I wrong, when I would expect the image from GetResponsiveCropUrl() method to return to the image size of the defined crop?
/Bjarne
Yep, use different widths at break points or make it fluid.
You're right on the over sizing, it's largely pointless and I will change it in the next version.
You could do
<img src="GetResponsiveCropUrl(cropAlias, propertyAlias)&upscale=false"/>in the meantimeIt's true to say that you most likely won't see the original image size in your crop unless you turn off JS. These dimensions are used to calculate the image ratio and for the no js fallback.
Jeavon
Thanks for your explanation and the insight..
So with the core method this returns the defined crop size of 220 x 220 px:
<img src="@Model.Content.GetCropUrl("profilePhoto", "normal")" alt="" class="profile-photo" />and with Slimsy a crop of 320 x 320 px (larger than the crop defined, but not larger than the original size 540 x 720 px)
<img src="@Model.Content.GetResponsiveCropUrl("normal", "profilePhoto")&upscale=false" alt="" class="profile-photo" />and adding this in the css I get max 220 px (as I would max use this size).
.profile-photo { max-width: 220px; }The crop url from Slimsy look like this:
/media/1001/bjarne.jpg?crop=0.093726494922903414,0.066769109627679624,0.078894791274914708,0.31269685502068395&cropmode=percentage&quality=90&width=320&heightratio=1&slimmage=true&rnd=130525887470000000&upscale=false
where the width parameter has a value of 320 .. in the url I can change the value to 220 and I get pretty much the same crop as when using the core method.
can I change the value with GetResponsiveCropUrl) method? if I add &width=220 after &upscale=false it's just added to the end of the url, but the other width=320 still exists and the crop is generated from this value. Because the image at 320 x 320 px is 15,3 KB and the one on 220 x 220 is only 9,13 KB (same size as the 220 x 220 I get from the core crop method) .. and I don't need to load a larger image than needed :)
The core crop method does also have an overload to specify width, height, quality, property alias where it doesn't use crop alias otherwise it use the sizes from the specified crop.
It confuse me a bit that GetResponsiveCropUrl() method doesn't use the specified crop size, here 220 x 220 and instead returns 320 x 320.
/Bjarne
Hi Bjarne,
It's not actually the Slimsy method that's changing it here if you view source it will be 220, it is Slimmage that is changing the width parameter, this is what makes it adaptive responsive, by default it steps every 160 pixels which is why you are seeing 320. If you were to use a iPad it would request 640 to display in 320 due to the pixel density of the iPad being 2.
You can change the default step of Slimmage if you really want to, I will find that and post it for you later as I don't gave it to hand. It's set to 160 as that means you would roughly only have 5 size requests per image to be cached server side, so be aware that reducing it will mean more server side resizes maybe be generated and cached.
I hope this is beginning to make some sense?
Jeavon
If you are using the slimmage.js shipped with Slimsy, within your configuration (either on page or bundled) you can do this:
Okay, sorry if I misunderstood some of it Jeavon..
You're the img data-src is 220px and src is 320px:
So if these adjustments:
I just use css media queries and it will still only load the crop size of 220 x 220 px? or will Slimsy take over and load the generated 320 x 320 crop?
Ok, let me see if this makes sense. Imagine you have the following sizes of a single image on the server 160, 360, 480, 640, 800 (the multiple of which is determined by the widthStep setting). Slimmage.js job is to look at your media queries and request the size that is equal to or above the size you want to display based on your media query.
So if you change the widthStep to 100 you would have 8 server side images, compared to a widthStep of 160 having 5 server side images. Slimmage is going to be able to request a closer sized image to what you want with 8, but you need to weigh this up against having 8 images on the server compared to 5 for every image on your website.
Of course we have ImageProcessor generate either the 8 or 5 resizes but still the cached versions of these are stored on the server requiring disk space.
Make sense?
Thanks for the detailed explanation Jeavon :) It makes more sense now..
I would just have to specify in the media queries the image size I need, in this case 220px so I don't get an image displayed with a width of 320px.
/Bjarne
Yes, exactly. Ensure CSS is sizing your image and let the rest happen automatically.
is working on a reply...