如何将缓冲的图像转换为图像，反之亦然？

Question

Actually i am working on a image editing software and now i want to convert the buffered-image ie :

  BufferedImage buffer = ImageIO.read(new File(file));

to Image ie in the format something like :

  Image image  = ImageIO.read(new File(file));

Is it possible to so?? If yes, then how??

Answer 1

BufferedImage is a(n) Image, so the implicit cast that you're doing in the second line is able to be compiled directly. If you knew an Image was really a BufferedImage, you would have to cast it explicitly like so:

Image image = ImageIO.read(new File(file));
BufferedImage buffered = (BufferedImage) image;

Because BufferedImage extends Image, it can fit in an Image container. However, any Image can fit there, including ones that are not a BufferedImage, and as such you may get a ClassCastException at runtime if the type does not match, because a BufferedImage cannot hold any other type unless it extends BufferedImage.

Answer 2

Example: say you have an 'image' you want to scale you will need a bufferedImage probably, and probably will be starting out with just 'Image' object. So this works I think... The AVATAR_SIZE is the target width we want our image to be:

Image imgData = image.getScaledInstance(Constants.AVATAR_SIZE, -1, Image.SCALE_SMOOTH);     

BufferedImage bufferedImage = new BufferedImage(imgData.getWidth(null), imgData.getHeight(null), BufferedImage.TYPE_INT_RGB);

bufferedImage.getGraphics().drawImage(imgData, 0, 0, null);

Answer 3

BufferedImage is a subclass of Image . You don't need to do any conversion.

Answer 4

The right way is to use SwingFXUtils.toFXImage(bufferedImage,null) to convert a BufferedImage to a JavaFX Image instance and SwingFXUtils.fromFXImage(image,null) for the inverse operation.

Optionally the second parameter can be a WritableImage to avoid further object allocation.

Answer 5

You can try saving (or writing) the Buffered Image with the changes you made and then opening it as an Image.

EDIT:

try {
    // Retrieve Image
    BufferedImage buffer = ImageIO.read(new File("old.png"));;
    // Here you can rotate your image as you want (making your magic)
    File outputfile = new File("saved.png");
    ImageIO.write(buffer, "png", outputfile); // Write the Buffered Image into an output file
    Image image  = ImageIO.read(new File("saved.png")); // Opening again as an Image
} catch (IOException e) {
    ...
}

Answer 6

Just an information: let us all remember that the Image class is actually an abstract class and referencing a variable of this with a BufferedImage only stores or returns any Object's memory adress.

Also, wherefore, static java.awt.image.imageIO 's read() method returns a BufferedImage object, therefore no doubt that using operator/expression instanceof BufferedImage on that object will return true .

In fact, being abstract, Image class has such method signatures as:

1. public abstract Graphics getGraphics()
2. public abstract ImageProducer getSource()

among others.

I emphasize, an actual Image variable only holds memory adress of a concrete Image-subclass object, almost like pointers in C, C++, Ada, etc.

If you're introduced or advanced in those languages, and also of Java interface instances like Runnable , javax.sound.Clip , AWT's Shape , etc.. . Take note that Image has: public abstract Image getScaledInstance(...) - you get the point. (Of course, scaling in 2D Graphics programming is interchangeable to resizing, for which precision is desirable).

But in an impossible case when herein ImageIO method return ! (instanceof BufferedImage) ! (instanceof BufferedImage) just create a new BufferedImage object with this ImgObjNotInstncfBufImg apassed to one of its constructor argument. Then, at (rational) will manipulate this in the logic of your code.

Anyways, the Affine Transform class is appropriate for transforming Shapes and Images to thier scaled, rotated, relocated, etc forms, so I recommend you to study about using an "affine transform".

Take note that you can manipulate the actual pixels in such Image's Raster - well another technical 2D Graphics jargon which must be referenced from a technical glossary - which perhaps a excercised skill in Java ways of binary blitwise operations will be needed, in types of Image buffers that store individual color attributes in a compact in of 32-bytes - 7-bits each for the alpha and RGB values.

I suspect your gonna use it in layering images. So, FINALLY, the rational is that you only reference BufferedImage with the abstract Image, and if ever your Image object isn't a BufferedImage one yet, then you can just make an image out of this related-but-non-BufferedImage-instance without having to worry about any conversion, casting, autoboxing or whatever; manipulating a BufferedImage really means manipulating also the underlying root Image data-bearing object that it points to.

Okay, finished; I think I certainly extracted and splintered out what deadlock you may have thought you are facing to. As I have said abstract classes in java, and also interfaces, are very much the equivaleng of the low-level, more-close-to-hardware operators called pointers in other languages.