However, what seems to be happening is that the image is being cropped to the correct corner points, but the image is not resized to fit within 320 x 240
We have played around with the URL and can see that if you try and do a resize first. this correctly chains the commands together, but the example above that is produced by the Umbraco GetCropUrl function fails as described.
Can anyone else confirm that this is a problem with the Image Processor not correctly handling the chained resize process?
We are using the latest version of Image Processor.
There's something iffy about your url though as far as I can see. Umbraco should be generating a url that uses mode=crop not using the crop method. What version of Umbraco are you using?
Ah actually default mode is pad, but because the width and height were also used to create the coordinates it will be an exact fit, so I wonder if Jose/Chris have changed the size of the crop pre-value after the coordinates were set, that would explain it....
That said it would probably make sense for mode=crop to be appended to predefined crops instead of defaulting to pad...
No, we've not changed the pre-value's, they have been the same since the property was created.
On our local server ( with the main issue ) it is doing the crop, but not resizing at all, so in comparison to the other URL I posted, we are seeing the equivalent of this one:
I thought it might be worth me confirming what we thought this should do as I don't think the mode=crop is actually able to do what we need (unless I miss read the docs!)
We have a large image in Umbraco with multiple pre-defined crops, so for example we could zoom an image in the back office and crop around a specific person in a group photo.
From what I can see this is then output in the above statement as two x,y points based on percentages.
This image should then be cropped to this aspect ratio and subsequently resized to the defined size which in this case is 320 x 240
It seems to be doing the cropping correctly, but the resizing is not happening for us. We can't see anything else in our solution that could be preventing this from working.
Yes, resizing works fine on it's own, it's only not working when it is chained AFTER the cropping. If you try and put the width & height settings before the cropping it processes both... but of course you end up with an image smaller than the required size.
Can you delete the cache and do a full clean and rebuild with the site that the resize is failing on? I do recall an issue with earlier versions due to a regex issue. That's long fixed now but I'm wondering if the solution is still somehow holding on to the incorrect binaries.
I'd also go into the packages folder and remove any old ones to see if VS complains.
If you look at the response headers in Chrome for the image request you should be able to see exactly which version of ImageProcessor.Web is running. I add a header in there to help diagnose issues.
E.g ImageProcessedBy:ImageProcessor.Web/4.3.6.0 is the version running in qvoffices.
Thank you for your help with this issue, James has hit the nail on the head. The issue was even though we had upgraded ImageProcessor with NuGet the solution still had the old versions of the DLL's.
After manually updating the DLL's and deleting the Cache it is now working as expect :)
Watch out for a new website coming soon with nicely resized Images :)
Image Cropper crops but does not resize.
We are trying to use the following statement on our page:
This creates the following URL:
However, what seems to be happening is that the image is being cropped to the correct corner points, but the image is not resized to fit within 320 x 240
We have played around with the URL and can see that if you try and do a resize first. this correctly chains the commands together, but the example above that is produced by the Umbraco GetCropUrl function fails as described.
Can anyone else confirm that this is a problem with the Image Processor not correctly handling the chained resize process?
We are using the latest version of Image Processor.
Thanks in advance :)
Hi Jose,
By latest version do you mean v2.3.0 and v4.4.0?
This image requested from my website is using those versions and ImageProcessor is definitely working correctly given those parameters.
There's something iffy about your url though as far as I can see. Umbraco should be generating a url that uses
mode=cropnot using thecropmethod. What version of Umbraco are you using?We're using the same version and Umbraco version 7.2.6.
I could try to upgrade to version 7.2.8 if you think this might help?
Thanks for your help.
I don't think it will. My website is running 7.2 beta
Do you have any value converters installed or other plugins. That generated url is definitely not correct.
Hey James,
I'm not sure if we do add mode=crop on predefined crop urls, has that always been a requirement or did it change at some point?
Cheers,
Jeavon
Ah actually default mode is pad, but because the width and height were also used to create the coordinates it will be an exact fit, so I wonder if Jose/Chris have changed the size of the crop pre-value after the coordinates were set, that would explain it....
That said it would probably make sense for mode=crop to be appended to predefined crops instead of defaulting to pad...
Hi Jeavon,
No, we've not changed the pre-value's, they have been the same since the property was created.
On our local server ( with the main issue ) it is doing the crop, but not resizing at all, so in comparison to the other URL I posted, we are seeing the equivalent of this one:
https://www.qvoffices.com/media/1135/cmhlu4kwcaa8bksjpg-large.jpg?crop=0.51976037528003671,0.44302105380416629,0,0&cropmode=percentage
Cheers, Chris
Oh, I always thought it was... My bad, if not.
Without it just means it defaults to pad, hence the black boarders, I don't think it's related to this issue anyhow :)
Hi All,
I thought it might be worth me confirming what we thought this should do as I don't think the mode=crop is actually able to do what we need (unless I miss read the docs!)
Docs: http://imageprocessor.org/imageprocessor-web/imageprocessingmodule/resize/
We have a large image in Umbraco with multiple pre-defined crops, so for example we could zoom an image in the back office and crop around a specific person in a group photo.
From what I can see this is then output in the above statement as two x,y points based on percentages.
This image should then be cropped to this aspect ratio and subsequently resized to the defined size which in this case is 320 x 240
It seems to be doing the cropping correctly, but the resizing is not happening for us. We can't see anything else in our solution that could be preventing this from working.
Cheers,
Chris
Hi Chris,
So you are saying there is no resize so you are seeing a full size but cropped version of the original image?
Jeavon
Hi Jeavon,
Yes that's correct, it's strange, I have just tried the same parameters on another site and it does seem to be resizing... the plot thickens...
https://www.qvoffices.com/media/1135/cmhlu4kwcaa8bksjpg-large.jpg?crop=0.51976037528003671,0.44302105380416629,0,0&cropmode=percentage&width=320&height=240&rnd=130874864950000000
I am guessing the black bars are just because the original source image I am using in this test is not the same aspect ratio as the original one.
Cheers, Chris
Hi Chris,
That is odd, does it resize if you strip the querystring down to
?width=320Jeavon
Hi Jeavon,
Yes, resizing works fine on it's own, it's only not working when it is chained AFTER the cropping. If you try and put the width & height settings before the cropping it processes both... but of course you end up with an image smaller than the required size.
Cheers, Chris
Odd, so it's working on the qvcoffices URL you posted though but not somewhere else...
Any chance something else is intercepting and stripping out the width or height or both...
Hi Chris,
Can you delete the cache and do a full clean and rebuild with the site that the resize is failing on? I do recall an issue with earlier versions due to a regex issue. That's long fixed now but I'm wondering if the solution is still somehow holding on to the incorrect binaries.
I'd also go into the packages folder and remove any old ones to see if VS complains.
If you look at the response headers in Chrome for the image request you should be able to see exactly which version of ImageProcessor.Web is running. I add a header in there to help diagnose issues.
E.g ImageProcessedBy:ImageProcessor.Web/4.3.6.0 is the version running in qvoffices.
Hi James,
We just checked the headers and sure enough it is using an older version of the DLL:
ImageProcessedBy:ImageProcessor.Web/4.2.1.0
I also checked the QV Offices site and that is using:
ImageProcessedBy:ImageProcessor.Web/4.3.6.0
I will try what you have suggested and post an update shortly.
Cheers, Jose
Hi All,
Thank you for your help with this issue, James has hit the nail on the head. The issue was even though we had upgraded ImageProcessor with NuGet the solution still had the old versions of the DLL's.
After manually updating the DLL's and deleting the Cache it is now working as expect :)
Watch out for a new website coming soon with nicely resized Images :)
Cheers, Jose
Brilliant!
Excellent! Glad you got it sorted.
I dunno why VS doesn't update the dll's sometimes. A clean/rebuild usually sorts thing though.
is working on a reply...