@Traveler100: Thanks for reporting this. Can you please provide a specific example including a specific link and clear steps to reproduce for that example? Also see https://www.mediawiki.org/wiki/How_to_report_a_bug - thanks!

Discussion at [[voy:Wikivoyage:Travellers' pub#Page preview pop-ups]] https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Page_preview_pop-ups . Example page[[ voy:Ohrid]][https://en.wikivoyage.org/wiki/Ohrid.

Thanks. I go to https://en.wikivoyage.org/wiki/Ohrid and do what exactly? Please provide a list of clear steps to see the problem.

Sorry let me try again.
The problem is with preview image of Wikivoyage pages. For example if you go to https://en.wikivoyage.org/wiki/Western_Macedonia. Mouseover the city number 8, which is Ohrid. This will show preview of the page, assuming preference not changed, the image of which is an airport image. Alternatively show the page info https://en.wikivoyage.org/wiki/Ohrid?action=info and note the default image.
If however you look at the page the first visible image is https://en.wikivoyage.org/wiki/File:Ohridpanorama.jpg (excluding pagebanner). The airport listing is coming from the section "Get in", will need to go into edit mode to see the source, in listing type go is parameter image=StPaultheApostleAirport-2.jpg .
Both these image are same size. Issue is listings with coordinates are in the page source before images on the page.

Allow me to chime in and add some more information here:
PagePreviews, which uses PageImages, was introduced to all language versions of Wikivoyage about a year ago if I am not mistaken. We since have found that these previews present readers with images that are not helpful to them. These would be images of things like train stations, tourist information centres, airports or non-representative landmarks, rather than an image that does represent the destination. A small list of such pages with undesirable preview images I have made accessible here. To see the images, hover your mouse over the links in the article. In brackets behind the link you will find where this image is specified within the article if it has been found. This should be enough information to then find this image in the linked article's source code.

Since these images in some cases are far from appealing in some cases and in other cases may do a destination more harm than justice, we want to get rid of this issue. Most of these cases can be traced back to PageImages scoring images from Templates higher than images from thumbnails in the article, the latter of which is much more desirable for Wikivoyage. This may not a bug per se, but we are looking for a method to disable PageImages from fetching images from templates, and if none such method exists, we have come to request such an possibility.

If more context is needed, then said context may be found in previous discussions about this issue from October 2018, December 2018 and January 2019. Since I was quite active in these discussions as well, I may also be contacted for further information if needed.

e since have found that these previews present readers with images that are not helpful to them.

These page images have been showing for about 5 years time - but inside the mobile interfaces. The page previews now thankfully make this much more visible so it's good this is getting attention!

we are looking for a method to disable PageImages from fetching images from templates, and if none such method exists, we have come to request such an possibility.

While it' s not going to be feasible to disable PageImages on templates per request, you will likely be interested in T91683 which makes it possible for editors to set the page image.

In the mean time, the page images algorithm is well documented on https://www.mediawiki.org/wiki/Extension:PageImages#How_does_it_select_images?
Previously we made use of $wgPageImagesLeadSectionOnly for Wikivoyage, but the majority of articles do not have images in the lead section (due to banners), so proved problematic. I feel T91683 is the appropriate solution long term, but in the short term, aside from edits to the article to place better representatie images near the top the blacklist might be of interest - you can list images that should not be used as pge images.

@Jdlrobson Thank you for your feedback. A method of making editors able to set the page image was briefly mentioned in our previous discussions on Wikivoyage. On the long term, that would be a good resolution to this issue. For now though, we may have to resort to $wgPageImagesLeadSectionOnly. I've previously suggested this as well, the only problem being that Wikivoyage tends to have its images appear in the second section of the article, rather than the lead. Naturally, this can be solved without too much trouble through the means of a bot.

What we were thinking of was an option to blacklist images from specific sources, in our case templates, but if that isn't feasible, we'll have to think around the issue. Blacklisting every problematic image we run into is not feasible for us, since we're talking about hundreds if not thousands of articles with poor imagery. To rearrange our listings in articles so that better images surface is a potential solution for now, but that's quite a manual task, and besides, it will not always be helpful. "See listings" for attractions are listed before "Do listings" because of Wikivoyage's article structure. Attractions such as theme parks will therefore never be the featured image, even if it's what destination is best known for. Another solution may be the ability to blacklist certain article sections, but I would not be surprised if that's as feasible as blacklisting templates.

Would like to understand a little more why it is not going to be feasible to disable PageImages on templates per request? This is a logical and clear exclusion, something that should be programmable. Alternatives being discussed at Wikivoyage will be a huge amount of work possibly taking a year to address by the community. Understand mediawiki developers are busy and cannot do everything but is this a case of technically not feasible or a prioritisation of work?

The image algorithm is pretty dumb - it has no concept of how the images relate to content - it just gets a list of links, which it filters for images in the order they appear in the article via https://www.mediawiki.org/wiki/Manual:Hooks/LinksUpdate hook. As a result all context of where the link appears is gone.

Thus to be able to identify an image inside a template the whole extension would need to be rewritten with that in mind :(

I reckon we could adjust PageImagesScores and PageImagesAPIDefaultLicense to give better results by adjusting how image sizes are considered..