Start a new topic
Implemented

Option to create artist thumbnails in different aspect ratios

 It would be great, if I could set a different aspect ratio for my artist thumbnails (1:1, 4:3, 16:10, 16:9).


This would give me back some unused space in artist related views.


> I assume that thumbnail aspect ration should be applied to album thumbnails as well?
Well, since most album covers are 1:1, I don't think this should be applied to those... at least I don't see myself setting album thumbnails to anything else than 1:1... ;-)

For everything else, I've sent you an e-mail.

My suggestion is that we continue to investigate this report over email for simplicity.

I assume that thumbnail aspect ration should be applied to album thumbnails as well?



>>That's perfectly wrong... This is only the maximum frame-size - but all thumbnails vary in real pixel counts. See the attached picture. ;-)

>>Yes, that's exactly how it's working now...

>>If the thumbnail is 160x256px you'll have to pump this up to 256x410px before cropping to 256x256px...

I cannot see why this should occur, during the generation of the thumbnails 256px in width or height is the maximum factor, so the thumbnail should not need to be bigger, thus upscaling should not be neccesary.


This one growed a bit more than I thought, I still think we might speak about different things.


Can you identify an example of two source pictures (any size you like to) and let me know about the expected behavior when:


1) Shown as Large thumbnails in 1:1

2) Shown as Large thumbnails in 16:9

3) Shown as Small thumbnails in 1:1

4) Showin as Small thumbnails in 16:9


Remember that the container of a artist/album item has a static width and height that is dependant on the thumbnails size (the container = the box which should the selected border).

This size must be set static upon startup, it is the constraint that exists for the controls to work.


Thanks.

> Today, when a thumbnail is generated it will be generated in 256*256 pixles.
That's perfectly wrong... This is only the maximum frame-size - but all thumbnails vary in real pixel counts. See the attached picture. ;-)

> In your example it seems like you can have various sized pictures depending on the aspect ratio on
> source file
Yes, that's exactly how it's working now...

> My initial thought was to keep the generating of 256*256px cache files on disc so that does only needs
> to be done once, and apply cropping and scling to the thumbnails when aspect rations are used in
> combination with thumbnail sizes (today only scaling is used)
So you would like to do cropping / scaling on the fly? Well (down-)scaling on the fly seems to be OK, but cropping may look bad, since you might have to up-scale the thumbnail...

If the thumbnail is 160x256px you'll have to pump this up to 256x410px before cropping to 256x256px...

If you're going to create thumbnails for all sizes, ratios and eventually cropping, you should create bigger thumbnails. 400x400px come to mind - this would create 250x400px instead of 160x256px from an original image with 640x1024px.
thsize.jpg
(87.4 KB)

Sorry, now I do not follow how you mean.


Today, when a thumbnail is generated it will be generated in 256*256 pixles. Scaling will occur when needed, no cropping.


Then, when all thumbnails are generated (this takes a while the first time), they can be scaled using the thumbnail sizes without the need of being regenerated.


The same would have been possible no matter if the new modes are always 256 pixels wide with a dynamic height or having a dynamic witdth set by the thumbnails size (256 is always the maximum size).



In your example it seems like you can have various sized pictures depending on the aspect ratio on source file, this will mean that you can get odd sized pictures like you describe above which is not appliciable to a thumbnail which always have a static size of something. 

Also, what you request will result in that cache files will always needs to be regenerated fully when the aspect ratio is changed, which will be a slow operation.

(We might be talking about different things, sorry if so, but I do not quite follow the calculations shown in your post above)


Edit:

My initial thought was to keep the generating of 256*256px cache files on disc so that does only needs to be done once, and apply cropping and scling to the thumbnails when aspect rations are used in combination with thumbnail sizes (today only scaling is used)

I think it should be as it is right now - relative in size, but in a static maximum frame-size.
Static frame-sizes are: 1:1 -> 256x256px, 4:3 -> 256x192px, 16:9 -> 256x144px.

Some examples:

Original image size: 1920x1200px...
...in 1:1 -> 256x160px
...in 4:3 -> 256x160px
...in 16:9 -> 230x144px

Original image size: 600x800px...
...in 1:1 -> 192x256px
...in 4:3 -> 144x192px
...in 16:9 -> 108x144px

If you think about dynamic size (L=256px width, S=144px width), you would need to recreate the thumbnails when switching size, don't you?

Should the values be relative to the selected thumbnail size or static?


Example if static:

Width is always 256px and height is calculated


Example if dynamic:

If thumbnail size = large, width will be 256px and height is calculated

If thumbnail size = small, width will be 144px and height is ~81px when 16:9 is selected


Relative sizes feels a bit more powerful but is also more complex to implement.

Thanks Sven, I will do more tests related to this topic after we have ensured that all functions for 12.1 is stable and working.


Marked as planned for further analysing.

Here are the samples for 1:1 and 16:9.

 

16-9.jpg
(82.8 KB)
1-1.jpg
(103 KB)
I will create a few examples, when I'm back home later today. I think we're talking about something different, because of the upper quick'n'dirty mock-ups...
This is only about pixel-ratio for the thumbnails - not about pixel-ratio of the screen... A 16:9 thumbnail will still be correct on a 4:3 screen. ;-)

>> Designed for 4:3? All thumbnails are 1:1 here!?

Yes, but a standard screen will never show 1:1, it will use 4:3.


Example:

Today it looks fully correct on a display with 1920*1440 (4:3) with 256*256 thumbnails.

If this will be mapped to a "new" 4:3 mode, it should become 256*192 instead.


This behaviour needs to be further tested I think, but on the other side, this will be a user chose so it might not matter at all.

>> I wonder a bit how sizes should be treated 
 Your values are correct. 
 >> Is it really neccesary to have separate setups for 16:9 and 16:10 ? 
 If I can select cropping, 16:9 would suffer. 
 >> today it is actually designed for 4:3, so mapping to 1:1 can make the results weird. 
 Designed for 4:3? All thumbnails are 1:1 here!?

Also, one thing that complicates stuff is that today it is actually designed for 4:3, so mapping to 1:1 can make the results weird.

Yes, that might be a better way around it.


I wonder a bit how sizes should be treated;

1:1 - This is what we have today (assume 256*256)

4:3 - This should be 256*192

16:9 - This should be 256*144

16:10 - This should be 256*160


Is it really neccesary to have separate setups for 16:9 and 16:10 ? 

Login or Signup to post a comment