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 [EMAIL PROTECTED] and include
in the body
of the message "signoff JAVA2D-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff JAVA2D-INTEREST". For general help, send
email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
