Edit image in Flash and Using Imagemagick at backend

[magick]

Normalization is 0.0-1.0 or in your case -40/256 or 0.15625. You might get a small difference if you are using the default Q16 version of ImageMagick which has a greater depth of precision than the traditional image processing packages that typically only support [0..255].

[anthony]

Hello again.

I'm testing it on following example: http://www.emanueleferonato.com/2009/04 ... ter-class/
Lets pick "Adding contrast" matrix, which is:

Code: Select all

1.50 0.00 0.00 0.00 -40.00
0.00 1.50 0.00 0.00 -40.00
0.00 0.00 1.50 0.00 -40.00
0.00 0.00 0.00 1.00 0.00

....

And voila! The black square

Bad choice the firth column is NOT zero! And it is the fifth column that IMs -recolor does not understand!
It is also 'Quality' level dependant, whcih is what Magick is going on about.

Try this... remove the fifth column...

Code: Select all

1.50 0.00 0.00 0.00
0.00 1.50 0.00 0.00
0.00 0.00 1.50 0.00
0.00 0.00 0.00 1.00

No the last row does nothing. so is not needed so remove the 4th row AND column

Code: Select all

1.50 0.00 0.00
0.00 1.50 0.00
0.00 0.00 1.50

Feed into the -recolor, then subtract '40' (or for IM Q16 40*256) from the three color channels.

Code: Select all

convert rose: -recolor '1.5,0,0,  0,1.5,0,  0,0,1.5'  -evaluate subtract 10240  show:

NOW for the problem with this... multipying by 1.5 BEFORE subtracting as two seperate operations will 'clip' the image (unless you use HDRI) See IM Evaluate introduction for details.
http://www.imagemagick.org/Usage/transform/#evaluate

This problem is ONLY present if you have non-zero fifth column!

However for this operation you are not mixing colors. You are ONLY multiplying color channels by 1.5 and subtracting some value. That is new_color_value = old_color_value * 1.5 - 0.157
The value .157 is the 'normalized color value' that is 40 divided by the 'range' of the color values EG 40/255

Well that is a polynomial and that was something that was also built into IM! So this will do that matrix's task without the excessive clipping...

Code: Select all

convert rose: -function polynomial 1.5,-.157 show:

As wil most good tools there are LOTS of ways to do anything. The above can also be implemented as as slower '-fx' operation. or even a '-level' operation, the latter however defines it in terms of 'limit values' rather than multiplication values, but as color mixing is not involved it can still do the task!

The -recolor operator could probably be extended so that +recolor adds the extra 'addition' column. However best practise implementation would still not make it compatible with Flash! I would make the addition value a normalized color value so that the matrix would not be dependant on the color range (that is 255 in Flash, or the compile time quality setting in IM).

See...
Recolor Matrix (raw notes)
http://www.imagemagick.org/Usage/color/#recolor
Evaluate and Functions
http://www.imagemagick.org/Usage/transform/#evaluate
FX DIY image manipulation (direct free for math functions)
http://www.imagemagick.org/Usage/transform/#fx
IM in-memory Image Quality setting (compile time Q setting)
http://www.imagemagick.org/Usage/basics/#quality
HDRI compiled version of IM (in-memory floats - no clipping or quantum round-off)
http://www.imagemagick.org/Usage/basics/#hdri

[anthony]

Actually the documentation on recolor is wrong in one aspect.

It provides a matrix that can scale, rotate, and mix color chanels, but it can NOT 'translate' (add/subtract) a constant from that color.

HOWEVER! if you use a RGBA matrix, on an image that is full-opaque, then you have a source of '1.0' values which you can use to add or subtract a constant to each of the color channels.
so you matrix...

Code: Select all

1.50 0.00 0.00 0.00 -40.00
0.00 1.50 0.00 0.00 -40.00
0.00 0.00 1.50 0.00 -40.00
0.00 0.00 0.00 1.00 0.00

can be converted into a 4x4 matrix (assuming the image has no transparency) (NOTE 0.157 = 40/255)

Code: Select all

1.50 0.00 0.00 -0.157
0.00 1.50 0.00 -0.157
0.00 0.00 1.50 -0.157
0.00 0.00 0.00 1.00

That is
new_red = old_red * 1.5 + old_green * 0 + old_blue * 0 + old_alpha * -.157
or as alpha is fully-opaque its value is always 1.0
new_red = old_red * 1.5 + 1.0 * -.157
or just
new_red = old_red * 1.5 - .157

So using that matrix the 'all in one' (no clipping) -recolor operation becomes ...

Code: Select all

convert rose: -recolor '1.5,0,0,-.157  0,1.5,0,-.157  0,0,1.5,-.157   0,0,0,1'  -evaluate subtract 10240  show:

NOTE you can use either comma's or white-space (space/tab/returns) between the numbers, I like to use this for formating to make things clearer... for example in a UNIX shell script I can just as easilly have written...

Code: Select all

convert rose: -recolor '
1.5, 0,  0,  -.157
0,  1.5, 0,  -.157
0,   0,  1.5, -.157
0,   0,   0,    1.0  
           ' -evaluate subtract 10240  show:

[magick]

Shouldn't the -0.157 be in the bottom row, otherwise you can multiplying alpha by -0.157 rather than subtracting -0.157*QuantumRange from the RGB components?

[anthony]

The bottom row defines the ALPHA channel result. You do NOT want to change that!

I am just using the images 'fully-opaqueness' to provide a way to 'add' a constant value.

Idealy recolor should be modified so that +recolor allows a matrix with a extra column of 'additions'
(implies a extra row of all zeros but for last value which is 1). this is the normal way matrix translations are performed.

That is -recolor can take a 3x3 4x4 or 5x5 matrix while +recolor takes a 4x3 5x4 or 6x5 matrix with an extra translation column. translations however should be 'normalized color value' (unlike flash that uses a 255 quantum range). Using a '+recolor' syntax will preserve backward compatibility.

[magick]

Perhaps a bug then or I'm missing something. Here is the code for 4 x 4:

Code: Select all

        for (x=0; x < (long) image->columns; x++)
        {
          q->red=ClampToQuantum(k[0]*p->red+k[1]*p->green+k[2]*p->blue+
            k[12]*QuantumRange);
          q->green=ClampToQuantum(k[4]*p->red+k[5]*p->green+k[6]*p->blue+
            k[13]*QuantumRange);
          q->blue=ClampToQuantum(k[8]*p->red+k[9]*p->green+k[10]*p->blue+
            k[14]*QuantumRange);
       }

Suggesting that the bottom row is added to the color components. For 4x4 alpha is not considered. It is in play for a 5 x 5.

[anthony]

Perhaps a bug then or I'm missing something. Here is the code for 4 x 4:

Code: Select all

        for (x=0; x < (long) image->columns; x++)
        {
          q->red=ClampToQuantum(k[0]*p->red+k[1]*p->green+k[2]*p->blue+
            k[12]*QuantumRange);
          q->green=ClampToQuantum(k[4]*p->red+k[5]*p->green+k[6]*p->blue+
            k[13]*QuantumRange);
          q->blue=ClampToQuantum(k[8]*p->red+k[9]*p->green+k[10]*p->blue+
            k[14]*QuantumRange);
       }

Suggesting that the bottom row is added to the color components. For 4x4 alpha is not considered. It is in play for a 5 x 5.

That certainally does not look right! and very non-matrix like. For one thing there are a lot of indexes missing!
My understanding was a 4x4 was for RGBA handling!

If this was for 4x4 as meaning for RGB with translations, ten it should be
q->red=ClampToQuantum(k[0]*p->red+k[1]*p->green+k[2]*p->blue+ k[3]*k[15]*QuantumRange);
q->green=ClampToQuantum(k[4]*p->red+k[5]*p->green+k[6]*p->blue+k[7]*k[15]*QuantumRange);
q->blue=ClampToQuantum(k[8]*p->red+k[9]*p->green+k[10]*p->blue+ k[11]*k[15]*QuantumRange);
The k[12] to k[14] is ignored as its results are not assigned.

If however the matrix was a 4x3 then k[15] is assumed to be a value of 1.0 while k[12] to k[14] are 0.0 (and not used)

Perhaps -recolor should accept
3x3 (9 values, RGB no translations)
4x3 (12 values, RGB with translation)
4x4 (16 values, RGBA no translations)
5x4 (20 values, RGBA with translations)

this should also be backward compatible, as it is dependant on number of values given, and does not need the use of 'plus' option sytax, or library API call changes.

You could go further for CMYK and CMYKA handling

Basically it is lack of any 'definition' of exactly what the operator does that may be the problem here.

[magick]

We'll add a patch to ImageMagick 6.6.1-0 beta to fix the 4x4 recolor matrix bug. In the mean-time a 5x5 matrix should work properly.

[xtonic]

Sorry, but i really puzzled now, finally ist is now possible to convert flash matrix to magick or need to wait for 6.6.1 ?
Im using Perl interface and there is no "substract" function

[snibgo]

When the dust settles on this issue, perhaps someone could ensure the documentation states what matrix sizes are available (3x3, 4x4, 5x4, 5x5, whatever), and what each of them means, eg

dstR = a[0] * srcR + a[1] * srcG + a[2] * srcB + a[3] * srcA + a[20]
dstG = a[5] * srcR + a[6] * srcG + a[7] * srcB + a[8] * srcA + a[21]
dstB = a[10] * srcR + a[11] * srcG + a[12] * srcB + a[13] * srcA + a[22]
dstA = a[15] * srcR + a[16] * srcG + a[17] * srcB + a[18] * srcA + a[23]

or whatever it will be.

[magick]

There is a bug in the 4x4 matrix of the recolor function. You should be able to use a 5x5 matrix now but will need to wait a few days to properly use the 4x4 matrix when we release ImageMagick 6.6.1-0.

[fmw42]

Does this affect the 3x3 matrix as I have several scripts that use that.

[magick]

3x3 should be fine as well. Fred, grab 6.6.1-0 beta and ensure that the -recolor option works properly for your scripts. We added this to the docs:

• This option permits saturation changes, hue rotation, luminance to alpha, and various other effects. Although variable-sized transformation matrices can be used, typically one uses a 5x5 matrix for an RGBA image and a 6x6 for CMYKA (or RGBA with offsets). The matrix is similar to those used by Adobe Flash except offsets are in column 6 rather than 5 (in support of CMYKA images) and offsets are normalized (divide Flash offset by 255).
  
  As an example, to add contrast to an image with offsets, try this command:
  
  convert kittens.jpg -recolor \
  " 1.5 0.0 0.0 0.0, 0.0, -0.157 \
  0.0 1.5 0.0 0.0, 0.0, -0.157 \
  0.0 0.0 1.5 0.0, 0.0, -0.157 \
  0.0 0.0 0.0 1.0, 0.0, 0.0 \
  0.0 0.0 0.0 0.0, 1.0, 0.0 \
  0.0 0.0 0.0 0.0, 0.0, 1.0" kittens.png

[fmw42]

Magick,

I tested one script, whitebalance, and it did not seem to change from before.

Thanks.

[anthony]

More discussion is still happening behind the scenes because of this topic, so as to try and resolve and improve the situation.

For example one possibility is to use the new 'morphology' kernel definition method for the recolor arguments. This falls back automatically to a square matrix so is already backward compatible!

That is you can specify the matrix size as part of the argument. For example

Code: Select all

convert kittens.jpg -recolor "5x5: 
1.5 0.0 0.0 0.0, 0.0, -0.157 
0.0 1.5 0.0 0.0, 0.0, -0.157 
0.0 0.0 1.5 0.0, 0.0, -0.157 
0.0 0.0 0.0 1.0, 0.0, 0.0 
0.0 0.0 0.0 0.0, 1.0, 0.0 
0.0 0.0 0.0 0.0, 0.0, 1.0" kittens.png

That way you don't need to count up the number of argument to determine what -recolor is going to do. Also IM can (in the future, not yet) do some extra checks to ensure you actually provided enough floating point arguments. Basically it makes it easier to read.

If this happens while a 'geometry size' is not required for square matrices, it would be recommended.

What do users think of this? Remember it would be optional for square matrices.



There is however a FLAW in above recolor definition

A 3x3 is a RGB matrix without translations.
But is then what is a 4x4 matrix?
RGB with translation
or just RGBA without translation?

When translations are involved the final line is all zeros but for the last value which is one. As such it should not be needed to be specified, the matrix can be one row short, just as it is in the FLASH recolor matrix. As I shown above the size of the matrix could then determine whether the user wants translation or not.

square matrix - no translations
one row short of being square - translations

EG: 4x4 is RGBA withotu translations but 4x3 is RGB with translations.