PhpGedView / Discussion / Help: Wrong Thumbnails After Upgrade to 4.2.3

Brian Gautier - 2010-02-12

The wrong thumbnail is now appearing in my charts where ever I've got more than one image associated with an individual. I've got lots of media files (jpegs) in events linked to individuals as well as portraits of the individuals. I suddenly find that PGV seems to be using the image in the first OBJE tag after the INDI tag which is in the first event in the GEDCOM listing. This is instead of the portrait of the individual. Is there anything I'm doing wrong?

I've been using PGV for some time with no problem and feeding it with a GEDCOM produced by Legacy 6.0 then 7 and now 7.4. Note that this problem first appeared before I upgraded from 7 to 7.4.

Here's a GEDCOM fragment to illustrate:

0 @I13@ INDI
1 NAME Albert Collard /GAUTIER/
2 GIVN Albert Collard
2 SURN GAUTIER
1 SEX M
1 BIRT
2 DATE 22 Feb 1892
2 PLAC 88 Westbourne Road, Islington, London, UK
2 SOUR @S4@
3 PAGE Islington 447
3 QUAY 4
1 DEAT
2 DATE 30 Dec 1939
2 PLAC The Infirmary, Leeds
2 CAUS Ulcerative Endocarditis
1 BURI
2 DATE 4 Jan 1940
2 PLAC Bridlington Cemetery, Bridlington, East Yorkshire, UK
1 RESI
2 DATE 22 Feb 1892
2 PLAC 88 Westbourne Road, Islington, London, UK
2 NOTE Address at birth
2 SOUR @S19@
3 PAGE Page 40 Schedule No. 268
3 QUAY 4
1 RESI
2 DATE 1 Apr 1901
2 PLAC 9 Road Place, Hornsey Road, Islington, London
2 NOTE Address at 1901 census aged 9
1 EVEN Haringay Swimming Club
2 TYPE Hobbies
2 DATE 1909
2 OBJE
3 FORM JPG
3 FILE C:\Documents and Settings\Brian\My Documents\Family History\Legacy\Pictures\GAUTIER, Albert Collard Haringay Swimming Club.JPG THIS GROUP SHOT IS THE IMAGE THAT IS BEING USED
3 TITL Haringay Swimming Club
3 NOTE Albert Collard Gautier is at front and centre of picture
3 _DATE 1909
3 _SCBK Y
3 _PRIM Y
3 _TYPE PHOTO

LOTS OF EVENTS HERE

1 OBJE
2 FORM jpg
2 FILE C:\Documents and Settings\Brian\My Documents\Family History\Legacy\Pictures\GAUTIER, Albert Collard.jpg
2 TITL GAUTIER, Albert Collard THIS IS THE IMAGE THAT SHOULD BE USED
2 _SCBK Y
2 _PRIM Y
2 _TYPE PHOTO

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Hattam - 2010-02-12

Doesn't the

3 _PRIM Y

declare it as the PRIMary picture? Shouldn't only one picture (the Preferred one) have _PRIM Y ?

Mark

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2010-02-12

PGV will not remove your PRIM tags and you could, in theory, have many within a particular INDI or FAM record, although that would not be particularly wise or proper. You should define your PRIM image and then not apply the tag to other added images, unless you wish to change your featured image at which point you would remove the PRIM Y designator from the currently featured iimage.

If when the images were uploaded, there was no designator (PRIM Y/N) included, PGV will display the first media OBJE as the PRIM/featured item. There have been many, many, many discussions about this assumption and frankly there are simply as many opinions on this procedure as there are admins, so it has NOT been changed, mostly from a legacy issue with previous installations and operations.

The OBJE details included with your gedcom INDI should have been stripped from the gedcom INDI record and applied to the OBJE created by PGV. At that time, PRIM and THUM level designators would have become level 1 from the 0 level OBJE
0 @Mxxxx@ OBJE
1 FILE media/photofilename.jpg
2 FORM jpeg
3 TYPE photo
2 TITL Media Title to display to users
1 _PRIM Y
1 _THUM N

-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2010-02-12

If you have two _PRIM Y tags how is PGV to know which to use? So it takes the first it finds.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2010-02-12

When several media objects are identified as "highlight" by having the PRIM line set to "Y", PGV chooses the first one it finds. This depends on the order in which they occur in the database. If you were to edit the first of the two media objects, its order in the database could very well change so that the second media object is selected for display.

Media objects that have a PRIM value of "N" are never selected for display. They will, however, appear in the media list of the person, family, or source with which they are linked.

Media objects that have no PRIM value (the line is missing or the value is blank) are considered for display only when there are no media objects with a PRIM value of "N". The selection rules are the same as what applies when you have several PRIM Y records.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2010-02-13

Sorry, the last paragraph should have said, "… no media objects with a PRIM value of "Y".

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-13

I'm a bit disappointed by this. Legacy applies a default PRIM to the first image in an event and there is no way I can see to remove it apart from editing the GEDCOM after I've exported it. The number of these makes that too much of a chore. kiwi_pgv says how does PGV know which to use but the OBJE tag that I want to use is at level 1 within the INDI whereas the one that is being picked is at level 2 within the EVEN tag. Surely this gives the program something to hang on to. Another point is that the layout of my GEDCOM hasn't basically changed since I first started using PGV and it all worked fine before.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2010-02-13

When you notice that the wrong picture is being selected, you just need to edit the offending media object (using the facility provided) and set the "Highlight" option to blank. That will remove the "PRIM Y" tag from that object.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-13

Thanks for the suggestion canjun2eh. However I already tried this and it doesn't change anything. In any case I would expect it to just substitute the image in the next event as it occurs next in the GEDCOM. There are 20 image references in the listing to pass over before reaching the one I want.
My way of working is to use my Legacy database as the "master record" and periodically update what is on line by overwriting the GEDCOM used by PGV with newly exported one from Legacy. So I would have to edit the highlight for too many media items each time I update. I still don't understand why this is happening now when it never occurred before. I've had this kind of data with images associated with events right from the off.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-13

When I tinkered with the highlight settings directly in PGV there was no effect on the thumbnail used. Since then I've experimented and found that by editing the GEDCOM exported from Legacy by moving the OBJE tag and associated lines for the INDI's image above the first occurrence of an EVEN for that INDI then PGV selects the right image.
Doing this for all the similar occurrences in my GEDCOM would probably work but is just too onerous. After all why do we use computers if not do all the boring repetitive tasks.
You may disagree but I regard this as a bug because PGV is not distinguishing between the INDI's own image OBJE at level 1 and other image OBJEs referred to within EVEN tags occuring at level 2

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Greg Roach - 2010-02-13

<<I regard this as a bug>>

Since PGV is working as designed. (The design is noted in in lines 1184-6 of includes/functions/functions_db.php), this is more likely a feature-request than a bug.

If you think you have a better rule for determining the highlighted image, please raise a feature request, and describe carefully the logic you would use.

You might also consider that marking *every* image as primary is also a bug, and report this to the Legacy developers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-13

Legacy does not mark every image as primary. It allows for one of several images included in an event to be marked as primary within that event. If one is not chosen it defaults to the first image added to the event. The problem is PGV is not distinguishing between an OBJE directly associated with an INDI and one which is associated with events do do with that INDI.
It seems to me that PGV is simply not conforming properly to the clear logic of the GEDCOM. This is why I call it a bug rather than a "nice to have". If I had the neccessary skill set I would be delighted to suggest how this could be addressed. Unfortunately I do not.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Greg Roach - 2010-02-13

Legacy does not mark every image as primary

The gedcom extract you gave in your first post has a "_PRIM Y" tag against every image. Perhaps we have different understanding of the gedcom format and/or the word "every" ;-)

Let me copy/paste the relevant comments from the code.

* Rules for finding the highlighted media object: * 1. The first _PRIM Y object will be used regardless of level in gedcom record * 2. The first level 1 object will be used if there if it doesn't have _PRIM N (level 1 objects appear on the media tab on the individual page)

This is the design. Unless I see a counter-example, this is what I believe the code does.

If I had the neccessary skill set I would be delighted to suggest how this could be addressed

I'm not asking you to write code, or submit a patch. I asked you to describe what sort of logic you would use. For example, you might want level 1 objects to always take priority over level 2 objects. Perhaps think about all the possible combinations of level, primary, etc. and list them in order. Remember that gedcoms can contain any old garbage (e.g. two copies of the same image, one marked _PRIM Y and one marked _PRIM N, etc.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-13

Legacy definitely does not mark every image as primary. The fragment I presented just happens to only have one image in the event shown. As I explained Legacy allows for one of several images included in an event to be marked as primary WITHIN THAT EVENT. If one is not chosen it defaults to the first image added to the event. What you are looking at is a very abbreviated part of the GEDCOM. The individual has about 30 events associated with him. About 20 have associated images. Some have more than one in an event. Legacy always marks one of them as primary in each event. Second and subsequent images will not be marked as primary unless the user changes which is the "preferred" image.

I can see that the current rules for finding the "right" object will result in exactly what I am getting. However coming up with "better" rules obviously needs a bit of thought. Why IS level ignored in the rule? Ease of programming/speed of operation? At first sight it seems that giving priority to level 1 OBJEs makes more sense but what do I know.

I will ponder further.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Greg Roach - 2010-02-13

Why IS level ignored in the rule?

If not, then suppose you have two media objects, one at level 1 and one at level 2. If a user ticked the "primary" option for the level 2 object, the presence of the level 1 object would overrule it.

You clarified how Legacy implements primary. Thanks for this. I've never used Legacy, nor have most of the people here. I haven't used FTM either, but I believe we handle _PRIM the same way as that.

So, you seem to be asking that rule #1 be split into

1a. The first _PRIM Y object at level 1 in gedcom record 1b. The first _PRIM Y object at any other level in gedcom record
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stuart.G - 2010-02-14

Brian,

I have been a Legacy user for many years but now I handle the process in the opposite way that you do. My PGV database is my active database and I export a PGV Gedcom to Legacy for some reports and features. Legacy has problems with both importing and exporting Gedcoms. I have been working with Brian at Legacy support on several issues. Some have been fixed; others haven't. Even up to release V7.4. From memory (and mine is bad), I think the only reason Legacy set the PRIM tag for events is that it can only print one image per event in reports. If I recall correctly, Legacy does not allow, for example, multiple images in FAM reports.

I'm sorry that this does not help you solve your problem. It is just another way of doing things. From my experience - a better way. PGV is a great bit of software thanks to all of the developers and testers.

Stuart

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-14

Thanks for the comments bigone60. Yes I agree, PGV is the best in its class. In fact there is no real competition. I don't know why but I just feel more secure having the "master" of my 20 years genealogy work on my PC and backed up under my control.

Fisharebest - I started out with the same way of working but with FTM. I found however the GEDCOMs it produced weren't quite right and produced errors in PGV. At FTM 2006 I gave up and moved to Legacy 6 upon which all the problems went away. FTM may have moved on since then.

Yes that rule change seems more logical to me. Isn't it more likely that the link to an individuals image would be in an OBJE at level 1 rather than further down inside another tag. But I suppose changing the rule may create problems for those whose GEDCOM does not follow this pattern.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-14

Incidentally, I've looked for the comment about the rules in functions_db.php but lines1184-6 are spanned by function search_fams_custom. I've done a text search but can't find it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Greg Roach - 2010-02-14

Sorry, my typo. functions.php, not functions_db.php

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2010-02-14

Perhaps we should change the rules:

1. Look for highlighted level 1 media
2. Look for highlighted media at any level
3. Look for level 1 media that don't have the Highlight option set to "N"
4. Look for media that don't have the Highlight option set to "N", at any level

In each case, pick the first one that matches the selection criterion.

This is basically a sort of media objects, using the Highlight option as the major key and the level as the minor key. Pick the topmost one without the Highlight option set to "N".

The "sort" method of choosing a suitable media object should be easy to implement, and could be amended as we decide on new rules.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-14

This looks good. Thanks for taking the problem seriously guys.

In the meantime I've found a quick fix for my problem. As the _PRIM setting for the references to the images I want displayed are all at level 2 in my GEDCOM and the others' _PRIM settings are at level 3, I can simply do a find and replace of the string "3 _PRIM Y" with "3_PRIM N" in my GEDCOM before I upload. I've tested this and it works fine.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mark Hattam - 2010-02-15

I'm not so sure about the #4. catchall step … as that would mean a lot of inserting of "N" on all the gravestone photos, church photos, document scans and so on to avoid them being shown as the INDI thumbnail. Level 1 can be fair game, but level 2 or level 3 is only decorating the event(s), not the basic indi … unless I specifically want them by marking them with a "Y".

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Brian Gautier - 2010-02-15

On reflection wouldn't it be simpler to say that the INDIs portrait image reference is expected to be found in an OBJE at level 1 and l don't look anywhere else?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2010-02-15

Mark,
With over 3500 OBJE's, and only 300 or so as INDI-Portrait-like PRIM's, I wholeheartedly agree. I worked hard to avoid display of Headstones as INDI images, but any further changes truly complicate the matter.
Brian
Sort of, as most of my featured INDI-media OBJE's are level one while most of my other 3200+ media OBJE's (census, WWI-II draft registrations, headstones, churches, residences, etc) are Level 2 o2 2+ but that ignores the hundreds of family photos that reside at level 1.
-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2010-02-15

Ok, how about this:

1. Look for highlighted level 1 media
2. Look for level 1 media that don't have the Highlight option set to "N"
3. Look for highlighted media at any level

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Wrong Thumbnails After Upgrade to 4.2.3

Forums

Help

Wrong Thumbnails After Upgrade to 4.2.3 document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Wrong Thumbnails After Upgrade to 4.2.3