Withdrawn: No more blurry album covers!

[seashell]

Same problem in firefox on windows 10. First time it's loaded Moode. Comes up in album view at top. I click "S" and it takes me to "P" in my library.

No problem on "old Edge". Takes me to "S". I suspect it's not lazy loading.

Edit: No "old edge" is lazy loading, not sure what it does differently than chrome and firefox.

[seashell]

Just installed latest chrome on Win10 as well and it has the problem too. It got me to "O" when I clicked "S". Three clicks on S finally got me to a stable position. Actual number of clicks seems to vary slightly between cache cleared reloads.

With my changes works every time in all the browsers I've tested.

Actually more poking at old edge shows it has a lesser version of the problem. Clicking a letter will still cause the page to move twice in some cases just a small amount than chrome/firefox.

I have no Apple stuff so I can't compare how Safari works.

[Tim Curtis]

The lazy load is active on Safari but what may not be obvious is that there are two different lazy load mechanisms available. The first is a JS based lazy load script that does use placeholders. The second is a Browser integrated native lazy loader which I don't think uses place holders.

Chrome and possibly FF have native lazy loading which moOde will use instead of the JS based lazy loader.

Using Chrome I do see where clicking an index letter doesn't position to the correct item since as you pointed out there are no place holders for the images and the page length will be off.

You could force the JS based loader to always be used by modifying /var/www/js/scripts-panels.js. The code block is near the top. Set the GLOBAL to false.

Code:

   // Check for native lazy load support in Browser
   // @bitkeeper contribution: https://github.com/moode-player/moode/pull/131
   if ('loading' in HTMLImageElement.prototype) {
       GLOBAL.nativeLazyLoad = true;
   }

[swizzle]

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

The max image size is the space allocated on the screen to display the image, if you have a 2000x2000 image it’s not going to look any better than 700x700 if 700x700 is all the space there is. There may be some slight super sampling benefit from scaling down wrt smoothness but I think sharpness is the desire here. There will always be some degree of scaling because the image won’t ever be exactly the size of the space allocated for it, downscaling is obviously better than upscaling.

The bypass I meant was to have an option to not use a thumbnail image at all and to display the album cover art instead. I don’t see any point to thumbnails > 800px and 600px is probably more reasonable. With a bypass and a system that’s fast enough you can get perfect results without any additional lossy compression.

The size of the image grows rapidly after about q60, a 800x800 image at q90 can be 400-500k which is larger than most publicly available (i.e. not press kit) images. We don’t want people thinking they want maximum quality and choose the highest possible settings and end up with a slower system than if we’d just used the orginal cover art. A png thumb would be > 1MB for 800x800 and again wouldn’t offer any benefit over the original cover art.

...

I wrote a routine to calculate the HxW of the thumbnail images and add them to the image element instead of using css at one point as it was supposed to help native lazy load performance according to a comment on the Chrome bug tracker for the feature but I didn’t notice any real improvement and it bloated up the list a bit, it might help with the jitteriness of scrolling up.

[Tim Curtis]

Unfortunately the word "quality" associated with a number is definitely an issue because human nature being what it is we will always go for the highest value. "Bigger is better" as the saying goes.

What's really needed at this point to figure out whats best is some sample images.

@fmaxwell, zip up some sample covers and PM me a download link. I'll resample them at various resolutions and quals and post the resulting images.

[seashell]

The lazy load is active on Safari but what may not be obvious is that there are two different lazy load mechanisms available. The first is a JS based lazy load script that does use placeholders. The second is a Browser integrated native lazy loader which I don't think uses place holders.

I did see that but since all my browsers support the native version I didn't realize your js version inserts place holders. It also inserts a "MoOde" generic image if the cover image link is broken. Probably explains why "old edge" essentially worked as I bet it doesn't support native lazy loading.

The native version doesn't have place holders nor an image fallback. My code inserts responsive place holders. They work fine with your js code and the native version, but I suppose logic could be put in place to only insert them for the native version.

Another odd thing I just noticed and have no idea where the code is for this, but the local display if turned on doesn't use lazy loading at all. It loads all the images right up front. I had to look because the janky scrolling doesn't happen on it even though it's chrome.

I do hope you'll test the place holders along with the all artist mod (since they're now in the same push request.) If the place holders work for you some of the styling can be moved to your css files and maybe it can be disabled when your js library is in use.

The janky scrolling is really annoying on my phone. So much so that if I want to scroll up I actually click a letter higher up than I need and scroll back down.

[Tim Curtis]

For sure 'll review and test your PR. It's just a matter of clearing my backlog of other TODO stuff. Everything is priority 1, you know how that goes...

I wasn't even aware of the place holder / list length issue with native lazy load and so your contribs have already been very useful :-)

[seashell]

For sure 'll review and test your PR. It's just a matter of clearing my backlog of other TODO stuff. Everything is priority 1, you know how that goes...

I wasn't even aware of the place holder / list length issue with native lazy load and so your contribs have already been very useful :-)

Yep I understand too much to do and too little time/energy to do it.  No rush from me as I've already go the changes hacked in and working in my setup.

The lazy image artifacts have been there since I started using Moode not too long ago.  So I was shocked when you came back and said you'd never seen them.  

[Miss Sissy Princess]

The max image size is the space allocated on the screen to display the image, if you have a 2000x2000 image it’s not going to look any better than 700x700 if 700x700 is all the space there is. There may be some slight super sampling benefit from scaling down wrt smoothness but I think sharpness is the desire here.

The limitations in moOde 6.7x doesn't mean that 7.x and/or later can't be enhanced to take advantage of 8K or larger monitors using a larger size (the largest of which I suggested was 1000x1000).

[quote pid='24857' dateline='1600380840']
There will always be some degree of scaling because the image won’t ever be exactly the size of the space allocated for it, downscaling is obviously better than upscaling.

[/quote]

That's why it would be better to downscale it from an 800x800 thumbnail than to upscale it from a 400x400 thumbnail.

We don’t want people thinking they want maximum quality and choose the highest possible settings and end up with a slower system than if we’d just used the orginal cover art. 

All you have to worry about as a developer is choosing reasonable defaults that will work well for most users with typical setups and personal priorities.  Users of video games adjust anisotropic filtering, full screen anti-aliasing, texture resolutions, motion blur, view distance, fog quality, ambient occlusions, and shader quality, all while balancing off performance vs. display quality. So I think that moOde users can be trusted to adjust album art thumbnail size and quality, especially since it's only those users who are dissatisfied with the default settings.

A png thumb would be > 1MB for 800x800 and again wouldn’t offer any benefit over the original cover art.

I'll give you a perfect example of where an 800x800 PNG has an advantage.  Here's a 3.2MB, 1500x1500 JPEG of the album art for the soundtrack of 2001: A Space Odyssey.

Resized to an 800x800 PNG, it clocks in at under 1.5MB.

PNGs offer advantages over of JPEG, especially in images that include text, like most album covers.  

JPEG, unlike JPEG XS. is not designed for high multi-generation robustness.  It's DCT data compression algorithm is optimized for a single generation encoding from a lossless image source, much as MP3's data compression is optimized for a single generation encoding from a lossless audio source.  As you make JPEGs of JPEGs, you increase the artifacting in ways that become more visually apparent.

Note:  I understand that PNG is off the table for reasons of code complexity.  Nothing in this message should be interpreted as my suggesting that is the wrong choice.  It's just a technical discussion.

[Tim Curtis]

For sure 'll review and test your PR. It's just a matter of clearing my backlog of other TODO stuff. Everything is priority 1, you know how that goes...

I wasn't even aware of the place holder / list length issue with native lazy load and so your contribs have already been very useful :-)

Yep I understand too much to do and too little time/energy to do it.  No rush from me as I've already go the changes hacked in and working in my setup.

The lazy image artifacts have been there since I started using Moode not too long ago.  So I was shocked when you came back and said you'd never seen them.  

Running an Open Source project means relying on others. I do my part of the dev on Mac/Safari. Other parts are done by the moOde crew in their own dev environments. The Open Source community and our nice community of moOde users provides other parts of moOde.

No need to be shocked :-)