ViliusL's profile

3 Messages

 • 

110 Points

Thursday, December 1st, 2022 9:12 PM

Closed

Solved

Uncompressed images

Hello,

when viewing galleries, some images are really huge in size (in both dimensions and bytes). 

For example I just got email "See What's Streaming in December" with link to gallery:

https://www.imdb.com/list/ls566562419/mediaviewer/rm3903797761?ref_=pe_43914690_684673780_eml_nws2p

Most of images are fine, but there are few that are not compressed and it takes long time to download/view it even with fast internet. Of course you provide smaller images for smaller browser windows size using srcset (which is very good), but if browser width is greater than 1280px (very common now), sometimes you give original JPG which is not compressed (98% JPG quality) and has huge width and height - see example below.

For example: image below has few issues:

  • width and height is 7644x6062, this is really too big, I guess this is your original image. 
  • file size is 32 MB. Even it is compressed with JPEG, which is really good, but quality is 98%, which is too much.  I believe 90% would be best, optimal.

https://m.media-amazon.com/images/M/MV5BMzRkNTc1MDktODIzMC00YTk0LWFhNTItYzU2NjY5YTFjNzIxXkEyXkFqcGdeQXVyMTUzMTg2ODkz._V1_.jpg

Solutions could be:

  • support additional size like 1920px width, larger browser width is very rare.
  • Do not give users image with 98% quality. This is your original, but you can compress friendly version to users, right, and keep original not public.

I understand that it may require time and resources and priority could be low, but I wanted you to know that this issue exists.

Employee

 • 

729 Messages

 • 

8K Points

2 years ago

Hello @vilius_l_j4o1p50gsefn6,

I've forwarded this information to our technical team for further investigation.

I'll reply once we receive further information. Thank you for your patience!

3 Messages

 • 

110 Points

2 years ago

Additional info: information given above about 1280px was wrong, there are many images, that does not have 1280px resized version, but only with something like 479px max.

p.s. I was previewing gallery with 204 images, and I had to stop after about 20+ images, because user experience waiting for each image to load is ... let just use word "bad".

(edited)

Employee

 • 

729 Messages

 • 

8K Points

@ViliusL​,

Our team is working to investigate and resolve this as quickly as possible.

We'll update this combined thread once we receive further information.

Thanks to you all for your patience.

10.6K Messages

 • 

225.3K Points

2 years ago

The slideshow presentation system of gallery images on IMDb used to automatically take advantage of the scaling-by-URL-data feature for some classes of image hosted through Amazon's content delivery network (CDN), the Amazon Web Services (AWS). A couple of years ago, this was somewhat forgone by IMDb. So, for example, https://m.media-amazon.com/images/M/MV5BMzRkNTc1MDktODIzMC00YTk0LWFhNTItYzU2NjY5YTFjNzIxXkEyXkFqcGdeQXVyMTUzMTg2ODkz._V1_.jpg would be substituted with, say, one of the following URLs:

That's pretty cool, aye?

You may notice that the thumbnail images on IMDb are still generated via this mechanism. Quiet as it is kept, there are quite a number of other awesome things (like cropping and stretching) that can be done with these kinds of URLs. Unfortunately, I only know very little about it. I wonder whether or not there is a way to control the image quality and therefore the file size. I also wonder how much it costs, so to speak, because every time an uncached request is sent to the cloud servers, an image manipulation algorithm has to be executed, which is going to eat some a small bit of computing resources, which can unfortunately slow things down.