Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Image quality issue (GD related maybe)


Reply


8 Posts   5501 Views

Avatar
fishe

Community Member, 42 Posts

15 January 2009 at 6:41pm

I have some code to do resizing of a single image for various purposes. Here's my class extending Image:

class OutfitPage_OutfitImage extends Image {
   
   function generateOutfitImage($gd) {
      $gd->setQuality(100);
      return $gd;
   }
}

This function here was just to test something. Does GD do default background processing of the image, e.g. when resizing etc.? I ask as when I present both the edited/resized image on a page along with the same image "accessed directly" (using src=assets/Uploads/image.jpg) they are different file sizes as reported by the browser, and there are obvious image artefacts - even with the function above supposedly setting the quality to 100%.

It seems to be resampling the whole image, and with a poor jpeg algorithm, no matter what.

Have I got this right? Is there a way around this?

Thanks :)

Avatar
fishe

Community Member, 42 Posts

15 January 2009 at 6:44pm

Additionally...when using the code below, the setQuality function appears to have no effect and the resulting image is poor quality (I estimate around 40-50% jpeg quality setting).

   function generateOutfitImage($gd) {
      $gd->setQuality(100);
      return $gd->resizeByWidth(360);
   }

Avatar
Liam

Community Member, 470 Posts

16 January 2009 at 10:11am

You can edit sapphire/filesystem/GD.php to change the default quality in 2.2.x

In 2.3, you can set GD::set_default_quality(100); in your config file.

I would have thought the custom functions you have would do the trick...

Maybe somebody else knows a bit more on the topic.

Avatar
fishe

Community Member, 42 Posts

16 January 2009 at 5:35pm

Setting GD::set_default_quality(100); in _config.php in 2.3 rc2 solves my problem...

So maybe this is a 2.3 issue whereby the $gd->setQuality() function isn't working.

Avatar
fishe

Community Member, 42 Posts

16 January 2009 at 5:39pm

there is something weird going on here...

with default quality set at 100 I get a 89kb image file. With default quality set at 90 I get a 18kb file which is obviously a lot more compressed with artefacts. The difference between 100 and 90 should be minimal no, like jpeg compression scales normally work.

Avatar
ChrisBryer

Community Member, 95 Posts

23 January 2009 at 7:13am

I havent touched GD but i do know that in photoshop there's a huge difference in filesize between 12 (max) and 11 jpeg compression, everything else is much less dramatic, ie 8-9 is comparable filesize...

i think it's just the way jpeg compression works, and i dont think it is a linear compression where 90 is 90% of 100.

Avatar
fishe

Community Member, 42 Posts

23 January 2009 at 5:33pm

I understand this concept but still what GD is doing in my example doesn't seem normal.

Any way to do some testing here? Is SS 2.3.0 rc2 using the latest gd library?

Avatar
alirobe

Community Member, 35 Posts

11 December 2009 at 6:07pm

Edited: 11/12/2009 6:10pm

I know this is old but it popped up on Google so I thought I'd answer it.

JPEG compression is based on a quality threshold, not size. Image compression at 90% would ignore 'noise' such as film grain but keep other fidelity. The quality threshold is complex, but can be thought of as being based on comparison of adjacent pixels. As you go down the scale, less-slight changes in inter-pixel variation are lost and things are smoothed out.

Because of this, results vary wildly depending on the type of image. Some images will see massive drops in file-size with just a small amount of compression (thanks to film grain, etc), but others may see none until much more aggressive compression is applied.

tl;dr, It has nothing to do with SilverStripe - compression algorithms aren't predictable in any circumstance.