[FIXED] possible bug -emboss 6.8.6.2 Q16 Mac OSX

[fmw42]

It would appear that -emboss is working on linear data rather than non-linear since 6.8.4.0. The current results are darker than before.

Here is what it used to look like 6.7.4.10 with some variations up to 6.8.3.9

im67410 convert rose: -emboss 0x1.05 rose67410.png



Here is what it now looks like at 6.8.6.2 and back to 6.8.4.0 (and note no difference by adding -intensity rec601luma before -emboss)

convert rose: -emboss 0x1.05 rose67410.png

[glennrp]

This bug does not seem to be peculiar to Mac OSX. I see the same dark result using Ubuntu.

[anthony]

Emboss should have no grayscaling intensity component. it is just a convolution of the image data, with each channel handles completely separate to each other.

So the problem would likely be a convolution problem. Perhaps kernel normalization?

[fmw42]

Emboss should have no grayscaling intensity component. it is just a convolution of the image data, with each channel handles completely separate to each other.

So the problem would likely be a convolution problem. Perhaps kernel normalization?

OK. I thought it might be converting the color channels to linear RGB before operating on them.

[magick]

You may recall we adapted a number of convolution-based algorithms to use Anthony's morphology apply method. The exact call is:

• emboss_image=MorphologyApply(image,DefaultChannels,ConvolveMorphology,1,
  kernel_info,UndefinedCompositeOp,0.0,exception);

Anthony, are these parameters correct?

[fmw42]

Looking at the code I see at the very bottom:

Code: Select all

  if (emboss_image != (Image *) NULL)
    (void) EqualizeImage(emboss_image);
  return(emboss_image);

Checking -equalize, there is a large difference at the same time as -emboss changed (between 6.8.3.9 and 6.8.4.0) probably when the default of -equalize was changed from each channel separately to all channels together.

This can be seen from

convert rose: -equalize x:
im6840 convert rose: -equalize x:
im6839 convert rose: -equalize x:

My guess is if you set -equalize (in the above code only) to process each channel separately as in 6839, that might fix the -emboss problem, so that it matches the earlier results.

I tried this, but apparently -emboss is not channel sensitive and so this did not help.

convert rose: -channel rgb -emboss 0x1.05 show:

[fmw42]

ADDITIONAL INFORMATION (I think this might be more likely the issue):


I believe that -equalize in the default setting (all channels together) is not working correctly (since IM 6.8.4.0) and may be using linear channels.


This is a comparison of -equalize with my redist in the same mode (shape= uniform)




convert zelda3.jpg -equalize zelda3_equal.jpg


redist -s uniform -m rgb -g rec601 zelda3.jpg zelda3_uni_rec601.jpg


redist -s uniform -m rgb -g rec709 zelda3.jpg zelda3_uni_rec709.jpg



The two look the same when channels are processed separately.

convert zelda3.jpg -channel rgb -equalize zelda3_channels_equal.jpg




convert zelda3.jpg -intensity rec601luma -separate +channel zelda3_channels_%d.png
redist -s uniform -m rgb zelda3_channels_0.png zelda3_channel_uniform_0.png
redist -s uniform -m rgb zelda3_channels_1.png zelda3_channel_uniform_1.png
redist -s uniform -m rgb zelda3_channels_2.png zelda3_channel_uniform_2.png
convert zelda3_channel_uniform_*.png -combine -colorspace sRGB zelda3_channels_uniform.jpg

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.6-4 Beta available by sometime tomorrow. Thanks.

Note, you'll need to convert to linear manually to get the previous results: -colorspace RGB -equalize -colorspace sRGB.

[fmw42]

WITHDRAWN. See next post below.

[fmw42]

OK. In IM 6.8.6.3, -equalize is fixed.

6.8.6.2 with -set colorspace RGB
im6862 convert zelda3.jpg -set colorspace rgb -equalize -colorspace sRGB zelda3_rgb_equal6862.jpg


6.8.6.3
convert zelda3.jpg -equalize zelda3_equal6863.jpg


From my redist (as earlier):




But this does not seem to fix -emboss

Here is what it used to look like 6.7.4.10 with some variations up to 6.8.3.9

im67410 convert rose: -emboss 0x1.05 rose67410.png



Here is what it now looks like at 6.8.6.2 and back to 6.8.4.0 (and note no difference by adding -intensity rec601luma before -emboss)

im6862 convert rose: -emboss 0x1.05 rose6862.png



Here is the current result from 6863:

convert rose: -emboss 0x1.05 rose6863.png


So if -emboss is calling the new -equalize, then my suspicion goes back to the possibility that when emboss calls -equalize, -equalize needs to be put into equalizing each channel separately to match the old results.

[magick]

Add -channel RGB to your command line. Does that fix the problem?

Also instead of -colorspace RGB -equalize -colorspace sRGB. Does -intensity Rec609luminance -equalize return the same results?

[fmw42]

Add -channel RGB to your command line. Does that fix the problem?

Also instead of -colorspace RGB -equalize -colorspace sRGB. Does -intensity Rec609luminance -equalize return the same results?

-equalize was fixed as noted above. It is -emboss that is not working as before.

None of your suggestions match the 67410 result.


im67410 convert rose: -emboss 0x1.05 rose67410.png


convert rose: -emboss 0x1.05 rose6863a.png


convert rose: -channel rgb -emboss 0x1.05 rose6863b.png


convert rose: -set colorspace RGB -emboss 0x1.05 -colorspace sRGB rose6863c.png


convert rose: -intensity rec601luma -emboss 0x1.05 rose6863d.png



The first change occurred between 6792 and 6793, which corresponds to when -equalize went from equalizing each channel separately to equalizing all together

im6792 convert rose: -emboss 0x1.05 rose6792.png



im6793 convert rose: -emboss 0x1.05 rose6793.png



The second change occurred between 6839 and 6840, when channel went from non-linear to linear

im6839 convert rose: -emboss 0x1.05 rose6839.png



im6840 convert rose: -emboss 0x1.05 rose6840.png




Changes between 6862 and 6863

im6862 convert rose: -emboss 0x1.05 rose6862.png


convert rose: -emboss 0x1.05 rose6863.png

[magick]

Perhaps Anthony can comment. We're adapted emboss to the morphological convolve operation which he wrote / supports.

[fmw42]

Perhaps Anthony can comment. We're adapted emboss to the morphological convolve operation which he wrote / supports.

I understand. But perhaps if you set -emboss to use non-linear gray in equalize (which I think it is now doing from the -equalize tests above) and to have -equalize in -emboss process the channels separately, it might work properly.

I can test if you put that in the beta.

It would be OK with me if you want to set up emboss to be channel sensitive and -intensity sensitive. That way all options can be tested.

If you want to wait to here back from Anthony, that is fine. Let me know if you make a change in the beta and I will try to test right away.

[anthony]

Perhaps Anthony can comment. We're adapted emboss to the morphological convolve operation which he wrote / supports.

I have never actually looked at how emboss actually works. All I know is that it uses some type of convolve to achieve its task. I have no idea what the kernel looks like, or even what the results are supposed to look like, other than the basic example in IM Example (whcih I did a very very long time ago).

Consequently I don't know what version is wrong or right or whatever. For Emboss like situations, I myself generally prefer the more controlled "-shade" operator.

Channel separation, and/or intensity (greyscaling) variant would probably be a good idea.

I mentioned that it was perhaps a change in normalization that caused the problem, as it did for other convolve operators.