Skip to main content

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

4 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ken Warner

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".

Jim Graham

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

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".

Jim Graham

When I run the applets from appletviewer I see 16 numbers printed on the
console for the BI version but only 8 printed for the PG version -
hopefully there isn't a typo causing the loads to be done twice?

...jim

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".