Database Filter For "2048x1536" Dimensions

[Darius1968]

Okay, the filtering allows me to set the width "2048" and height "1536", which will return for my result landscape mode images.  However, what if I want images that were shot in portrait mode, ie., the width is "1536" and the height is "2048"?  I can filter a second time, but can I return images for both cases in the same filter?  If the answer is yes, can this capability be carried over to database filtering that allows for a range in both dimensions? 

[Mario]

You cannot create a file dimension filter which filters for multiple different image dimensions.
I suggest you create one filter for each orientation and save it. Then just check the filter you want to apply in the Filter Manager.
To see files in both orientations, combine one stored filter with a 'normal' dimension filter.

Another (more automatic) approach would be a data-driven category which groups your files into orientation- and size-based categories, maybe with a numerical range to grab only the file dimensions you are interested in.

[Darius1968]

"File Size" is one of the possible filter panels in IMatch's filtering.  It has the "From" and "To" data entry fields to facilitate a range.  Is a similar thing possible for the "Image Pixel Count"? 

[Mario]

Filtering for a range of pixel count is not an operation that is required often. You can handle this easily with a data-driven category.
The IMatch help explains all options for all available filters. If it is not there, it does not exist.

BTW: I have extended the file dimensions filter to include a long edge / short edge variant. You can still not filter for both a long and a short edge at the same time, but you can find all files with a long (short) edge between x and y. Next release.

[Darius1968]

Thanks for the reply.  I think I know what I'm doing, but I'm not confident about  where/how/what to correctly input the syntax in the data driven category to effect what I want.  Are there any examples on how to do this? 

[Mario]

The help for data-driven categories contains many examples. And, a bit of trial-and-error is normal  - that's what the Preview is for. It shows you the result without going through all the hoops of creating categories and is quick.

The tag XMP::exif\PixelXDimension\ExifImageWidth for example contains the width of the image in pixel. If you use that, IMatch creates one category for each unique width. You can use a numeric range to consider only files within specific bounds.

[Darius1968]

Okay, I tried this tag:  "XMP::exif\PixelXDimension\ExifImageWidth".  It doesn't really work because I have images that have widths of 352 pixels, but that tag says the pixel width is 3072!!!  What tag can I use to reflect the TRUE image width? 

[Mario]

This tag should by updated when you change the size of an image. Which application did you use? The EXIF data should be correct all the time.
You can also try the {File.Width} variable as the base for your data-driven category, which contains the width IMatch has determined.

[Darius1968]

I'll try "{File.Width}" and see what happens.  I don't have answers to many of these questions for a sizable amount of the images because they were acquired from others. 

[Darius1968]

Okay, so, I got this "{File.Width}" variable to work, which you say, "contains the width IMatch has determined."  Interestingly enough, there are no incorrect values her, but there are some files that end up in the "other" category!  To be sure, I have photos taken with my old iPhone 4 (2592x1936), but this variable doesn't even recognize that the file has an entry for the resolution.  What gives? 

[Mario]

Without as much as a sample file, how can I tell?
IMatch fills the Width/Height variables from the width/height information returned from whatever image library / WIC codec / RAW library / video codec is used to extract the data from the image, the cache file, the thumbnail etc. I don't care much about Apple products, but usually images taken with iPhones are processed without a problem and the files also contain a usable EXIF record that can be extracted by ExifTool and then just used.

Unless your iPhone files are very special or you have used some software which damaged the files, I have no clue. I suggest you help us by providing a sample file so we can all see which data it contains, what information IMatch/ExifTool is pulling from the file etc. Otherwise we all run just in circles trying to help you. When I have one of your files here, I can tell you why IMatch is unable to determine a width value. You can attach it (< 2 MB) or send it to my support email address (see my signature below).

[Darius1968]

Okay, I've attached a sample file from the iPhone (I downloaded this file from this board to make sure that the metadata tags were all still there.), which will not register in a data driven category with the file.width variable at level 1.  Also, I can not seem to effect level 2 on the data driven category with the variable, "File.Height".  What would I be doing wrong?  Yes, I do have the "Other" option in this category enabled at both, level 2 and level 2. 
Is it indeed possible to let a data driven category have multiple nodes with descending hierarchies (Level 1, Level 2, Level 3, etc.), using variables instead of tags? 

[attachment deleted by admin]

[Mario]

This file has a proper EXIF record, GPS record etc.
IMatch imports it, and the variables return



Looks good to me. Switch the Metadata Panel to the Browser layout. If you don't see EXIF data etc. , try to force a rescan of the file via Shift+Ctrl+F5. Maybe there was a problem at the time you added the file?

Is it indeed possible to let a data driven category have multiple nodes with descending hierarchies (Level 1, Level 2, Level 3, etc.), using variables instead of tags? 

Sure, why not. I just created a data-driven category with {File.Width} on the first and {File.Height} on the second level. Just make sure you enable the levels, put the variable in the correct field etc.

[attachment deleted by admin]

[Darius1968]

Something very strange, very strange in behavior that I'm experiencing right now, right off that bat:
I, too, successfully get the "Var Toy App" to display "2,592" for a query of the {File.Width} variable, which is as expected.  But, in my data driven category "Image Size" that has the very same variable, this very same file is place at "2"!  I'm certain that there is no auto-grouping in effect.  And, yes, the proper value can be seen with the metadata panel reflecting the "Browser" layout.  A forced update of the file (Shift+Ctrl+F5) has no effect. 
About my attempt to get this category to have two level of hierarchy, for {File.Width} and for {File.Height}:  I can't get any preview, and when I update the category, IMatch says it is busy with another task and can't complete the operation at the current time.  This is what I run into every time. 

[Erik]

You're saying that the category is just "2" and not the full "2,592"?  Or perhaps it's just not going in the correct location?

Two things I can think of: 
1. You might need to make sure the setting in there is that the field is numerical (should help for sorting the categories and dealing with numbers)
2. You might need to set the field or variable to use Raw values... the comma may be a potential problem if IMatch is trying to display it.

[Darius1968]

Erik, thanks for your input, which sheds some light on my problem.  There's no change in outcome regardless of the setting for "Raw".  However, I had the data type set to Integer, which is a problem!  When I set it to Automatic, the file in question indeed does show up where it belongs!  (at node "2592", not at node "2"!)  It seems that the comma is throwing a wrench into things!  With all what is said above, how can I substitute 'Integer' so that I can for example, restrict the range for files whose width falls within 2590,2600? 

[Mario]

Please keep in mind that IMatch formats numerical values using your local number settings (as configured in Windows). Variables return text!

On a German Windows, a integer number like 2592 will thus be formatted as 2,592.
A floating point number like 4321.456 will be formatted as 4.321,45.

If you use this as input for data-driven categories  you either need to use the auto mode which processes the numbers as text, or you need to cast the variable to an integer or floating point number the cast formatting function:

{File.Width|cast:int}
{File.Height|cast:int}

See the help topic on variables for details.
Using variables for data-driven categories is extremely powerful, but needs some deeper understanding of variables, what they return and what you expect to use as the basis for your data-driven categories.

[Darius1968]

Mario, I tried using "{File.Width|cast:int}" for level 1, "{File.Height|cast:int}" for level 2.  This solves half the problem.  I can now, for instance, restrict the range from 2590-2600, at level 1, for the width, but I still can't use 2 levels (I had to choose no at level 2 to deactivate it).  If I try to use both levels, I still get this business of IMatch telling me it is busy and can't complete the task at the moment.  To test, I restricted level 1 to widths of a range 2593,2595.  This leaves just seven files in my whole database to be processed!  With it like this, I still get the all circuits are busy kind of a deal.  What to do now? 

[Mario]

Works here. No idea why it does not work on your system.
Please supply log file in Debug mode. I don't even know how large your database is.

When IMatch displays this message it could not lock the database exclusively because another background operation is currently in progress. Usually it is sufficient to try again later. Or you have somehow constructed a data-driven category setup which takes ages to process...

Using metadata tags (EXIF Width/Height) is an order of magnitude faster than using variables. I suggest you use metadata tags and not variables. As we have learned yesterday, your files indeed contain proper metadata which can be used for this purpose.

[Darius1968]

I've attached the log file for your inspection. 

[attachment deleted by admin]

[Mario]

Your database has nearly 300,000 files. That's massive, especially when your data-driven category requires 600,000 variables to be parsed, processed, casted and then grouped. Probably one one part of the data-driven category takes to long, blocking other parts out. I never have tried to do such a thing and I currently have no time to spend further time with this. I suggest you file a bug report so I remember and look into this for a later version. Probably I just prevent a user from doing things like this. 300,000 files, two levels, variables...too much. Not even IMatch can do everything.

Try my suggestion to use metadata tags. This is a lot faster.

Your files have EXIF info so this should work. If some of your files don't show EXIF data, did you follow my advise from yesterday or the day before to reload their metadata?

I'm sure when you switch to EXIF tags instead of variables, 300,000 files in a data-driven category with two levels will work. Please note that, in theory, using such varying values like width and height can produce thousands over thousands of elements per level. Make sure you use numeric filters to limit the number of categories to create. Especially for a 300,000 files database, having tens of thousands of categories will slow down even IMatch.

[Darius1968]

Okay, I just now switched back to the tags (using the tag you suggested).  Some files will register in the category, but not all, and to answer your question, yes, I did do a refresh of the file's metadata as well as a total refresh of the file itself for all those not registering in the category.  Such an image that won't show up in the category, when I have the width & height tags respectively set to 800x600, is attached here.  The tag based category tells me I have 650 images that are 800x600.  The actual number of 800x600 images in my database is roughly 3,400. 

[attachment deleted by admin]

[Mario]

What do you see in the Metadata Browser for a file which fails to be assigned to the correct category?
The size extracted by IMatch may be different from what you expect.

[Darius1968]

Well, the last image I posted in this thread is in pixels 800w x 600h, and it is one of those images that "fails to be assigned to the correct category". 

The following is what the metadata panel's Browser layout reports, which is reporting two different versions of the image's size. 
Megapixels   0.480
Profile Description   c2
Color Profile Name   c2
File Extension   jpg
File Folder   C:\Users\User\Downloads\
File Format   JPEG
File Name   73375_3008909598988_1844139470_n.jpg
Lifetime ID   ff3a0c4e-9417-43a4-8ad5-3a66d6887ec6
JFIF Version   1.01
Resolution Unit   inches
X Resolution   314
Y Resolution   314
Bits Per Sample   8
Color Components   3
Encoding Process   Progressive DCT, Huffman coding
Image Height   600 {File.MD.JPEG::SOF\ImageHeight\ImageHeight\0}
Image Width   800 {File.MD.JPEG::SOF\ImageWidth\ImageWidth\0}
Y Cb Cr Sub Sampling   YCbCr4:2:2 (2 1)

As can be seen, it is somewhat logical why the tag I used didn't put the said image in the category.  I used an EXIF tag, whereas what's embedded in the image is a JPEG tag.  I prefer the speed of tags over the variables in the data driven category.  It's just that the variable seems more universal.  Is there a way to take all the images in a database and map their variable height & width into a said tag to insure all images are on the same wavelength with regard to which tag the info is at?  Or, is it possible to use multiple tags at once on the same level to insure all relevant data is accounted for? 

[Mario]

Your sample file has no EXIF record, only a minimal JFIF record. ExifTool/IMatch do not 'make up' EXIF records and thus neither there will be EXIF or EXIF-based XMP data for your files. This means that the corresponding tags will not be filled and thus cannot be used for data-driven categories.

The image size is however correctly reported by IMatch as 800 x 600 (it uses the dimensions reported by the image library), and the corresponding variables also return this result.

When I now create a data-driven category based on

{File.Width|cast:int} Level 1
{File.Height|cast:int} Level 2

both your files are sorted into the correct categories. The first file (IMG_0176) into

2592 and 1936

and the second file into

800 and 600

Looks good to me. Please double-check your category setup. Maybe try with a fresh test database to simplify analysis.

[Darius1968]

Is there any way to map what is reported by the image library into a tag instead of having to resort to using the variables? 

[Mario]

Yes: Metadata Templates.

If you work with files which have no EXIF data or any other usable data at all, just fill the XMP Width/Height tags via a Metadata Template from the File.Width etc. variables.