use Tumbler for thumbnails

[Danielle Foré]

No sense creating two sets of thumbnails on the disk. Let's use Tumbler to create thumbnails and drop the thumbnailing code from Shotwell.

[Jim Nelson (yorba-jim)]

One major issue: Shotwell doesn't store fully-transformed images on disk.

Shotwell's editor is non-destructive. It stores changes (rotation, color correction, crop, etc.) in its database and applies them on-the-fly when the image is viewed within Shotwell. This is a major reason for Shotwell's internal thumbnailing. Shotwell stores fully-transformed thumbnails (including rotation) to get them on the screen as quickly as possible.

An external thumbnailer will need to know how to get that information from Shotwell's database and apply those changes exactly as Shotwell would in order to produce thumbnails that look like the final image. Those thumbnails aren't useful outside of Shotwell, as they might show images that look nothing like the image if it was loaded with a regular image viewer (like eog).

A secondary issue is that Shotwell allows the user to dynamically change the size of the thumbnail. If the thumbnail is too small, artifacts will appear when scaled up. If it's too large, Shotwell is slow to display thumbnails when the user sets them small, as it needs to load a large number of them and apply scaling. This is why Shotwell stores two sets of thumbnails, 360px and 128px. Our guiding rule is: always scale down, never scale up.

[Danielle Foré (danrabbit)]

Great points, Jim. Marking "Wont' Fix"

[Jim Nelson (yorba-jim)]

Wait -- before you do that, understand that there's another route.

One large feature we want to add to Shotwell is storing fully-transformed photos on disk. The ticket is at https://bugzilla.gnome.org/show_bug.cgi?id=716280

The broad idea is that when a photo is edited Shotwell would write a fully-transformed photo out to disk in the background. It would use the same filename and store the original master elsewhere on the filesystem (an "Originals" subdirectory, for example). If the user reverted those edits, Shotwell would destroy the transformed photo and move the master back to its original location.

It's a bit tricky and the devil's in the details, but this solves a number of problems:

* A user navigating the filesystem can see the image as it appears in Shotwell
* Shotwell can now drag-and-drop images to other applications
* Exporting an image to another application (though Contractor, Send-To, Web publishingetc.) doesn't require exporting the image to a temporary file (as it does today)
* External thumbnailers now work, opening the door to Shotwell using them rather than its own
* Shotwell can avoid the pipeline when performing photo operations, making it snappier overall (see https://bugzilla.gnome.org/show_bug.cgi?id=718909)

There was some talk early on about making this a user option, but over time I've come to lean to just making it part-and-parcel of Shotwell's operation. It has some downsides too (extra disk space being used), but the upside seems pretty attractive.

[Danielle Foré (danrabbit)]

Okay, I added bug# 1272753 and this bug will depend on that architectural change. Re-opening and marking as triaged.

I agree that the advantages (in performance) would outweigh the costs (in disk space) especially since sharing thumbnailers with the file manager would mean less disk usage on that end. Part of our philosophy is not asking users to make engineering decisions, so I also agree with not having it be an option.