'-compose lighten' on Linux

[indiego]

Hi,

as I understand it, 'lighten' should return the maximum of the given values. In the following example I combine the alpha channel of a small square with color rgba(255,0,0,200) and a big square with color rgba(255,0,0,100). The resulting graphic has a transparency of 222 (and not max(100,200)=200) in the inner square. Looks like a bug to me.

Debian 6.0.5 -32bit, IM 6.6.0-4

Code: Select all

#!/bin/bash
convert -depth 8 -size 100x100 xc:'#FF0000C8' one.png
convert -depth 8 -size 200x200 xc:'#FF000064' two.png
convert \( -channel Opacity two.png \) \
  \( -gravity center -channel Alpha two.png one.png -compose lighten -composite \) \
  \( -gravity center -compose copy_opacity -composite \) \
  -depth 8 result.png

BTW: I have problems to produce an equivalent example under windows (just this example). Even tried to composite the 'Linux' graphics under Windows, but the result has still no transparency. What am I missing?

Windows 7 -64bit, IM 6.7.9-1

Code: Select all

convert -depth 8 -size 100x100 xc:"#FF0000C8" one.png
convert -depth 8 -size 200x200 xc:"#FF000064" two.png
convert ( -channel Opacity two.png ) ^
 ( -gravity center -channel Alpha two.png one.png -compose lighten -composite ) ^
 ( -gravity center -compose copy_opacity -composite ) ^
 -depth 8 result.png

Anyhow, it's not easy to produce batch code, that runs on Linux AND Windows (aside from formal differences).

[fmw42]

#!/bin/bash
convert -depth 8 -size 100x100 xc:'#FF0000C8' one.png
convert -depth 8 -size 200x200 xc:'#FF000064' two.png
convert \( -channel Opacity two.png \) \
\( -gravity center -channel Alpha two.png one.png -compose lighten -composite \) \
\( -gravity center -compose copy_opacity -composite \) \
-depth 8 result.png

This is not likely to work. First image must come before options and settings. Your -channel opacity is doing nothing as it is a setting with no operator. You likely need to use -separate to extract the alpha channel. Note -channel alpha and -channel opacity are the same.

Can you explain each step above in terms of what you are trying to do and what result you expect? The perhaps we can correct the command.

Also it always helps if you can post links to your input images.

[indiego]

I see.This is just a simplification of a more complex call. I made this example to figure out, why I get the wrong colors under Linux.

Note -channel alpha and -channel opacity are the same.

Oh, my fault. Looks like I have mixed 'opaque' and 'opacity' here.
But in the real world example I use '<picture> +matte -fill <color> -colorize 100%' to get an opaque only graphic.
Anyhow, thanks for the hint.

Can you explain each step above in terms of what you are trying to do and what result you expect? The perhaps we can correct the command.

What I want to archieve here, is to
1. extract the opaque channel(s) of two.png (the bigger graphic)
2. combine (lighten) the transparency channels of both pictures
3. combine (copy_opacity) 1 and 2 .

Also it always helps if you can post links to your input images.

I totally agree, but in this case the images should be created by the given code.
They are available now under

https://www.wuala.com/indiego/public/?key=caiCGLasLFmJ

[fmw42]

This does what you say you want it to do, but I am not sure that is really the result you want. I am not sure how lighten works if the two images are not the same size. Is the result you posted correct or not correct?


convert 1two.png \
\( +clone 1one.png -alpha extract -gravity center -compose lighten -composite \) \
-alpha off -compose copy_opacity -composite 1result.png

[anthony]

You can control if composition will do (whatever is defined to do) in non-overlaid areas using the special define

Code: Select all

-define compose:outside-overlay=false

This turns off changes outside the overlay area.

I have been thinking of extending this to 'virtual-pixel' to mean use virtual pixel setting (source image) to determine the pixel to compose with outside the overlay area. But that is a long term 'todo'

[indiego]

This does what you say you want it to do, but I am not sure that is really the result you want. I am not sure how lighten works if the two images are not the same size. Is the result you posted correct or not correct?

You are right. This does exactly what I want it to do and the result is also as expected.

I missed somehow, that '-channel' only limits the operation but does no separating. So my combined transparency channel graphic always had an opaque part, which had an unwanted influence on the result. With my flawed code the results look good, but the final transparency value is not always predictable.
On the other hand the error free version gives predictable results, but sadly they look bad (at least with the parameters I used before). I have to do some more parameter testing, before I can make a decision what is best here.

Thanks for your help!

[indiego]

I have changed the code, but I still don't get the same graphics on Linux and Windows. After adding

"-depth 8 -set -colorspace srgb"

I get at least the same graphics for both shadows (umbra-?.png,preumbra-?.png). Under Debian IM uses 16bit and RGB(?) as default, while the Windows version uses 8bit and sRGB. The result of the composition still differs.

The test pictures are available under
https://www.wuala.com/indiego/public/?key=caiCGLasLFmJ

*-l is Linux based, *-w is produced under Windows

Linux:

Code: Select all

convert -depth 8 -set -colorspace srgb  -define compose:outside-overlay=false  \
preumbra-l.png umbra-l.png -channel Alpha -gravity Center -compose Lighten -composite -blur 0x2.0 \
-units PixelsPerInch -set density 150 -quality 00 -type TrueColorMatte +set date:create +set date:modify -background white -colorspace srgb test-l.png 

Windows:

Code: Select all

convert -depth 8 -set -colorspace srgb -define compose:outside-overlay=false ^
preumbra-w.png umbra-w.png -channel Alpha -gravity Center -compose Lighten -composite -blur 0x2.0 ^
-units PixelsPerInch -set density 150 -quality 00 -type TrueColorMatte +set date:create +set date:modify -background white -colorspace srgb test-w.png

Are there still any flaws in my code?

[fmw42]

from my testing of my scripts I have had to use the following:

Code: Select all

# get im version
im_version=`convert -list configure | \
	sed '/^LIB_VERSION_NUMBER /!d; s//,/;  s/,/,0/g;  s/,0*\([0-9][0-9]\)/\1/g' | head -n 1`

# colorspace RGB and sRGB swapped between 6.7.5.5 and 6.7.6.7 
# though probably not resolved until the latter
# then -colorspace gray changed to linear between 6.7.6.7 and 6.7.8.2 
# then -separate converted to linear gray channels between 6.7.6.7 and 6.7.8.2,
# though probably not resolved until the latter
# so -colorspace HSL/HSB -separate and -colorspace gray became linear
# but we need to use -set colorspace RGB before using them at appropriate times
# so that results stay as in original script
# The following was determined from various version tests using autolevel.
# with IM 6.7.4.10, 6.7.6.10, 6.7.8.6
if [ "$im_version" -lt "06070606" -o "$im_version" -gt "06070707" ]; then
	cspace="RGB"
else
	cspace="sRGB"
fi
if [ "$im_version" -lt "06070607" -o "$im_version" -gt "06070707" ]; then
	setcspace="-set colorspace RGB"
else
	setcspace=""
fi

Where $setcspace is used after reading the images or before a compose operation and $cspace is used at the end if needed with -colorspace $cspace.

This is due to the colorspace changes that took place to -colorspace RGB and -colorspace sRGB after 6.7.6.6 and the use of linear grayscale images after IM 6.7.8.2. Sorry I don't know the equivalent for windows.

[indiego]

So it's more a version than an OS related problem. Good news.

Thanks for the code! Will test and report back.

[indiego]

I think I found the problem. I again reduced and corrected ('-set -colorspace') my code, but still got different output. After comparing the different images, it came into my mind, that the '-channel Alpha' setting is simply ignored on Linux side. I removed the channel setting on the Linux side and got the same result as with 'active' setting. After removing '-channel Alpha' under Windows, I get the same output as under Linux. Donno if this is a general problem or only related to my Linux distribution.

no effect of '-channel Alpha' under Linux (Debian 6.0.5 -32bit, IM 6.6.0-4)

Code: Select all

convert -define compose:outside-overlay=false \
  preumbra-l.png umbra-l.png -set colorspace rgb -channel Alpha -gravity Center -compose Lighten -composite \
  -units PixelsPerInch -set density 150 -quality 00 -type TrueColorMatte -background white -colorspace rgb alpha.png

convert -define compose:outside-overlay=false \
  preumbra-l.png umbra-l.png -set colorspace rgb -gravity Center -compose Lighten -composite \
  -units PixelsPerInch -set density 150 -quality 00 -type TrueColorMatte -background white -colorspace rgb noalpha.png 

I have to test again, what is best for my graphics.

[indiego]

Just forgot one thing. The background color ('bKGD' chunk) for the Linux generated png is set to (254,254,254) instead of pure white. The windows version works ok (tested with TweakPNG, http://entropymine.com/jason/tweakpng/, where you can even inspect single palette entries).

[anthony]

post that as a seperate topic. perhaps in the Bug area. Make sure you specific it is a PNG problem in topic

[indiego]

I just compiled a new binary from the actual source (6.7.9-2) and the error does not occur any longer. Probably no need to report an allready fixed bug...

[edit] Stupid me. The actual version doesn't use the 'bKGD' chunk, the background color is part of the palette. Will report in the bug section.