Reposted by request: Thumbs resize desperately needs rethink

Ideas for improvements and requests for new features in XnView MP

Moderators: XnTriq, xnview

Post Reply
User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Reposted by request: Thumbs resize desperately needs rethink

Post by JohnFredC » Thu Oct 28, 2010 3:36 pm

I really appreciate the thumbnail size slider in MP. :D

Well, I WOULD appreciate it if its behavior was changed. 8)

The benefit of the thumbnail size slider control is the dynamic interface it provides for scaling thumbs "on the fly". If one needs more thumbs displayed, move the slider. If one needs bigger thumbs, move the slider. This is great, but... moving the thumb slider ALWAYS re-reads the image files.

This is NOT great (awful, actually) because:
  • a) For large images, and esp. lots of large images, it simply takes too long to resize the thumbs. Note that a user typically makes thumbs smaller in folders that have many images. So the browsing benefit to cached thumbs is defeated by the time needed to resize them.

    b) After resizing, there is no way to quickly return to the original thumb size preferred by the user for most folders or that fits the current layout. This means the user must "twiddle" with the thumb slider... and every "twiddle" with the slider forces a resize operation from the original files in the thumb cache! Esp. on folders with lots of big (<100MB) images or lots of folders full of images this is completely unacceptable. One of my folders takes 5 (five!) minutes to resize the thumbs.

    c) Navigation to another folder always rebuilds its thumbs to the new size, even though I don't want this! It is very unproductive to have to await the thumb resizing, esp. when I don't want it to occur at all, or to try to estimate the correct size with the slider! Again, one of my folders takes 5 (five!) minutes to resize the thumbs.
Because of all of these issues, I think the thumbnail situation/process needs radical change. Repeat: RADICAL CHANGE. Here are my suggestions:
  • 0. GUIDING PRINCIPLE: Avoid re-reading the original file at all costs unless the user requests it or the original file itself has changed.

    1. Completely abandon both the current thumbs slider behavior and the thumbnail/image resizing paradigm, which is based on thumbs cartouche size and which causes MP to unnecessarily reread the original file over and over (and over and over) again.

    Instead: make the thumb slider specify how many columns and/or rows of thumbs to show in the thumbs panel.

    2. Save the number of columns and/or rows for each folder separately AND/OR...

    3. ...save the number of columns and/or rows for each browser layout. Currently (in MP 0.30 and all other versions of XnView) the thumbnail cartouche size and browser layouts are disconnected from one another. IMO this is crazy.

    4. Allow the user to specify thumbnail image resolution separately from thumbnail cartouche size. 3 resolutions should be sufficient: "coarse", "medium", "fine", for instance.

    5. Initially default to "intelligent" values for the three resolutions based on screen dimensions at installation, but give the user the ability to change them/rebuild them/store them.

    6. Build and store the 3 resolutions (course, medium, fine) for each image file into the cache when the user initially enters each folder (or specifies rebuild thumbs), or when MP detects that an image file has changed, or when the user makes changes to the ini settings.

    An efficient way to do this would be to extract/build the "fine" thumbs image first and then rescale the other two resolutions from it. This avoids reading the image file more than once.

    7. Allow user to define thumbnail cartouche "info" layouts independently of thumbnail image resolution and for each of three cartouche sizes. For me, three thumbnail "info" layouts (no info, some info, lots of info) would be sufficient.

    A "small" thumb cartouche would display the "no info" layout, a "medium" size cartouche would display "some info" (perhaps just the filename), and a large cartouche the "lots of info" layout. The visibility of thumbnail icons/symbols should also be specifiable for each "info" layout.

    8. When the user moves the thumbnail size slider:
    • a) Change the number of rows and/or columns of thumbnails displayed in the panel.

      b) Change the thumbnail cartouche size to fit the rows and/or columns of thumbs exactly into the thumbs panel.

      c) Change to the thumb "info" layout (small, medium, or large) that best fits the newly calculated thumb cartouche size.

      d) Display the appropriate thumbnail image resolution from one of the three stored sizes ("coarse" for small thumbs, "medium" for medium thumbs, "fine" for large thumbs) without rereading the original image files!

      e) Finally, to make everything fit perfectly, adjust the thumbnail spacing to evenly fill either the width or height of the thumb panel (no wasted space) based on the aspect ratio of thumbnail panel width/height.
    8. When the user resizes the thumbnail panel...
    • a) Incrementally change the size of the thumbnails cartouche AND spacing to maintain the number of rows and/or columns panel previously set by the thumb slider. If necessary, automatically switch to the thumbnail info layout that best matches the new thumb size.
    9. Again: whenever MP must resize the thumbnail cartouches, resize the displayed thumbnail image from the currently displayed cached resolution! Do not rebuild the cached thumb from the original image itself without asking the user!

    For instance, when resizing the thumbs panel (or moving the thumbs slider) causes the thumb cartouche size to select for the "some info" thumbs layout (but not yet large enough for the "lots of info" layout), rebuild the thumbnails image to fit the thumbs cartouche by resizing the assigned "medium" cached image, NOT by rereading the image file itself. Avoid re-reading the original file at all costs unless the user requests it.
SUMMARY

This is a complex approach to explain and I apologize for that, but it should make the thumbs situation much, much faster!
John

User avatar
XnTriq
Moderator & Librarian
Posts: 5434
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: Reposted by request: Thumbs resize desperately needs ret

Post by XnTriq » Sun Oct 31, 2010 3:30 am

Thank you for this very comprehensive analysis, John!
This post is a very good basis for starting a discussion about how to optimize a feature with great potential.
JohnFredC wrote:Instead: make the thumb slider specify how many columns and/or rows of thumbs to show in the thumbs panel.
The more I think about this idea, the more I like it.
As you've already stated, this is a complex issue, and there are many factors that have to be taken into account.
Unfortunately I'm still struggling to reproduce certain bugs right now :|

User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Re: Reposted by request: Thumbs resize desperately needs ret

Post by JohnFredC » Sun Oct 31, 2010 2:14 pm

Thanks for your response, XnTriq!

I notice that the thumbstrip in MP's Compare panels responds very quickly to resizing, apparently without re-reading the thumbs from the original files. Perhaps some of the code that supports the thumbstrips could be ported to the Browser thumb panel...
John

Post Reply