For 8 bit grayscale your method must be good.

I can not figure out a fast method for 32 bit grayscale, because there are too many cases. But I am sure that for 32 bit grayscale image the concept of LUT is bad even for the grayscale->RGB transformation. I do not know ImageJ (I use OpenCV), but I suppose that for coloring 32 bit grayscale images it uses functions: if you have got a grayscale value "V", it uses R(V), G(V), B(V) functions. I think you should "measure" these functions in a lot of points and try to construct interpolation table from them: IR[V], IG[V], IB[V].

If you have got a pixel with (Rp, Gp, Bp) values you can find the V, where Rp≈IR[V] and Gp≈IG[V] and Bp≈IB[V].

The problem is that generally R(V), G(V), B(V) will not be monotonic. But in a lot of colouring schemes the colour has monotonic dependence in HSV, HSL, CIE LUV or other coordinates. It is the case in your example: H (hue) depends monotonically on grey value. If you can find such a monotonic colour coordinate, you can build an interpolation table, e.g. H[V], and in this table you can easily search the V value for a specific H.

If you have such monotonic colour coordinate, the 8bit case can be faster too.

I hope this helps you.

It probably depends on the programming/scripting environment you are using ...

In a fast compiled programming language (such as C, C++, ...), a low-level approach would be to loop over all pixels (you must look at each pixel anyway), and write a new image (2D array) with the original intensity levels after translating each RGB value into your original intensity. This can be done with some kind of associative array (= dictionary, symbol table, map ...) whose keys are the RGB tuples (or derived integers such as R + 256 * G + 65536 * B); the value is just the original intensity.

The required associative array would be small (256 entries) for an originally 8-bit intensity (gray-scale) dataset; it would still be of reasonable size for originally 16-bit data (65536 entries); the approach should work efficiently in both scenarios. (I'm not aware of any 32-bit intensity (gray-scale) data applications, which really use all 4.3e9 intensity values - you will probably need some different, more efficient approach in this case.)

Many languages have support for associative arrays (or maps); for C, you will need some external implementation (cf. links below).

http://en.wikipedia.org/wiki/Associative_array

http://stackoverflow.com/questions/4864453/associative-arrays-in-c

Hello Andras and Olaf,

I'm using imageJ because it is very often used in life sciences and at the time I'm writing my scripts mostly in the imageJ macro language. So far I'm very happy with. Sooner or later I will also try out some more straightforward languages. Because the problem with the ImageJ macro language is, that for many tasks it is very slow. For example when I assign pixels in a loop, even if I use the "batch mode". Arrays in general are also very poorly supported and by default lack a lot functionalities; Only 1-D arrays are supported, and therefore no associative arrays :-( However, for most tasks there are roundabouts or shortcuts and with your nice suggestions I certainly will find a solution.

Thanks!

Am I right in assuming you don't know the LUT? In that case, your problem is very ill-posed. Given the RGB image, I would first compute its histogram. If the RGB image truly comes from applying a LUT to an 8-bit grayscale image, then you will find that at most 256 entries in the histogram will be different than zero. Each of those entries corresponds to an 8-bit gray level, but it's impossible to know which corresponds to which without additional constraints (there could be up to 256! solutions). For instance, one constrain could be smoothness-related: similar RGB colors correspond to similar grayscale values. Another constraint could be intensity-related: intense colors correspond to intense gray values. Under these constraints, it should not be hard to pose the problem as a combinatorial optimization problem and solve it with any combinatorial search algorithm like simulated annealing, genetic algorithms or metropolis.

Hello Alfonso,

I of course would have to know at least which LUT was used, otherwise I would be lost :-) especially if the LUT can not be defined as some kind of a gradient. I however don't know if I can access the lookup tables with an imageJ macro (I doubt it). My idea was just to give me the possibility if I had lost the original grey scale image, that I could back calculate it from the RGB image which is the result of an RGB conversion of my image with a known LUT.

I liked this question when I first saw it... I've attached a macro that uses your method, taking advantage of ImageJ's 'changeValues' macro function.  Wouldn't really trust it and definitely wouldn't advise using it for anything serious (what if the brightness/contrast was set before RGB conversion - or if multiple values map to the same RGB entry in the LUT?), but it's a nice question to look for an efficient solution :)

This way likely ends up resulting in every pixel being visited 256 times, which isn't great... but since I also don't think ImageJ's macro language supports maps, I don't know of a better solution.  Would be interested if you come up with one :)

Hello Pete,

I came up with a somewhat similar solution to yours but my code was again a bit longer. I searched my computers and hard drives but couldn't find the macro so far. I will upload my solution in case i find it soon. Thanks again for your very useful Input! :-)

Hi Martin,

This is actually a question.

I have used an imageJ plugin "PIV" to produce plots of particle velocity with colourised arrows indicating vector magnitude. It is a good plugin (Tseng PIV), but there is a problem. There seems to be a bug that does not allow me to select the LUT for the vector colourisation. The default setting is too dark for printing and a PhD (still) needs to be printed at my university. Thus I have a requirement for your LUT reversal algorithm!

Did you ever get it working?

Thanks and regards,

Lucas.

https://sites.google.com/site/qingzongtseng/piv

Hello Lucas,

if you can access the Lookup table, you may reverse it. This is if your Luted image is saved in a losless format and if your assigned RGB values are unique. Pete Bankhead added a working FIJI macro (Undo_LUTs.ijm) in his answer above. If you can't make it run, let me know. I am happy to help you, otherwhise maybe ask Pete, he's an extremely talented image processor.  

Martin