Releases: SmilyOrg/photofield
v0.3.0
More Efficient Database
This release should be functionally equivalent to v0.2.1, however it reorganizes database storage and processing so that it both takes less space and runs faster (especially scene creation on slow disks).
As an example, in v0.2.1, it takes up 193MiB for my database of ~540k photos. In v0.3.0 the same database with the same data takes up 74MiB.
More Detail
Both sizes are after vacuuming for a more accurate comparison. You can run a vacuum as a maintenance task through the app itself now too. Ideally in the future this would be automatic, but for now you can run it now and then if you'd like to reclaim some space after adding/removing a lot of files.
Even More Detail
Previously all the file paths were stored as absolute paths, which worked pretty well, but if you have a lot of files, it can lead to a lot of duplication as the same long path is stored for each file. This release de-duplicates all the directories into a separate table, so each file only references this table. It almost sounds like I'm reimplementing file systems here, but I swear it makes sense 😅
This leads to only the file names and a reference to a directory having to be stored. With the above real-world collection of 540k photos, they are only part of ~4600 directories, leading to the big storage savings. This complicates the queries a bit, but SQLite does a good job at executing them.
Due to internal reworking, file paths are also no longer needed when listing / opening a collection (album), so the query can just filter to a few specific directory ids, returning the file metadata in order. With the right indexes this can be pretty fast and efficient. At least that's the idea 😄
Changelog
- 0f5278b Optimize file paths
v0.2.1
v0.2.0
Embedded JPEG thumbnails
Embedded JPEG thumbnails are now supported. Extracting them is slower than loading pregenerated thumbnails already on disk, but way faster than loading the original, so it's a nice middle ground if you don't already have thumbnails.
Debug Modes
Additionally, the two debug modes supported by the API are now accessible again. They exist to more easily debug how and when the thumbnails are being used.
Debug Overdraw
Shows how close to "perfect" is the thumbnail / image being loaded.
More red 👉 too high resolution / wasted loaded pixels / slow loading
More blue 👉 not enough resolution / blurry display
Using only embedded JPEG thumbnails shows that when the original images has to be used, it is way too high of a resolution for the currently displayed size, so it's slow.
debug.overdraw.mp4
Debug Thumbnails
Shows the resolution of the thumbnail / image being used, the "distance" from the ideal resolution for the currently displayed size and the name of the thumbnail (or original for the original photo).
debug.thumbnails.mp4
Changelog
- e95e1c3 Merge pull request #5 from SmilyOrg/embedded
- 9aa66f8 Support embedded jpeg thumbs + fix debug modes
Docker images
docker pull ghcr.io/smilyorg/photofield:v0.2.0docker pull ghcr.io/smilyorg/photofield:v0docker pull ghcr.io/smilyorg/photofield:v0.2
