Recoloring images broken

[anthony]

If I have an image with transparency I would typically use

Code: Select all

   -fill red -colorize 100%

to make that image red while preserving its transparency
This is failing.

With this

Code: Select all

 -alpha shape

is also failing.

For example

Code: Select all

  convert -background none -pointsize 72 label:A -fill red -colorize 100% show:

produces a sloid red canvas.. the text is gone.


My current work around is to use the newer option I adds a few years ago... +level-colors red

[magick]

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

[fmw42]

if the image has transparency, then you may need to specify colors as rgba(255,0,0,1) for pure opaque red

[anthony]

No the issue here is channels. The alpha channel should not be updated as it is not part of channels.
The colorize operator has always not effected 'transparency' in images simply as 'alpha' was not set by default in the channel setting. This should continue for 'normal usage' of the colorize operator, even in IMv7, unless told otherwise.


Channels can effect operators in two ways in IMv6. By default a special channel flag 'sync' tells an operator to 'do the normal thing', whatever that is with regard to the operation.

While if the flag is missing (typically meaning the user has set the channel setting), operators (generally) will obey the channel setting in what should and should not be updated in images.

For example: -threshold normally grayscales the image before thresholding by default, and mathematical compose does alpha blending as per SVG definition. But if channel setting was set (sync flag removed), then threshold does individual channel thresholds (no sync), and mathematical composes does the mathematics operations on each channel without alpha blending, including the alpha channel.


I have NO idea how this aspect is working in IMv7, as the channel 'sync' flag was replaced with a per-image channel data attribute called 'alpha blending' (to allow the use of multiple alpha channels)


Cristy, can you please enlighten what has changed for IMv7 in this regards.

[anthony]

verified that -colorize is now fixed for default (no channel setting) handling.

Though it seems colorize is not effected by the -channel setting :-/ it is purely a color blending operation.
That may be a nice 'future to-do'.

[fmw42]

These 3 commands work just fine for me in IM 6.8.5.5 Q16 Mac OSX Snow Leopard. In my opinion, this is the way it should work. When you colorize, you want the result to be the color you asked for whether there is transparency or not. That is the definition of colorize. So to avoid changing the alpha data, turn it off, process and then turn it on.


# produces an opaque red image
convert logo: -transparent white -fill red -colorize 100% show:

# produces a fully transparent image with red under the transparency
convert logo: -transparent white -fill "rgba(255,0,0,0)" -colorize 100% show:

# produces a red image everywhere there is no transparency and keeps the original transparency. The color under the transparency is also red
convert logo: -transparent white -alpha off -fill red -colorize 100% -alpha on show:

[magick]

OK, patch reverted until we reach a consensus on whether this is a bug or not.

[fmw42]

This goes back to a change log entry

2012-08-16 6.7.9-1 Cristy <quetzlzacatenango@image...>
Don't colorize alpha channel if it is not active (reference viewtopic.php?f=3&t=21547

Which references a bug report I made (viewtopic.php?f=3&t=21547).

I believe the end result was to make it like it is today. At least the test in my last post on that topic confirm that it was working this way after the bug fix in the specified release. Though it may have more to do with being able to enable the alpha channel after turning it off and colorizing than with -colorize. Thus -colorize may have been working this way even before that release.

Doing some release testing:

This command

convert logo: -transparent white -fill red -colorize 100% x:

kept the transparency as Anthony had expected up to 6.7.6.5

But then afterwards, up to 6.7.9.0 (when I submitted the bug report), it was making everything totally red (and turning on and off channels did not allow the transparency to be kept). After the bug report (6.7.9.1), it still keeps everything red, but allows the alpha channel to be turned off and on so as to preserve the transparency.

So it has made the image fully opaque red, since 6.7.6.6 (about 90 versions)

I have been making my scripts conform to this post 6.7.6.5 way -colorize works.

But I suppose that it could be changed back to the pre 6.7.6.5 processing so that it kept the alpha channel unchanged when colorizing. So long as I can still do the same with

convert partiallytransparentimage -alpha off -fill red -colorize 100% -alpha on show:

and can make the image totally red by

convert partiallytransparentimage -alpha opaque -fill red -colorize 100%

I suppose I could go along with that.

But lets hear back from Anthony (and anyone else).

[anthony]

My concern is that -colorize has preserved alpha from the days of IMv5, and probably earlier.
It just suddenly changed on me when I went to use this aspect of the operator to change the color of shaped image. Something I have in a number of examples.

It 'tinting aspects was useful when say tinting GIF images with transparency.
I'm not talking about 100% colorizing, but just de-contrasting images with a specific 'center' color.

At the IMv5 to IMv6, clearing an existing image to a blank color was difficult, and usually a 'side-effect' of some other technique. -draw 'color 0,0 reset' was most common but was considered difficult to understand. The -colorize method became the accepted 'best way' so it is in a lot of scripts.

It is even part of the -alpha shape whcih also broke when -colorize was patched not to preserve alpha, as it was internally part of the commands defination.

Now of course we have +level-color, though that is a relative new-commer on the block.

I think I would prefer to see -colorize continue to preserve transparency by default, unless a -channel setting tells it otherwise (a bit like -threshold and its greyscaling function), but that is what I am used to. As mentioned users can use -alpha off or -alpha opaque, either before or after the -colorize to remove the preserve transparency aspect.

But then again.. you can't use a semi-transparent color with -colorize, if that even works now with that patch!

As it stands, I don't think there is a 'right' solution. As such I would probably be inclined to go with the 'most useful' solution. Which means you should be able to some how...
1/ blending with a semi-transparent color (even if it means setting -channel RGBA to do so)
2/ able to preserve alpha for 'shaped images' (either via default -channel RGB, or the channel 'sync' flag, or -alpha off ... -alpha on)
3/ able to blank a canvas including alpha to the color (perhaps even a semi-transparent color)

It is the handling of a semi-transparent color that need to be tested with othe patches and patched versions
The old version I do not believe handles semi-transparent colors well, while I doubt the new patched version does either.

So my vote is -- new functionality, and boils down to...
backward compatibility vs semi-transparent color handling

[fmw42]

This seems to work in IM 6.8.5.5

Half transparent red:
convert logo: -fill "rgba(255,0,0,0.5)" -colorize 100% show:


What example fails for you using -alpha shape? I don't use it that often and you did not give a full example?

[anthony]

When -colorize failed, I tried using -alpha extract -alpha shape instead to re-color, but it failed in the same way. I did not look into it further.


It is failing but now doing so in a wierd way...

Code: Select all

convert -background none -pointsize 72 label:A \
            -alpha extract -background blue -alpha shape show:

I get a result that looks like a color image (RGB turples) was read as as greyscale. that is a 'prison bar greyscale' look instead of a color image.

IMv7 "magick" works just fine.

[fmw42]

It does the same for me. But it is a problem with show: that I have reported several times with other functions to Magick and he has fixed it for them. I do not know how global an effect this is. Try using x: or save to an image and it will work fine.

see for example viewtopic.php?f=3&t=23209 (also with -colorize, but that one got fixed at least for the release I tested)

[anthony]

Then it isn't actually show; that is going wrong, but MIFF: which is used to give the image to "display" (the show spawn delegate)

[fmw42]

Then it isn't actually show; that is going wrong, but MIFF: which is used to give the image to "display" (the show spawn delegate)

Out of curiosity, why does x: work?

[magick]

The MIFF problem is fixed. What is the decision on -colorize? Patch or no patch?