Free size of thumbnails

[Krodo]

In the regular version of XnView you can set the size of the thumbnails totally free. I miss this option in XnViewMP for I prefere quadratic thumbnails so that the shown area of the thumbnails is the same regardless of the pictue is taken in landscape or in portrait mode.

[helmut]

+1 Support of custom thumbnail sizes is really needed. (Using the slider you can set the thumbnail size to any size, but the width/height ratio cannot be changed.)

[XnTriq]

Even if it's already possible into the xnview.ini file :

Code: Select all

...
[Browser]
...
thumbWidth=150
thumbHeight=113
...

[Krodo]

I already set this options with a text editor. But I would like to change it via the GUI. An alternate idea would be an option in the GUI to fix the aspekt ratio of the thumbnails. So I could fix it to 1:1.

[m.Th.]

I already set this options with a text editor. But I would like to change it via the GUI. An alternate idea would be an option in the GUI to fix the aspekt ratio of the thumbnails. So I could fix it to 1:1.

In fact, I would link this request with this one: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28952 and more specifically with this post: http://newsgroup.xnview.com/viewtopic.p ... 52#p115322

IOW, on top of the menu/list customization engine add a small form like this to edit the thumb's dimensions:

Thumb-Dimensions.png (10.21 KiB) Viewed 4212 times

[thibaud]

Someone please en-light me as to what the thumbnail ratio would do ?
AFAIK Thumbnails are strictly using the original image ratio. (and I fail to see any good reason why anyone would want to change that, cropped thumbnails ?)
Perhaps are you talking about the "thumbnail cell" which is conveniently square (most probably like in any image manager I can think of)
I have nothing against custom ratio for thumbnail cells but I do have doubts about the usability of this feature though.
can anyone give an example of workflow where non square thumbnail cell would be useful ?

on a related subject I do dislike the idea of having wasted screen space:
http://newsgroup.xnview.com/viewtopic.php?f=60&t=16300

[JohnFredC]

Hi Thibaud,

The thumbnail ratio setting would change the vertical and horizontal dimensions of the rectangle that contains the thumb image. (This is about display only, not database storage.)

IMO "Aspect ratio" and "Thumbs across" are a much more direct and efficient way of fitting thumbs to the panel.

1:1 is useful for folders with an even mix of both portrait and landscape images. But for folders dominated by one or the other orientation, 1:1 becomes increasingly inefficient.

For instance, I have many (many!) folders of horizontal panoramas. Compare three approaches to displaying their thumbs below.

(I rest my case).



PS. Perhaps "Height" is a more user friendly term than "Aspect ratio"?

[thibaud]

Hi Thibaud,
1:1 is useful for folders with an even mix of both portrait and landscape images. But for folders dominated by one or the other orientation, 1:1 becomes increasingly inefficient.
For instance, I have many (many!) folders of horizontal panoramas. Compare three approaches to displaying their thumbs below.

Ok
My opinion is that unless I have to work for a very long period (a very huge folder) in a specific folder only containing a unique format of images that strongly deviates from the 1:1 ratio,
going through the length of adjusting a thumbnail ratio that I will have to change back again once I get back to my normal workflow is probably not something I will do.

In any case I think a modal window with width and height slider (as kindly proposed by M.Th) would definitively not be the most efficient solution.
IMO, a more elegant solution would be to be able to simply drag the border of any of the rows to re-size them all.
this would allow adjustment (with instant visual feedback) in a single click.

[XnTriq]

AFAIK, all thumbnail browsers (Windows Explorer, XnView, ThumbsPlus, FastStone Image Viewer, etc.) are based on a grid layout with wrapped lines:

Code: Select all

[1] [2] [3] [4]
[5] [6] [7] [8]
[9]

A flexible Masonry type of table/grid would generate thumbnails of varying sizes and place them where they fit in (think Tetris):

Code: Select all

[22222] [5] [88]
[77] [4] [11111] 
[77] [9] [11111]
[77] [3333] [66]

I've been thinking about “adaptive thumbnail sizes” for...

• Panoramic (stitched) photos
• Screenshots of web pages
• Large format printing
• Toolbar skins

... myself in the past.

The idea was that the thumbnail would span (horizontally or vertically) over more than one cell of the grid, if the dimensions of an image exceed a certain ratio (specified by the user).

[JohnFredC]

My opinion is that unless I have to work for a very long period (a very huge folder) in a specific folder only containing a unique format of images that strongly deviates from the 1:1 ratio,
going through the length of adjusting a thumbnail ratio that I will have to change back again once I get back to my normal workflow is probably not something I will do.

I completely agree. For my part, I'm just not moving that slider very often. That's why I would like the thumbnail aspect ratio saved with the folder.

In any case I think a modal window with width and height slider (as kindly proposed by M.Th) would definitively not be the most efficient solution.
IMO, a more elegant solution would be to be able to simply drag the border of any of the rows to re-size them all.
this would allow adjustment (with instant visual feedback) in a single click.

I agree with this too. For me, a slider (the current control) to adjust the number of columns, and a drag border between the rows of thumbs to adjust the height (aka "Aspect ratio") would be ideal.

[thibaud]

My opinion is that unless I have to work for a very long period (a very huge folder) in a specific folder only containing a unique format of images that strongly deviates from the 1:1 ratio,
going through the length of adjusting a thumbnail ratio that I will have to change back again once I get back to my normal workflow is probably not something I will do.

I completely agree. For my part, I'm just not moving that slider very often. That's why I would like the thumbnail aspect ratio saved with the folder.
I agree with this too. For me, a slider (the current control) to adjust the number of columns, and a drag border between the rows of thumbs to adjust the height (aka "Aspect ratio") would be ideal.

I'm not sure that saving the thumb ratio in the folder (or worse in the db) would be a good solution.
I fear that this would be the source of all sorts of problems (folder content change, write rights,etc..)
If adjusting the global cell ratio would be made as simple as dragging the row border all the hassle than per folder settings saving will bring could be avoided.

Also, Like XnTriq exposed a global setting is still certainly less effective in terms of screen space optimization than a per thumbnail ratio (aka masonry grid) for most real life situations (mixed images ratios).

Personally I can live with square cells grid...
But (as I'm not aware of any other image manager providing this feature) having a global ratio adjustable in a single click might give MP an edge compared to it's competitors.
So yes this could be a welcome feature (looking at qt doc I think it should be quite easy to implement too)

I'm more skeptical regarding the masonry (per thumbnail ratio) grid implementation though for a couple of reasons:

• Feasibility I'm pretty sure that Pierre is using native Qt component (GridView perhaps) I doubt that he will be exited to code a new masonry type gridView.
• Performance no doubt that this will add a serious overhead to the grid drawing process.
• Layout approximations alright I may be nitpicking but as you know pictures are not bricks so I'm not sure I understand how you'd do to keep the grid outer border (left or right) straight (remember than we want to fit the grid to the window) what's certain is that you'd definitively throw away the column number control.

[XnTriq]

To me, the Masonry approach isn't so much about optimzed use of screen real estate or aligning thumbnails along both the left and right margin (justification) of the pane. I like the concept, because it might enable XnView's browser to better accommodate thumbnails of images with mixed aspect ratios.
Perhaps an option to switch between style sheets (table-less/fluid vs. table-based/fixed grid) might offer a way to quickly change the thumbnail layout without sacrificing too much in terms of performance.

• Qt Project
  • QAbstractListModel Class
  • GridView

I hope I'm making sense. Unfortunately I can't be as elaborate as I would like, because I'm too busy.

[thibaud]

To me, the Masonry approach isn't so much about optimzed use of screen real estate or aligning thumbnails along both the left and right margin (justification) of the pane. I like the concept, because it might enable XnView's browser to better accomodate thumbnails of images with mixed aspect ratios.

I fail to see any difference between "better accommodate" and "optimized use of screen real estate".
the goal is just the same. (note that the idea to use justification to extend the grid to the pane borders does plays a role in that optimization process by allowing bigger thumbs for the same pane)

[XnTriq]

OK, let me try to explain the different options (as I understand them) with the help of this three-frame animation:

• 
  [ z00m ]

1. Actual screenshot of XnView with thumbnail size set to 160×160 (square)
2. Fake screenshot of XnView with thumbnails of variable width (“colspan”)
3. Fake screenshot of XnView with thumbnails of variable width but fixed identical height

What's not included in my simulation is the PaperPort approach where thumbnails seem to be displayed in a proportional manner, i.e. thumbnails of letter-size scans are bigger than those of scanned CD artwork or receipts or whatever.

• paperport_ui-lg.jpg
• B002JB3CUS-1.jpg
• 71BO5KGmMaL.jpg

XnView is many things to many people. Some may even prefer PhotoScape-style grids.

See also JohnFredC's screenshots:

• Re: Integration of a LIGHT TABLE function in XnView
• Re: Image basket

[JohnFredC]

I think the masonry approach mentioned by XnTriq would be particularly suited for a thumb panel mode we haven't mentioned in this thread yet: "Group By" mode.

This clip from Corel PSP X2 best illustrates the concept of a "Group By" panel (thumbs grouped by a date value):



In "Group By" mode, the "ragged right" margin would be expected by the user (since each band would typically have a different number of thumbs).

Accepting "ragged right" for a potential masonry thumbs / group by display mode would side-step the complexity of the thumb size algorithm required to fit the thumbs (in masonry mode) exactly to the width of the panel.

One other remark: Any mode that displays thumbs of varying shapes in one panel will be problematic for caption/label layout.