Get Image Ratio Macro (v10.2)
I'm new to KM and this is my first ever upload, so it's pretty simple. I'm sure there are more efficient ways but better to get something working and tidy it up later, right?
For the image currently selected in Finder, it will give you the image ratio in a "Display Text Briefly" window.
Get Image Ratio.kmmacros (21 KB)
Super neat marco, I deal with image files all the time & will find this helpful!
Minor suggestion, to add in an "if then" condition for only image format
thanks for sharing
That's a great idea. Thank you for the feedback!
Another minor tweak -- reverse your logic. As it stands you have to do 9 tests for every image because you need "all of the following" to be true. If you change to "any of the following", make the tests all "is" (rather than "is not"), and switch round your "execute" and "otherwise" blocks then the "If..." condition will short-circuit on the first "true" test and KM won't have to do the others.
Extra points if you put your most commonly found ratios nearer the top of the conditions list, as that will be even more efficient!
I think you've got a ratio missing as you've no corollary to "1.6" but you have two "0.5625"s -- should one of those be "0.625"? Which throws up another possible optimisation -- if you don't care about the aspect of the image you could precede the "If..." action with another:
if pixratio < 1 then set pixratio to 1/pixratio
...and then you can cut the number of comparisons by half. (If you do care about the aspect you could use another variable and set nonaspectRatio to 1/pixratio or similar, then test nonaspectRatio.)
To reduce the size of that IF action you could just use this instead:
Except that would match eg 1.55. You could (I think) get round that with ^1.5$|^0.66666$|^1$... but that's messy and possibly a maintenance burden. Perhaps there's a cleaner regex?
Oops. Hadn’t thought of that so good catch! Yes - messy regex but the big IF can be problematical too as you showed earlier. Since there are only a limited number of standard aspect ratios once you’ve got it right maintenance should be minimal 
Nothing to do with whether a Switch Case or Regex Match is used to get these matches...
I'm just wondering if there is a fundamental problem with exactly matching a list like this which contains decimal places derived from a bit of maths. I.e. would not 1.33 or 1.33333333333 for all practical purposes be the same as 1.33333 if we are looking for standard image ratios?
You're right @Zabobon - the aspect ratios really need to be expressed as actual ratios or fractions rather than decimal numbers to be absolutely correct. To do that the image width and height should be factored out so that then the test becomes a collection of statements like "if width is 3 and height is 4", "if width is 4 and height is 3", etc.
I'm confused by what you mean.
1.55 is 1.5 -> false
1.55 matches 1.5 -> true
I also wondered about treating numbers as text, as well as the precision employed. For example, be only one pixel out on a 10,000 by 15,000 pixel image and 10000/15000 = 0.6666222252 -- "not standard" by the macro's rules. IMO the answer would be force to a certain precision, for example, setting pixratio with:
%CalculateFormat% pixwidth/pixheight % 0.### %
...then use is= (or is!=) in the conditions to treat everything as numbers.
@kixx, I think you need to ponder the precision required!
Yes, maybe If either of these is true
Height is (Width ÷ 3) x 4
Width is (Height ÷ 3) x 4
Sorry, picking out 1.55 was a bad choice as by total coincidence it looks like a recurring decimal. All I meant was that there needs to be a mathematical test rather than simply matching a text string.
Gotcha.
Text matching is fine for an (in)equality test, as long as we fix the number of characters -- it doesn't really matter if you do 1.555 is 1.555 or 1.555 is= 1.555 (although I suspect that number comparison is faster than text comparison).
But I always have the feeling that numbers should be treated as numbers and text as text unless there's good reason to do otherwise...
Perhaps readability, maintainability, and concision are good enough reasons? Even stopping at two decimal places is +/-50 pixels in a 15,000 by 10,000 pixel image:
Image Ratio Test.kmmacros (4.2 KB)
I suppose it all depends what the purpose of this macro is. If it is to flag up image files that are not of standard dimensions then what are the margins of error, if any? Is it for aesthetic reasons that the files should match certain proportions or is there a delivery requirement that they should?
A 16:9 movie file, to pass a delivery standards test is not approximately 16:9 - it is 16:9 otherwise it would be rejected.
It does show how even programming what appears to be a simple task can reveal the task to be more subtle than it first seems 
Hey Guys,
1.5|0.66666666/1.6/1|0.75/1.33333333]0.5625/1.7777778|0.625
I haven't read everything carefully, but I think you've missed something here...
Remember – the dot is not a decimal point in a regular expression but a metacharacter for any character.
This has caused me some head-scratching more than a few times over the years, until I realized I'd gotten trapped in contextual thinking.
-Chris
Another gotcha! Yeah - you’d think I’d know better by now 
If you do it the other way round -- searching a list for the calculated ratio -- having the dot in the search pattern doesn't matter. The only positional match for the single "any character" is the decimal point in each line of the list (for any even remotely sensible ratios I've tried, at least).
Perhaps a problem being a problem is, itself, contextual? 
