processwire / processwire-issues

ProcessWire issue reports.
45 stars 2 forks source link

ImageSizer gamma correction should be turned OFF by default #1075

Open fijha opened 4 years ago

fijha commented 4 years ago

Short description of the issue

I have recently noticed that imageSizer is crushing blacks in my images. The problem lies in gamma correction. I'm not sure why gamma correction is applied by default. This should be turned OFF.

Expected behavior

The original quality of image (gamma, color, etc) should not be changed. Maybe sharpening should also be turned OFF by default.

Actual behavior

Something is wrong with gamma correction…

Screenshots that demonstrate the issue

'defaultGamma' => -1,
'quality' => 90

gradient-(gamma-off)

// 'defaultGamma' => 2.0, // default
'quality' => 90

gradient-(gamma-on)

Suggestion for a possible fix

Don't apply any gamma correction. Use 'defaultGamma' => -1 in wire/config.php.

The default gamma in wire/config.php is set to 2.0, which is strange because standard gamma should be 2.2. But I've tried different values and the results are always bad.

Setup/Environment

ryancramerdesign commented 4 years ago

@fijha I don't know much about gamma correction and am not sure if the issue you are reporting might be isolated or not (haven't had other reports) so going to ping @horst-n for this as he is the PW expert on this stuff. Thanks.

horst-n commented 4 years ago

Hi @fijha, many thanks for your tests and suggestions. This is a weird one, gamma correction. I have to go a bit further to show that you are right, but that it is still better to leave Gammacorrection on by default. At first, the current default of 2.0 should be adapted to 2.2. For historical reasons I have choosen the 2.0 in 2013 as the default, because in earlier years we have had two different default values for images on Win and Mac platforms. They was 1.8 and 2.2! And one could not read out from which platform they came, what makes me decide to set 2.0 as default. But nowadays we can savely switch to 2.2! <= @ryancramerdesign

Now to the more obvious issue you show with your grayscale wedge. You have done it with the GD ImageEngine that have this weird issues in the very dark parts. The imagick engine doesn't have that and renders nicely! Gammacorrection is applied in every correct working image app, if handled correctly. I will collect and provide you some links to the subject in a later post here.

With the most common used images this miss behave of the GD-renderer will not affect the results. I believe it is less than 1% of all commonly used images that gets hit by it. So, the decission is: should we have 95 - 99% images per default with lesser visual quality then it could be, (and is not really recognized by the majority of common users), or should we have 1 - 5% images with this bad issues, what is good to recognize by the common users, and should result into switching him the gamma correction to -1!

But besides this unpleasant behaviour I have already worked out a way how to automatically recognize these pictures with a high percentage of darkness. Unfortunately, this is time consuming and can / should therefore only be done once during import, which leads us to a real weakness: we can only save flags etc. for JPEGs, since we do it in the very space-saving IPTC meta-markers, which are not supported by PNG and GIF. :-(

This would be the next step we should try to implement. There have been some other points in the last 1-2 years that could have been implemented well if we had a fast and robust, individual storage option for image tags and short info.

@ryancramerdesign : We should discuss on this and some more image related things via another channel. I'm not sure when I will have enough time, but maybe it is a good idea to start collecting all outstanding points on a central point and discuss them step by step, as we find time each other?

horst-n commented 4 years ago

@fijha : This is the link to my first testing code for dark images detection:

https://processwire.com/talk/topic/14236-webp-support/?do=findComment&comment=185357 (with zip download)

here are some links regarding the subject:

http://www.ericbrasseur.org/gamma.html

https://processwire.com/talk/topic/9511-gamma-correction-bug/

https://processwire.com/talk/topic/14715-imagemagick-resizer-colorprofile-consistency/?do=findComment&comment=132098

fijha commented 4 years ago

@horst-n Thank you for stopping by. I'm using default GD engine. I guess that's what most users are using. Yes, the issue is not very noticeable with most of the images. It affects only the darkest parts of the images, so I guess that's why not many users are complaining about the issue, but if somebody looks a little closer (photographers), its definitely noticeable.

I've never had any problems with GD engine in the past. As far as I know, there is no need for gamma correction. Every image (at least on the web) is supposed to be 2.2 gamma. So I really think it's not necessary to do any gamma correction. Most users don't even know what gamma is. Without gamma correction (in my case) images looks exactly as they should comparing to original.

http://www.ericbrasseur.org/gamma.html — this is very interesting… now I understand what are you trying to solve. Looks like this is still relevant… and "expected" with most (even the latest) software. I've never noticed this issue with any software before. The gamma_dalai_lama_gray.jpg is probably the worst case scenario. I would say this PW GD gamma correction issue affecting black parts is (in most cases) worst and more noticeable — it's quality degradation instead of just a small (in most cases barely noticeable) gamma error.

In terms of dark images detection, I'm a fan of simple solutions. That's why I think disabling gamma correction by default is probably the best. Leaving this option to power users who really understand they need it, or leaving it OFF until it's fixed in GD lib.

Also maybe more appropriate name for the option could be gammaCorrection with values just 0/1 (OFF/ON) and the default corrected gamma 2.2, because it actually doesn't change image gamma as expected. In my case there is not a big difference between 1.8 and 2.4, as 2.4 should be considerably darker. The option called defaultGamma could be used for changing gamma, but why would actually anyone want to change gamma to some specific value for image thumbnails… probably not needed… Making it less confusing for most people.

horst-n commented 4 years ago

@fijha In general I agree with most what you say, - but - you may have overlooked an important point. Your assessment that it is better to avoid the broken dark areas and accept the slight darkening of the light and medium areas is correct if an image is processed only ONCE. But it is not uncommon for an image to be processed several times in a row. In this case the first slightly darker image is the source for the second image, the slightly darker result of it is the source for the third processing, which then becomes considerably darker than the original image. It is simply not possible to "correctly" decide on a general setting.

My observations are that people who place a high value on quality image processing choose ImageMagick instead of GD. And most people who are not extra sensitive to image quality will accept results with gamma correction as good. Even a lot of professional photographers say that there images are looking more "shiny" with PWs processing.

Personally, I hope that in the future we will do a one-time scan when importing images and the result can be permanently saved with the image. By this way, the gamma correction in GD can be automatically switched off for images with higher dark portions.

So, but I'm not the one who decides what to do. Above I tried to explain how we came to where we are now. It is open for discussion.

@ryancramerdesign The suggestion from @fijha to change the setting to a boolean ON/OFF makes sence, because I never heared of someone using different gamma settings. Therefor it makes sence to use the default gamma 2.2 (instead of our previous historical 2.0). But with the default setting for gamma correction I opt for ON, not like fijha who opted for off. :-)

horst-n commented 4 years ago

@ryancramerdesign If we decide to change that, I can do the work sometime at mid or end of spring this year.

fijha commented 4 years ago

@horst-n The gamma scaling error correction is a really nice feature. As you mentioned, the pro users will probably choose ImageMagick instead of GD. So maybe leave it ON for users using ImageMagick, but I would rather leave it OFF with default GD engine unless it works perfectly as expected.

Another thing to keep it mind is that browsers will scale images anyway if we consider responsive design, so the gamma scaling error is almost always present. So it works only if images are displayed 100% pixel to pixel.

I consider the gamma scaling error as "expected feature", or at least much more expected than a strange pixelated crashed dark areas — the only positive I can think about this is that probably the result thumbnail file size can be a little smaller because there are no gradients in the dark areas ;-).