I have my DO9 thumbnail cache size set to 800MB. I'm not entirely sure what's being cached, but it seems like this should be enough space for a LOT of 96x96 thumbnails. I started noticing some directories that I know had been cached previously were needing for the thumbnails to be regenerated. I decided to wipe the cache and start over. I did this two nights ago.
Tonight I started actively regenerating some of the thumbnails by pulling up the directories with the images and waiting for the thumbnails to be displayed. After doing maybe a couple thousand images I checked the thumbnail cache size. Even though it's still set to a maximum of 800MB, the size reads as over 1 GB. Oops, I just checked it and now it's back down to 800MB.
Okay, that still leaves me with questions about what exactly is getting cached. I did a couple test images and am guessing the average thumbnail, if converted to jpg, would be about 4k bytes. 800MB should be enough for 200,000 thumbnails. I have a lot of images, but not quite that many. What's going on with this?
The cache uses structured storage which will have overheads besides the actual image data. A 96x96 JPEG can actually be much larger than 4k, depending on the quality. For example, one I just resized then came in at 45k. If you have the "lossless compression" option enabled then PNG is used which will be even larger.
I can't imagine what 96x96 image would end up at 45k. The most complex image I could find (it started as a 10MB jpg), trimmed square to maximize the "thumbnail", reduced to 96x96, and saved as a minimum compression PNG came in at 17k.
That aside, I think it would be useful if there were better visibility to the thumbnail cache contents. Something that indicated how many images were in there would be a good start. Then at least an average image size could be calculated. It would either make obvious that there's an issue or provide strong evidence that there isn't. Now it's just me scratching my head at how the cache could be using the whole 800MB I've allocated to it.
Using jhead to strip the non-image data (jhead -purejpg ) shows that 35KB of the 40KB thumbnail is EXIF data (etc.)
I don't know if that's just a thumbnail that Jon resized in an image program as a demo, or one that comes from the Opus thumbnail cache. I suspect it's resized in an image program as that would be easier to do, but perhaps the Opus thumbnail cache is also generating/storing thumbnails with data that isn't needed.
(Of course, Opus may store and use cached EXIF data to avoid opening two files instead of one, but there's still at least 10KB wasted in the example JPG due to an embedded EXIF thumbnail (thumbnail-in-a-thumbnail), unless Opus is stripping that out when it caches the imaged. I don't know which data the Opus caching system stores, which it strips, and which it uses, but there might be something here.)
Something worth mentioning: If dynamic thumbnail resizing is turned on in Preferences then all thumbnails are generated and cached as 256x256 and will (in general) obviously be larger than a 96x96 example.
Well the OP didn't say anything about EXIF data, I just wanted to prove that a 96x96 jpeg could be bigger than 4K
Seriously though, I think Leo's probably right - dynamic thumbnail resizing means Opus handles all thumbnails internally as 256x256 and scales them down for display. If you have this turned on, turn it off and regenerate your cache - it should hold a lot more.
Most of my images lie on the other side of a network connection, so pulling thumbnails out of the cache is vastly quicker than regenerating them. If I had to regenerate them all the time I'd turn the whole feature off.
If your thumbnails are always 96x96 and you never resize them (via Preferences or temporarily via the Thumbnail Size slider) then you might as well disable dynamic thumbnail resizing so that Opus stores the thumbs as 96x96.
