MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Ideas for improvements and requests for new features in XnView MP

Moderators: XnTriq, xnview

User avatar
xnview
Author of XnView
Posts: 31793
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by xnview » Wed May 09, 2012 3:12 pm

JohnFredC wrote:
Can you explain your wish number 2 ? The number of thumbs across is dependent on the thumbnail size, do you want to "make 4 pics" and the thumbs resize accordingly with the size of the xnview window or do you want them so we have horizontal scrollbars? I don't want to scroll horizontal, I do that enough in the directory pane already where it is unavoidable
No horizontal scrollbar, no wasted space. Always an integer number of thumbs across the thumb panel.
Yes will be great, but currently i don't know how to do that if i don't have multiple resolution thumbnails in the DB :(
Pierre.

Jou
Posts: 50
Joined: Sat Nov 03, 2007 9:38 pm
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by Jou » Wed May 09, 2012 9:00 pm

xnview wrote:
JohnFredC wrote:
Can you explain your wish number 2 ? The number of thumbs across is dependent on the thumbnail size, do you want to "make 4 pics" and the thumbs resize accordingly with the size of the xnview window or do you want them so we have horizontal scrollbars? I don't want to scroll horizontal, I do that enough in the directory pane already where it is unavoidable
No horizontal scrollbar, no wasted space. Always an integer number of thumbs across the thumb panel.
Yes will be great, but currently i don't know how to do that if i don't have multiple resolution thumbnails in the DB :(
If you read my suggestion in http://newsgroup.xnview.com/viewtopic.p ... 92#p103154 -

Can it work to scale only for viewing? When I move the slider (even if xnview is still reading the pictures to create thumbs) the scaling routine seems to be lighting fast, and shows smaller-than-cached thumbs in good quality.

xnview just loves to crash when I use the slider to often within a short time *g*. I'll make that an extra topic.
Gaming in 4k / 6k / 8k / 15k? Yes! http://joumxyzptlk.de

User avatar
xnview
Author of XnView
Posts: 31793
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by xnview » Thu May 10, 2012 7:16 am

Jou wrote:If you read my suggestion in http://newsgroup.xnview.com/viewtopic.p ... 92#p103154 -

Can it work to scale only for viewing? When I move the slider (even if xnview is still reading the pictures to create thumbs) the scaling routine seems to be lighting fast, and shows smaller-than-cached thumbs in good quality.
So scaling thumbnail? But which size to use?
Pierre.

Jou
Posts: 50
Joined: Sat Nov 03, 2007 9:38 pm
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by Jou » Thu May 10, 2012 1:22 pm

xnview wrote:
Jou wrote:If you read my suggestion in http://newsgroup.xnview.com/viewtopic.p ... 92#p103154 -

Can it work to scale only for viewing? When I move the slider (even if xnview is still reading the pictures to create thumbs) the scaling routine seems to be lighting fast, and shows smaller-than-cached thumbs in good quality.
So scaling thumbnail? But which size to use?
I hope you don't mind my syntax here, my coding times are 15+ years away (except for things which are not worth mentioning in freebasic).
int used to cut of everything behind the comma "in my times", i.e. always round down.
All vars are int.
ThumbnailWidth is the Width of the Thumbnail as defined via the zoom bar or the option menu.
WindowsWidth is the width of the viewable area (not whole xnview).

NumberOfPicturesPerRow = (WindowWidth+ThumbnailWidth-1) / ThumbnailWidth
ThumbnailWidthViewOnly = WindowWidth / NumberOfPicturesPerRow

You _could_ use float for ThumbnailWidthViewOnly if your scaling routine can handle it, makes it smoother.
If you need the ScalingFactor instead of ThumbnailWidthViewOnly:
ScalingFactor = (WindowWidth / NumberOfPicturesPerRow) / ThumbnailWidth

The complex part: I completely ignored the the border around the thumbnail, my example only works for BorderWidth=0.

My try with Border looks like this (if I didn't miss something obvious):

NumberOfPicturesPerRow = (WindowWidth+ThumbnailWidth+BorderWidth*2-1) / (ThumbnailWidth+BorderWidth*2)
ThumbnailWidthWithBorderViewOnly = WindowWidth / NumberOfPicturesPerRow
ThumbnailWidthViewOnly = ThumbnailWidthWithBorderViewOnly - BorderWidth*2
Gaming in 4k / 6k / 8k / 15k? Yes! http://joumxyzptlk.de

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

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by JohnFredC » Thu May 10, 2012 2:55 pm

Pierre wrote:
But i can't save multiple resolution thumbnails in the database (already big)
Storing additional thumb resolutions in the db (by adding blob fields to the file record) is probably not a good idea. A user might choose to save more than one "large" thumb size, for instance, and have a very large number of images cached.

Marsh wrote:
Why not store miniatures individually on all platforms?
...and Jou responded:
filesystem clutter without end? And if you have large amounts of pictures (including your LAN, i.e. NAS) having the same amount of single files in you home directory (or %appdata%) ? The horror!
A properly contained file structure for the miniatures might prevent "system clutter". Perhaps a single parent folder that could be deleted from within MP. But prime facie the proliferation of "miniatures" should be avoided.

What about a "middle ground"? Allow the user to choose to cache the "miniatures" to a db file saved with the image files.
  • • The central database could persist as currently implemented for general purpose browsing and image search.

    • The local folder's .xnviewsort data would be combined with the cached image data into a db file. The name of the db file might be something like foldername.xnfldrdb.

    • A new menu item (or option) "Prefer data cached in this folder" might automatically create the .xnfldrdb in the current folder (...but only when asked. :wink: ).

    • On entering a folder, MP would look to see if an .xnfldrdb was present and load the miniatures (and the custom sort sequence and ...maybe even... thumb layout with aspect ratio and a saved browser layout) from it, otherwise revert to the central db.
There are subtle issues hiding behind this proposal that might prevent a clean implementation. Perhaps Pierre's labor for such a schema might be better served elsewhere in MP.

Nevertheless, user-optional, individual, "folder-local" thumbs et al dbs might reconcile the database size and file proliferation objections to the "multiple miniatures" idea.
John

Jou
Posts: 50
Joined: Sat Nov 03, 2007 9:38 pm
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by Jou » Thu May 10, 2012 3:26 pm

JohnFredC wrote:...and Jou responded:
filesystem clutter without end? And if you have large amounts of pictures (including your LAN, i.e. NAS) having the same amount of single files in you home directory (or %appdata%) ? The horror!
A properly contained file structure for the miniatures might prevent "system clutter". Perhaps a single parent folder that could be deleted from within MP. But prime facie the proliferation of "miniatures" should be avoided.
From my experience: It is easier to handle one .db file, including limiting it's size, than handle several 100000 single files + DB info on various platforms.
It is also a matter of disk space since the cluster size on most filesystems is 4K, wasting an average of at least 2k for every thumbnail, + the directory which gets fragmented too. Have you ever experienced when a DIRECTORY is fragmented since several 10000 files are in there? Do not test in one copy job, that won't show the problem, the number of files has to grow slowly with other write operations in between - like the real world with xnview browsing is. No OS (including linux) handles this gracefully, once the performance is too low you either have to copy / move it into a new directory (linux and Windows) or run a defrag (Windows) - though Win7 defrags automatically when the system is idle, but does not defragment directories.
Real-World example for Linux: That directory fragmentation problem is the reason why the squid cache uses such a pre-created directory structure.
Real-World example for Windows: My Machine here, defragmenting the affected directory is done on a regular base.
In a .db it does not pose a problem, a compress/compact run and everything is fine, no matter which platform or filesystem.
In a .db it is easier to kill "old" thumbnails which simply aged out, or it's original doesn't exist any more.

I know there are filesystems out there who can do it a bit better than EXT4/NTFS/FAT, but those three are the most used.
Gaming in 4k / 6k / 8k / 15k? Yes! http://joumxyzptlk.de

marsh
XnThusiast
Posts: 2443
Joined: Sun May 15, 2005 6:31 am

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by marsh » Fri May 11, 2012 8:25 pm

I am advocating integration with recent linux file managers. The folder structure on NTFS need not match EXT4, etc. if there is a severe difference between them. With folder names in settings matching the originals, a high count shouldn't be much of a surprise. Leaving it up to users not to overload the image folders which they normally use. I have tried to make scripts for my own use which create subfolders with a few hundred images in each one so proliferation of miniatures should not represent any difficult problem. It would be a shame to read about MS FAT limiting possibilities on either OS at least.
Also, transparent thumbnails exist in MP? This seems to contradict lossy compression setting (jpg)- why bother with that??

Jou
Posts: 50
Joined: Sat Nov 03, 2007 9:38 pm
Contact:

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by Jou » Fri May 11, 2012 8:50 pm

I vote for putting the xnview.db vs. single files for thumbs to a different thread, it has nothing to do with displaying them and the AR.
Gaming in 4k / 6k / 8k / 15k? Yes! http://joumxyzptlk.de

marsh
XnThusiast
Posts: 2443
Joined: Sun May 15, 2005 6:31 am

Re: MP 0.48: Thumbnails aspect ration 1:1/5:4/4:3/16:10/16:9

Post by marsh » Sat May 12, 2012 7:26 am

Jou wrote:I vote for putting the xnview.db vs. single files for thumbs to a different thread, it has nothing to do with displaying them and the AR.
The off-topic trumpet was sounded before that offering. Why drag the moderators into it? You can repost what you like in any style.

Post Reply