One of the most common problems when importing a GEDCOM file into kiwitrees is enabling the “Keep media objects” option. In fact this should almost never (less than 1% of times) be used. It exists only for a very specific group of users.
The result of enabling this option when you don’t require it is that all your media items will no longer be connected to any records (individuals, families, sources etc.) in your tree.
What is a “media object”?
A media object is the reference in a GEDCOM file to a specific media item or file such as an image, a PDF, or video etc.. In the GEDCOM file it will look like this:
0 @M1001@ OBJE 1 FILE grandfather.png 2 FORM 3 TYPE photo
Also in the GEDCOM data are “media links”. These are references like this:
2 OBJE @M1001@
They tell kiwitrees that this media object (M1001) is linked to this individual or other type of record.
Who are the “very specific group of users”?
Some family history software does not support, and actually deletes media objects, like the one above, from any GEDCOM file use. That used to be fairly common, but is less so today.
Kiwitrees tries to cater for users of most other software products, and allow import / export between them so the “Keep media objects” option is maintained to help users of such software, and ONLY them.
What does enabling “Keep media objects” actually do?
When you import a new, or replacement GEDCOM file into an existing tree the first step is always to delete all the existing GEDCOM data for that tree from your database. That is why, when you start the import routine there is a delay before your computer starts actual importing.
“All existing data” means everything directly related to the GEDCOM file, so all individual, family, source, note, and media records, as well as a few related tables such as the “changes” log and links between records. It is the same process as just deleting that tree from your system. It doesn’t delete files or non-GEDCOM related data. So your media items (files) themselves always remain.
Then the import process starts, taking all the information from the new GEDCOM file and transferring it to the appropriate tables in your database, including re-creating all links between records.
So, if the family history software you used to create that new GEDCOM file changed, or removed the media objects, there is nothing left to tell kiwitrees what items link to which records, so no media can be connected.
By enabling the “Keep media objects” option, when the new GEDCOM file is imported kiwitrees does NOT remove the existing media links, the import process uses those links to recreate the correct media object (that the other software remove or changed), so that the correct connections are re-instated.
What happens if I mistakenly enable “Keep media objects” when I don’t need to?
Because the “Keep media objects” setting tells kiwitrees the incoming GEDCOM file has no media objects, it knows NOT to create any media links. so no attempt is made to re-connect your media file to your data. So you end up with no media being displayed.
Is there a way to fix the issue if I mistakenly used the “Keep media objects” option?
Yes, and it’s quite simple. Just run the import again, using the same GEDCOM file, but without setting the “Keep media objects” option. It will now delete the links, and then accurately recreate them for the GEDCOM media objects it contains, as it should.
Creating thumbnail images requires three things: a PHP graphics extension; sufficient memory on your server; and sufficient CPU power and/or time to allow the process to complete. You can check these using information shown on your kiwitrees page Administration > Site administration > Server information.
PHP graphics extension
Kiwitrees uses the “GD” graphics extension in PHP. Your server information should therefore list GD, and show it as GD support = enabled.
For gd, your server information should include a section for GD, with an entry of “GD support = enabled”.
To process an image from full size to thumbnail, GD requires memory of 4 bytes-per-pixel. An image that is 5000×4000 pixels will require 5000×4000×4 = 80MB (GD). In addition, the rest of the script requires approximately 20MB. So generating a thumbnail of a 5000×4000 pixel image will require at least 100MB. Your server’s “memory_limit” must be set to a figure higher than that.
CPU power and/or time
Image manipulation requires a lot of server resources. If you have very large images, and low memory limits, then you will need to arrange, perhaps with your web host, to increase any limits on these..