Haiku Tracker should have ability to show image previews. This ability is already present in Tracker.NewFS in BeOS: https://mlotz.ch/newfs/screenshots/3.0b5.png.
Up for this, I agree!
3 Likes
Technically it isn’t challenging to modify Tracker to generate/display/store thumbnails vs HVIF images for registered image files (an average developer can get this working in a weekend), the primary challenge is “the bikeshedding” associated with the design of a thumbnail caching policy. Existing solutions for other OS’s have major annoyances (as witnessed by the abundance of MacOSX ._DS_Store and Windows .thumb files), and Haiku should do better. I doubt many developers are ready to grab the “bull by the horns” to tackle this particular problem, since the non-technical issues (although important) are bound to overwhelm the process than talk involving actual coding problems.
Having said all that, a RFC proposal (with several “concept/iteration/revision” cycles within the community) will eventually get the “requirements” sorted out. Actual developers (who can do the actual work) may feel less pressure to tackle the problem once the bike-shed discussion had run its course. Of course, the end developers can ignore the suggestions entirely since Open Source is a technocracy (no one is paid to do the work, its all volunteer based).
To sum up, a formal proposal is a good start. Each journey of a thousand miles starts with a first step.
For my video editor I generate thumbs for image and video files. For video thumbs I also scan neighbouring frames if the thumb is 75% black. Its less than 200 lines of code for image thumbs, and audio thumbs are an extra 200 lines of code - I can donate this if someone asks. But why stop with image and audio … and I’m bike-shedding. … 
5 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).