Legacy ImageMagick Discussions Archive

IM 6.7.9.6 Q16 Mac OSX Snow Leopard

According to the documentation for -color-matrix at http://www.imagemagick.org/script/comma ... lor-matrix, it says

"typically one uses a 5x5 matrix for an RGBA image ..."

However the 5x5 format produces no change for me on the following test; whereas, the 6x6 format does work properly.

I am just adding a unity value for the red offset as a test here.


Input:



5x5 test
convert rose: -color-matrix "1 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1" rose_cm_5x5b.png


6x6 test:
convert rose: -color-matrix "1 0 0 0 0 1 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1" rose_cm_6x6.png

The color matrix needs a 5x5 matrix for RGBKA channels. 6x6 adds a constant column, with the last row being usless, ans it assigned to 'constant' and thus is not needed.

You can ensure the matrix is the size you want by prefacing the numbers with a "WxH:"

The matrix is simply overlayed on a identity 6x6 matrix, before being matrix multiplied to each source pixel.
This is explained in IM Examples, Color Modifications, Color Matrix
http://www.imagemagick.org/Usage/color_ ... lor-matrix

In the first 5x5 case you multiply the black channel by a value of 1.0 but this image has no balck channel, so make no contribution. Result unchanged image.

In the second 6x6 case, the values to calculate a red result is: 1 0 0 0 0 1
That equates to red from source (multiplyed by 1) plus 1.0 as a constant (6th column).
The result is Red+1.0 which does not fit in a 0 to 1 (normalized color) range.
As such it is clipped to 1.0, and results in just red = 1.0 in the destination image. A very red image.

The -color-matrix is working as it is currently defined to work.

In many ways color-matrix has never quite been what people want, as everyone has different needs and expectations. The black column/row for example is very rarely needed or used.

I myself would prefer to be able to define what channels, and the order of the channels whcih are in the matrix. Especially in IMv7 where we can have many extra channels, not all of which will be involved in the calculations.

Sorry I did not look at your docs. But the options page says that a 5x5 is typical for rgba+offset. It does not specify the need for a WxH. Would you update that at least to mention the WxH aspect and when it is needed, or what case can work without it.

Let me see if I understand from your docs. You can subset any of the following:

r,g,b,k,a,offset

Do you allow c,m,y,k,a,offset? If so, how do you distinguish. If not, then why is there a k included?

So you need 3x3 for rgb. 4x4 is the same. 5x5 is rgbka even though there is no meaning to k, but you have to have it to fill out the diagonal of ones, just to get the alpha included. 6x6 is rgbka+offset where again the k is meaningless, but needed to fill out the diagonal just to get to the alpha and offset.

If you can clarify for me I can modify the options page, if you want.

fmw42 wrote:Sorry I did not look at your docs. But the options page says that a 5x5 is typical for rgba+offset. It does not specify the need for a WxH. Would you update that at least to mention the WxH aspect.

It was added (actually extracted from the morphology kernel definition), by cristy. In fact the reason for the 'overlay' is to convert from a kernel array to a actual matrix form. The two structures has different forms, needed for the different functional usage, it is put to.
NO. but you can have a 6x3 to provide that functionality. -- and example is even provided.

If not what about a 5x5 that is rgba+offset? How would it know it was not cmyka?

NO, you would use a 6x5, (a 6x6 has a useless row, which you may as well not even provide).
Nope. The kernel code used, assumes a square kernel.
However most matrices are fairly 'common' and could be made to be automatically 'understood' by the operator,
and mapped accordingly.

That is...
9 numbers -> 3x3
12 -> 4x3 (rgb+offset)
16 -> 4x4 ( rgba OR cmyk) ***
20 -> 5x4 (rgba+offset OR cmyk+offset) ***
25 -> 5x5 (cmyka)
30 -> 6x5 (cmyka+offset)

The two difficult ones (*** above) could be determine by whether the image is in CMYK colorspace or not.

I advocated this. But it was never implemented.

You have changed your docs for -color-matrix quite a bit since I last looked.

Thanks. You posted as I was modifying my post above. I think I am beginning to understanding now, since you don't allow cmyk at this time. But am I correct in that the k is meaningless and included to fill out the diagonal of ones (and possibly as a placeholder for future cmyka+offset)

3x3 is rgb

4x4 cannot be rgba --- it must be rgbk?

5x5 is rgbka

6x6 is rgbka+offset

Are the 4x4 and 5x5 self-determined without the WxH? I believe that one does not need the WxH for 3x3 or 6x6. Correct?

fmw42 wrote:You have changed your docs for -color-matrix quite a bit since I last looked.

That must have been some time ago!

Thanks. You posted as I was modifying my post above. I think I am beginning to understanding now, since you don't allow cmyk at this time. But am I correct in that the k is meaningless and included to fill out the diagonal of ones (and possibly as a placeholder for future cmyka+offset)

Yes, but I did not do it.

3x3 is rgb

(or cmk, or hsl, or hcl

4x4 cannot be rgba --- it must be rgbk?

AT THE MOMENT, yes. But it was a proposal in what it could mean in a operator update. It could also be cmyk

Are the 4x4 and 5x5 self-determined without the WxH? I believe that one does not need the WxH for 3x3 or 6x6. Correct?

It is the morphology kernel code that parses it, and that assumes it is square when WxH is not provided.