Ability to show thumbnails of images

[mmadia]

Being able to display a thumbnail of images would be beneficial, if not an expected feature.

The later Tracker.NewFS builds included this functionality. The thumbnails were stored in BFS attributes.

[jstressman]

I actually just wrote a blog article about this earlier today and made a mockup to show how much better it would look.

To paraphrase that article a bit:

The lack of using the actual thumbnail attribute has become especially apparent since larger icon size options were added in Tracker by John Scipione back in hrev44422.

In essence the problem is that currently Tracker uses either the BEOS:M:STD_ICON or BEOS:L:STD_ICON attributes to display the icon for the file in Tracker. But since these icons come from more than 15 years ago back in the BeOS days, those icon sizes are 16px and 32px respectively, on top of being dithered. (See the "GetIcon(), SetIcon(), GetTrackerIcon()" section of the BNodeInfo page in the BeBook for more info: ​http://www.haiku-os.org/legacy-docs/bebook/BNodeInfo.html )

While those may not look too terrible at those very small sizes (and even that is definitely arguable), the problem is that the 32px BEOS:L:STD_ICON is the biggest one we have to work with when it comes to showing a preview of the actual image for image files. So this gets scaled up double for even 64px sizes, triple for 96px, and quadruple for 128px sizes.

You can see the result of this for 96px sizes in the image below showing the current way it's done. And that's not even the worst example.

There is also a GRAFX:Thumbnail attribute set, which includes a high quality (up to) 96px actual thumbnail version of the image. I've kept finding myself wondering why Tracker refuses to use this far superior thumbnail even when I'm using the largest icon size options.

Here are two images... the first of the way it is now... and the second showing how it could look if Tracker used the GRAFX:Thumbnail attribute instead.

[jstressman]

Tracker as it is now, using the upscaled 8bit dithered 32px icons

[jstressman]

Tracker mockup using the full color 96px thumbnails from the GRAFX:Thumbnail attribute.

[dsjonny]

+1

[dsjonny]

One thing: if I know right, the GRAFX attribute will add by an application, so if the image has no this attribute, than only the standard icon will shown. Why not the Tracker generate this attribute when it is not present? There would be a "Show trumbnails" option in the Tracker. If we check this option, the Tracker will try to generate the thumbnail for image type entries, and show as an icon. If the image has already a thumbnail, then the Tracker will skip to generate it again. But if the image has been modified, then Tracker needs to regenerate the thumbnail.

[Giova84]

Replying to dsjonny:

Why not the Tracker generate this attribute when it is not present? There would be a "Show trumbnails" option in the Tracker. If we check this option, the Tracker will try to generate the thumbnail for image type entries, and show as an icon. If the image has already a thumbnail, then the Tracker will skip to generate it again. But if the image has been modified, then Tracker needs to regenerate the thumbnail.

+11 :-)

[Giova84]

Would be fine publish this ticket as GCI 2013 task :-) ​http://www.google-melange.com/gci/org/google/gci2013/haiku

[Giova84]

I've seen that John seems to be at a good point about this feature :-)

​http://insightfactory.tumblr.com/image/91811088137

[jscipione]

Yes, I have gotten thumbnails to work by probing files, finding out their MIME types, filtering out the images in an approved list of MIME types using the Translation Kit, then I use the Translation Kit once again to create a thumbnail at the size of your current finder setting (16x16, 32x32, 40x40, 48x48, 64x64, 96x96, or 128x128) and the store the thumbnail(so) in one or more attributes on the file.

All of this works, all that remains for the feature to be complete is that when the user changes the file, the thumbnails must be updated at all sizes that have previously been computed.

[danboid]

Hi John

This is my most wanted feature for the Tracker, above SMB and SFTP browsing. Have you made any progress on your Tracker thumbnailer with updating previews?

Does it work for video files too or just images?

Have you uploaded your code anywhere public yet?

Thanks

[danboid]

Does your thumbnail preview code work for files on read-only partitions or drives such as CD and DVD-ROMs?

It would be good if it could fall back to storing thumbnails for read-only files on the Haiku drive somewhere.

[jscipione]

@danboid

I haven't touched Tracker thumbnail support in a while. What I've done can be seen here: ​https://github.com/jscipione/haiku/tree/tracker_thumb

thumbnail preview will work for read-only partitions such as CD and DVD-ROMs but you won't be able to cache the resulting thumbnail in an attribute so the thumbnail will have to be recreated each time.

[danboid]

So why did it never get merged? I presume you never finished it or else it would've been integrated right? Do you intend to finish this or have you given up on this feature?

Thanks

[danboid]

Does it work for video files too or just images?

[pulkomandy]

At the time, we thought it was better to first merge aldeck's tracker_refactoring branch (even older, 2010 or so) before further work on addding functionalities to Tracker, because the code was not very clean.

This has been done now, and the branch could be merged once it is brought up to date with current state of Tracker.

Previewing videos is difficult, a naive approach would be to decode the first frame but that is often completely black, so smarter code is needed. I think the thumbnail code is generic and will provide thumbnails for anything, as soon as there is a translator which can somehow turn the file data into a BBitmap. Then it is only a matter of writing the appropriate translators to preview anything you'd like.

[diver]

I don't think that tracker_refactoring branch has been merged. I believe it's even impossible to do that now. Too bad that all the work is lost now :/

[pulkomandy]

right, it was not strictly merged. Waddlesplash did try to salvage as much as he could from it when he switched Tracker to use the layout kit.

[axeld]

No, actually, he left out the interesting parts, and only took over the stuff that has to do with the layout API. The long-overdue refactoring of Tracker has been omitted, unfortunately.

[ttcoder]

Replying to pulkomandy:

Previewing videos is difficult, a naive approach would be to decode the first frame but that is often completely black, so smarter code is needed.

Stumbled on something that might help for this, while reading the ffmpeg man page (that thing is a real treasure trove!):

ffmpeg -i in.avi -vf thumbnail,scale=300:200 -frames:v 1 out.png

Tested on a couple videos, seems to work. Probably needs tweaking to make it read more than just 100 frames.

[danboid]

This is still one of my most wanted missing features of Haiku but I'd imagine this might have to wait until post 1.0 now?

128x128 pixel thumbnails aren't much use when 4K displays are increasingly common so they'd really need to scale larger than that in order for it to be useful.

[jscipione]

More recent progress on this: ​https://insightfactory.tumblr.com/image/190955136557

[bitigchi]

​https://review.haiku-os.org/c/haiku/+/3163

[jscipione]

Implemented in hrev55348.