Hello Martin,

I find this rather puzzling. The patterns you are getting are obviously a sort of brightness contours - something like Newton rings formed by interference of light. They highlight the subtle changes of brightness in the image such as can be seen on the neck of the dummy. Where there are steep gradients in brightness in the original image (such as on the sleeves of the dress) these "interference ring become very dense and difficult to discern.

However, I don't understand how these pattern can be obtained by the procedure you describe. When I look at the images in the individual channels, I don't see how I can get any patterns by summing them. Neither do I think that adding the edges could do the trick. Being, thus, puzzled, I tried to repeat the procedure outlined:

1) RGB to CMYK

2) edge detection on each channel

3) add the edge image to the original image in the respective channel

4) sum up the resulting 4 images.

but failed to get any such patterns (attached). Have I got correctly your procedure or have I missed some additional step which would be responsible for the patterns?

Radek

Btw. If I wanted to produce such patterns, I would divide the image by a constant and take the modulus, as shown at the attached image (made from the black channel). I believe that by taking all channels and fine tuning the constant I could get exactly the same image as you do. Though I don't say it's the only way how it can be produced.

Radek, I think you are right. Dividing the image by a constant and taking the modulus, is comparable to an overflow situation. I don't know ImageJ, but I think what happened is that by adding edges, some parts of the image could not 'fit' in 8 bits anymore, and the most significant bit was lost.

Hello Radek and Lampert,

thanks for your answers, in case you want to repeat it, this is my macro i made from my procedure (but you need to install the "RGB to CMYK" class)

rename("Ori");

run("RGB to CMYK");

selectWindow("CMYK_Ori");

run("Find Edges", "stack");

run("Z Project...", "projection=[Sum Slices]");

selectWindow("SUM_CMYK_Ori");

run("Invert");

selectWindow("CMYK_Ori");

close();

imageCalculator("AND create 32-bit", "Ori","SUM_CMYK_Ori");

run("Images to Stack", "name=Stack title=[] use");

I've tried your code and it starts to make more sense to me. Your code doesn't do exactly what you've described in your question - namely, the code doesn't add edges to individual CMYK channels, instead it adds the sum of all edge images to the original image (the one in RGB space):

imageCalculator("AND create 32-bit", "Ori","SUM_CMYK_Ori");

Since the sum of edge images is a 32-bit grey-scale image and the original is an RGB, they are not compatible and, as Lambert suggested, there happens some sort of overflow. I'm not sure, though, how exactly Image J handles arithmetic operations between grey-scale and RGB images. If I first convert the image "SUM_CMYK_Ori" to RGB, I get again something like the image attached to my first answer.

Thank you! This was very helpful! :-)

If I follow, another explanation could be a one-letter typo :-)

imageCalculator("AND create 32-bit", "Ori","SUM_CMYK_Ori");

looks like it should be

imageCalculator("Add create 32-bit", "Ori","SUM_CMYK_Ori");

Is that right?

---

(Answer edited because I made a typo in my attempt to highlight the typo....)

Hi Peter, true, still gives me the same result... :-)

Not for me - after I fixed my own typo, I got the attached image.

ImageJ should be doing the 32-bit conversion or the RGB image before any combination because you use the 'create 32-bit option', so it shouldn't cause overflow.... and without the 32-bit flag, it behaves nicely and clips to 255. 

It's a nice example of image/bitwise-operation oddness though... I added some lines to your macro (and commented out one):

rename("Ori");

run("RGB to CMYK");

selectWindow("CMYK_Ori");

run("Find Edges", "stack");

run("Z Project...", "projection=[Sum Slices]");

selectWindow("SUM_CMYK_Ori");

run("Invert");

selectWindow("CMYK_Ori");

close();

imageCalculator("AND create 32-bit", "Ori","SUM_CMYK_Ori");

//run("Images to Stack", "name=Stack title=[] use"); 

setThreshold(5, 100);

run("Create Selection");

selectWindow("Ori");

run("Restore Selection");

run("Histogram");

rename("Histogram from combined >= 5");

selectWindow("Ori");

run("Make Inverse");

run("Histogram");

rename("Histogram from combined < 5");

If we get the same, the histograms should look a bit interesting.  Then there is the question of why the background value is 11.4677 after run("Invert")... :-)

rename("Ori");

run("RGB to CMYK");

selectWindow("CMYK_Ori");

run("Find Edges", "stack");

run("Z Project...", "projection=[Sum Slices]");

selectWindow("SUM_CMYK_Ori");

run("Invert");

selectWindow("CMYK_Ori");

close();

imageCalculator("AND create 32-bit", "Ori","SUM_CMYK_Ori");

//run("Images to Stack", "name=Stack title=[] use"); 

setThreshold(5, 100);

run("Create Selection");

selectWindow("Ori");

run("Restore Selection");

run("Histogram");

rename("Histogram from combined >= 5");

selectWindow("Ori");

run("Make Inverse");

run("Histogram");

rename("Histogram from combined < 5");

selectWindow("Histogram from combined < 5");

run("Duplicate...", "title=1");

selectWindow("Histogram from combined >= 5");

run("Duplicate...", "title=2");

color = newArray("Red","Green");

for(i=1; i

Yes, that looks familiar - although your merge is a nicer way to look at it :-)

I use the latest ImageJ & Fiji and switch between them.  Probably ImageJ most of the time unless I know I need a particular Fiji feature (like the script editor).

so, the pixel values of the resulting image smaller than 5 were in the original image in alternating intervals with the other pixels. I need to think how that makes sense. I guess it's too much for me.

For me too.  The 5 was really just because it was around about the middle of the image range.  To make much more sense of it, I had a look at the relevant source code (It's here https://github.com/imagej/imagej1/blob/master/ij/process/FloatBlitter.java#L106 if you're interested...).  It seems that the 32-bit floating point values in your two images are rounded down to the closest integer, and then a new integer created by AND-ing the bits of the integers together: http://en.wikipedia.org/wiki/Bitwise_operation#AND

Once you know that ImageJ rounds down the values and discards the fractions before combining them (with AND... not for adding, subtracting etc.), you can see that in your edge image most pixels end up being rounded to 11.... which in binary is 00001011.  Because you'll get 0's in the same place when you AND this with *anything*, you can only end up with

00001011 = 11

00001010 = 10

00001001 = 9

00001000 = 8

00000011 = 3

00000010 = 2

00000001 = 1

00000000 = 0

i.e. the result of the AND operation might change a 1 to a 0, or keep it as a 1, but it won't change a 0 to a 1 (I've pretended it's 8-bit because the other 24 bits don't really matter in this case, as they are all 0).  In the histogram of your original result image, most pixels had one of the values I listed (there were a few in between corresponding to where the edge image wasn't rounded down to 11, but instead to some other value).

When you threshold at 5, you separate the numbers ending with 00, 01, 10 and 11 from the others, leading to the gaps in the histograms.

And *that* is why I think it's better to use 'Add' with the image calculator than 'AND' :-)

(Ok, I suspect that might have been fairly incomprehensible, but it's as far as I could get...)

Ok, now it makes absolute sense to me, thank you! I had to read it 3 times but now I can see what imageJ does there. Thanks for your help! :-)