Withdrawn: No more blurry album covers!

[Tim Curtis]

I could see where the "bypass" option would prolly be better than offering "high res" sizes that would likely result in worse image quality and performance due to downsampling via PHP routines, and mislead users into thinking that the higher resolutions would improve thumb qual.

Maybe there is a misunderstanding about what happens when an image is downsampled to a lower resolution. This operation removes a lot of pixels and to compensate for the pixel loss the algorithms that perform downsampling perform tricks to make the resulting smaller image look decent to-the-eye. It works to a point.

The "bypass" option would leave the image resampling up to the Browser which prolly does a pretty good job considering that Browser image handling is super ultra optimized.

[Miss Sissy Princess]

Making the thumbnails larger won’t improve the resolution of your display, the largest a thumbnail image (6/2 currently) can only ever be ~700px for your display. 700px x 6 = 4200px with the remainder being spacing between thumbs and the screen edges.

I think a better option for users that find themselves in a similar situation might be a setting to bypass thumbnails (or at least large thumbs) and instead use the original image instead of generated thumbnails.

I first began developing software in the 1970s and spent my career in engineering, so I have a reasonably good understanding of how display resolution works and that software can't increase the physical number of pixels on the screen.

Since the cover art is tack-sharp when displaying the album art next to the track list, but less so when displaying the smaller thumbnails, the problem is almost certainly the thumbnail resolution of 400px being interpolated into more pixels for display on the my monitor.  Given that there are already 8K monitors, and undoubtedly higher resolutions on the way, it seems sensible to include some resolutions, and quality settings (maybe a PNG option) that are more than I, or you, need today.

[Miss Sissy Princess]

I could see where the "bypass" option would prolly be better than offering "high res" sizes that would likely result in worse image quality and performance due to downsampling via PHP routines, and mislead users into thinking that the higher resolutions would improve thumb qual.

Maybe there is a misunderstanding about what happens when an image is downsampled to a lower resolution. This operation removes a lot of pixels and to compensate for the pixel loss the algorithms that perform downsampling perform tricks to make the resulting smaller image look decent to-the-eye. It works to a point.

The "bypass" option would leave the image resampling up to the Browser which prolly does a pretty good job considering that Browser image handling is super ultra optimized.

If most all of my artwork is 1000x1000 or better, how will I get worse image quality with 800 pixel thumbnails than with 400?  

At some point, I'd let dumb users do dumb things rather than tying the hands of users who understand that it's a bad thing to go from 320x320 album art upsampled to 1000x1000 and then downsampled to 400x400 for display on a laptop screen.

My concern with a bypass option is that it might move massively more data than necessary when someone has really large album artwork.

How about an option to set the maximum thumbnail size (in pixels)?  The album art goes in at the native size if it is smaller than the selected maximum; otherwise it gets downsampled to the maximum size.  

[Tim Curtis]

Right, the 800's will have more pixels than the 400's and should appear better looking to the eye depending on the display resolution. What @swizzle is talking about is that moOde's album grid layout impose a max image size so even for the highest res display, thumbs greater than 800px would be in the "diminishing returns" space.

Ah, of course since the routine knows the source image width and height it would be trivial to check that and only downsample the image if target W * H < source W * H. Good idea :-)

What I might try is having separate options for resolution and quality. Something like below. There's plenty of time b4 7 ships to get this feature nailed down.

Resolution [ ]
Auto
Bypass
400
600
800

Quality [ ]
60
70
80
90

[Miss Sissy Princess]

I think Swizzle and I were talking at cross-purposes. My reasoning for higher than 800 pixel images is "future-proofing" - and I should have said that I would expect the grid layout to be updated to make use of any higher resolutions for very high resolution monitors (8K is coming).  But that's not a must-have right now and I realize that it wouldn't buy anything without that corresponding change to the grid layout.

Ah, of course since the routine knows the source image width and height it would be trivial to check that and only downsample the image if target W * H < source W * H. Good idea :-)

See, I don't just cause strife and anger. 

If all of your cover art is 600x600, setting a maximum thumbnail size of 800x800 would effectively be "bypass."  Everything would be stored at its native resolution.

What I might try is having separate options for resolution and quality. Something like below. There's plenty of time b4 7 ships to get this feature nailed down.

I think that's the best approach.  

I'd make it clear that the user would be choosing the maximum resolution (rather than upsampling small images into larger ones) as that is important for all the reasons we've been discussing (bandwidth, storage, RAM, etc.).

Please consider a PNG option as the highest setting under "Quality."  Like MP3, JPEG is designed for a single encoding from a lossless source.  To use an analogy for the resizing of cover art, would you start with a 24/96K WAV, encode that to a 192K MP3, transcode that to 128K MP3, and then decode that and resample it to 16/48K WAV for playback?

Thanks, Tim.

[Tim Curtis]

A PNG thumb option would add a fair amount of complexity to the code. Maybe we look at this post 7.0.0 if the JPEG thumb options are not cutting it.

[Miss Sissy Princess]

A PNG thumb option would add a fair amount of complexity to the code. Maybe we look at this post 7.0.0 if the JPEG thumb options are not cutting it.

Noted.  I clearly underestimated the complexity.  Thanks.

[seashell]

Hey while we're talking album cover sizes, in the album view the lazy loading causes what is typically called "janky" scrolling. You scroll up, new albums load, it pushes you down. You click a letter and it gets you close but not really there. Click it again it gets you closer, etc.

Tim I added four lines to my all artist commit pull request on github that fixes this so that scrolling is smooth and letters go to where they should.

(Sorry they got combined. I'm a git novice.)

[Tim Curtis]

I'm not experiencing the odd scrolling on Safari. What Browser and OS is this happening on?

[seashell]

Android chrome, android firefox, linux chrome, linux firefox. I can't imagine safari doesn't have the problem, but maybe it has a big cache or you have super fast networking. Or maybe your lazyload script doesn't work on Safari and all images load all the time.

You don't load any place holders for the album images, so the page length isn't calculated correctly for the letter jump points. Same thing when scrolling, the page grows as thumbnails get loaded. It's generally more noticeable slowly scrolling up.

If you start at the top of album view and do a (preferably full - meaning discard the cache) reload then click a letter late in the alphabet like "S" on your side pane does it go to that letter correctly? If you click the letter again before you scroll the page at all does it move?

Now I'm going to go fire up the Win10 box and check there.