Skip to main content

[JAVA2D] I need a way to decode an image file directly into a byte or integer array...

6 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
imagero
Offline
Joined: 2003-11-18

> But this whole experiment still leads me back to ask
> for a way to
> decode an image directly into an integer array like I
> first asked.
>
> Something like pixels =
> imageReader.decodeFileBytesToIntegerArray(...)
>
> But all I seem to get from you is "...rewrite the
> applet..." Ok.

Ken, don't rewrite applet, but add conversion (just a few lines of code) from byte array(s) to int array.
This is really an inexpensive operation.

Andrey

Ken Warner

Thanks, I've done that and am getting much better performance
than previously.

ba = ((DataBufferByte)(bi.getRaster().getDataBuffer())).getData();
pixels = new int[width*height];
for(int i = 0,j = 0; i < pixels.length; i++,j+=3)
{
pixels[i] = 0xff000000 | (((ba[j+2] & 0x000000ff) << 16) | ((ba[j+1] &
0x000000ff) << 8) | (ba[j] & 0x000000ff));
}

Now I'm exploring

ri = reader.readAsRenderedImage(0, param);

But this stuff is really dense and convoluted. It would probably
make more sense to me if I took a hit of LSD but...

java2d@JAVADESKTOP.ORG wrote:
>>But this whole experiment still leads me back to ask
>>for a way to
>>decode an image directly into an integer array like I
>>first asked.
>>
>>Something like pixels =
>>imageReader.decodeFileBytesToIntegerArray(...)
>>
>>But all I seem to get from you is "...rewrite the
>>applet..." Ok.
>
>
> Ken, don't rewrite applet, just add conversion (just a few lines of code) from byte array(s) to int array.
> This is really an inexpensive operation.
>
> Andrey
> [Message sent by forum member 'imagero' (imagero)]
>
> http://forums.java.net/jive/thread.jspa?messageID=275567
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

demonduck
Offline
Joined: 2008-03-14

Well, I stumbled onto a way to decode a JPEG image even faster than using ImageIO.

Here's the gist from SUN:

http://java.sun.com/products/java-media/2D/samples/suite/Image/JPEGFlip....

Here's a snippet:

BufferedImage bi1 = null;
JPEGImageDecoder decoder = JPEGCodec.createJPEGDecoder(new ByteArrayInputStream(imageBuffer));
bi1 = decoder.decodeAsBufferedImage();

It's twice as fast (takes half as long) as:

readers = ImageIO.getImageReadersByFormatName("jpg");
reader = (ImageReader)readers.next();
reader.setInput(iis, true);
bi1 = reader.read(0,null);

AND -- the JPEGDecoder returns a BufferedImage with a DataBufferInt just
like what I wanted.

The problem is (there's always a problem) from the documentation of JPEGCodec:

* This interface describes a JPEG data stream decoder. This decoder
* takes an InputStream that contains JPEG encoded image data. The
* JPEGImageDecoder will decode the JPEG image data according to the
* parameters set in a JPEGDecodeParam object. The resulting image
* data is returned in either a Raster or a BufferedImage.
*
* Note that the classes in the com.sun.image.codec.jpeg package are not
* part of the core Java APIs. They are a part of Sun's JDK and JRE
* distributions. Although other licensees may choose to distribute these
* classes, developers cannot depend on their availability in non-Sun
* implementations. We expect that equivalent functionality will eventually
* be available in a core API or standard extension.
*
* @see JPEGCodec
* @see JPEGDecodeParam
* @see Raster
* @see BufferedImage
* @version 4 December 1997

That's right -- ten years ago we were promised " equivalent functionality will eventually be available in a core API or standard extension. " What we have now is certainly not equivalent if it takes twice as long to do a similar thing.

And what I get when I (unknowingly) ask for what was promised ten years ago is a demeaning and derogatory "...re-write your applet..."

I don't have very positive feelings about the Java2D team right now.

Ken Warner

Whatever... The image was not being drawn because the alpha
channel was 0x00. Initializing the alpha channel to 0xff allowed
us to see the image. I don't have a lot of energy for a big discussion
about this.

But this whole experiment still leads me back to ask for a way to
decode an image directly into an integer array like I first asked.

Something like pixels = imageReader.decodeFileBytesToIntegerArray(...)

But all I seem to get from you is "...rewrite the applet..." Ok.

I think I'm done.

Jim Graham wrote:
> The MemoryImageSource relies on the ColorModel to define whether or not
> the data contains an alpha channel. If you use one of the MIS
> constructors that does not take a ColorModel object then those
> constructors are specifically specified to use the default RGB
> ColorModel as defined by the ColorModel.getRGBdefault() method which
> specifies 8 bits of alpha.
>
> I'm not sure what you mean when you say that it "means it's transparent
> to [...] BufferStrategy" since that object doesn't deal with pixel
> storage formats...
>
> ...jim
>
> Ken Warner wrote:
>
>> Maybe it doesn't mean the BufferedImage is transparent but
>> 0x00 in the alpha channel of a pixels means it's transparent to the
>> MemoryImageSource and BufferStrategy.
>>
>> Jim Graham wrote:
>>
>>> The 3byte databuffer has no storage available for an alpha value.
>>>
>>> When the data is loaded into the TYPE_INT_RGB BufferedImage there is
>>> no alpha stored there since that is an opaque type. More
>>> specifically, if you load one of the integers from the underlying
>>> int[] pixel array of such an image the upper 8 bits are undefined and
>>> should be ignored - if those bits are 0 then that does not mean that
>>> the pixel is transparent, and if they contain a 0xff value then that
>>> is just a lucky coincidence as those bits are not explicitly tracked
>>> or initialized by any code that deals with that image type...
>>>
>>> ...jim
>>>
>>> Ken Warner wrote:
>>>
>>>> I just thought of something. What is the alpha channel set to
>>>> when the BufferedImage is created and the databuffer is extracted?
>>>>
>>>> If the alpha channel is 0, that would explain a lot. That means the
>>>> image is transparent. There's two stages of rendering. The first
>>>> stage
>>>> only does nearest neighbor interpolation. The second stage does a
>>>> bi-cubic
>>>> interpolation and I explicitly initialize the alpha channel to 0xff
>>>> to make
>>>> the image not transparent.
>>>>
>>>> Ken Warner wrote:
>>>>
>>>>> Hi Jim,
>>>>>
>>>>> I'm not communicating the step by step procedure for the projection
>>>>> I guess. It's not like you describe. There is no massaged data.
>>>>> It's
>>>>> just a pixel map that I take a portion of and calculate a gnomic
>>>>> projection.
>>>>>
>>>>> If I had a white board I could draw a diagram that explains
>>>>> everything.
>>>>>
>>>>> It's a realtime (sort of) projection.
>>>>>
>>>>> Anyway, here's the two different versions of the applet I
>>>>> promised. One
>>>>> uses PixelGrabber the other uses BufferedImage. This is the
>>>>> performace
>>>>> problem I'm seeing.
>>>>>
>>>>> I always take the blame for something like this until proven
>>>>> otherwise.
>>>>>
>>>>> So I must be doing something wrong but the code is so simple I just
>>>>> don't see where.
>>>>>
>>>>> http://pancyl.com/BufferedImage.htm
>>>>>
>>>>> http://pancyl.com/PixelGrabber.htm
>>>>>
>>>>> PixelGrabber works ok for a prototype.
>>>>> BufferedImage is a mystery yet.
>>>>>
>>>>> You have the source to the class where
>>>>> the problem is. If you have time to take a look at makeBuffereImage()
>>>>> and maybe you will see something I don't.
>>>>>
>>>>> Ken
>>>>>
>>>>> Jim Graham wrote:
>>>>>
>>>>>> Hi Ken,
>>>>>>
>>>>>> Do you really need to rewrite it all the way through? For
>>>>>> example, the massaged data (that has been run through the
>>>>>> panoramic projection) could be stored in integer format - it's
>>>>>> just the code that reads a pixel out of the source tiles that
>>>>>> needs to change, but any intermediate storage and the final
>>>>>> storage that you use could be integer-based.
>>>>>>
>>>>>> I'd have to see the conversion code to make any suggestions beyond
>>>>>> these guesses...
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>> Ken Warner wrote:
>>>>>>
>>>>>>> I'll try that.
>>>>>>>
>>>>>>> Using bi = reader.read(0,param);
>>>>>>> PanTile Testbed
>>>>>>> 1813
>>>>>>> 1031
>>>>>>> 1001
>>>>>>> 982
>>>>>>> 941
>>>>>>> 981
>>>>>>> 1002
>>>>>>> 971
>>>>>>>
>>>>>>> Using bi = reader.read(0) <-default reader
>>>>>>> PanTile Testbed
>>>>>>> 1081
>>>>>>> 601
>>>>>>> 291
>>>>>>> 330
>>>>>>> 261
>>>>>>> 270
>>>>>>> 300
>>>>>>> 280
>>>>>>>
>>>>>>> Using PixelGrabber etc.
>>>>>>> PanTile Testbed
>>>>>>> 1432
>>>>>>> 1221
>>>>>>> 1272
>>>>>>> 1112
>>>>>>> 1141
>>>>>>> 1081
>>>>>>> 1101
>>>>>>> 1092
>>>>>>>
>>>>>>> Clearly the default reader is faster by a lot -- except the data is
>>>>>>> not in a format I can use in the current version. The current
>>>>>>> version
>>>>>>> of the apple is only expected to download one image so I wasn't much
>>>>>>> concerned with that piece of code.
>>>>>>>
>>>>>>> A version loading tiles is another thing. But the code would
>>>>>>> have to
>>>>>>> be re-written all the way through to the final paint loop.
>>>>>>> Because I use
>>>>>>> integer arrays everywhere.
>>>>>>>
>>>>>>> Maybe it would be worth the effort if I could be sure that the
>>>>>>> final
>>>>>>> performance was really going to be much faster than it is now. The
>>>>>>> rendering would have to be significantly faster to make the re-write
>>>>>>> really worth the effort.
>>>>>>>
>>>>>>> And while I have been resistent to the idea of using
>>>>>>> BufferedImages --
>>>>>>> I will do anything to make my applet faster. But given that the
>>>>>>> applet is stable and fairly well tuned using integer arrays, I'm not
>>>>>>> likely to re-write it using the three byte databuffer to save 800ms
>>>>>>> per 1meg tile. Tiles will most likely be even smaller.
>>>>>>>
>>>>>>> *And the performance slowdown is after I get the pixels from the
>>>>>>> databuffer.*
>>>>>>>
>>>>>>> After the int [] pixels is assigned to, all the other code
>>>>>>> remains the same
>>>>>>> except I see this unexplained slow down in user interaction.
>>>>>>>
>>>>>>> If I can figure that problem out (with your help) then it might
>>>>>>> be worth the
>>>>>>> re-write.
>>>>>>>
>>>>> [stuff deleted]
>>>>>
>>>>> ===========================================================================
>>>>>
>>>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>>>> the body
>>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>>> email to
>>>>> listserv@java.sun.com and include in the body of the message "help".
>>>>>
>>>>
>>>> ===========================================================================
>>>>
>>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>>> the body
>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>> email to
>>>> listserv@java.sun.com and include in the body of the message "help".
>>>
>>>
>>>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Jim Graham

Hi Ken,

I'm sorry that you are having trouble understanding the newer imaging
APIs as they generally provide facilities that are quite flexible and
useful for writing the type of application that you are creating here.
The primary missing link would seem to be some documentation that would
bridge the gap for you and I have been trying to help you out there with
some email conversations behind the scenes. Apparently the frustration
there is not worth the gains for you.

This may not make sense to you, but your request for a new API to
produce "the data you want" would not streamline the process for the
simple fact that you want to work with data in a format that differs
from what is generated by the JPEG decoders so some format conversion
must occur somewhere. The only "conversion free" way to get the raw
pixel data from the JPEG decoders is to accept it in the 3byte format
that they want to generate it in. Your request for a new API would not
change that fundamental fact of the JPEG format in any way.

The old PixelGrabber code was probably the least efficient way to get
the data converted into the format you want.

The ImageI/O mechanism you chose, which allows you to specify the format
of the generated BufferedImage is more efficient than the PixelGrabber
method per your own image reading benchmarks. Apparently it had some
negative interaction with the rest of the code which I was hoping to
help you figure out, but it is hard for me to debug such problems via
email without seeing the rest of the code.

Adapting your code to the inherent storage format used by the JPEG
decoders (the 3byte format) is the only way to eliminate the loading
overhead.

We aren't being lazy or obstinate here Ken. Just because you can write
pseudo-code for your desired API doesn't mean it will magically
implement itself with zero overhead. It won't happen. If you do not
wish to understand the underlying flow of pixel data enough to
understand that, then feel free to live with the overhead of whichever
mechanism you find most easy to use. As you pointed out in an earlier
email the image decoding step is far from the most important player in
your process, so worrying about speeding up the rest of the process
would probably be more fruitful in the long run anyway.

Good luck!

...jim

Ken Warner wrote:
> Whatever... The image was not being drawn because the alpha
> channel was 0x00. Initializing the alpha channel to 0xff allowed
> us to see the image. I don't have a lot of energy for a big discussion
> about this.
>
> But this whole experiment still leads me back to ask for a way to
> decode an image directly into an integer array like I first asked.
>
> Something like pixels = imageReader.decodeFileBytesToIntegerArray(...)
>
> But all I seem to get from you is "...rewrite the applet..." Ok.
>
> I think I'm done.
>
> Jim Graham wrote:
>> The MemoryImageSource relies on the ColorModel to define whether or
>> not the data contains an alpha channel. If you use one of the MIS
>> constructors that does not take a ColorModel object then those
>> constructors are specifically specified to use the default RGB
>> ColorModel as defined by the ColorModel.getRGBdefault() method which
>> specifies 8 bits of alpha.
>>
>> I'm not sure what you mean when you say that it "means it's
>> transparent to [...] BufferStrategy" since that object doesn't deal
>> with pixel storage formats...
>>
>> ...jim
>>
>> Ken Warner wrote:
>>
>>> Maybe it doesn't mean the BufferedImage is transparent but
>>> 0x00 in the alpha channel of a pixels means it's transparent to the
>>> MemoryImageSource and BufferStrategy.
>>>
>>> Jim Graham wrote:
>>>
>>>> The 3byte databuffer has no storage available for an alpha value.
>>>>
>>>> When the data is loaded into the TYPE_INT_RGB BufferedImage there is
>>>> no alpha stored there since that is an opaque type. More
>>>> specifically, if you load one of the integers from the underlying
>>>> int[] pixel array of such an image the upper 8 bits are undefined
>>>> and should be ignored - if those bits are 0 then that does not mean
>>>> that the pixel is transparent, and if they contain a 0xff value then
>>>> that is just a lucky coincidence as those bits are not explicitly
>>>> tracked or initialized by any code that deals with that image type...
>>>>
>>>> ...jim
>>>>
>>>> Ken Warner wrote:
>>>>
>>>>> I just thought of something. What is the alpha channel set to
>>>>> when the BufferedImage is created and the databuffer is extracted?
>>>>>
>>>>> If the alpha channel is 0, that would explain a lot. That means the
>>>>> image is transparent. There's two stages of rendering. The first
>>>>> stage
>>>>> only does nearest neighbor interpolation. The second stage does a
>>>>> bi-cubic
>>>>> interpolation and I explicitly initialize the alpha channel to 0xff
>>>>> to make
>>>>> the image not transparent.
>>>>>
>>>>> Ken Warner wrote:
>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>> I'm not communicating the step by step procedure for the projection
>>>>>> I guess. It's not like you describe. There is no massaged data.
>>>>>> It's
>>>>>> just a pixel map that I take a portion of and calculate a gnomic
>>>>>> projection.
>>>>>>
>>>>>> If I had a white board I could draw a diagram that explains
>>>>>> everything.
>>>>>>
>>>>>> It's a realtime (sort of) projection.
>>>>>>
>>>>>> Anyway, here's the two different versions of the applet I
>>>>>> promised. One
>>>>>> uses PixelGrabber the other uses BufferedImage. This is the
>>>>>> performace
>>>>>> problem I'm seeing.
>>>>>>
>>>>>> I always take the blame for something like this until proven
>>>>>> otherwise.
>>>>>>
>>>>>> So I must be doing something wrong but the code is so simple I just
>>>>>> don't see where.
>>>>>>
>>>>>> http://pancyl.com/BufferedImage.htm
>>>>>>
>>>>>> http://pancyl.com/PixelGrabber.htm
>>>>>>
>>>>>> PixelGrabber works ok for a prototype.
>>>>>> BufferedImage is a mystery yet.
>>>>>>
>>>>>> You have the source to the class where
>>>>>> the problem is. If you have time to take a look at
>>>>>> makeBuffereImage()
>>>>>> and maybe you will see something I don't.
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>> Jim Graham wrote:
>>>>>>
>>>>>>> Hi Ken,
>>>>>>>
>>>>>>> Do you really need to rewrite it all the way through? For
>>>>>>> example, the massaged data (that has been run through the
>>>>>>> panoramic projection) could be stored in integer format - it's
>>>>>>> just the code that reads a pixel out of the source tiles that
>>>>>>> needs to change, but any intermediate storage and the final
>>>>>>> storage that you use could be integer-based.
>>>>>>>
>>>>>>> I'd have to see the conversion code to make any suggestions
>>>>>>> beyond these guesses...
>>>>>>>
>>>>>>> ...jim
>>>>>>>
>>>>>>> Ken Warner wrote:
>>>>>>>
>>>>>>>> I'll try that.
>>>>>>>>
>>>>>>>> Using bi = reader.read(0,param);
>>>>>>>> PanTile Testbed
>>>>>>>> 1813
>>>>>>>> 1031
>>>>>>>> 1001
>>>>>>>> 982
>>>>>>>> 941
>>>>>>>> 981
>>>>>>>> 1002
>>>>>>>> 971
>>>>>>>>
>>>>>>>> Using bi = reader.read(0) <-default reader
>>>>>>>> PanTile Testbed
>>>>>>>> 1081
>>>>>>>> 601
>>>>>>>> 291
>>>>>>>> 330
>>>>>>>> 261
>>>>>>>> 270
>>>>>>>> 300
>>>>>>>> 280
>>>>>>>>
>>>>>>>> Using PixelGrabber etc.
>>>>>>>> PanTile Testbed
>>>>>>>> 1432
>>>>>>>> 1221
>>>>>>>> 1272
>>>>>>>> 1112
>>>>>>>> 1141
>>>>>>>> 1081
>>>>>>>> 1101
>>>>>>>> 1092
>>>>>>>>
>>>>>>>> Clearly the default reader is faster by a lot -- except the data is
>>>>>>>> not in a format I can use in the current version. The current
>>>>>>>> version
>>>>>>>> of the apple is only expected to download one image so I wasn't
>>>>>>>> much
>>>>>>>> concerned with that piece of code.
>>>>>>>>
>>>>>>>> A version loading tiles is another thing. But the code would
>>>>>>>> have to
>>>>>>>> be re-written all the way through to the final paint loop.
>>>>>>>> Because I use
>>>>>>>> integer arrays everywhere.
>>>>>>>>
>>>>>>>> Maybe it would be worth the effort if I could be sure that the
>>>>>>>> final
>>>>>>>> performance was really going to be much faster than it is now. The
>>>>>>>> rendering would have to be significantly faster to make the
>>>>>>>> re-write
>>>>>>>> really worth the effort.
>>>>>>>>
>>>>>>>> And while I have been resistent to the idea of using
>>>>>>>> BufferedImages --
>>>>>>>> I will do anything to make my applet faster. But given that the
>>>>>>>> applet is stable and fairly well tuned using integer arrays, I'm
>>>>>>>> not
>>>>>>>> likely to re-write it using the three byte databuffer to save 800ms
>>>>>>>> per 1meg tile. Tiles will most likely be even smaller.
>>>>>>>>
>>>>>>>> *And the performance slowdown is after I get the pixels from the
>>>>>>>> databuffer.*
>>>>>>>>
>>>>>>>> After the int [] pixels is assigned to, all the other code
>>>>>>>> remains the same
>>>>>>>> except I see this unexplained slow down in user interaction.
>>>>>>>>
>>>>>>>> If I can figure that problem out (with your help) then it might
>>>>>>>> be worth the
>>>>>>>> re-write.
>>>>>>>>
>>>>>> [stuff deleted]
>>>>>>
>>>>>> ===========================================================================
>>>>>>
>>>>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>>>>> the body
>>>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>>>> email to
>>>>>> listserv@java.sun.com and include in the body of the message "help".
>>>>>>
>>>>>
>>>>> ===========================================================================
>>>>>
>>>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>>>> the body
>>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>>> email to
>>>>> listserv@java.sun.com and include in the body of the message "help".
>>>>
>>>>
>>>>
>>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Ken Warner

I understand the "newer imaging API's" well enough to know they
are awkward and lacking in flexibility and utility.

I understand your responses well enough to know when I'm being sandbagged.

I understand that any request to do anything different from the Gold
Standard of Perfection that exists only in your head is received with
disdain.

I know that your response to my simple request for a simple enhancement is
"re-write your code so that we don't have to do any more work." is perfect
giant, faceless bureaucratic behavior. Could I expect less? Enjoy your
cubicle.

Jim Graham wrote:
> Hi Ken,
>
> I'm sorry that you are having trouble understanding the newer imaging
> APIs as they generally provide facilities that are quite flexible and
> useful for writing the type of application that you are creating here.
> The primary missing link would seem to be some documentation that would
> bridge the gap for you and I have been trying to help you out there with
> some email conversations behind the scenes. Apparently the frustration
> there is not worth the gains for you.
>
> This may not make sense to you, but your request for a new API to
> produce "the data you want" would not streamline the process for the
> simple fact that you want to work with data in a format that differs
> from what is generated by the JPEG decoders so some format conversion
> must occur somewhere. The only "conversion free" way to get the raw
> pixel data from the JPEG decoders is to accept it in the 3byte format
> that they want to generate it in. Your request for a new API would not
> change that fundamental fact of the JPEG format in any way.
>
> The old PixelGrabber code was probably the least efficient way to get
> the data converted into the format you want.
>
> The ImageI/O mechanism you chose, which allows you to specify the format
> of the generated BufferedImage is more efficient than the PixelGrabber
> method per your own image reading benchmarks. Apparently it had some
> negative interaction with the rest of the code which I was hoping to
> help you figure out, but it is hard for me to debug such problems via
> email without seeing the rest of the code.
>
> Adapting your code to the inherent storage format used by the JPEG
> decoders (the 3byte format) is the only way to eliminate the loading
> overhead.
>
> We aren't being lazy or obstinate here Ken. Just because you can write
> pseudo-code for your desired API doesn't mean it will magically
> implement itself with zero overhead. It won't happen. If you do not
> wish to understand the underlying flow of pixel data enough to
> understand that, then feel free to live with the overhead of whichever
> mechanism you find most easy to use. As you pointed out in an earlier
> email the image decoding step is far from the most important player in
> your process, so worrying about speeding up the rest of the process
> would probably be more fruitful in the long run anyway.
>
> Good luck!
>
> ...jim
>
> Ken Warner wrote:
>
>> Whatever... The image was not being drawn because the alpha
>> channel was 0x00. Initializing the alpha channel to 0xff allowed
>> us to see the image. I don't have a lot of energy for a big discussion
>> about this.
>>
>> But this whole experiment still leads me back to ask for a way to
>> decode an image directly into an integer array like I first asked.
>>
>> Something like pixels = imageReader.decodeFileBytesToIntegerArray(...)
>>
>> But all I seem to get from you is "...rewrite the applet..." Ok.
>>
>> I think I'm done.
>>
>> Jim Graham wrote:
>>
>>> The MemoryImageSource relies on the ColorModel to define whether or
>>> not the data contains an alpha channel. If you use one of the MIS
>>> constructors that does not take a ColorModel object then those
>>> constructors are specifically specified to use the default RGB
>>> ColorModel as defined by the ColorModel.getRGBdefault() method which
>>> specifies 8 bits of alpha.
>>>
>>> I'm not sure what you mean when you say that it "means it's
>>> transparent to [...] BufferStrategy" since that object doesn't deal
>>> with pixel storage formats...
>>>
>>> ...jim
>>>
>>> Ken Warner wrote:
>>>
>>>> Maybe it doesn't mean the BufferedImage is transparent but
>>>> 0x00 in the alpha channel of a pixels means it's transparent to the
>>>> MemoryImageSource and BufferStrategy.
>>>>
>>>> Jim Graham wrote:
>>>>
>>>>> The 3byte databuffer has no storage available for an alpha value.
>>>>>
>>>>> When the data is loaded into the TYPE_INT_RGB BufferedImage there
>>>>> is no alpha stored there since that is an opaque type. More
>>>>> specifically, if you load one of the integers from the underlying
>>>>> int[] pixel array of such an image the upper 8 bits are undefined
>>>>> and should be ignored - if those bits are 0 then that does not mean
>>>>> that the pixel is transparent, and if they contain a 0xff value
>>>>> then that is just a lucky coincidence as those bits are not
>>>>> explicitly tracked or initialized by any code that deals with that
>>>>> image type...
>>>>>
>>>>> ...jim
>>>>>
>>>>> Ken Warner wrote:
>>>>>
>>>>>> I just thought of something. What is the alpha channel set to
>>>>>> when the BufferedImage is created and the databuffer is extracted?
>>>>>>
>>>>>> If the alpha channel is 0, that would explain a lot. That means the
>>>>>> image is transparent. There's two stages of rendering. The first
>>>>>> stage
>>>>>> only does nearest neighbor interpolation. The second stage does a
>>>>>> bi-cubic
>>>>>> interpolation and I explicitly initialize the alpha channel to
>>>>>> 0xff to make
>>>>>> the image not transparent.
>>>>>>
>>>>>> Ken Warner wrote:
>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> I'm not communicating the step by step procedure for the projection
>>>>>>> I guess. It's not like you describe. There is no massaged
>>>>>>> data. It's
>>>>>>> just a pixel map that I take a portion of and calculate a gnomic
>>>>>>> projection.
>>>>>>>
>>>>>>> If I had a white board I could draw a diagram that explains
>>>>>>> everything.
>>>>>>>
>>>>>>> It's a realtime (sort of) projection.
>>>>>>>
>>>>>>> Anyway, here's the two different versions of the applet I
>>>>>>> promised. One
>>>>>>> uses PixelGrabber the other uses BufferedImage. This is the
>>>>>>> performace
>>>>>>> problem I'm seeing.
>>>>>>>
>>>>>>> I always take the blame for something like this until proven
>>>>>>> otherwise.
>>>>>>>
>>>>>>> So I must be doing something wrong but the code is so simple I just
>>>>>>> don't see where.
>>>>>>>
>>>>>>> http://pancyl.com/BufferedImage.htm
>>>>>>>
>>>>>>> http://pancyl.com/PixelGrabber.htm
>>>>>>>
>>>>>>> PixelGrabber works ok for a prototype.
>>>>>>> BufferedImage is a mystery yet.
>>>>>>>
>>>>>>> You have the source to the class where
>>>>>>> the problem is. If you have time to take a look at
>>>>>>> makeBuffereImage()
>>>>>>> and maybe you will see something I don't.
>>>>>>>
>>>>>>> Ken
>>>>>>>
>>>>>>> Jim Graham wrote:
>>>>>>>
>>>>>>>> Hi Ken,
>>>>>>>>
>>>>>>>> Do you really need to rewrite it all the way through? For
>>>>>>>> example, the massaged data (that has been run through the
>>>>>>>> panoramic projection) could be stored in integer format - it's
>>>>>>>> just the code that reads a pixel out of the source tiles that
>>>>>>>> needs to change, but any intermediate storage and the final
>>>>>>>> storage that you use could be integer-based.
>>>>>>>>
>>>>>>>> I'd have to see the conversion code to make any suggestions
>>>>>>>> beyond these guesses...
>>>>>>>>
>>>>>>>> ...jim
>>>>>>>>
>>>>>>>> Ken Warner wrote:
>>>>>>>>
>>>>>>>>> I'll try that.
>>>>>>>>>
>>>>>>>>> Using bi = reader.read(0,param);
>>>>>>>>> PanTile Testbed
>>>>>>>>> 1813
>>>>>>>>> 1031
>>>>>>>>> 1001
>>>>>>>>> 982
>>>>>>>>> 941
>>>>>>>>> 981
>>>>>>>>> 1002
>>>>>>>>> 971
>>>>>>>>>
>>>>>>>>> Using bi = reader.read(0) <-default reader
>>>>>>>>> PanTile Testbed
>>>>>>>>> 1081
>>>>>>>>> 601
>>>>>>>>> 291
>>>>>>>>> 330
>>>>>>>>> 261
>>>>>>>>> 270
>>>>>>>>> 300
>>>>>>>>> 280
>>>>>>>>>
>>>>>>>>> Using PixelGrabber etc.
>>>>>>>>> PanTile Testbed
>>>>>>>>> 1432
>>>>>>>>> 1221
>>>>>>>>> 1272
>>>>>>>>> 1112
>>>>>>>>> 1141
>>>>>>>>> 1081
>>>>>>>>> 1101
>>>>>>>>> 1092
>>>>>>>>>
>>>>>>>>> Clearly the default reader is faster by a lot -- except the
>>>>>>>>> data is
>>>>>>>>> not in a format I can use in the current version. The current
>>>>>>>>> version
>>>>>>>>> of the apple is only expected to download one image so I wasn't
>>>>>>>>> much
>>>>>>>>> concerned with that piece of code.
>>>>>>>>>
>>>>>>>>> A version loading tiles is another thing. But the code would
>>>>>>>>> have to
>>>>>>>>> be re-written all the way through to the final paint loop.
>>>>>>>>> Because I use
>>>>>>>>> integer arrays everywhere.
>>>>>>>>>
>>>>>>>>> Maybe it would be worth the effort if I could be sure that the
>>>>>>>>> final
>>>>>>>>> performance was really going to be much faster than it is now.
>>>>>>>>> The
>>>>>>>>> rendering would have to be significantly faster to make the
>>>>>>>>> re-write
>>>>>>>>> really worth the effort.
>>>>>>>>>
>>>>>>>>> And while I have been resistent to the idea of using
>>>>>>>>> BufferedImages --
>>>>>>>>> I will do anything to make my applet faster. But given that the
>>>>>>>>> applet is stable and fairly well tuned using integer arrays,
>>>>>>>>> I'm not
>>>>>>>>> likely to re-write it using the three byte databuffer to save
>>>>>>>>> 800ms
>>>>>>>>> per 1meg tile. Tiles will most likely be even smaller.
>>>>>>>>>
>>>>>>>>> *And the performance slowdown is after I get the pixels from
>>>>>>>>> the databuffer.*
>>>>>>>>>
>>>>>>>>> After the int [] pixels is assigned to, all the other code
>>>>>>>>> remains the same
>>>>>>>>> except I see this unexplained slow down in user interaction.
>>>>>>>>>
>>>>>>>>> If I can figure that problem out (with your help) then it might
>>>>>>>>> be worth the
>>>>>>>>> re-write.
>>>>>>>>>
>>>>>>> [stuff deleted]
>>>>>>>
>>>>>>> ===========================================================================
>>>>>>>
>>>>>>> To unsubscribe, send email to listserv@java.sun.com and include
>>>>>>> in the body
>>>>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>>>>> email to
>>>>>>> listserv@java.sun.com and include in the body of the message "help".
>>>>>>>
>>>>>>
>>>>>> ===========================================================================
>>>>>>
>>>>>> To unsubscribe, send email to listserv@java.sun.com and include in
>>>>>> the body
>>>>>> of the message "signoff JAVA2D-INTEREST". For general help, send
>>>>>> email to
>>>>>> listserv@java.sun.com and include in the body of the message "help".
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".