What does turning alpha on and then off again do?

[Oogst]

We use ImageMagick to rescale images to a smaller size for our automated build pipeline. Now a former colleague (who is not with the company anymore and thus cannot explain this) changed how ImageMagick is called. It was for example this:

Code: Select all

convert.exe input.tga -resize 128x128! output.tga

He added alpha commands, like this:

Code: Select all

convert.exe input.tga -alpha off -resize 128x128! -alpha on output.tga

The only result of this seems to be that the rescaled images are now sharper. I don't get how this can have this result, and I don't get what turning alpha on and then off like this could do in the first place. So how does this work?

[snibgo]

The effect is probably to prevent pre-multiplication of pixel values by alpha during the resize. The effect can be demonstrated in a Windows script, using IM 6.8.6-9, writing black text on a transparent white background:

Code: Select all

%IM%convert ^
  -size 1000x600 -background rgba(100%%,100%%,100%%,0) ^
  label:snibgo ^
  -trim +repage ^
  s.png

%IM%convert ^
  s.png ^
  -resize 25%% ^
  s1.png

%IM%convert ^
  s.png ^
  -alpha off ^
  -resize 25%% ^
  -alpha on ^
  s2.png

%IM%compare -metric RMSE s1.png s2.png NULL:

s1.png has proper anti-aliasing, where s2.png has removed some anti-aliasing and this can, of course, increase the perception of sharpness (by removing grey pixels at boundaries).

If you can post an example image (before the resize), I'd be interested to see it.

[snibgo]

Another problem with s2.png is that it makes some of the white (from the background) visible as a thin halo around the black letters. This isn't visible when viewing the images against a white background, but is against other colours. This problem doesn't happen with s1.png.

So, for my example image, turning alpha off for the resize doesn't work well. For other images, it might.

[Oogst]

Thanks for the reply!

I thought "-alpha off" was a parameter, but it is a command, isn't? So do I understand it correctly that if it says "-alpha off -resize 25%% -alpha on", this actually means three commands in a row: it turns the alpha off, then it resizes, and then it turns alpha back on. Do I understand that correctly?

Thin halos around objects is indeed something I want to avoid, since we rarely render anything on a white background. If doing alpha on/off causes that, then I should not be doing that. Is there any benefit to doing the alpha on/off at all?

As for the sharpness: my testing image actually has an all-white alpha. Shouldn't that give the exact same result in both cases? The difference is difficult to see, so I have put the original image and the two resized versions online for download. Swap quickly between both resized versions to see the difference. Here are the images:

http://www.ronimo-games.com/ImageMagick ... arison.rar

Note that I don't really care for the extra sharpness, but I do care for that all my images come out changed, meaning all my Awesomenauts players would be downloading a gigantic patch to download all textures again.

[snibgo]

I thought "-alpha off" was a parameter, but it is a command, isn't? So do I understand it correctly that if it says "-alpha off -resize 25%% -alpha on", this actually means three commands in a row: it turns the alpha off, then it resizes, and then it turns alpha back on. Do I understand that correctly?

Correct.

As for the sharpness: my testing image actually has an all-white alpha.

I think you mean that SplashScreen_Original.tga has an alpha channel, but all values are 255 (ie the maximum, so full opacity).

Shouldn't that give the exact same result in both cases?

Yes. The image has no transparency, so ignoring it or not should make no difference to the result. But there is a difference.

The difference is difficult to see, so I have put the original image and the two resized versions online for download.

There is a difference. Overall the difference is RMSE 0.3%, which is very small, but concentrated in certain areas. Where lightish pixels are surrounded by dark pixels, we can see they become lighter in the "-alpha off" version.

We can see the difference more scientifically:

Code: Select all

convert ^
  SplashScreen_WithAlphaOnOff.tga ^
  SplashScreen_WithoutAlphaOnOff.tga ^
  -compose Difference -composite -auto-level ^
  ssDiff.png

The lighter pixels in ssDiff.png show where the greatest changes occur.

The TGA files are not compressed, so that's not the problem.

I'm trying to pin this down. Meantime, can you give the exact commands you used to create the smaller versions? (It wasn't "resize 25%%".)

[Oogst]

The exact commandos I used are:

Code: Select all

convert.exe input.tga -resize 1024x512! output.tga

Code: Select all

convert.exe input.tga -alpha off -resize 1024x512! -alpha on output.tga

[snibgo]

Thanks.

I've reduced the situation to the simplest that shows the problem, and written it up as a bug report: viewtopic.php?f=3&t=24142

I normally use PNG files. When IM writes these, when an image is fully opaque it doesn't write an alpha channel, so the problem doesn't occur. For my test case, I create a TGA file with opaque alpha channel.

[Oogst]

Quite surprising this was a bug, I expected I was just doing something wrong...

Is there any reason I should leave the alpha off/on in? Subtle white lines around objects is definitely a problem (we have tons of alpha-objects in Awesomenauts), and I don't see any benefit to it. Can you think of any reason why my former colleague might have added this?

[snibgo]

The subtle white halo occurs in my script upthread because I had a transparent white background. Your image contains no transparency, so won't have that problem.

There is an infinite number of methods for resizing, with very subtle differences between them. "-alpha off" shouldn't make a difference, but it does, though it is very small. Replicating the process with PNG files, where is is no alpha channel, gives me exactly the same results as using "-alpha off". On that basis, I would take the "-alpha off" as the more correct version.

When a TGA file has no alpha channel, having or not having "-alpha off" makes no difference, and the result is identical to PNG files, and identical to TGA files with opaque alpha channel and "-alpha off".

So, my advice is:

(a) The difference is very small. If you prefer one version over the other, then use that.

(b) I think "-alpha off resize 1024x512! -alpha on", when you have opaque alpha channels, is more correct than "resize 1024x512!".

If the developers accept this as a bug, and fix it, I expect it then won't matter if you use "-alpha off".

[Oogst]

Sorry, I wasn't clear: most of my textures do have alpha. The one I posted here is actually an exception, I'd say at least 95% of all my textures do have alpha. Lots of character sprites and such.

When alpha is present, the subtle white halo is a problem, suggesting I should use it without the alpha off/on code. Can you think of any reason why my former coworker might have added it? Because I don't see any benefits for pictures with alpha, only drawbacks.

[snibgo]

The term "has alpha" is ambiguous. An image may have an alpha channel but be fully opaque. I suppose you mean "has transparency".

I can't see any advantages of using alpha off/on for resizing images with transparency. The disadvantage will depend on what the transparency is hiding. If those pixels are the same colour as the opaque ones, then no problem. If they are different (like my example above, transparent white against opaque black), colours will bleed from the transparent section to the opaque section, which is a bad thing.

[holden]

This is a pretty common problem, not sure its an IM bug- google "alpha white outline" and you'll see many, even very old, conversations about this. Gimp and apparently PS do the same- I've scaled sprite art with transparent backgrounds in Gimp and have had the same issue. http://www.pasteall.org/pic/59773

[snibgo]

As far as I can see, it's not a bug but an inevitable effect.

My script (in my first post upthread) creates black letters with opacity varying from about 1% to 100%, against a white background that is fully transparent (opacity = 0%).

When we resize normally, the white background is ignored. The colour of the background doesn't matter. It is never mixed with the foreground colour. In the result, every pixel is black, but the opacity varies.

When we switch off the alpha before the resize, the background colour is used. Some resulting pixels are black, some are white and the pixels at the edge are various shades of gray. When we then turn on the alpha, the black pixels become opaque, the white pixels become fully transparent (invisible), but the gray ones take various opacities. Thus, the background colour that was transparent has bled into the edge of the foreground.

Thus can all be seen by using Gimp's eyedropper, at 800% magnification.

[holden]

* as a side note, I wonder to what factor the interpolation method matters when scaling pixel art- I'm almost positive I had it set to "none" in Gimp, but it's worth looking into again.

[fmw42]

see -magnify for pixel art 2x scaling

http://www.imagemagick.org/script/comma ... hp#magnify

viewtopic.php?f=22&t=23046

also
viewtopic.php?f=1&t=17447&p=65637&hilit=scale2x#p65637