XnView Software

I have struggled with this for quite some time. I am using v 2.40. I use FastStone often and I had a photo that I cropped. But when I view it in XnView, the thumbnail does not change making it hard for me to tell which is the cropped image. Rebuilding the thumbnail in XnView does nothing. See attached PICS. the cropped photo has "NED" added as a JPEG comment--you can see that in the PIC below also.

NOTE: if XnView crops the photo, the thumbail is updated. So, is this a problem with FastStone, or with XnView not respecting other program's cropping? This is a main reason I do **NOT*** use XnView--I can not trust its thumbnails (made by other programs)!!

FastStone displays its cropping correctly.

JStockton wrote:Rebuilding the thumbnail in XnView does nothing.

Is Use Embedded thumbnail (Tools → Options... → Thumbnails → Appearance) activated?

1. Create a copy of A BEAUTIFUL photo […] rocky shoreline (NED)_cr.jpg.
2. Select the copy in XnView's browser and go to Edit → Metadata → Recreate EXIF thumbnail....
3. Optional: Go to View → Rebuild thumbnail.

OK, that worked, but I need for this to happen automatically when I open XnView! I can not open XnView and know whch hundreds of files have been cropped recently and which have not been. In that case Thumbnail view, and XnView in general, is utterly useless to me since I use other programs too.

What am I suppose to do--everytime I open a folder with 1 zillion files, I got to select all of them and do the procedure you said? That's too bothersome.

For those who need reliable thumbnails, you need to provide an automatic means to enure the correct thumbnails are shown. Perhaps an option for those that need this featrure to enable automatic regeneration, whole others can opt out if this causes time delays and is not needed for them.

In order to make absolutely sure that the thumbnails in XnView's browser always represent the actual image, you have to deactivate the following options:

1. Enable Caching (Tools → Options... → Thumbnails → Cache)
   When caching is enabled, XnView saves all generated thumbnails in a database. Currently, XnView has no way of knowing if an image has been edited by different software. This would require a “daemon“ to permanently run in the background and monitor the cached files for changes.
2. Use Embedded thumbnail (Tools → Options... → Thumbnails → Appearance)
   Another way (besides a thumbnail cache) to speed up browsing is to tell XnView to extract the embedded EXIF thumbnails from JPEGs. Unfortunately, “photo manipulation software sometimes fails to update the embedded thumbnail after an editing operation”… *

* According to the following bug reports, FastStone Image Viewer seems to be one such program:

• Windows 7 Showing the Wrong Thumbnail
• Constantly have to refresh thumbnails manually
• Strange behaviour of (some) JPG thumbnails

Related topics:

• Obsolete thumbnails shown
• Thumbnails and database size
• External delete of image files leaves database inconsistent

Well, I disabaled what you said and now the thumbnails are regenerating correctly. It happens quickly enough too.

What a relief!

I have not noticed FastStone dong anything bizzarre with its thumbnail generation.

Thank you for your fast support.

Thanks for reporting back, JStockton!

JStockton wrote:Well, I disabaled what you said and now the thumbnails are regenerating correctly. It happens quickly enough too.

I don't use the thumbnail cache for this exact reason. But then again, I'm not a photographer who has to manage tons of multi-megapixel images.

PS: XnView MP allows the user to exclude and include folders from the cache.

JStockton wrote:I have not noticed FastStone dong anything bizzarre with its thumbnail generation.

I'm not involved in the development of XnView, and this is not to criticize or discredit FastStone. However, I can confirm that there's definitely a bug in their editor: If a JPEG is cropped and resaved, the primary image data changes, but the internal thumbnail (embedded inside the JPEG file itself) is not updated accordingly.