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:
public abstract Graphics getGraphics() 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) 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.