Class Image is an abstract class—as a result, programs cannot instantiate class Image to create objects. To achieve platform independence, the Java implementation on each platform provides its own subclass of Image to store image information.
The text is about class java.awt.Image.
I don't understand the second part, namely:-
... provides its own subclass of Image to store image information.
Technically, how does that happen?
Image instances are typically created through methods such as Toolkit.createImage(). In this case, the actual instantiation of the Image object is delegated to the Toolkit class, which is platform-dependent.
Note that while you cannot directly instantiate class Image, you can instantiate BufferedImage, which is a concrete Image subclass.
The concrete subclass of Image might, in some cases, be a class which isn't part of the public API of the JDK. (In other cases, you might find that you're getting a BufferedImage, which is much nicer in the event that you intend to do something with the image you get.)
Try System.out.println(img.getClass().getName()); just to see what you're getting.
Related
There are various ways of reading an image file in java such as BufferedImage and ImageIcon to name a few. I want to know what is the difference between these cases? Are they context dependent that in a particular case only one of them can be used?
What would be the best way of reading a image selected by JFileChooser by the user and separating the color channels of an image?
A good way is to use the different ImageIO.read methods, which return BufferedImage objects.
Image is an abstract class, so I think the real question is which subclass is more efficient for your program. Use VolatileImage if you need hardware acceleration. More on that here.
ImageIcon (and Toolkit#createImage/Toolkit#getImage) use a background loading process. That is, after you call these methods, they will return immediately, having created a background thread to actually load the image data.
These were/are used when loading large images across slow connections, like ye old 28k modems (ah, how I remember the days). This means that your application can continue running while the images are been downloaded.
You'll find in the Graphics class the drawImage methods accept an ImageObserver interface and that java.awt.Component implements this interface, this allows components the ability to automatically update themselves once the image has actually finished loading.
ImageIO on the other hand will not return until the image is fully loaded. It also makes it easier to introduce new readers/writers, making the API far more flexible then the original API. ImageIO also supports a wider range of images out of the box.
BufferedImage is also a far more flexible image class, especially when it comes to apply effects to the image.
Now, I, personally, prefer ImageIO. If I know I'm loading large images or images over a potentially slow connection, I will create my own background thread to load them. While a little more complicated, the trade offs greatly out weight the small amount of extra work -IMHO
What would be the best way of reading a image selected by JFileChooser by the user and separating the color channels of an image?
ImageIO without a doubt. In order to do any serious manipulation of an image loaded using something ImageIcon, you'd have to convert that image to a BufferedImage anyway
Whenever dealing with the loading and rendering of images in Java, I have previously always used BufferedImages to store and manipulate the images in memory.
However, I have recently come across a few different sites that use the Image class instead of BufferedImage and this got me wondering - what are the differences?
I'm aware that a BufferedImage has a larger/optimised toolset, but does come at any cost? If so, when does this cost become noticeable? In which situations would you use an Image over a BufferedImage, or vice-versa?
BufferedImage extends Image. Image is just a base abstract class and you can't instantiate it. Under the hood you are using BufferedImage or another implementation for sure.
There shouldn't be any real performance difference between directly creating a BufferedImage and a Toolkit image (java.awt.Toolkit or Image#getScaledInstance). You'll never have an actual instance of Image because it's an abstract class; you'll only be dealing with its subclasses (e.g. BufferedImage).
I want to double the size of an applet (including the graphics and components positioned on it).
Is there any easy way to accomplish this before I start changing every coordinate individually?
It has been a while since I wrote a Java applet, so I cannot tell you exactly which classes and interfaces.
But as a general principle you could do this with a decorator. Make a class that implements the same interface as your graphics context object*. Pass the actual graphics context to the constructor of your class. For each method on your class, call the same method on the graphic context object that it wraps. And set the magnification as a field of the class so you can make it 3x in future.
Then, when your code takes the graphics object, replace that with an instance of your custom class, which should wrap the graphics object.
If this is not possible, you may have to hack your original code. But take my advice - this time include a multiplication factor as a variable/field so that next time you can adjust the number in once place.
or, if there's no interface available, which looks to be the the Graphics class, extend it and be sure to override every method.
If the applet contents scale you just need to change the size of the applet in the embedding html page. This assumes that only relative or calculated coordinates and layout managers have been used. If elements are positioned at absolute positions, this will not work will. Then you will either have to touch the code or write a wrapper that scales the content, as Joe suggested.
I've been working on an assignment, and have all the requirements completed. The project is to compare the differences in runtime between a linear search algorithm and a binary search. I have a graph class that puts out the results of those searches in a xy graph.
The graph object is a Turtle class that extends JFrame. Is there any way I can convert that graph object to a bitmap and save it for future printing?
The professor requires printouts of the results. Since I don't want a printout of every time the program is run, I would prefer to save the graphics results in a designated folder, rather than using screen-grab.
Unfortunately, I haven't come up with any answers on Google or here. Is something like this even possible?
Another approach is to tell your Component to paint() itself into a BufferedImage, as seen in this complete example. The Container returned by a JFrame's getContentPane() method is suitable. In summary:
Component component = f.getContentPane();
BufferedImage image = new BufferedImage(…);
component.paint(image.getGraphics());
ImageIO.write(image,…);
You can pass the bounds of the area into the Robot.createScreenCapture(Rectangle) method to create a BufferedImage of the area. The easiest way to save the screenshot as an image file is to use the ImageIO class.
I have a Serializable object which is supposed to hold a java.awt.Image as its member. How should I go about serializing it?
(Edited from a not so clear first version, sorry.)
ImageIcon implements Serializable and it can be used to wrap an Image class
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/ImageIcon.html
javax.swing.ImageIcon, as a part of Swing, does not guarantee to have compatible serialised form between versions. However, you can cheat and look at its readObject and writeObject code - find width and height, grab the pixels with PixelGrabber. I'm not entirely sure that covers the colour model correctly. The obvious alternative is to write a real image format with javax.imageio.
None that I know of. I believe you need to write your own serializer for it to basically save out the width, height and pixel values... Or write it out to the stream as a PNG or something