From John Scipione’s blog: https://insightfactory.tumblr.com/image/190955136557
3 Likes
Is it possible to store a thumbnail as an attribute, extended attribute or a file stream? Terms borrowed from Ntfs and Linux filsystems, not sure if equivalent exists in BFS?
Thumbnails can be saved in RAM and generated on demand by add-on, it is much better than no image preview support at all. Persistent thumbnail caching can be implemented later.
Yes, that’s how it should be done. No bikeshedding needed.
So apparently we need an average developer and a weekend. Patches welcome, I guess?
2 Likes
Here’s a neat trick that’s not very well known:
The Icon view of Tracker takes the List view’s first column attribute as file label. So you can switch to List view, move the “Rating” column to the far left, switch back to Icon view and now have the rating under every file. Neato! Works with Mini icon view too.
I could imagine a submenu in Tracker’s Icon view called “Number of label attributes” or something. With it not just the first attribute column is used as label, but e.g. up to 6. One on each line.
Also WRT a thumbnail view in general. I’m not completely sure it’s needed anymore. Back in BeOS, we only had 16px or 32px icons. Now we have up to 128px icons, which should suffice for reasonably large previews. OK, maybe since HiDPI displays, up that to 256px…
Then again, we wouldn’t want to overwrite the actual icon of a file. So, maybe another tickable sub-menu “Use thumbnails” and do use a thumbnail attribute if available.
3 Likes
Sorry for my ignorance and the offtopic: why this featrue/patch was never merged?
2 Likes
jscipione here
I have done the work to add thumbnail support to Tracker but I haven’t shared it with Haiku yet/haven’t created a Gerrit patch set. The way that I implemented thumbnail support in Tracker was to store the thumbnail image in a file system attribute, one attribute per icon size, so one for 16x16, another for 24x24, for 32x32, etc. These are generated lazily so only the thumbnails that are needed are generated as you open a folder in Tracker that contains files that are of mime type image for example image/png or image/jpeg. In addition to generating a thumbnail, I also generate a CRC32 of the first 20MB of each image file and store that in another file system attribute. Next time a thumbnail attribute is needed, I check the CRC32 to see if the image has been modified. If the image has been modified, the CRC32 won’t match and so it will delete all the stored thumbnails and regenerate them as needed. If the calculated CRC32 matches the one stored in an attribute than I assume that the image has not been modified, so I then display the existing thumbnail, or if there isn’t one yet for the icon size you are viewing, I generate one and store it, then show it. The names of the attributes are in the format HAIKU:THUMB:32 for example for a 32x32 thumbnail, and the name of the CRC32 attribute is HASH:CRC32, the idea being there could be a HASH:CRC64 or HASH:SHA1 someday. This naming convention is to prevent collisions with thumbnails theoretically stored by other software and it matches the convention used by some attributes that were in the format BEOS:SOMETHING. Of course none of this is going to work on a file system that doesn’t support attributes, but on BFS it seems like a reasonable way to implement the feature.
I also looked at the Tracker.newfs code and it uses SVG thumbnails and extends Tracker in a different way than I did. The Tracker.newfs code assumed that there was only 16x16 and 32x32 icons like on BeOS and then added a third type for SVGs. However, since Tracker.newfs we have added support in Tracker for a bunch more icon sizes and reworked everything so I’m afraid that there isn’t any magic in the Tracker.newfs code that would make thumbnails work better than the way I did it.
8 Likes
Is here the same issue like text attributes that the file will not be biggest size displayed? Icon as attributes can blow up filesize?
I wonder if we should instead patch applications to generate the thumbnail on saving, which I think would reduce the need for the checksum. Also, isn’t there a modification date stored in bfs? Wouldn’t that work just as well?
It is unrealistic to patch all software including ported to generate thumbnail on saving. Tracker should generate it automatically by translation kit or special add-on. Also it should be option to not save thumbnails and only keep it in RAM.
3 Likes
Store thumbnails in RAM if FS is not BFS, otherwise store as attributes seem like a good approach to me.
1 Like
Storing thumbnails in file system can waste disk space. Live thumbnail generation is fast for small images and images with built-in thumbnails (JPEG for example).
Is storage really a problem in 2020?
Some built-in SSDs can be small, on my tablet SSD size is 64 GB and external micro SD card size is 128 GB. USB disks can be also small.
Absolutely, but I really think that even 64Gb is fair enough storage for storing thumbnails.
Let alone that nowdays is difficult to have huge collections of raster images on disk.
Photographers are a notable exception, but they most probably store photos in RAW format, which is a completely different subject which won’t be covered by thumbnails generation anyway.
And, if this is the case, they usually have a more capable storage for that (for example, I have a 256GB SSD and 3Tb on mechanical hardware).
I consider use case of displaying many small image files (PNG etc). Storing thumbnails can double folder size with no reason. I have many screenshots, schematics, mockups etc. that can be previewed in Tracker.
2 Likes
I think it can be a problem for user who want a fast starting system. The programs and other non-writable system parts of the system need space and then we have in the future more big size apps and games, the system be slower (correct me if i am false here). If we generate every start of the system thumbnails the system need more time to start and it need more default hdd space.
On live CDs this would run never?
-
Would it be possible to use image preview in Tracker Add-on to use with a folder (Images…)? Generate them in RAM?
-
Have a Viewer like Albums to give attributes (thumbnails, comments, ratings) to the images? Improve the program Albums?
-
Use Image preview in the Window menu by selecting the images, so now all the images in the folder would have to be generated at once?
-
Use a translator to handle the generation for attributes by saving?