QV panel "blinks" (photo, Loading..., photo, Loading...) - may have a root?

[MrPete]

I was importing a folder of files in the background, and simultaneously opened a folder in the file view.

QV for the JPG blinked back and forth between the photo, a "Loading..." message, and a brief mention of there being no thumbnail.

I turned on debug logging, and also saved the WIC log. 

Debug log is boring. I suspect the reason for the blinkies is the database busy-ness in the background. However, WHY would it blink at all, and WHY complain about no thumbnail? For that, perhaps we have an answer...

The WIC log looks most interesting. See below. I suspect what's happening is the WIC is giving errors, and QV may be endlessly retrying...

This effect stops for a given file, if I open the file for a full view. It also is at least invisible if the database is not busy in the background.

I'm rather surprised the CODEC won't supply a thumbnail for a jpg?! I tested JPG files from a dozen different cameras spread over 20 years, several brands, and a scanner or two. ALL get the same result:

Code Select Expand

WIC Codec Report - for diagnostic purposes.

List of installed WIC codecs:
...
.Codec 'JPEG Decoder' (Vendor: F0E749CA-EDEF-4589-A73A-EE0E626A2A2B) for extensions .jpeg,.jpe,.jpg,.jfif,.exif
...

WIC: Testing file 'F:\FAMILY ALBUMS\2013\1311 Grandpa Ashes\P1060343.JPG'
Thumbnail: Codec 'JPEG Decoder'
(GetThumbnail failed (88982F44 The bitmap codec does not support a thumbnail.).) 0x0 pixel in 0 ms.
Preview: Codec 'JPEG Decoder'
(GetPreview failed (88982F81 The operation is unsupported.).) 0x0 pixel in 0 ms.
Full resolution: Codec 'JPEG Decoder'
() 4000x3000 pixel in 78 ms.

IMatch Integrated RAW Processing.

Analyzing image 'F:\FAMILY ALBUMS\2013\1311 Grandpa Ashes\P1060343.JPG'
    Error opening file: -2 (Unsupported file format or not RAW file)


[Mario]

That WIC codecs don't supply thumbnails or previews for JPG files is normal. Microsoft made that decision.
LibRaw does not support JPEG files, AFAIK.

No idea why the Quick Preview Panel should be blinking file files are imported. It monitors the even bus to react on relevant messages, like the loaded file being changed, annotations for the loaded file being modified, metadata being modified. But only for the load file, not other files.

How can I reproduce this?

Can you attach the boring log file. I may see things you don't. Like activity, reload QVP frequency, thread activity.

[MrPete]

Sure enough! See attached.
I also just saw the Bugs topics... will do other reports there.

[Mario]

The first thing in the log file is see are error messages from the installation verifier (a security feature), e.g.

'C:\Program Files\photools.com\imatch6\imengine6x64.dll' not found. [Error 2 (2)]

IMatch checks for and validates all of it's components during startup to ensure they are valid and the certificates check out. On your system, this fails with error 2, meaning "file not found". But the files exist, else IMatch could not start. Why does this fail? Which virus checker do you use and did it lock that it prevented IMatch from accessing the files?

IMatch is in full flight importing and processing files.

Then I see tons of messages like

"Failed to produce a large thumbnail 80004001 'Not implemented". I cannot see the file names since the log is not in debug logging. But this seems to happen while processing videos or audio files?

Then a severe warning when trying to process a PDF file "Q:\Y copy\Curv..."

Some ExifTool warnings about invalid IPTC digests (typical when another application has written XMP but did not care to update legacy IPTC and the checksums too).

All the while IMatch is performing reverse geocoding.

Then IMatch imports existing XMP face regions but cannot detect a face in the region. Many, many times. Not sure that I have seen this before. Which application did write the files?

Many more ExifTool warnings.
Many more of reverse geocoding.
Version processing. Face recognition.
IMatch was very busy dealing with all this.
I see a memory peak at 4GB.

Nothing that would tell me why the Quick Preview is flashing.
Maybe all the warnings and file issues were the cause. Or maybe the system was low on memory. Not sure.

[MrPete]

@Mario good questions...

• I use WebRoot for virus scan. It hasn't flagged anything in iMatch at all. In fact, WebRoot hasn't flagged anything in this computer for a long time. I'll run a ProcMon watching for imengine6x64.dll to see if I can find that.
• Hadn't really thought about it until now, but my photo library is a great set of QA testing files for any digital asset workflow LOL. I'm not surprised some images might cause hiccups! My photo collection includes a rich variety of sources, from the 1997 Olympus D-500L to Nikon DSLRs w/ non-electronic lenses, to current cameras, scanners, apps and more.

I would guess that most of the face issues relate to Picasa. For all its wonderfulness, it had some very serious bugs, including:

• Database blowup requiring a rebuild... but the rebuild normally forgot who the faces are.
• Rebuilt database often/usually would shift face-location rectangles to a completely wrong place. Result of this: 'faces' that point at nothing.
• And then, when rescanning to get the right faces, one ends up with multiples for the same person on the same photo, only one of which is (or might be) correct.

You've touched on something here that I eventually want to get to: importing our family photo collection, already pre-processed by Picasa, appears to point to a painful future task:

• iMatch (very reasonably!) attempts to import the data, and preserve what is real.
• But much of the time, what's there is either inadequate (just now I was looking at photos with zero or one faces identified, yet if I manually F6 re-scan it finds all four.)...
• Or, wrong (due to above bug, or just seeing faces that aren't)
• AND, iMatch assumes such photos don't need rescanning (at least by default?)

I'm hoping there's a way to:

• Use the already-identified person info, including the training info iMatch already has...
• And bulk re-scan ALL photos imported from Picasa (because most likely the majority are suffering from these and other errors.)

For my older images that do cause grief, can you point me toward anything in iMatch that might help translate the APP12 PictureInfo tags in our oldest images to modern tags? They are visible in the tag Browser, but don't show in iMatch as useful dates, camera or other info. All I need is a shove in a close direction and I'm happy to create whatever filters or are needed...

[Mario]

Please stick to the default font size, if possible. Your post contains tons of formatting instructions, did you copy & paste it from somewhere?

iMatch assumes such photos don't need rescanning

Rescanning is the term when IMatch rescans an image already in the database, when it is externall modified, e.g. by an image editor. I don't understand what you mean by this sentence.

I would guess that most of the face issues relate to Picasa.

Picasa did a lot of damage. Google bought it to get a foot in. Maintained it badly, Then switched everything to online so they can track you. But it was free, so people used it back in the day.

You've touched on something here that I eventually want to get to: importing our family photo collection, already pre-processed by Picasa,

IMatch imports existing XMP face regions by default (see Working with XMP Face Regions). This usually saves a lot of work, assuming that the software which performed the face recognition and wrote the XMP face regions did a proper job. Which is not always the case. From Apple's width/height=0 face regions (which you only recognize when you leave the walled garden) to Picasa's sometimes plain wrong or mispositioned face regions, it's all part of the metadata mess.
If you have many images with crappy face regions, I recommend to disable XMP face region import and to let IMatch's face recognition to the job. When this affects only some files, you can just select them in a File Window, delete all faces via the context menu and run IMatch's face recognition to do the job properly.

And bulk re-scan ALL photos imported from Picasa (because most likely the majority are suffering from these and other errors.)

What is that supposed to do? IMatch will import them in the same way it imported them the last time.
You can force IMatch to re-ingest files using Shift+Ctrl+F5 > Force Update, but that's very rarely needed.

I'm hoping there's a way to: Use the already-identified person info, including the training info iMatch already has...

When IMatch performs face recognition on an image it uses the face data already in the database to find the best matching person.

For my older images that do cause grief, can you point me toward anything in iMatch that might help translate the APP12 PictureInfo tags in our oldest images to modern tags?

Sure. Lookup:
Metadata Mechanic
Metadata Template
in the IMatch help. Both allow you to copy data between tags, enabling you to salvage data stored in abandoned metadata by copying it into XMP tags and/or IMatch Attributes.
Note: When copying date and time info, pay attention to the corresponding sections in the help which explain the date and time format expected.

APP12 PI is very old, only supported ASCII, was never widely supported and all that. Metadata mess, again. Like all the XMP and EXIF tags camera vendors and Microsoft introduced over the years, supported shortly, then abandoned - leaving users who relied on the data in the rain...

[MrPete]

Please stick to the default font size, if possible.

I'm trying, I'm trying    ... I pasted one word (the dll name) from your reply. It broke the font size for the entire rest of what I'd written... and I can't find a bbcode tool to remove text formatting.  VERY frustrating. (In fact, I had to manually remove tags per-paragraph from this reply to get it back to 'normal'.)

Rescanning is the term when IMatch rescans an image already in the database, when it is externally modified, e.g. by an image editor. I don't understand what you mean by this sentence

Sorry, what I mean is the equivalent of F6 (re-detect / re-recognize faces?) What I'm thinking is:
1) At least the data stored by Picasa does include correct names, and often has valuable training info allowing iMatch to correctly see the right person for that name. Saves big on re-entering hundreds of names if nothing else.
2) I'd love to do a bulk F6 re-detection (without losing the training info), since so much of what was ingested is garbage.

Metadata Mechanic... Metadata Template...
APP12 PI is very old, only supported ASCII, was never widely supported and all that. Metadata mess, again.

THANK YOU! And yes, the Olympus D-500L dates to before Exif was made publicly available (Exif 2.0 was the first 'visible' version  ) and even IPTC was software-only back then. I for one appreciate your diligence in working to smooth over the Metadata mess. I sometimes think it's a wonder anything can work (similar to the fact that I can grab a case, motherboard, RAM, PSU, storage, keyboard, etc... plug them together and it works  )

I'll see what I can do w/ these tools to empower good ingestion of D-500L, and quite possibly our large collection of photos made with a modern DSLR but older manual focus lenses. (Another amazing reality: due to Nikon's commitment to backward compatibility, our latest DSLR's provide better support for my father in law's old lenses, than did his original Nikon F1 etc! The lenses are mostly sold off by now, but we do have a lot of those images still.)

Thanks again, Mario.

[Mario]

1) At least the data stored by Picasa does include correct names, and often has valuable training info allowing iMatch to correctly see the right person for that name.

When IMatch imports XMP face regions, it performs the steps described here: Working with XMP Face Regions
It assumes the regions contain a face. When a face is detected by the IMatch AI, it is processed and the person with the same tag as the face region is assigned. This face can then be used for training, like any other face.
When IMatch cannot detect a face, it creates a manual face annotation and links it to the person.

I'd love to do a bulk F6 re-detection (without losing the training info), since so much of what was ingested is garbage.

How would than even work? There is no "training data" in face regions. They are just a box and a tag (text).
IMatch must perform face recognition itself to see if there is actually a face in that box. Could be a pumpkin or a bicycle.

[MrPete]

How would than even work? There is no "training data" in face regions. They are just a box and a tag (text).
IMatch must perform face recognition itself to see if there is actually a face in that box. Could be a pumpkin or a bicycle.

Of course. Sorry, let me rephrase my thoughts:

• Picasa often (obviously not always!) defines tags and face regions that are actually correct.
• On import, iMatch absorbs that, and scans the region for a face, which (if successful) saves the associated face fingerprint.
• At least at the UI level, there is a direct linkage between a person, a file, and "trained" (fingerprint) data. (pressing "T" toggles that person+file on/off as a training source.

What I'd like to do with Picasa imported data (after the initial ingest) is be smart about re-detecting all faces in Picasa files, thus cleaning out the garbage:

• Bulk re-detect faces in every image, without throwing away the already-discovered training/fingerprint data, which is already linked to person names/tags.
• In other words, if I simply clean out everything learned from those files and attempt to import blindly, iMatch has no way to know who the people are in the files, correct?
• (In theory I supposed this could be done on a per-file basis, but I suspect it's best to allow the whole set of people to be ingested first, since knowing all fingerprint-person linkages up front will make the redetect that much better... at least in my imagination it ought to  )

[Mario]

On import, iMatch absorbs that, and scans the region for a face, which (if successful) saves the associated face fingerprint.

And if no face is found, IMatch creates a manual face annotation and assigns the person.

So the face regions existing in your image are always used to the maximum available information. You will only see a problem if Picasa placed random face regions on your images which you would have to remove manually.

Bulk re-detect faces in every image, without throwing away the already-discovered training/fingerprint data, which is already linked to person names/tags. 

Why so complicated? Do you plan to manually change XMP face regions outside of IMatch? Why?
And then want IMatch to perform some sort of face detection of an image while sparing out already detected faces?
Makes no sense to me and would be time and money wasted for the implementation.

In other words, if I simply clean out everything learned from those files and attempt to import blindly, iMatch has no way to know who the people are in the files, correct?

I still don't follow, sorry. What would you clean out? Delete the face regions in the metadata? Delete the face annotations already created by IMatch?

For 99.99% of users all this works like this:

1. Import images into IMatch.

2. If the images already have XMP face regions created by Lr, the camera, Picasa or whatever, IMatch uses them

3. If the images containsno XMP face regions and automatic face detection is enabled, IMatch scans the images for faces, creates face regions and assigns the best matching person.

4. Review files when needed to check for missing face regions and to confirm or assign persons

I'm not sure what Picasa did so different in your case. In the sames I have, Picasa did a fairly good job at detecting faces and assigning persons (or the user did). IMatch just imports the faces and either creates a true face annotation (with fingerprint in the IMatch AI format) or a manual face annotation and uses the tag Picasa has written to link to the corresponding person.

[MrPete]

Long delayed response on this topic.

Mario, sadly I have extensive examples where Picasa bugs cause face regions -- for what reason I do not know -- to get shifted away from the originally-recognized faces. I have seen this happen on several machines, for many years.

I suspect it has something to do with bugs in rebuilding the Picasa database after it crashes.

In any case, the very common result is images that have:
* Good face information (name, etc) EXCEPT
* Bad coordinates for the XMP face region. I've not analyzed for a pattern although I suspect there IS one.

I have many thousands of photos like this.   ... and I've seen it reported by others over the years.

As might be imagined, it is incredibly painful to go through and manually fix this.

So, my hope is that iMatch could somehow re-recognize the location of the faces already known to exist in a photo.

[Mario]

When IMatch imports face regions, it can only assume that they are correct.
To fix it, let IMatch run it's own face recognition on the files to get the correct face regions. Or move the face regions so IMatch updates the coordinates but retains the associated persons.

Picasa was a a very buggy software back in its day and Google never invested much. The only reason they've bought is was to transfer the user base and their images (!) into the Google cloud over time. Only when the database is in the cloud, Google can use and monetize it. Picasa was free, so users where the product.