possible bug gradient with transparency IM 6.8.5.6 Q16 Mac

[fmw42]

Perhaps I misunderstand about gradients with transparency, but the following does not seem right to me for the base image under the transparency.



convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! 1grad.png



convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha extract 1grad_alpha.png



convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off 1grad_aoff.png


Shouldn't this last image, the image under the transparency, be a gradient from red to black, and not pure red

[glennrp]

Notice that the rightmost column is black while the rest of the image is pure red.
The problem isn't in the PNG encoder because the same result is obtained
by converting to .txt and .miff

[fmw42]

Notice that the rightmost column is black while the rest of the image is pure red.
The problem isn't in the PNG encoder because the same result is obtained
by converting to .txt and .miff

Yes, I noticed the right black edge, but thought it might have been just an illusion. Thanks for pointing that out.

This also is the same as the png result, but using jpg and is all red with the black line on the right side.

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off 1grad_aoff.jpg


I also note that the following is half red and half pure transparent. But I assume that is a different issue with x:. Perhaps x: cannot display 8-bit transparency.

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! x:


whereas this looks fine

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! x:

[snibgo]

Code: Select all

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off 1grad_aoff.tiff

Confimed that this gives solid red, apart from black strip down right side, tested on v6.7.9 and 6.8.0 to 6.8.5, on Windows 7.

I think the result should be identical to ...

Code: Select all

convert -size 1x256 gradient:"rgb(0,0,0)-rgb(255,0,0)" -rotate 90 -scale 256x50! 1grad_b.tiff

convert -size 1x256 gradient:"rgba(0,0,0,1)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off 1grad_c.tiff

... which both give a graduation from red on the left to black on the right.

[glennrp]

Using 255 instead of 1 for alpha=1.0 gives the expected result. It is as though rgba(255,0,0,1) is being interpreted as alpha=(integer)1 and any pixels which have alpha less than 1 (all except the right column) are rounded down to zero. Also using rgba(255,0,0,1.0) works.

[snibgo]

Yup, I think Glen has nailed it. Use "1.0" instead of "1" for alpha, and it works fine.

[magick]

Gradients blend the start and stop colors with the Plus composite operator @ http://www.imagemagick.org/Usage/compose/#plus. Also take a look just below that section @ Plus and Plus Blending. The mathematics of alpha blending keeps the red fully red while varying the alpha. Here is the pseudocode:

• red=(Sa*Sr+Da*Dr)/(Sa+Da)

If you remove the alpha component, you get the expected results. Anthony, can you confirm that CompositePixelInfoBlend() / CompositePixelInfoPlus() is implemented properly?

[fmw42]

If you remove the alpha component, you get the expected results. Anthony, can you confirm that CompositePixelInfoBlend() / CompositePixelInfoPlus() is implemented properly?

Something is not correct, in my opinion.

I do not believe that one should get a nearly all red image under the transparency, except for one black column on the right.

Also replacing alpha=1 with alpha=1.0, makes no difference for me


convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off 1grad_aoff1.png

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1.0)" -rotate 90 -scale 256x50! -alpha off 1grad_aoff2.png



Both give the same image as above. So removing the transparency by -alpha off, does not seem to give a reasonable result.

It works fine if no transparency is involved in the colors.

Let me clarify further. The gradient itself probably looks correct, because it is blending red to transparent. My complaint is that the image under the transparency is not correct. It should blend red to black in linear gradient and not just make the last column black.

[magick]

The results we're getting are the correct results for Plus composite blending. We had a different blending operation in the past that just assigned the alpha value and blended RGB and at some point Anthony had us change it to the Plus composite blending. Anthony, is gradient behaving correctly? Do we need to revert to the older blending composite op or is there a bug in the Plus blending composite op?

Note the black comes from the stop color. Gradients start with the start color, stop with the stop color, and gradually blend everything in between.

[fmw42]

It does not look fixed to me, when I do:

convert -size 1x256 gradient:"rgba(0,0,0,0)-rgba(255,0,0,1)" -rotate 90 -scale 256x50! -alpha off show:

I was expecting that the rgb image below the gradient would blend linearly between red and black, ie. the colors with the alpha removed, ie., rgba(255,0,0,1) to rgba(0,0,0,0) would become rgb(255,0,0) to rgb(0,0,0), or just red to black. It does not and I do not understand why it should not be this way. One should be able to create an gradient with transparency and turn off the alpha channel and still have a gradient, not a pure color with one black column on the right.

The transparent gradient is OK in this case, since it does indeed go from pure red to pure transparent. So one never sees what is under the transparency. But if one creates a transparent gradient and wants to do -alpha off, then the result is not reasonable in my opinion -- it should be a smooth gradient.

If there is a good reason to do it the way it is, then please clarify for me. Otherwise, it produces an non-logical result and certainly unexpected.

[anthony]

Tthat last pixel is fully transparent so technically can be any color (black or other-wise).

Before a change, we were getting a semi-transparent dark red in the middle that really did not look right.

See version warnings in IM Examples
http://www.imagemagick.org/Usage/canvas ... ransparent

Previous to version 6.5.4-7 the gradient was being generated in a colorspace that looked like a pure RGBA 4D Hypercube. What was needed was for the gradient to be generated using a 4 Dimentional Cone (along Alpha), with a RGB Cube at one end (fully opaque).

The results we're getting are the correct results for Plus composite blending. We had a different blending operation in the past that just assigned the alpha value and blended RGB and at some point Anthony had us change it to the Plus composite blending. Anthony, is gradient behaving correctly? Do we need to revert to the older blending composite op or is there a bug in the Plus blending composite op?

Seems to be working perfectly correct as I see it. Using Plus Blending of the two colors will by virtue of the way alpha blending works generate colors in colorspace defined by a 4D Cubic-Cone.

NOTE this was the same colorspace problem that the Fuzz Factor had. It was comparing colors in a 4D Hyper Cube, instead of a 4D Cubic-Cone. That is transparent colors are closer together as they get more transparent.

See IM Examples, Color Basics, Fuzz Factor and alpha transparency...
http://www.imagemagick.org/Usage/color_ ... fuzz_alpha

[fmw42]

OK. I think I see the issue. If I create what I had expected using


convert \( -size 50x256 gradient: -rotate -90 +write show: \) \( -size 256x50 xc:black \) \( -clone 1 \) \
\( -clone 0 -clone 1 -clone 2 -combine +write show: \) \
-delete 1,2 +swap -alpha off -compose copy_opacity -composite show:

then the red disappears too quickly and leave too much of the image transparent as above

However, it I do

convert \( -size 256x50 xc:red \) \
\( -size 50x256 gradient: -rotate -90 +write show: \) \
-alpha off -compose copy_opacity -composite show:

Then I get a more reasonable gradient, but it does not match the following

convert -size 50x256 gradient:red-none -rotate -90 show:

Can you expain why?

However, the black vertical edge on the right should be corrected so that the image is pure red under the transparency as if created by my second command.



Note that this does not look correct -- Another issue with show: (MIFF?)
convert -size 50x256 gradient: -rotate +90 show:


Wheras this looks fine:
convert -size 50x256 gradient: -rotate -90 show:


PS. The reason I am trying to understand all this is that I am writing a CSS style gradient script (linear and radial) with most of the bells and whistles. It works fine for non-transparent gradients, but the gradients with transparency are not coming out correctly. So I am trying to find a workaround. But I need to understand how to create a black-white 2D gradient and colorize it with a transparent 1D clut gradient.

[anthony]

If there is a good reason to do it the way it is, then please clarify for me. Otherwise, it produces an non-logical result and certainly unexpected.

What you described is a mathematically line in 4D hypercube. where fully-transpareny colors are not all the same.

Here I generate a gradient off that type...

Code: Select all

convert -size 30x500 gradient:red-black gradient: -compose CopyOpacity -composite -rotate 90 gradient_old.png 

Here I turn off alpha - you get your black-red gradient

Code: Select all

convert gradient_old.png -background white -alpha off  gradient_old_alphaoff.png

Now lets do the equivelent of overlaying this gradient on white...

Code: Select all

convert gradient_old.png -background white -alpha remove  gradient_old_overlay.png

Look carefully at the above gradient... It has this dark 'smudge' of dark colors in the middle. Now compare that to what you get if I had used a 'correct' transparent to red gradient and overaid it on white.

Code: Select all

convert -size 30x500 gradient:red-none -rotate 90 -background white -alpha remove gradient_new_overlay.png 

Note how the gradient pure white to red, exactly as you would have gotten for a white-red gradient. A red to transparent gradient should NOT contain any black. it is transparent, not black!

Technically we could modify gradient: so it knows about the 'alpha blending flag in the channel setting. In IMv6 that is done by simply using -channel RGBA (turn off alpha blending 'sync' flag, in IMv6). however currently gradient: does not do this.

NOTE the -compose blend does understand turning off alpha blending in IMv6, but this is not used for individual pixel color blending such as what gradient is using.

Also I have not found out from Cristy yet as to how to turn off alpha blending in IMv7, though internally in the core library it is present as a 'alpha channel trait'. It is set up in a different way so as to allow the use of multiple (and separately switch-able) alpha channels.

[fmw42]

Per my previous post, I can see why my original concept does not work. But I do not see why the following are not equivalent.

convert \( -size 256x50 xc:red \) \
\( -size 50x256 gradient: -rotate -90 +write show: \) \
-alpha off -compose copy_opacity -composite show:


convert -size 50x256 gradient:red-none -rotate -90 show:

Can you clarify for me why they do not match?

More importantly, see my red comments above. I need to be able to create a black-white gradient and colorize it with a 1D transparent gradient clut. That is not producing results as expected as far as I could tell. The problem is it can have multiple colors and stops. It works fine without transparency.

[anthony]

However, the black vertical edge on the right should be corrected so that the image is pure red under the transparency as if created by my second command.

It only happens if one of the colors is fully-transparent, at which point blend mathematically becomes 'any-color'. I am certain with a slight change that 'any-color' can be given the non-transparent color, but it is hard to say how complicated the code modification needed would be.

It may be easier to correct it as a 'special case'.



NOTE: Common use of HDRI and possible input of negatives may make this harder, as then that 'zero' color could happen anywhere in a gradient. For example a gradient of red to what is essentially negative red (with negative transparency)!

But then that is really getting nonsensical!