Macro language equivalent to “Image > Adjust > Brightness/Contrast… > Apply”



I am trying to write an ImageJ macro and need to duplicate what happens when you use “Image > Adjust > Brightness/Contrast… > Apply” on an image that is neither 8-bit nor RGB. I have tested with a 16-bit grayscale and confirmed that doing so using the GUI does, in fact, change the pixel values. However, when I try to use the commands listed in the recorder, it gives me an error message stating the supposed limitations as described in the documentation. This is true for both the macro language (‘run(“Apply LUT”)’) and Java (‘, “Apply LUT”, “”)’). Is the output of the recorder incorrect, am I missing something else, or is it a bug that this works using the GUI?

This topic was originally posted on StackOverflow. However, per a user’s suggestion, I have reposted it here.



Welcome to the Forum !!! And thanks @imagejan for pointing you here …

Would you be able to post a snippet of your code and perhaps an image as a test example? Just so we can see if we can recreate the same error… and what was the exact error message? Is it that you were NOT expecting pixel changes because (as per the User Guide):

Apply Applies the current display range mapping function to the pixel data. If there is a selection, only pixels within the selection are modified. This option currently only works with 8-bit images, 8-bit stacks and RGB stacks. This is the only B&C option that alters the pixel data of non-RGB images.

(Did any of this functionality change for images other than 8-bit @Wayne?)

When I just did my own ‘dumbie’ test (too - note that I might be mis-interpreting the real issue you are encountering here) - I got the changes to pixel values after running the following code example on a 16-bit test image (File > Open Samples > Neuron (1.6M, 5 channels)):

run("Neuron (1.6M, 5 channels)");
run("Split Channels");

// can also uncomment 3 lines below - to test with ROI
//makeRectangle(162, 163, 196, 146);
//roiManager("Select", 0);

run("Enhance Contrast", "saturated=0.35");
run("Apply LUT");

I’m running on a Mac OS X Yosemite 10.10.5: ImageJ 2.0.0-rc-61/1.51n; Java 1.8.0_66 [64-bit].




Thank you for replying. Here is the snippet of code that produces the error.

for (j = 0; j < num_files; j++) {
    setMinAndMax(min, max);
    run("Apply LUT");
    saveAs("Tiff", save_path+IJ.pad(idx, 5)+"_"+file_names[j]);
    idx = idx+1;

The idea is that the macro grabs all images in the specified folders and adjusts the brightness/contrast using the specified values. The macro should then save the images to a different folder as specified by the user. If need be, I can copy the entire file (it looks like only images can be uploaded).

The attached images show the exact error message as well as the macro produced by the recorder which also gives the error message when used. The recorder-produced macro is the result of using the “Set” and “Apply” options on the “Brightness/Contrast…” graphical interface.

Based on the behavior when using the graphical interface, I expect the pixels to be changed. However, as already stated, when running from a macro, the error is produced and the image remains unchanged.

I am running Windows 7 Enterprise; ImageJ 1.50b

I am not sure which Java version as I can’t seem to find it by any of the common methods listed online.

Adjust Brightness-Contrast Error
Lines Produced by Macro Recorder


Upgrade to the current version of ImageJ (1.51p) and the run(“Apply LUT”) macro function will work as expected with 16-bit images.

This test macro

  run("M51 Galaxy (177K, 16-bits)");
  getMinAndMax(min, max);
  print("before: "+min+"-"+max);
  run("Apply LUT");
  getMinAndMax(min, max);
  print("after: "+min+"-"+max);


   before: 0-10106
   after: 0-65535



Thanks so much! My macro has a few other issues but this was the one I couldn’t figure out. That portion of the macro does indeed work now.



What about 32-bit images like this one? I know it looks all back but it isn’t.


For anyone coming across this later, run(“Apply LUT”) appears to be unnecessary for 32-bits; at least when converting to 8-bits as I was.