Grabbing palette index from a pixel

Java 2D
#1

Hi,

I have a 16 colour indexed/paletted bitmap. After loading this into an object, I want to look at the image data and grab the palette index for a specific pixel.

How can I do this? I tried using a BufferedImage, being too stupid to realise that getRGB actually returns a colour value instead of an index. D’oh… I’m too used to retro programming ::slight_smile: ;D

Besides loading the bitmap in manually and sifting through the data, is there a lazy way to do it?

Speed isn’t important.

#2

hmm, if its an IndexColorModel bufferedImage, you should be able to do this… (I havn’t tried it, so it might not be exactly correct :))


BufferedImage icm = #your indexcolormodel image#;
int [] pixel = new int[1];
icm.getData().getDataElement(x,y,pixel);

System.out.println("pixel @ " + x +"," + y +" is set to index " + pixel[0]);
#3

Hi,

That done it, thanks. Was previously trying to access the DataBuffer instead of the Raster, and it was giving strange results.

Although, it’s getPixel(x,y,pixel) instead of getDataElement() :slight_smile:

Thanks, again.

David

#4

Hi,

Ok, ran into a new problem.

When using ImageIO to load into a BufferedImage directly, the above works fine.

I can’t use this though, since I’m writing an applet. Have to use getImage() instead.

So, I created a BufferedImage with type TYPE_BYTE_INDEXED, and gave it a new IndexColorModel object. Then I drew the previously loaded Image onto it.

So far so good. However, using the above code to grab the palette index from a pixel just gives nonsensical values.

Here’s the code:


            //create a new indexcolormodel
            byte[] t = new byte[16];
            IndexColorModel icm = new IndexColorModel(4,16,t,t,t);

            //draw the loaded image onto a BufferedImage
            tempImage = new BufferedImage(w,h,BufferedImage.TYPE_BYTE_INDEXED,icm);
            tempImage.createGraphics().drawImage(tempImage2,0,0,null);

            //grab a pixel
            int [] pixel = new int[1];
            tempImage.getData().getPixel(0,0,pixel);

            System.out.println(pixel[0]);

On a bitmap where the first three horizontal pixels have the values 1,2,1 this code will return 15, 15, 15.

Any ideas?

#5

drawing an image with a different pallete onto an Image of type IndexColorModel will force some kind of dithering. (to make the src colors fit within the pallete of the dst image)

if your dst image’s palette is full of zeros, all the pixels drawn will be dithered to the same arbitrary palette index.

hence your result :S

#6

Thanks for the reply again. That’s what I thought :frowning:

By tweaking the RGB values of the temporary palette, I did notice that the function is trying to be smart by remapping the image, thus destroying the data I want >:(

Are there any non idiot-proof methods for doing a direct data transfer from an Image to a BufferedImage?

Is getImage() the only way to load images in an applet?

If so, is there any other way to access the raw data of an Image?

Such a simple thing, and yet so awkward.

tears hear out

#7

Just out of curiousity, what are you trying to accomplish? There may be a better way than trying to read the pallette indexes.

#8

when i want to grab pixels i use java.awt.image.PixelGrabber

dunno if it does what you want, but look it up

#9

What I’m trying to do is use a bitmap as a very simple level-map, with each colour index representing a block type.

I know there’s a lot of map systems out there, but this is for a Uni project where every bit of code should be my own, and also has to be fully tested by myself.

So, I guessed this would be a nice easy way to implement a level map, and also get a free map editor in the process (MS Paint ;D ). It’s worked for me really well on other platforms before, and it gives GIF compression on the map in the bargain.

I think I’ll ditch the Applet and move to a JFrame, since the alternative idea of writing my own map format, loader and editor is just too much hassle for this :-/

#10

Errm… Maybe you have some secret reason I’m missing, but why don’t you just use the color value as a block type? Grayscale images would work particularly well since the red, green, and blue values would be the same.

#11

I considered this, but the team members who are going to be working on this map will most likely not have a clue how this works.

It’s easier to say “each colour represents a block type” than to say "colour #001001001 represents block 1, #002002002 represents block 2… " etc.

I guess a palette could always be provided to make sure the correct colours are always used, but then it limits the software they use.

For the moment though, JFrames are the way forward ;D

#12

You can still use the pallette. Just use the actual color value instead of the pallette value.