Bugzilla – Bug 4209
JPEG compression/quality level for server-resized artwork is too low
Last modified: 2008-12-18 11:12:53 UTC
This is with SlimServer Version: 6.5.0 - 9916 - Windows XP - EN - cp1252, Perl Version: 5.8.7 MSWin32-x86-multi-thread & MySQL Version: 5.0.22-community-nt. In v6.5, album artwork is resized by SlimServer using GD. For artwork in JPEG format, SlimServer uses GD's default compression/quality level. To my eyes, for some artwork this results in resized artwork that has visible artefacts. Of course, it's still better quality that the browser-resized artwork. See http://forums.slimdevices.com/showthread.php?t=27073 for more details. In summary, changing line 269 of Slim::Web::Graphics from "$newImageData = $newImage->jpeg;" to "$newImageData = $newImage->jpeg (95);" results in artwork that doesn't have visible artefacts. However, artwork is 2x the size of the current setting. Using 90 is almost as good but is 1.5x the size of the current setting. A preference to choose the artwork quality would be great, but that brings more complication to SlimServer. Changing the quality to 90 or 95 would be best (IMO). My view is that the resizing process shouldn't make the artwork visibly worse that the original (i.e. it is transparent). A quality of 90 or 95 is transparent whereas the current setting is not. More info... If no quality is specified, GD uses the GD library's default (http://search.cpan.org/~lds/GD-2.35/GD.pm#Image_Data_Output_Methods - search for "choose a good default"). In turn, the GD library uses the IJG library's default (http://www.boutell.com/gd/manual2.0.33.html - search for "default IJG JPEG quality"). The IJG library uses a default of 75 (http://www.faqs.org/faqs/jpeg-faq/part1/ - seach for "default IJG quality setting"). Thanks.
let's add a setting for the quality in a future release.
given the recent graphics rework for png/gif/jpg, is there still a point in having a jpg quality setting? Might it make sense to have an "artwork quality" setting from 0-100, and use the given ing(value/10) for png quality? gif would of course not be affected by this setting. The setting could go on the interface page with the rest of the artwork settings, default to remain at 75 (8 for png) Let me know what you think.
Some semi-random thoughts... PNG is lossless, isn't it? It reads like the PNG parameter is lossless compression level (i.e. size-only), not visual quality. Also, the PNG compression level is 0-9, but it's inverse to the 0 - 100 JPEG quality (0 PNG is no compression, 0 JPEG is high compression). The last link says that "Q 100 is a mathematical limit rather than a useful setting". I'm not sure if that means you shouldn't use above 99, or that above 95 doesn't gain you much and above 99 the again virtually nothing. My guess is the latter.
in that case, for simplicity and best trade-off. Lets fix this at 90, and leave it as seemless to the users. If there are any mentions in future, this can be reopened. merged into trunk at change 14338
Thanks.
Kevin, is it possible for this quality level to generate files larger (in bytes) than the original? That seems to be what I'm seeing in SC7.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.