Home > Archive > Java Help > July 2006 > Newbie Image class question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Newbie Image class question
|
|
| fiziwig 2006-07-27, 7:01 pm |
| I have an image in an ImageIcon that I need to BASE64 encode for
transmission. How do I get the pixel bytes from an Image object?
Image.getSource() gets me something called an ImageProducer, (whatever
that is) but I don't see how that gets me any closer to being able to
turn the actual image into an array of bytes so I can encode them.
What I seem to need is the OPPOSITE of the ImageIcon constructor:
ImageIcon(byte[] imageData) that will get me back the image data as a
byte array, but there doesn't seem to be such a method in the ImageIcon
or Image class.
Any hints or clues would be deeply appreciated.
--gary
| |
| Knute Johnson 2006-07-27, 7:01 pm |
| fiziwig wrote:
> I have an image in an ImageIcon that I need to BASE64 encode for
> transmission. How do I get the pixel bytes from an Image object?
You can't easily.
> Image.getSource() gets me something called an ImageProducer, (whatever
> that is) but I don't see how that gets me any closer to being able to
> turn the actual image into an array of bytes so I can encode them.
It won't help you.
> What I seem to need is the OPPOSITE of the ImageIcon constructor:
> ImageIcon(byte[] imageData) that will get me back the image data as a
> byte array, but there doesn't seem to be such a method in the ImageIcon
> or Image class.
Doesn't exist.
> Any hints or clues would be deeply appreciated.
Don't use ImageIcons as the class to load images with. Use the methods
from the ImageIO class. That will give you a BufferedImage that has a
method to return the actual byte values of the pixels.
If you are using an ancient version of the VM then you can:
1) get the Image from your ImageIcon
2) create a BufferedImage of the same dimensions
3) draw the Image onto the BufferedImage
4) recover the pixel values from the BufferedImage
My best suggestion is to use the modern classes and methods.
--
Knute Johnson
email s/nospam/knute/
| |
| fiziwig 2006-07-28, 7:02 pm |
|
Knute Johnson wrote:
> fiziwig wrote:
<snip>
> If you are using an ancient version of the VM then you can:
>
> 1) get the Image from your ImageIcon
> 2) create a BufferedImage of the same dimensions
> 3) draw the Image onto the BufferedImage
> 4) recover the pixel values from the BufferedImage
>
Thanks, that worked.
> My best suggestion is to use the modern classes and methods.
Thanks. I'm sure that's good advice. As a newbie to Java, is there
anything in the Java docs that tells me which are the modern classes
and methods? I just built my very first ap on snipets of code borrowed
from the Java tutorial on the sun site. I don't recall any mention of
"modern" vs "ancient" classes.
--gary
> --
>
> Knute Johnson
> email s/nospam/knute/
| |
| Oliver Wong 2006-07-28, 7:02 pm |
|
"fiziwig" <fiziwig@yahoo.com> wrote in message
news:1154110981.948447.308110@s13g2000cwa.googlegroups.com...
>
> Knute Johnson wrote:
>
> Thanks. I'm sure that's good advice. As a newbie to Java, is there
> anything in the Java docs that tells me which are the modern classes
> and methods? I just built my very first ap on snipets of code borrowed
> from the Java tutorial on the sun site. I don't recall any mention of
> "modern" vs "ancient" classes.
Not really, AFAIK. Some classes have a "since" tag, which tell you when
they were introduced. If they were introduced since 1.5, for example,
they're probably not ancient (seeing as how 1.5 is the current version at
the time of writing this post). However, even if you see something like
"since 1.1", while that's an indication that the class is old, that doesn't
nescessarily mean there exist anything newer to replace it. Maybe that old
class is doing its job well, and Sun is following a "If it ain't broke,
don't fix it" philosophy.
On the other than, there's also a "deprecated" tag. This is supposed to
clearly indicate that you should avoid the class whenever possible, because
something newer HAS replaced it. Ideally, near the "deprecated" tag will be
an explanation of what to use instead of this class, but sometimes the
documentation authors forget to write that stuff.
- Oliver
| |
| Andrew Thompson 2006-07-28, 7:02 pm |
| Oliver Wong wrote:
> "fiziwig" <fiziwig@yahoo.com> wrote in message
> news:1154110981.948447.308110@s13g2000cwa.googlegroups.com...
>
> Not really, AFAIK. Some classes have a "since" tag, which tell you when
> they were introduced. If they were introduced since 1.5, for example,
> they're probably not ancient (seeing as how 1.5 is the current version at
> the time of writing this post). However, even if you see something like
> "since 1.1", while that's an indication that the class is old, that doesn't
> nescessarily mean there exist anything newer to replace it. Maybe that old
> class is doing its job well, and Sun is following a "If it ain't broke,
> don't fix it" philosophy.
>
> On the other than, there's also a "deprecated" tag. This is supposed to
> clearly indicate that you should avoid the class whenever possible, because
> something newer HAS replaced it. Ideally, near the "deprecated" tag will be
> an explanation of what to use instead of this class, but sometimes the
> documentation authors forget to write that stuff.
Yes, that's occasionally true for both the @deprecated and
@since attributes.
OTOH, if you can get your hands on a JVM/rt.jar of that flavor,
simply and add it to the -bootclasspath at compilation time for
a definitive answer.
Andrew T.
| |
| Andrew Thompson 2006-07-28, 10:00 pm |
| Andrew Thompson wrote:
> Oliver Wong wrote:
>
> Yes, that's occasionally true for both the @deprecated and
> @since attributes.
>
> OTOH, if you can get your hands on a JVM/rt.jar of that flavor,
> simply and add it to the -bootclasspath at compilation time for
> a definitive answer.
(..ummm) to the '@since' in any case, I don't think* it
would warn of /deprecated/ classes or members.
* I can see no way that compilation against a 1.2 rt.jar
could warn you of something that was deprecated in 1.5.
Perhaps compile against both lowest and highest,
lowest for @since, highest for @deprecated.(?)
Andrew T.
|
|
|
|
|