[JAVA2D] Zoom relative to mouse position
Hi,
I am trying to figure out how to zoom relative to the mouse pointer position.
Below, please find my sample code. When I position the mouse pointer on one
corner of the red rectangle and use the mouse wheel, I am able to zoom in and
out as expected. As soon as I move the pointer position, let's say to another
corner of the red rectangle, and try to zoom in or out, my position relative to
the rectangle shifts around. I think I may be missing a transform or two. Any
help is greatly appreciated.
Thanks.
Here is my code:
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.Point;
import java.awt.event.MouseWheelEvent;
import java.awt.event.MouseWheelListener;
import java.awt.geom.AffineTransform;
import java.awt.geom.Path2D;
import java.awt.geom.Rectangle2D;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
@SuppressWarnings(serial)
public class ZoomDemo extends JPanel {
AffineTransform tx = new AffineTransform();
Rectangle2D.Double rect = new Rectangle2D.Double(100, 100, 20, 30);
public ZoomDemo() {
this.addMouseWheelListener(new ZoomHandler());
}
@Override
public void paint(Graphics g) {
super.paint(g);
Graphics2D g2 = (Graphics2D)g;
Path2D.Double path;
g2.setColor(Color.RED);
path = new Path2D.Double(rect,tx);
g2.draw(path);
}
private class ZoomHandler implements MouseWheelListener {
Point oldPoint = null;
double scale = 1.0;
public void mouseWheelMoved(MouseWheelEvent e) {
if(e.getScrollType() ==
MouseWheelEvent.WHEEL_UNIT_SCROLL) {
scale += (.1 * e.getWheelRotation());
scale = Math.max(0.1, scale);
Point p = e.getPoint();
tx =
AffineTransform.getTranslateInstance(p.getX(), p.getY());
tx.scale(scale, scale);
tx.translate(-p.getX(), -p.getY());
ZoomDemo.this.revalidate();
ZoomDemo.this.repaint();
}
}
}
public static void main(String[] args) {
JFrame f = new JFrame(ZoomDemo);
ZoomDemo zoomDemo = new ZoomDemo();
JScrollPane sp = new JScrollPane(zoomDemo);
f.getContentPane().add(sp);
f.setSize(500, 500);
f.setLocationRelativeTo(null);
f.setVisible(true);
}
}
[Message sent by forum member 'kouch' (kouch)]
http://forums.java.net/jive/thread.jspa?messageID=275115
===
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.
[JAVA2D] Developing a CAD Engine
I am developing a CAD Engine Using Java Technology. I need assistance of those peoples worked with Java Graphics. What i need is nothing but my programme could perform basic drawings feature i.e. draw line, draw rectangle, circle insert text and etc. for this i need a bit assistance. any programmer who worked with this contace me. I am a fresh student and need any one who understand the java graphics. [Message sent by forum member 'yousafzee' (yousafzee)] http://forums.java.net/jive/thread.jspa?messageID=275128 === 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.
Re: [JAVA2D] JAI package (show an error that package doesn't exist)
Hello experts: Please help me for this. I've install JAI package to my c:\ root and have added C:\jai-1_1_2_01\lib to my CLASSPATH value. How do i use the JAIPlugIn class? do i add it to one of my package then set it as my jai.class in my properties object? How do i start? Is there step by step instructions? Any help will be appreciated Thanks in advance maijavanet [Message sent by forum member 'maijavanet' (maijavanet)] http://forums.java.net/jive/thread.jspa?messageID=275234 === 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.
[JAVA2D] Prototype applet using BufferedImage...
If I do this to get the pixels from an image for later rendering in a
MemoryImageSource my applet runs fine.
width = image.getWidth(canvas);
height = image.getHeight(canvas);
pixels = new int [width * height ];
int cnt = 0;
pg = new PixelGrabber(image,0,0,width,height,pixels,0,width);
try
{
while (pg.grabPixels(0) != true)
{
Thread.yield();
}
if ((pg.getStatus() ImageObserver.ABORT) != 0)
{
System.err.println(Image fetch aborted or errored...);
}
}
If I do this -- then the applet becomes sluggish to the point
of not being usable.
int [] pixels = null;
try
{
ImageInputStream iis = ImageIO.createImageInputStream(new
ByteArrayInputStream(imageBuffer));
Iterator readers = ImageIO.getImageReadersByFormatName(jpg);
ImageReader reader = (ImageReader)readers.next();
ImageReadParam param = reader.getDefaultReadParam();
bi = new BufferedImage(1024,1024,BufferedImage.TYPE_INT_RGB);
param.setDestination(bi);
reader.setInput(iis, true);
bi = reader.read(0,param);
width = bi.getWidth();
height = bi.getHeight();
pixels =
((DataBufferInt)(bi.getRaster().getDataBuffer())).getData();
}
Does this have something to do with the way integer arrays
are stored? Is there indirection involved somewhere.
I've attached my entire class file for your inspection.
===
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.
package pantile;
import java.awt.*;
import java.io.*;
import java.net.*;
import java.util.*;
import java.awt.color.ColorSpace;
import java.awt.image.DataBufferInt;
import java.awt.image.PixelGrabber;
import java.awt.image.ImageObserver;
import javax.imageio.*;
import javax.imageio.stream.*;
import java.awt.image.BufferedImage;
public class PanTileImageFetch implements Runnable
{
private URL imageURL = null;
private PanTileCanvas canvas = null;
private PanTileProjector projector = null;
private PanTileApplet applet = null;
private final int CHUNKSIZE = 1024;
public byte[] imageBuffer = null;
public InputStream in = null;
public int numRead = 0;
public int size = 0;
public boolean cache = true;
private int [] pixels = null;
private PixelGrabber pg = null;
private Image image = null;
public PanTileImageFetch(PanTileApplet a)
{
applet = a;
}
public void setImageURL(URL u)
{
imageURL = u;
}
public void setCanvas(PanTileCanvas c)
{
canvas = c;
}
public void setProjector(PanTileProjector p)
{
projector = p;
}
public boolean FIRSTIMAGELOADED = false;
public boolean READKILL = false;
public boolean getImageBytes()
{
int numRead = 0;
int offset = 0;
if(PanTileApplet.DEBUG) System.err.println(getImageBytes()...);
try
{
URLConnection urlConnection = imageURL.openConnection();
//urlConnection.setConnectTimeout(8000);
//if(canvas != null)
//{
//canvas.paintCachingIndicator(Loading., FIRSTIMAGELOADED);
//}
//if(cache)
//urlConnection.setUseCaches(true);
//else
//urlConnection.setUseCaches(false);
//urlConnection.setReadTimeout(8000);
size = urlConnection.getContentLength();
if(size = 0)
{
if(canvas != null)
{
canvas.KILLCACHINGINDICATOR = true;
canvas.paintMsgScreen(Image zero length...,false);
}
return false;
}
imageBuffer = new byte[size];
in = urlConnection.getInputStream();
if(PanTileApplet.DEBUG) System.err.println(Starting Read...);
while((numRead = in.read(imageBuffer,offset,imageBuffer.length - offset)) != -1)
{
//if(PanTileApplet.DEBUG) System.err.println(Bytes Read = + numRead);
if(READKILL) return false;
offset += numRead;
if(offset = imageBuffer.length)
{
byte[] temp = new byte[imageBuffer.length + CHUNKSIZE];
System.arraycopy(imageBuffer, 0, temp, 0, offset);
imageBuffer = temp;
}
Thread.yield();
}
//if(canvas != null)
//{
//
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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 [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.
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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.
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
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
