* Show Project Statistics plugin – TIF files with frame links.

[LornaCraig]

When I run the Show Project Statistics plugin it reports a number of Unusual Multimedia Frame : Area errors. A few of these are cases where the frame link has accidentally extended beyond the edge of the image. These are easily corrected. However there are many others where there is no obvious problem with the frame link. In all of these cases the report says Invalid or unrecognized file format, as seen below.

report.JPG (17.44 KiB) Viewed 1150 times

Investigation shows that the files in question are all either .TIF or .TIFF . As far as I can tell, the plugin is reporting all cases of TIF/TIFF files where there is a frame link. I assume the problem is that it can’t verify the size and position of the frame because it can’t tell the size of the image itself.

FH doesn’t have a problem with these files or their frame links. Is it just an oversight that the plugin doesn’t recognise TIF/TIFF files?

EDIT: I have just found some .TIF files with frame links which are NOT reported as errors or 'unrecognized file type'! There must be some other complication but I can't think what it is.

[tatewise]

Sorry but I'm not sure what is causing that particular error message.

The plugin uses the standard IM: Digital Imaging Toolkit library to open Media files and discover their width & height.
For some reason, the IM library is returning that 'Invalid or unrecognized file format.' error message either when the file is opened or when reading its image info to obtain width & height.
So there must be something about those TIF files' internal format that IM does not like.

Do they open Ok in an image editor such as IrfanView or PhotoShop?

I have tested some TIF files and cannot produce the error message.

[ADC65]

You've probably already checked, but in the Media Record, does the Format field match the actual file format? When I did a major media tidy-up last year I noticed that a number of my TIFF files were recorded as JPEG in the Media Record (and I don't know how that happened). This didn't cause me any issues in FH that I noticed, but it slightly impacted on a plugin I was writing to standardize some of my media. I just wondered if something similar may be happening in your case.

[LornaCraig]

Mike: Yes, the files all open OK in image editors and internally in FH.

I have been trying to find what the 'problem' files have in common. They were all downloaded from ScotlandsPeople.gov.uk, and the ones causing the problem are older ones. More recent images from ScotlandsPeople are OK, as are other TIF files from other sources. I am wondering if SP have changed the type of compression they use. Another possibility is that I edited the images (to straighten or trim them) and when I saved them I used a different type of compression.

Attached are two files for comparison. The HOOD Robert birth file causes the error report (when a frame link is added to it) and the McEWEN Helen birth file is OK with a frame link.

NOTE: I couldn't attach them as .TIF files (warning said "Error parsing server response") so I have changed the type to .docx in order to get them attached. Hopefully you can recreate the problem when you change them back to TIF.)

HOOD Robert birth.docx

(57.51 KiB) Downloaded 28 times

McEWEN Helen birth.docx

(57.68 KiB) Downloaded 25 times

[LornaCraig]

Adrian: Yes, the Media record file format matches the actual file format. Curiously, if I change the actual file format to JPG exactly the same problem is exhibited!

[LornaCraig]

I have just realised that the newer files would have been downloaded as JPG files, but I edited them (to straighten or trim them) and then saved them as TIFs. These are the files that are OK. However I can't remember whether the older files were downloaded as TIFs. I think they may have been.

[tatewise]

I get the same IM error message as you do with the HOOD Robert birth.tif file.
I've tried an alternative IM function to read the file but it produces the same error.

The McEWEN Helen birth.tif file does not produce an error.

I used IrfanView to open the HOOD Robert birth.tif file and inspect its characteristics.
Its compression uses CCITT Group 4 Fax Encoding the same as the McEWEN Helen birth.tif file.
So I simply saved the file over itself and chose the same compression option.
None of its characteristics seemed to change but it now does not produce the error!

BTW: Regarding ADC65's comment about Media Record Format versus Media file type, the plugin checks that and produces a different exception report for Unusual Multimedia Format.

[LornaCraig]

So I simply saved the file over itself and chose the same compression option.
None of its characteristics seemed to change but it now does not produce the error!

How peculiar! I know I can ignore those error messages from the plugin but I suppose it might be worth re-saving all of the 'problem' files just in case the mysterious glitch causes problems with any future versions of FH. Thanks for investigating.

[LornaCraig]

Update: I decided to re-save the TIF files which had been picked up by the plugin, and also identify any others which might have the same issue but were not reported by the plugin because they don't have frame links in FH.

The vast majority, though not quite all, of the files had a time stamp of 13/02/2010 18.22. I assumed something must have happened at that time 13 years ago which caused the files to be saved with a very minor glitch. I started re-saving them in the manner described by Mike (open each file in Irfanview, save it over itself with the same compression, CCITT 4). The plugin now recognises the file format and not longer produces the error report. But the files all now have a time stamp of 19/09/2019 11.07 !!!

EDIT: It turns out that the basic ‘date’ column in File Explorer was showing a mixture of date created and date modified. How unhelpful can Microsoft get? (And don’t get me started on how a file can be modified before it’s been created!)

[tatewise]

File Explorer supports several dates such as Date created, Date modified, Date accessed, as well as just Date.
You can choose whichever of those dates you would like to be displayed in the File Explorer columns.
When I used IrfanView to update the TIF file it did not alter the Date created or Date modified, and only updated the Date accessed but I've no idea where that 2019 date is coming from. Are you sure your PC has the correct Date?

[LornaCraig]

13/02/2010 was the Date Modified before the files were re-saved.
19/09/2019 was the Date Created.
05/02/2023 was the Date Modified after the files were re-saved.

The general ‘Date’ column evidently displays whichever is the earlier for each file. Hence before the re-save it was showing 2010 (the original Date Modified) and after the re-save it was showing 2019 (the Date Created) for those particular files.

Whoever thought that was a good idea? (Even if you ignore the counter-intuitive concept of a file being modified before it has been created!) I normally display the Date Modified column, but at some point it must have got changed to the general Date column without my noticing.

I still have no idea what caused the original problem but all is well now and the plugin is happy.

[AdrianBruce]

... the counter-intuitive concept of a file being modified before it has been created! ...

I have this vague and possibly erroneous idea that the last time I set a new machine up, the create-dates were set to the date that the file was created on the new machine, but the modified-dates were untouched - i.e. the modify-date was effectively a logical date and the create date was effectively a physical date. Or that's the way that I interpreted it....

[jelv]

It's not just copying files to a new machine, if you copy a file to another place on the same PC you will see the same. The modify stays the same and the create date is when the new file was created.

[AdrianBruce]

... if you copy a file to another place on the same PC you will see the same. The modify stays the same and the create date is when the new file was created.

So I wasn't imagining things then. I can justify that in my head by interpreting one as logical and the other as physical - but it is, as Lorna says, a touch counter-intuitive.

[jelv]

but it is, as Lorna says, a touch counter-intuitive.

Not really; when you copy a file you are not changing the contents of the file itself, so it hasn't actually been modified.