Yellow triangles

[pmcabinet]

How about an Option to tell iMatch to ignore yellow warning triangles that cannot be resolved. This on a per file basis (right click < Additional Functions perhaps?).

These triangles are now littering my database (starting 9 months ago) but have absolutely no bearing or effect on any image processing I undertake. As warnings they are completely useless - so why retain them?

I understand it is possible to edit metadata "if you know what you are doing"[Mario quote]. So teach us how, please.

 

[axel.hennig]

I don't think that this should be done. I think you should really try hard to solve these issues. These problems might get bigger going forward (e.g. when Metadata "standards" changes, Metadata mapping changes,...).

Can you upload a file (jpg preferred) where you cannot resolve the yellow warning? I would like to test if I can solve the issue.

I also have yellow warnings (not many, not often), but they could be always resolved.

[pmcabinet]

Thank you Axel, that would be really good. I have tried hard but reached a cul-de-sac.

Mario has downloaded some of my yellow triangle images before (from a shared link in Google Photos, although I don't really use Google - it's local storage for me) and says he has written back successfully the metadata to a test database. I have never been able to replicate the process.

Always the error is 'FPXR segment too small'. There might be other minor errors in some images, but it's the FPXR nuisance that seems to stop the write back.

Mario gave up in the end - I think he just thought I was being incompetent (not impossible), so I would be really interested to know what you make of it.

Update:
Now it gets interesting: I could not attach the full res jpg file here because it is larger than 5MB, so I reduced it to 4MB in Affinity Photo. I don't know what effect that has on the metadata, but when I exported the file back to the folder in my database, I clicked the pen icon to write back - guess what, no yellow triangle!

So I went back to the full res image in Affinity and exported it again, as is, with a minor change to the file name. You can guess the rest; I think this must be what Mario was referring to when he said I need to 're-write' it but I didn't know how I could do that. Still unexplained is how both he and I could download the same images to respective databases, when he could write back OK, but I couldn't.

Still, I have a workaround now. Not ideal because the original file size, 5.59 MB, has increased to 9.96 MB on export. Just copying the original file, changing the name and bringing it back into iMatch was no good. I don't know what export processing is causing such a large increase in file size.

If you would like to see and download examples of a few problem images, this is the link to Google Photos:
https://photos.app.goo.gl/1eYStTsUS1Bhx8gY9

Many thanks for your interest here.

[jch2103]

Still, I have a workaround now. Not ideal because the original file size, 5.59 MB, has increased to 9.96 MB on export.

You should be able to change the JPG compression in the image exported from Affinity. It sounds like it may have been exported at 100%, but in any event you should be able to change the percentage to reduce the file size without visible changes. 

[Mario]

These links are not public. Google want's me to sign up to download these photos?

Re-saving in your image editing software is what I meant with 're-write'.  This creates a new JPG file, which apparently does not contain whatever is upsetting ExifTool on your system.

I could never reproduce it, but that does not mean I think you are incompetent. Such a thought would never cross my mind. I just try to solve the problem. Sometimes problems appear only on one PC, and when I cannot reproduce the problem and exhausted all problem soling avenues, I move on. There is always the next IMatch user with problems to fix.

Just on Sunday I was finally able to figure out a "IMatch terminates without DUMP file" problem that pestered one user. We could finally reproduce it after he provided 20 GB (!) of sample images via his cloud. We've exchanged probably 20 emails, I did various tests and stuff, to no avail. Only the mass of sample images provided allowed me to reproduce the issue. The Windows WIC codec for ARW files crashing so hard when attempting to read one of the images provided that it even overwrites memory in the IMatch process (!) - which causes Windows to terminate IMatch for safety.

After knowing that and switching to LibRaw, I could finally drill down to the issue that's the real problem. A 4GB TIFF file that was not handled all to well by the 3rd party imaging library I use. It just crashed real bad.
OK, TIFF files with a size of 4GB are not that common and exceed the 32-bit address space, which is always troublesome.
Still, the 3rd party library should have handled this more gracefully. I have replaced it it and use something else for TIFF files above a certain file size. Storing the TIFF with lossless ZIP compression reduced it to only 800 MB.

[axel.hennig]

These links are not public. Google want's me to sign up to download these photos?

I was able to download the photos without logging-in. Click on the photos, then they get enlarged. Three dots at the top right to get more options (one of them is downloading the photo).

[axel.hennig]

If you would like to see and download examples of a few problem images, this is the link to Google Photos:
https://photos.app.goo.gl/1eYStTsUS1Bhx8gY9

I've downloaded the images, imported them to IMatch and clicked on write-back. Write-back was successful and no yellow triangles. Everything seems to be working.

[Mario]

Maybe you've downloads some kind of "copy" or "proxy" Google has produced from the files?
I would very much prefer to download the original files unmodified, in case this is caused by some file format or metadata issue.

[pmcabinet]

Thank you all for your comments. Axel is able to write back as well - why cannot I? As mentioned before, I go through the exact same process but still get the yellow triangles.

Mario, I would be very happy for you to download the original files. I'm not keen on Google Photos myself either (although I always upload full-res images, not allowing Google to compress them); I have attached them to an email to your support channel.

I have tried re-saving them (without any processing) in Affinity software ('Save As') but this still 'modifies' the image and increases the file size from 5.85 MB to 15.99 MB! Then I tried just 'Save' (over the original) which gave a slightly better file size but still increased it to 9.56 MB. I lose the original in that case, of course. The metadata will write back in both cases, but it's not good - I don't want these big increases.

I'm assuming that those who have downloaded the images and successfully written back the metadata have preserved the original file size (5.85 MB)?

As a postscript, there is another curious bit of behaviour: I selected an image that had been written back OK some months ago - no problems. I altered the existing description slightly, clicked to write back and hey presto - the yellow triangle appeared! FPXR again. Completely mystified.

[thrinn]

I just downloaded the 3 files from the Google link you provided. Of course, there is no possibility to check if Google somehow alters the files - because all of them were imported in my test database, and for all of them a metadata write-back went without errors.

Regarding the increase in size you experienced: I used the Affinity Photo "Export" to resave the file, not "Save As". My settings were:
You cannot view this attachment.

The important thing is the 85% quality setting. With this, the file size actually decreased a bit:
You cannot view this attachment.

But keep in mind that every JPEG export will reduce the quality a bit - that's just how JPEG works. Another question is if the differences are really visible. You can try different settings for the quality to check the impact on the file size.

[Mario]

Same here. Download all 3 images, added some metadata, wrote back without any problems.
Metadata Analyst show now issues with the file, except some minor warnings about some EXIF tags not sticking to the standard.

I don't know if Google modifies images when you upload them. I would assume so?
The correct way would be to ZIP them and upload the ZIP file. Or you can send them to support email address with a link back to this topic.

[Mario]

Thanks for sending the original images.
The upload to Google has definitely altered the files (why?) because the files in your email show a much larger number of EXIF warnings, including the 'FPXR segment too small' warning and 50 (!) other warnings. It seems like OnePlus is writing kinda messy EXIF data.

Attempting to write back these files causes an ExifTool error message!
In the ExifTool Output Panel I see:

Code Select Expand

Warning: FPXR segment too small - E:\data\download\community\13811\IMG_20230914_115238.jpg
Warning: FPXR segment too small - E:\data\download\community\13811\IMG_20230914_115238.jpg
Error: Error reading ThumbnailImage data in IFD1 - E:/data/download/community/13811/IMG_20230914_115238.jpg

But the data I've added (title, rating and some keywords) is actually written to the file!
I see the yellow warning icon in the File Window afterwards (which is added because ExifTool reported an error), but when I now <Shift>+<Ctrl>+<F5> > Reload Metadata the file, the warning icon vanishes.

I think the problem is that the thumbnail in the file is damaged, always causing ExifTool to report an error during write-back. This tells IMatch to flag the file has having an error, which caused the warning icon.

While reading metadata, ExifTool ignores the bad thumbnail or just gives a warning, hence no error icon is displayed in the File Window.

Still, the file should be re-saved at, say, 85% JPG compression in your image editor. Or as a PSD, PNG or TIFF file to avoid any quality loss. This will recreate the damaged thumbnail and metadata in the file and fix the root of the problem.

[pmcabinet]

OK, I have found that opening the file in Affinity and exporting it (not 'save as' - which gives a huge file size whatever format is chosen) as a jpeg at 95% gives almost the same file size as the original.

This seems the best workaround; I've compared the original with the exported at very high magnification and there is no noticeable loss of quality. Then, at last, the metadata will write back

But the data I've added (title, rating and some keywords) is actually written to the file!
I see the yellow warning icon in the File Window afterwards (which is added because ExifTool reported an error), but when I now <Shift>+<Ctrl>+<F5> > Reload Metadata the file, the warning icon vanishes.

I also tried this, adding (more) keywords etc. but the file still doesn't write back. I'm puzzled why it works for you, but at least I have a workaround now. I just hope I don't have to do it too often, 'cos it really slows down the workflow!