For Programmers: Free Programming Magazines  


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.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com