How to display aspect ratio (or other calculated values)

[ubacher]

I would like to display the aspect ratio on my thumbnail.  (Image Width/Image Height)
I could not find a way to calculate/display this - although it is surely possible in an app.

This is actually just one instance of various calculated information one might want to display.

Is there a way to do this or should I add a feature request?

Background: When I have various images to select from and I need to fill a space with a
given aspect ratio I would select based on the best matching aspect ratio.

[Mario]

You can display all data that is accessible via a variable in the file window.

[ColinIM]

Hi ubacher,

I've been doing exactly this (displaying image aspect ratio) on my Thumbnail panel for a while using the File.AspectRatio variable.
(See the screen-grab below which shows my ratios in cyan colour).

In my Edit Layouts ... dialogue I'm using this Custom Template formula for the Footer 4 Right corner of each thumbnail:

Code Select Expand

{File.AspectRatio|replace:-1.#J:1==-:-}

I've added the extra "replace:" formatting function as a work-around for a strange value returned for non-image files by the File.AspectRatio variable! For all non-image files, the File.AspectRatio variable should logically return a value of 0 ... and this is what's declared on the "Variables" page in IMatch Help.  But on my setup here (IMatch 5.1.14 on Windows 7 x64) I get this strange value returned instead:

Code Select Expand

-1.#J:1

My 'replace' parameter on the File.AspectRatio variable gives me a neat unobtrusive -:- on non-image file thumbnails instead of the odd "-1.#J:1" which was showing before.

(I think this "-1.#J:1" value might be a bug, but I'll wait for Mario to confirm this before I raise a Bug Report. I'm not yet certain whether I need to use some other subtle variation on File.AspectRatio in this context?  Also my instinct is that the Variables Help page is not wrong when it says that File.AspectRatio will (should) return '0' for non-text files, therefore I won't be sending Mario a semi-automated Help Page erratum on this, unless I learn later that there IS actually a good reason why I'm getting this odd "non-image" value here! (Although I think it's unlikely)    )

Happily(?) this odd value of  "-1.#J:1"  is consistently returned for all the non-image files I've tried so far; and I've tested multiple files having these extensions:

.txt
.dop
.html
.pdf

Note that a PDF file can have one or more embedded image(s), and when IMatch is able to extract an image from a PDF to use as the thumbnail for that file then the File.AspectRatio variable happily returns the X/Y ratio for that same thumbnail image.

This concludes my reply to your general query ubacher ...

... but - as we're here in the General Discussion board - I'll continue with a gripe about the non-ideal results shown by this File.AspectRatio variable whenever the image X/Y ratios fall around the 1.40:1  to 1.42:1 region. In other words, around the 1.414:1 ratio upon which the European-popular ISO 216 paper sizes (and often print-paper sizes) A3 / A4 / A5 etc. are based.

As a quick summary: I had hoped that the File.AspectRatio variable would show "7:5" or "1.41:1" whenever my image X & Y ratios are close to the 1.414:1 ISO 216 ratio values, but instead - for a span of ratios around 1.4:1 which is much much too wide - this variable will only show these sub-sets of (otherwise really clever and laudable) simplified (distilled?, fuzzy-logic?)  human-friendly values:

1. When our image X(width) divided by Y(height) ratios span actual values between 1.300:1 and 1.400:1 inclusive,
(for example with an image of 1,398 pixels wide by 1,000 pixels high, and scaled multiples thereof)
this File.AspectRatio variable shows a result of "4:3".

2. When our image X / Y ratios span actual values between 1.401:1 and 1.404:1 inclusive,
the File.AspectRatio variable shows a result of "1.40:1". (This is OK IMHO)

3. When our image X / Y ratios span actual values between 1.405:1 and 1.409:1 inclusive,
the File.AspectRatio variable shows a result of "1.41:1".
(This is also acceptable IMHO, even though the displayed value is rounded up from any of these actual X / Y ratios.)

4. BUT, when our image X / Y ratios span actual values between 1.41:1 and (a remarkably high value of) 1.7:1 inclusive,
the File.AspectRatio variable shows a result of "3:2" throughout this range.

(I synthesized a bunch of quick .PNG files of different sizes to test how this algorithm responded.)

On item 4, that span of X/Y ratio values for which File.AspectRatio returns "3:2" is far far too wide IMO.

Example images for which "3:2 is reported would be:

a. An image 1,410 pixels wide by 1,000 pixels high (with an actual X/Y ratio of 1.41:1 of course) is shown as 3:2

b. (scaled-up by 2) An image 2,820 pixels by 2,000 pixels is shown as 3:2,

all the way up to ...

c. An image 1,700 pixels by 1000 pixels (having an actual X/Y ratio of 1.7:1 of course) is also shown as 3:2.

Of course I don't know how this algorithm works in detail, and i don't know how 'accessible' it might be for you (Mario) to modify or to adapt, but if perhaps the algorithm isn't locked solidly out of your (programming) reach then I'd be happy to add this as a low priority Feature Request.

Colin P.

[attachment deleted by admin]

[Mario]

(I think this "-1.#J:1" value might be a bug,

Fixed for 5.1.16. IMatch now returns 0 if it cannot derive/find an aspect ratio.
I've modeled the aspect ratio variable based on common values we encounter with normal cameras and other imaging devices, and to return the same values as other applications:

1:1
6:7
5:4
4:3
3:2
16:9

It may not cover all fringe cases, but so be it. A user can always calculate a "better" aspect ratio value in a script and store it somewhere in the metadata or a custom Attribute.

[ubacher]

Thank you Colin!
My mistake was to only search metadata for "aspect" and  "ratio" . Did not think of searching for variables.

I can confirm the strange value returned for non-image files.

[sinus]

Of course I don't know how this algorithm works in detail, and i don't know how 'accessible' it might be for you (Mario) to modify or to adapt, but if perhaps the algorithm isn't locked solidly out of your (programming) reach then I'd be happy to add this as a low priority Feature Request.

Colin P.

Hi Colin

BTW: I am always astonished (since years ) how exactly you do answer and shed light on things! Admirable!

[ColinIM]

Fixed for 5.1.16. IMatch now returns 0 if it cannot derive/find an aspect ratio.

Ah! Excellent.

It may not cover all fringe cases, but so be it. A user can always calculate a "better" aspect ratio value in a script and store it somewhere in the metadata or a custom Attribute.

Thank you Mario.  This variable is already very good as it is, but OK, I'll have a go at crafting my own version of it to show something like "7:5" for ratios within some margin of 1.414:1.  I'll add a post in the Scripting and Apps board when/if I succeed 

Colin P.

[ColinIM]

Thank you ubacher  and thank you sinus 

[Mario]

For the range of 1.41 to 1.70 IMatch uses 3:2.

[ubacher]

I am not sure about the usefulness of rounded aspect ratio.
I would find it much more useful to find aspect ratios which are NOT exact 3:2 etc.

If I, for instance, send photos to be printed, I need to decide how to handle images which
will not fit the selected format exactly.
If I make a "contact sheet"-like arrangement  of x images I like to have all images the same ratio. I need to be able
to find images which are "off-ratio" and manually crop them to the desired ratio. If I can not find these images
via Imatch how do I do that?

Would it not be better to just give the decimal ratio? What is the opinion out there?

[ColinIM]

Would it not be better to just give the decimal ratio? What is the opinion out there?

That would be a rather nice compromise I think, although an ironic one, considering that the "AspectRatio" variable was designed to 'refine' those occasionally messy displayed ratios such as (we can guess) 1.3333333333:1 

Perhaps we could ask Mario for an option to choose between his existing table of refined values, or an alternative result based on (say) a two decimal place, rounded value - like "1.40:1" - which we already get with ratios between 1.405:1 and 1.409:1?

(I've added this task (of writing my own version of AspectRatio) to my 'IMatch to-do list' as a super opportunity to grapple with IMatch's deeper scripting potential, but it's a long (deliciously long!) IMatch to-do list, so it won't bubble to the top for a while!!!)

Colin P.

[Carlo Didier]

Why not have both (in different variables or whatever)?
Or display exact matches in bold, like 3:2 and other in italics, like 3:2, or even like ~3:2?

[ColinIM]

Oooh! Great idea Carlo!

(Thinking aloud about how this could be done ...) In order to implement your idea, our eventually-displayed ratio would have two 'elements', namely (i) it's value (obtained by dividing the image's longest edge dimension by its shorter edge) and then (ii) its 'displayed style' (bold or italic etc.).

So we'd need to decide where / when would be best to assess the style for each new value (maybe by counting the decimal digits in the calculated value? Or by using an existing programming function like floor()?) - but the key point here is that we could assess the style in one of two places/times, either (iii) at the same time we calculate its value, or (iv), later, at the place & time where we choose to display this result.

If we choose (iii) then our new "variable" would need to become a two-part variable, or else we'd need to maintain two separate variables to be recruited later at the point of display - one variable for the value and a second variable just to carry the style we assessed earlier.

Or, if we choose (iv) then we'd only need to maintain a single variable for the value, but then the code and complexity at the point of display would be significantly increased as we assess which style to apply to it each time!

(I feel a programming itch coming on ... !)

I've got a strong feeling that we're in the realm of re-inventing wheels with this puzzle, so it might be good to look around other (open source) programmer's resources & libraries before investing new brain-power on it. (Although I already did this a couple of years ago hoping to do similar with IMatch 3.)

OR ... to acknowledge the elephant in the room ... dare we ask you Mario if you could reveal your own code for this AspectRatio variable?  Or is the fuzzy logic algorithm which distils values into a smaller sub-set of "3:2"-type results, part of a component in your development tools which could be 'exposed' for us to use through the IMatch Object Model?

I have to pause here as I've got a meeting in another town this afternoon (and thank goodness because I'd probably muse on this for far too long here ...). 

But yes Carlo, a nice enhancement idea 

Colin P.

[Mario]

There is no secret. I just made a table for common aspect ratios used in digital imaging and to fill the variable IMatch uses the best match of the image's width/height in this table. The idea was to give users some understandable and usable values, not the 1.33333333333 rationals you get when you do w/h.

I don't see a general use for a 'raw' aspect ration, e.g. using four digits. It would not hard to add another aspect ratio variable, or a "raw" formatting variant for the existing variable. Maybe 1 hour of my time (add variable, add code to fill it, test, document, update the help file). Not sure this is worth it for the maybe a handful of users who would be interested. I suggest you add a feature request and then we can see how many users +1 it.

[ColinIM]

There is no secret. I just made a table for common aspect ratios (....)

Ah! I see! I had been over-thinking things again 

(....) I suggest you add a feature request and then we can see how many users +1 it.

Yes ... that would be best, thanks.

@ubacher - I'd happily defer to you if you wish to paraphrase your original query here as a new Feature Request?  I'll pause a while before submitting a new request myself, and meantime here are my initial thoughts about it:

(I had imagined a couple of deeper, programming-related suggestions which might streamline our design of our own 'bespoke' versions of a File.AspectRatio variable, but given that we now know in general how Mario has implemented this, and given that it is only slightly (IMO) "off the ideal mark", I will base my request instead on a possible adaptation of this variable as it stands.)

My two-part Feature Request (FR) for an enhanced AspectRatio variable would be something like this: Others' views are welcome:

Cross-refer to this thread, posted by ubacher on 26 August 2014:
How to display aspect ratio (or other calculated values)
https://www.photools.com/community/index.php?action=post;quote=21185;topic=3214.0

Proposed Feature Request Part 1: Given that the results from the File.AspectRatio variable are drawn from a table or matrix of 'common' and simplified image X/Y ratios, and given that this matrix is currently 'hard-wired' into IMatch's configuration so that its (text) values are 'read-only', please make the contents of this matrix 'modifiable' by IMatch Users so that we can adapt the returned ratio-values to suit our own preferences.

As an example, I attach a fragment of a matrix of ratios as I would prefer them to be returned. This example matrix is a hypothetical one (I don't know how many cells are in the actual matrix as it's implemented) but the values in the second column of my attachment are those actually returned by the current File.AspectRatio variable (IMatch version 5.1.14).

Proposed Feature Request Part 2a: Please add a second table of "flags" - one flag for each possible returned value - which Users of the AspectRatio variable can examine in order to select or to switch between colours or text styles for the different aspect ratios at the point of display.

Proposed Feature Request Part 2b: These 'flags' would ideally be User-modifiable also, so that Users could choose to highlight image ratios of particular interest to themselves.

Proposed Feature Request Part 2c: These flags would ideally not be binary, true/false flags but instead could take (I suggest) any single-digit numerical value, 0 to 9. (Or maybe a less restrictive "integer only" constraint need apply here.)

As a starting point, these flags could by default indicate whether the "ratio" being returned for the current image is an approximation of the calculated X/Y ratio, or if it is an exact match.  For example, the flag for the returned ratio "3:2" would be "set" whenever the calculated longest-edge divided by the shortest-edge for the current image is exactly "1.5", but would be UNset for the near approximations of "3:2" such as when the result of the X/Y calculation is 1.48... or 1.53....

The fourth column in my attached matrix shows those values for which I would "set" this "particular significance" or "style" flag.

Again, all views & comments welcome, if any ... still at this 'discussion' stage.

Colin P.

[attachment deleted by admin]

[ubacher]

I think that letting the user define the table of ratios might be overkill/too difficult a change.
It would make the filter panel rather complicated.

An "exact" flag to be shown beside the ratio I think excellent. This flag
could then be used in searching for a given aspect ratio.
(The tolerance on "exact" is something to be worked out)

I will propose the addition of a width/height variable. In the filter panel one
should be able to filter for a "from-till" range of this variable.

I include a mock-up of a modified filter panel.

[attachment deleted by admin]

[ColinIM]

It would make the filter panel rather complicated.

Hmmmm! I have been focussed entirely on the File.AspectRatio variable alone, and I hadn't considered the Filter Panel at all!

The appeal of this File.AspectRatio variable to me is that it lets me see the aspect ratio on every thumbnail, in (potentially) every File view!  This is (of course) a very different concept in terms of our workflow than preparing and initiating a search for files having a particular X/Y ratio.

(Although it's a fair bet that behind the scenes inside IMatch, much of the same code will be used to maintain the AspectRatio variable as well as to modify the results from a Filter Panel query.)

So I would still vote to have the File.AspectRatio variable adapted as per my blurb above ...

... but yes! Your Filter Panel suggestion is (I think) a superb idea!

In the context of running a search (applying a filter) for specific image ratios, if Mario could include your extra "n-pixel tolerance" qualifier as well then it would be an almost perfect (almost perfect  ) resolution to this puzzle.  (It'll be perfect when I don't have to juggle with filters ....)

So ubacher ... does this look like it merits two Feature Requests now?  One for your Filter Panel enhancement (which seems teasingly viable IMVHO) and a separate one for the AspectRatio variable (which I admit seems a much tougher change to implement)?

Colin P.

[ubacher]

I added a feature request. Please add your request for user definable ranges etc.
Not sure if it should be a separate request (linking to mine) or if it best be added to my request.

[ColinIM]

Hi ubacher,

Very sorry for my delay in resuming here.

I'll add a separate feature request, but I'll be sure to cross-refer both to this thread and to your own feature request.

And because my request and yours are so tightly related, I'll include an acknowledge in my request to Mario's response in yours about the probable time-scale or low-priority status that your request (and certainly mine too) is likely to enjoy, unless we get a flurry of "+1s" from others 

Colin P.