• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Graphics - BufferedImage - ImageIO problem

 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This has me really mystified. WinXP, Java 1.5, JAI version 1_1_2_01.
I need to read a screen-shot of a dialog in GIF format, draw on the image, and write out the modified image. I am reading a BufferedImage with ImageIO and trying to modify it in the following code.

The intent being to draw green rectangles around rectangles of interest. Note that I have to change the type from GIF to PNG (or jpg) because ImageIO does not support writing GIF (that Compuserve copyright thing).
The first screen shot I tried - worked great - green rectangles around the hot spots in the resulting image file.
The second screen shot - - grey rectangles, not green.
Looking at the characteristics of the screen shot GIF files with paint shop pro - they appear to be identical, no special transparency, typical color set, etc.
I'm wracking my brain here
What can possibly be causing the color in the second example to be grey, not the Color I specified?
Bill
 
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, just a guess, but maybe the colour you are using is in the indexed palette of the first image, but not the second, so some weird internal mapping is choosing gray as a substitute?

Just thinking about how you could check.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, Horatio's idea sounds very plausible. You might be able to find out using graphics.getGraphicsConfiguration().getColorModel(). Or if you've got a BufferedImage then you can call getColorModel() directly. I'm not sure where exactly you'd go from there - probably do a getClass() and then study the API for whatever specific ColorModel you're dealing with. Good luck...
[ March 26, 2005: Message edited by: Jim Yingst ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since you've got a BufferedImage, it might also be useful to do a getRGB(x[i], y[i]) immediately after drawing the rectangle, to discover if the problem occurs in the drawing of the rectangle, or later in the writing of the image file.
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very helpful suggestions - I will report back on the results. I tested some more screen shots - some will show green, some show gray.
Thanks, Bill
 
Horatio Westock
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi again,

I just tried this out of curiosity. I started with two test images:

Image 1: GIF with 2 colour palette (red & black).

Image 2: GIF with 4 colour palette (red, black, green, white).

I tried to draw a pure green (00FF00) rect to both. The first ended up with a black rect, the second, a nice green rect.

I'm just experimenting with how to modify the colour model. I'll post again if I have any luck.
 
Horatio Westock
Ranch Hand
Posts: 221
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, this is probably not the correct way to do this, but it seems to work.

The theory is, create a BufferedImage with a ColorSpace large enough for most things, then copy your image into it, letting the internals worry about colour conversion, before doing any of your drawing operations.

e.g.



I initially tried to use image.setData( sourceImg.getData() ), but got some weird exceptions.

Anyway, not the best solution, but if you just want to get it working for now, this might work.
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have liftoff
Horatio Westock's suggestion works! The interesting thing to me is that the original screenshot GIF images do not use all of the color indexes available , but simply drawing with a new color can't add it to the table like I thought it could. Typical:
screen shot - uses 142 colors
modified - uses 143 colors

Seems to me there ought to be a way to add a new color to the screenshot color model and then draw with that color, but this works so I am happy.
Bill
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recently battled with this problem as well. You have a good solution in hand, but yes, you can also do this the hard way too.

If you are looking for a solution that maintains the exact indexed color model with only a few colors added, I found that creating a new BufferedImage with a new ColorModel solves this problem. This requires copying all of the colors from the source color model and leaving room to add additional colors in the new color model. Then you create a new buffered image with the new color model. I wrote a method, normalizeImage(), that takes a buffered image with an indexed color model and adds a few colors to the color map with which I want to draw. Here's what the method looks like:



However, with this in hand, I then wanted to draw text on the image with an anti-aliased font. This required the use of many more colors (they play with the color and alpha level on background colors for smoothing) and it was clear that nearly zero of these new colors were in the original color model. To solve this, instead of creating my own color map, I just always use the buffered image constructor that appears in the above catch() block. Then I end up with code that looks very much like Horatio's.

Goodluck!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic