Photoshop/Gimp type curves tool?

I only discovered ImageJ about a year ago but I’ve been working with digital images for at least 20 years. In the art/graphics/photography worlds a “curves tool” usually refers to a tool for manipulating the brightness/value of the images as a whole to have the desired effect on the histogram. It usually has nothing to do with Bezier curves, involving them is usually a disaster.

In the Unix world our main imaging tool is the GIMP, which has only an 8-bit per color data path. If you use a modern digital camera and want to work with “raw” files (direct from the camera’s sensor) those are often 14 bits per color. In the attached image most of the information is in the 0-64 range as 8-bit so it can have only 64 states when the original had more like 4000 states in that range.

I can appreciate that ImageJ isn’t intended as a tool for photographers in general but I would think such a tool would be beneficial in medical/scientific image processing. You may call it something else but I tried looking through the available plugins. In the attached image I wanted to compress the details in the highlights and emphasize the details in the shadows. Keeping as much precision as possible would be beneficial.

Welcome to the forum Alan!

It is great to see ImageJ used outside scientific image processing. I fear that any plugins or macros on this would feel clunky for artistic editing. But I wanted to mention that the development version of gimp 2.9.x supports up to 32-bit color depth, benefiting from several improvements in GEGL. Gimp 2.9 is available, e.g., through the gimp-edge ppa. It and seems quite stable already (although I only use it sporadically). (BTW, what about dartktable?)


I hadn’t looked at Gimp 2.9. Probably like most people I stick with the versions that come with the operating system (OpenBSD and Debian/Raspbian Linux in my case) because it’s possible to get into some gadawful messes if you don’t. If it’s possible to build Gimp 2.9 using the same libraries (including versions), etc. that 2.8 uses then I might try it. Otherwise I’ll have to wait for it to make its way into the stable versions of things I normally use. I don’t have time or bandwidth to mess with bleeding edge code.

Darktable I consider unusable because it has an incomprehensible user interface.

I had tried ImageJ and found it a tad slow on small (< 1000 pixel width) images because it’s written in Java. I was very pleasantly surprised to find it’s not much slower on camera-sized (6000x4000) images. And it correctly opens 16-bit TIFFs made with dcraw, which GIMP doesn’t. ImageJ’s dcraw plugin seems to only get me the embedded JPEG thumbnail, at least with Nikon .nef files. It’s possible the author didn’t have access to any and it works fine on Canon or Fuji raw files.

My beginnings in digital image processing were writing programs to massage spectrophotometer spectra in Apple 2 Pascal (80s), then Paint Shop Pro in the early 90s, then Photoshop in the mid 90s when I lived with an art major. I learned a lot of theory from Paint Shop Pro and Photoshop help files of that era. ImageJ being scientific in nature doesn’t bother me in the least. Most of GIMP’s features are irrelevant fluff apparently intended for people that draw in it. I tend to do statistical stuff working from histograms, resample to a smaller size for the web, add a watermark layer. Lately I’ve done some focus stacking with Hugin and Enblend, which I suspect do more automatic alignment and scaling than the stacking in ImageJ Example focus stack of 29 images enblend sets a local transparency (alpha) of a region based on its standard deviation. But overall I’m much more of a scientist than an artist. My photography is more physics than art.

Uh-oh, as an afterthought

I agree that such a feature would be quite nice in ImageJ and have been wanting it for some time.

In the meantime, there is another piece of scientific software you might try called MIPAV that has something like curves (notice its piecewise linear, not smooth). It also plays nicely with ImageJ.


Right idea, but LUTs are in < 256 color images. It would take 16777216 bins to handle 24 bit color. AKA palettes or color maps. I saw those in ImageJ, this looks like an editor for them.

Input file, nothing wonderful but an example of trying to expand shadows and not squash highlights. .nef file converted with dcraw to 48-bit TIFF, converted with ImageJ to a JPEG.

This is part of the interface in UFRaw importing my example .nef file. You set the slider at upper left so there are just barely no overexposed pixels, which is essentially a gain control. The curve below it has a nasty Bezier effect I don’t like but this time I started adding points at the bright end. The bottom histogram is output. At this point this is all 14 bits per color per pixel, once I hit the OK button it gets scaled into GIMP’s 8 bits per color per pixel. ImageJ can (I think) handle 16 bits here.

Actually it doesn’t, reading the plugin-writing tutorial, it doesn’t go beyond 8 bits per color. But ImageJ2 does.