All images resized to 533×300, ignoring Imsanity's Settings page

hmm that’s a weird one. if you have an image you can post somewhere to use as a test I can check it out next week.

Imsanity uses the meta table to query for large files during the bulk resize. but during the upload and resize process, imsanity only writes to the meta table – it doesn’t use that to determine the image size.

imsanity actually uses an PHP function getimagesize which looks like it may internally read EXIF data, but it’s not written in the manual how that function works. If getimagesize returns the wrong image size, then that would explain why imsanity and any other resize plugins or PHP code would produce the same incorrect size. Because PHP is being fooled about the image size.

That’s just a guess, I don’t know for sure. I haven’t been able to reproduce it myself yet.

That’s fantastic support response ?? Thanks!

Seemed interesting to me, too. Unfortunately the exact images we’re using have regular copyright terms. However, here’s an image from Wikipedia with a free to share copyright:

1024px-Hdpe_pipe_installation.jpg (JPEG Image, 1024?×?720 pixels)
https://upload.wikimedia.org/wikipedia/commons/thumb/5/53/Hdpe_pipe_installation.jpg/1024px-Hdpe_pipe_installation.jpg

You can confirm copyright status here:
https://en.wikipedia.org/wiki/File:Hdpe_pipe_installation.jpg

Note, though, that for whatever reason with the above image Imsanity is now resizing to 426 × 300, instead of the previous 533 x 300.

Nothing has changed in the configuration, except for the different image, and having deactivated Imsanity to test the other plugins, and then reactivating Imsanity just now.

When Imsanity was activated again no settings on the Imsanity Settings page had been preserved, so they were all back at the default 1024.

All three settings were set back to 730 x 300 (same as before) and then the above file was uploaded and deleted several times, each time being resized to 426 × 300.

This certainly makes it seem like my earlier hunch, that at least the width is being derived dynamically somehow, may have merit.

Just as before a full search of the entire MySQL database showed that wasn’t where Imsanity was getting the 533px width, ditto here. In fact, the number 426 only appears three times in the entire database — as a substring within two larger numbers, and in table wp_postmeta as one meta_id entry.

FYI, during the previous testing a full backup of everything was made first, per your excellent recommendation, and as we would always do anyway, and the “Bulk Resize Images” feature was used.

ALL images were resized to 533 x 300, so there is no way that Imsanity could have been getting the 533px width from EXIF data. We then restored the entire WordPress install to its previous state. I didn’t do that again here. But my guess is that if “Bulk Resize Images” were to be run now, it would resize all images to 426 × 300.

In case there is some magical math at work here (and Imsanity is somehow deriving the width by scaling), the previous test image was/is 1120 x 630, which Imsanity resized to 533 x 300 (as with all other images) every time. The other images were all completely different sizes, but Imsanity resized all images to 533 x 300, whether uploaded individually or processed using Bulk Resize Images.

The above image from Wikipedia is 1024 × 720 and resizes to 426 × 300.

Hmmm… Just tested the original test image again, the one that is 1120 x 630, and it’s resizing it to the same 533 x 300 as before.

More testing results…

Another (different) image that happens to be the exact same size as the main 1120 x 630 that has been used for testing, resizes to the exact same 533 x 300.

And two other completely different images, different sizes, yield the below results:

866 x 574 –> 452 × 300
1120 x 768 –> 437 × 300

FYI, the EXIF data on all of the aforementioned images is exactly the same as the stated original image size, and not the size that Imsanity is resizing to. So, again, it can’t be getting it from the EXIF data.

This is really continuing to make me think the new width is being derived somehow from scaling the original width.

But the strangest part of all of this is that when Bulk Resize Images was run it resized ALL of the images to 533 x 300, even though the images were of all different assorted sizes.

Though not 100% positive, because at the time Bulk Resize Images was first run there was no awareness or expectation of this issue, thus I wasn’t in troubleshooting, bug-hunting mode paying attention to every detail. But it’s pretty sure that the original 1120 x 630 image was the last image that had been uploaded to the Media Library and that was showing at the top of the Media Library list. Maybe it’s possible that Imsanity derived the resize dimension (533 x 300) based on that first image, and then applied it to all remaining images?

Hopefully this gives you enough to go on to track down the mystery of where Imsanity is deriving the resize width from?

For whatever it’s worth, if we end up being able to use this plugin, more than happy to make a donation.

Thanks again.

Missed the tree for the forest ?? As I should have realized even before finishing that last post that what is happening here is that the images are being scaled based on the height, and not width — whereas I’ve typically seen width as the default that images are usually scaled on.

All three settings on the Imsanity Settings page are set to 730 x 300.

Does Imsanity default to scaling based on width, or height?

Thanks again.

Not sure if you felt the “mystery” issue was solved by the second post, or the third. But it’s certainly solved by now. And would have to be chalked up 100% to the user thinking the “Max width/height” settings on the Imsanity Settings page work differently than they do, user error, having worked too many hours, or possibly all three ??

Had also just been working with a command-line image resizer where only one dimension (width) is specified, which probably didn’t help. Have scaled and resized plenty of images, so not sure how the obvious got overlooked, except for the reasons already stated.

Obviously with a 4.9 out of 5 star rating not too many users are making that same mistake. But, just a suggestion: On some of the other plugins (not all for WordPress) the author and/or documentation includes an explanation (or reminder, depending on how one looks at it) of what actions are taken by the software based on the Width/Height settings. One even states the results may not be what the user expects, which is what happened here, though I did and should have already known. But, just in case you get that .1 user who may have happened to put in too many hours at the keyboard before submitting a support request for a non-existent issue, the reminder might just come in handy! ??

5-star rating and review submitted!

And on your website you specify that you wish for donations to go to smiletrain.org, which I will be doing. Truly looking forward to using your plugin, as it saves a ton of time!

Sorry for the wild goose chase, but thanks again for the great plugin and great support!

aha! wow, thanks for the extremely thorough debugging!

I’ve run into the size thing before and it probably merits either a little hint/tip text by the setting or perhaps even a “recommended setting” with only one value. I personally just set both values to 1024. But if you do adjust those settings for landscape – then imsanity will aggressively scale on a portrait image and vice versa. Being that the point is to reduce file sizes, it probably makes the most sense to just use one value.

I’m glad to hear about giving to SmileTrain – it feels good!

Just my two-cents worth is that having only one field for the pixel dimension on the Imsanity Settings page would eliminate any possibility of confusion.

It would then be clear that the “Max width/height” dimension applies to both the “Max width” and “Max height”. And no hint/tip text would be needed.

Currently the second field really serves no purpose. Or, perhaps you’ve thought of an “Ignore Aspect Ratio” checkbox next to the existing Width / Height fields, and adding that capability, which is what I (mistakenly) thought the two fields meant ??

Made a donation to Smile Train, but their “How did you hear about us?” dropdown offers no “Other” option or way to tell them who referred the donor (unless you make it a “Tribute”). Otherwise I would have put in your name.

And I also made sure to click the “Works” button on the main WordPress Imsanity page.

Thanks again for the great plugin and support. And hope you have a great weekend!

I’m a little confused here.
If I want to only rescale / resize images that are larger than 550px, down to 550 and keep the aspect ratio, does this mean Imsanity can’t do that?

I was confused, also, which was what prompted me to open this support thread.

The confusion was being under the (incorrect) impression that since two fields are provided, in the absence of a keep or ignore Aspect Ratio option Imsanity was ignoring the aspect ratio and scaling to exactly the dimensions provided. But by default it is indeed keeping the aspect ratio, which seems to be what you want, and is probably default behavior in most software.

In a way, the behavior of the two provided fields,”Max width/height”, is obvious, but it’s also easy for it to confuse. Because, unless I’m really missing something, Imsanity (like most software) is going to scale to the smaller of the two dimensions (if the original image exceeds it).

That’s why the software installs with both fields “Max width/height” set to the same number, 1024, instead of something like 1024×768. Because if you put in “Max width/height” 1024×768 and the height of 768 is exceeded, there is no way to predict what the width is going to be after it gets scaled. The height will be no greater than 768, but the width could end up being any number really, as long as it’s no greater than 1024.

That’s why the software puts the same number in both fields, and the author says he just leaves it that way, so that it’s less confusing.

My two cents is still that having just one field for BOTH “Max width/height” would be the least confusing of all ?? Unless, of course, an “Ignore Aspect Ratio” option is added, so that the second field actually serves a purpose.

Haha I’m still confused ??
So in my case where I only want to locate and rescale images larger than 550px width and not worry about the height, am I looking at values such as 550/99999 or is this wrong?

hehe, wpcms_user gave a very accurate assessment of the issue, but the simple answer is just set both values to 550 and the plugin will do exactly what you want.

The reason it can be confusing is because the settings page might indicate you should enter different values for height/width in order to fit a certain ratio – for example a landscape image. But if you do that then it will work perfectly for landscape images, but when you upload a portrait oriented image it will most likely resize it smaller than you had intended.

oh, wait sorry.

yes if you don’t ever care how tall an image is but you want them to always be width of 550, then you could set the max width to 550px and max height to 999999px (or any really high number). This would do the trick and always give you a consistent width regardless if the original was a portrait or landscape oriented image.

I knew there was a reason had those as separate values… hehe

Hey thanks Jason
The image resizing works a treat.
The kicker for me, it seems, is that the dimensions are hard coded in the post to the larger and maybe due to captions.
It just gets more difficult hahaha