Translating greyscale image to colour

[Toll]

Current situation:

I have a greyscale image with alpha. I also have a colour. I want to change that greyscale image to the colour specified, with black remaining black and white being the specified colour, and the different shades of grey between becoming the shade of the specified colour.

I've got a couple of different thoughts about how to solve it myself, but I rather hope there's an easier way.

Solution one would be to use a BufferedImage and just use getRGB/setRGB excessively. This, however, will be slow...

The second solution would be to use the above and cache the result. Given that there can be up to 10 different colour schemes, and up to approx. 2000 different images, this can, in the end, become excessively memory-hogging (although the general case would likely be 3 colours and perhaps a hundred or two images). It would also mean I'd have to loop through all images whenever the user changes the colour.

Is there a magical third solution that can translate a greyscale image to colour on-the-fly that's fast enough to run hundreds of thousands of times per second?

No code available since this is just in the thought process right now.

[jim829]

Is there a magical third solution that can translate a greyscale image to colour on-the-fly that's fast
enough to run hundreds of thousands of times per second?

I believe it would depend on the processing power and image size. But I am unaware of such a capability.
I checked the documentation for the ColorConvertOP and it says this:

"This class performs a pixel-by-pixel color conversion of the data in the source image. The resulting color
values are scaled to the precision of the destination image. Color conversion can be specified via an array of
ColorSpace objects or an array of ICC_Profile objects."

So even the JDK does it pixel by pixel (but they probably work directly on the image raster).

Regards,
Jim

[Toll]

Hmm. So little hope of finding a memory-effective solution then... unless working on the image raster speeds the process up by a factor of ten or twenty or so. Managed to display 400 images updated at 30fps by doing the getRGB/setRGB (with an array of 256*3 to make me not having to recalculate the new colours all the time), which isn't nearly what I need. Buffering the drawn image made me able to put down ~100.000 images though, which is more than enough. Too bad on the memory though, but eh, win some lose some. If it all goes pear-shaped I can always revert back to the slow method. Thanks for the input though!

[JosAH]

Maybe an IndexedColorModel can be of help: the original grey values would be the index for the color model, while the value entries would make up the resulting color. If this works (and I think it can), the fun is that you can change the color by simply changing the LUT.

kind regards,

Jos

[Toll]

After reading up on it and wrapping my head around it... perhaps. It seems promising at least! Would need a fair bit of recoding, since it seems I'd have to create an indexed BufferedImage to use it with (or at least index the existing greyscale images). That is, unless I misunderstood something (which is always likely to happen when you're delving into the unknown). Definitely worth a quick test code though.

[JosAH]

My first (naive) approach would be to load the grey scale image somewhere, prepare a BufferedImage with an IndexedColorModel and draw the first image into the second one ...

kind regards,

Jos

[Toll]

Yeah, that's my thinking too. Right now I'm trying to figure out how to change the color model though... I can get the color model through getColorModel, but there's no setColorModel in BufferedImage. Likewise, I can get the data of the color model by using its functions, but there's no way to change the data in the color model that I can find. Unless, by using drawImage it actually uses the index of the BufferedImage and not the color it translates to (which, frankly, would be rather odd). But I haven't gotten to the code phase yet... Silly need to eat.

[jim829]

You set the color model when you create the target buffered image. It's a constructor argument.

Regards,
Jim

[Toll]

Yeah, that part I've found. But once I've got it in there, and the image is indexed and everything, how do I make it change colors if I can't actually change the underlying color model that translates the indexes to colors? As I said, I haven't started coding with it yet, so I might stumble across something when I do that, but right now I'm not sure how it's supposed to be done.

[Toll]

Managed to make it change colours by utilising getData in BufferedImage (which returns a Raster) and convertToIntDiscrete in IndexColorModel (which uses a Raster to create a BufferedImage). It was slightly quicker than my old method (by approx. 10%), but it wasn't fast enough. I might be able to use the IndexColorModel to lower the memory footprint though, if it ever becomes an issue, so the time spent certainly wasn't a complete loss!

[JosAH]

Hrmph, I gave it a second read, but it seems that the IndexColorModel isn't a real LUT, i.e. it seems that the color mapping can't be changed after it it set. That's a lousy implementation if you'd ask me ...

kind regards,

Jos

[jim829]

I tried the first approach suggested by Jos. Use a graphics context to write into another buffered image. It worked fine. I couldn't get the
raster method to work because I didn't notice the convertToIntDiscrete method. That will be useful. Too bad that you can't simply update
the map and then reapply it. What would really be nice if there was some way to share specific raster locations with colormap entries. Like a
many to one mapping which would simply take effect instantly.

Regards,
Jim

[Toll]

Yeah, sharing Raster between several images would be pretty awesome. As would being able to change the IndexColorModel in the BufferedImage. As it stands though, I doubt no matter what is tried the speed simply won't be where I need it to be, so for now, I'll just stick to caching generated images. Hopefully it won't be too bad; with any luck, I'll only need 200-400 different images in any one setting, even though there are a potential ~20.000 combinations. With any luck it'll work out.

[jim829]

If you are going to be caching images and have memory concerns, take a look at WeakReference and SoftReference classes. They might
be helpful.

Regards,
Jim

[Toll]

Hmm. I'll have a peek at those. Thanks!