Can we disable the image compression?

[arrbee99 1815]

Differences are significant! I've not looked at the code but I'm curious why the poster isn't just the full-sized 1500+px image squeezed into the smaller dimension on the movie page.

 

No idea - would it be a performance thing maybe...

[Diedrich 377]

Please try the latest release of emby server. Thanks.

I tried the beta server 3.2.32.12 and I don't think there is any way to make these images look better without manipulation. For example, I viewed a poster within Picasa Photo Viewer and then simply squeezed down the window to the approximate size of the poster in the Emby web view and the result was the same, it's a blurry compression of a beautiful, sharp image.

 

I then took the photo into Photoshop and simply shrunk down the image dimension to that in the Emby web view CSS

<img class="itemDetailImage lazy loaded" src="http://localhost:8096/emby/Items/.../Images/Primary?maxHeight=360&tag=...&quality=90">

and the result is drastic:

Emby Server 3.2.32.12

 

The only way I believe we can get superior images would be for Emby Server to get into the imaging business and do some basic image manipulation. Emby Server would need to go through each primary poster, thumb, banner, art, etc and  resize the image to the desired dimensions, save the new image with a unique name, and then that image would have to be the one called.

 

It's a two-faced coin though:

1. Pro: The resized image is drastically better. Pro: The new file is drastically smaller (181 KB vs 424 KB of the full-sized image) - therefore, web and mobile browsing would be significantly increased, especially when viewing the poster wall in the Movie library view.
2. Con: The image must be manipulated and then saved. For large libraries, this initial process could take some time, like 5 minutes. Con: You have now increased the size of your metadata by another image (granted that new image file size is quite small!)

Edited September 30, 2017 by Diedrich

[arrbee99 1815]

Interesting, Dumb question though. Why do the look fine (well, to me) in ET ?

 

Edit - is it because they're just shrunk less to begin with ? ET shrinks them a bit but the web app shrinks them a lot then I scale them back up again...

Edited September 30, 2017 by arrbee99

[Diedrich 377]

Interesting, Dumb question though. Why do the look fine (well, to me) in ET ?

 

Edit - is it because they're just shrunk less to begin with ? ET shrinks them a bit but the web app shrinks them a lot then I scale them back up again...

I don't know. Are you viewing ET on your computer or TV? I was looking through the Emby Server folders and found a "resized images" folder. I hope those are not the images being used because they just look like the images used when searching for new ones.

[PenkethBoy 2068]

if i understand correctly - Emby takes the original image then uses Imagemagick and more recently Skia to process the image and saves it to the Emby cache and that is the image you see in the interface.

 

So if that is correct Emby is in the "imaging business"

 

I suspect Emby only makes one processed version of the image to be used in all locations in emby so its a compromise and as people are using larger and higher resolution displays these days - their expectation of the quality of the image is going up - maybe the compromise settings need adjusting but as Emby is trying to cover a multitude of platforms and clients this may not be easy.

 

@aarbee99 - are you viewing them on the same screen? the web app is meant for desktop viewing (hence smaller sized images) and ET (if not in desktop mode) from 10 feet away. Does the difference show up if you use desktop mode in ET?

[arrbee99 1815]

The image I posted was of ET running on a PC (27inch 1920x1080 monitor) overlaid on Emby in Chrome running behind it. The poster in Chrome (the one on the left) is enlarged quite a bit using CSS (which would be after the processing Diedrich saw in the code) and zoomed in a bit (only to 110% though). So yes I'm magnifying the Chrome one quite a bit to try to match the ET version and its getting fuzzy, which I guess is to be expected (but it would still be nice if it wasn't).

[PenkethBoy 2068]

does the image quality change if you use ET desktop mode?

[Happy2Play 9780]

The image I posted was of ET running on a PC (27inch 1920x1080 monitor) overlaid on Emby in Chrome running behind it. The poster in Chrome (the one on the left) is enlarged quite a bit using CSS (which would be after the processing Diedrich saw in the code) and zoomed in a bit (only to 110% though). So yes I'm magnifying the Chrome one quite a bit to try to match the ET version and its getting fuzzy, which I guess is to be expected (but it would still be nice if it wasn't).

 

Go to settings-Display and what mode are you in?  default is 'Auto"

 

 

Looks like mode really doesn't matter when you are looking a itemdetail.

Edited September 30, 2017 by Happy2Play

[Jdiesel 1431]

When I was using the .Net Core builds on Linux with no image processor installed I was getting the full resolution images sent to all apps. There were some issues on some apps like the Roku app but for the most part the images looked very sharp and detailed on all apps. You really notice the difference when view ET on a desktop monitor.

[Happy2Play 9780]

Since I don't use ET except for testing I didn't know of the Display modes.  Desktop mode gives the same layout as Web Client.

[arrbee99 1815]

Normally I have ET in Auto. Tried in Desktop mode and the image quality is the same i.e. just as good as in Auto and better than in Chrome.

[PenkethBoy 2068]

Interesting that ET would have potentially a different image to the web app

 

i wonder if ET does not use the quality=90"> flag that the web app does - if that would account for the difference?

[Happy2Play 9780]

Interesting that ET would have potentially a different image to the web app

 

i wonder if ET does not use the quality=90"> flag that the web app does - if that would account for the difference?

 

I doubt it.  As image size alone are larger.  Since images in web client have to be zoomed to present the same size image as ET.  I have to zoom my browser to about 200% to get the image the same size as presented in ET.

Edited September 30, 2017 by Happy2Play

[DragonEmbers 0]

Sorry to open an old thread, but this still appears to be an issue.

 

The source image size: 680x1000

The URI emby uses to get the image has "maxHeight=267&maxWidth=178" (so 178x267)

The container the image is being loaded into is (on my screen, standard size of everything): 176.3x264.45 (when using "Extra large", the container size is: 274.83x412.25)

 

The fetched image, scaled by emby, returns a nice clear image, however when displayed in the container, there is a blurring that occurs due to that tiny difference. I believe the culprit CSS is:

.coveredImage {
  object-fit: fill;
}

because once it is removed (thank you console...) there isn't any blurring of the images (although they do shrink from the container a little). The alternative is to use a larger image than the container (say 1.5x) which also prevents the blurring. I'm guessing its all to do with the browser scaling method??

 

A couple of offenders attached as an example. They might not bother some people, but they jank my eyes something horrid.

Spoiler

Blurred is on the bottom

 

[Luke 42077]

6 hours ago, DragonEmbers said:

Sorry to open an old thread, but this still appears to be an issue.

 

The source image size: 680x1000

The URI emby uses to get the image has "maxHeight=267&maxWidth=178" (so 178x267)

The container the image is being loaded into is (on my screen, standard size of everything): 176.3x264.45 (when using "Extra large", the container size is: 274.83x412.25)

 

The fetched image, scaled by emby, returns a nice clear image, however when displayed in the container, there is a blurring that occurs due to that tiny difference. I believe the culprit CSS is:

.coveredImage {
  object-fit: fill;
}

because once it is removed (thank you console...) there isn't any blurring of the images (although they do shrink from the container a little). The alternative is to use a larger image than the container (say 1.5x) which also prevents the blurring. I'm guessing its all to do with the browser scaling method??

 

A couple of offenders attached as an example. They might not bother some people, but they jank my eyes something horrid.

  Hide contents

Blurred is on the bottom

 

HI, how does it compare with our hosted web app, http://app.emby.media ?

[DragonEmbers 0]

The web app shows the same blurring at different sizes to default. Default appears less blurry, but other view levels are just as blurry as self-hosted. Is there any difference between that and self-hosted emby?

The container size for default actually appears to be slightly smaller on the emby app than it does on my self-hosted. Perhaps the left nav bar is causing the containers to fluidly shrink which gives better scaling?

Edited April 15, 2023 by DragonEmbers

[Luke 42077]

When you hide the left nav bar, how does that compare?

[Suliamu 36]

On 4/14/2023 at 8:51 PM, DragonEmbers said:

Sorry to open an old thread, but this still appears to be an issue

I am a new emby-premiere-user.  
Migrated over from JF and exactly this aspect is what is at the moment nagging me the most since the library looks so dull unfortunately.   
The difference is quite large for me subjectively.
I actually was multiple times rubbing my eyes when looking at the library because i thought it was a physical problem with my eyes why i am not seeing sharp anymore.  
It would be nice to have the option to control compression/downsizing manually with the cover-images.  
Especially since at least for me the machine that serves those images has NVMe-Disks in Raid0. Even when displaying those in fullresolution simply downscaled as JF seems to do i have never experienced any lag even with a big library and fast scrolling.   

Edited October 4, 2023 by Suliamu

[Suliamu 36]

I have uploaded a screenshot where the problem might be seen quite nicely.
It is just as Dragon Embers described. 
The images are 175 x 250 and crisp when loaded from server but then are stretched on maxheight=263&maxWidth175 which creates this slight unpleasant blur it seems.

I would like to humbly request a deletion of the image when seen by someone of team.
Thank you

[Luke 42077]

Can you try the hosted web app and let me know how things compare?

http://app.emby.media

Thanks.

[Suliamu 36]

16 minutes ago, Luke said:

Can you try the hosted web app and let me know how things compare?

In the webapp the blur is nearly gone. I think there is still a slight stretching but it is _way less_ noticeable.
It might be from interest to say that i use 2560x1440 as display resolution, because i noticed that when changing the browser window
the images in the emby-webinterface change their size, with sometimes more, sometimes less stretch, and with more blur and less blur.
With the handling as in the hosted webapp the "problem" would be solved, for me at least

Edited October 6, 2023 by Suliamu

[Luke 42077]

8 minutes ago, Suliamu said:

In the webapp the blur is nearly gone. I think there is still a slight stretching but it is _way less_ noticeable.

Good, because when we release the upcoming 4.8 server release, your built-in web app will have everything that you see now in the hosted web app.

Quote

I think there is still a slight stretching

It's the same amount of stretching, but probably the image is downloaded from the server at a difference size and that is leading to the improvement. There will always be some stretching if your images don't match the display ratio. The display ratio for movie posters is 2:3. Each image is evaluated independently, and if is close to 2:3 then we just go ahead and stretch  it. If we didn't do that, then this is what you'd end up with:

See how the first image is exactly 2:3, but the second and third images are not. I personally am willing to accept a little stretching for the uniformity, and over the years it seems most have agreed with that.

[blgentry 51]

Stretching:  Do we mean resizing where the aspect ration is altered?

 

If that's the case, then stretching is essentially always the wrong solution.  Distorting an image is rarely what someone really wants.  If you must fill a frame (2:3) with an image of a different aspect ratio (2:2.9), then you should scale up and crop.  Losing a tiny bit of edge is far preferable to having things change shape.  Faces becoming long and tall, or short and wide are not what you want.  Losing a bit of hair up top, or feet down below with the face looking correct is the preferred solution.

 

I've noticed that CoverArt continues to distort my covers by stretching them.  I opened a thread about this, but it seems to have died off.

 

Please do not stretch images in Emby ever.  It is always the wrong solution.  If you disagree, please tell me your reasoning.

 

Thank you for reading.

Brian.

[ebr 16169]

1 hour ago, blgentry said:

I've noticed that CoverArt continues to distort my covers by stretching them

CoverArt has an option of whether or not to do this.  If you are still seeing this after enabling this option, then it is not CA it is the app that is distorting them.

[blgentry 51]

38 minutes ago, ebr said:

CoverArt has an option of whether or not to do this.  If you are still seeing this after enabling this option, then it is not CA it is the app that is distorting them.

 

Does this suggest some sort of action to fix it?  I use an Emby for AndroidTV as my main interface.

 

Thanks,

Brian.