aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Extending BufferedImage Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Extending BufferedImage" Watch "Extending BufferedImage" New topic
Author

Extending BufferedImage

Martin Thorpe
Ranch Hand

Joined: May 25, 2004
Posts: 45
I am a bit of a newbie at this Java game, only a few months. But what I am
trying to achieve is to utilise the undoManager from Swing with a buffered
image so that I can track changes to my image, by using an
UndoableEditListener.

The way I see of doing this is to extend BufferedImage in order to apply
the listener.

I have managed to simply extend buffered image but I am falling into a problem with the BufferedImageOp interface of BufferedImage (I am using teh BufferedImageOp in the app.). Because the BufferedImageOp interface returns an instance of BufferedImage as opposed to my new extending class. I have tried casting to my new extending class but get a runtime error: java.lang.ClassCastException. So there is obivously a big gap in my knowledge.

So how do I approach this?:
  • Extend the BufferdImageOp interface too.. or
  • Write my own interface to replace bufferedImageOp (don't think it is this)
  • Or is there something I can do in my class which extends BufferedImage to deal with this???



  • Just totally stumped.

    Thanks for taking the time to read

    cheers
    Martin
    Aaron Roberts
    Ranch Hand

    Joined: Sep 10, 2002
    Posts: 174
    Can you post some of your code? It seems like you should have a class that starts like so -

    public class MyBufferedImage extends BufferedImage implements UndoableEditListener

    Are you making a paint program of some sort?

    HTH.
    Martin Thorpe
    Ranch Hand

    Joined: May 25, 2004
    Posts: 45
    I have not actually got to the adding of the undoable listener bit... just trying to get the rest of the app. working with my extended buffered image class.

    Yes I am writing an image processing app. that uses bufferedImage filters to scale, darken, ligthen etc.

    This is the start of my bufferedImage extended class:


    that works a treat, calling to the super constructor and that. but further on in my application I am using BufferedImageOp, this is where is it throwing a wobbly:



    If I leave out the cast from the problem line like this:


    I get a compile error:

    Type mismatch: cannot convert from BufferedImage to MyImage


    Which is logical... so the question is how can I use BufferedImageOp with my BufferedImage extended class?

    [ July 22, 2004: Message edited by: Martin Thorpe ]

    [ July 22, 2004: Message edited by: Martin Thorpe ]
    [ July 22, 2004: Message edited by: Martin Thorpe ]
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    Have you read the Javadocs for BufferedImageOp.filter()? I've never used the class myself, but it seems to take two arguments for a very good reason.
    Martin Thorpe
    Ranch Hand

    Joined: May 25, 2004
    Posts: 45
    yeah I read the BufferedImageOp and yeah I am passing it two arguments, as far as I can make out:



    The code works when I am using my extended class of BufferedImage, but just the straight BufferedImage class, works a dream with the above line of code.

    The problem I am having is how to use the interface BufferedImageOp with and extended class of BufferedImage.

    Thanks for reading and thanks for the replies so far.

    cheers
    Martin
    [ July 22, 2004: Message edited by: Martin Thorpe ]
    Aaron Roberts
    Ranch Hand

    Joined: Sep 10, 2002
    Posts: 174
    It makes sense that you get a class cast error, as the method returns a new instance of a BufferedImage, regardless if you provided a BufferedImage or your extended class.

    I'm a tad confused. If you are extending BufferedImage, why do you also have a member variable of the same type? With the way your class is setup you actually have 3 images.

    - The MyBufferedImage, will hold image data
    - The BufferedImage variable has image data
    - Your Image variable also has image data

    You could do this to get your transformed image back -

    myBImage.setImage(op.filter(thisImg, null));

    setImage would be a method you add to your extended class, which would do an assign to your variable BufferedImage.

    I think you're going to run into a problem with keeping track of which is the 'real' image data though. If you do the above, then your base class won't have the new image data.

    Is this helping?
    [ July 22, 2004: Message edited by: Aaron Roberts ]
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    Originally posted by Martin Thorpe:
    yeah I read the BufferedImageOp and yeah I am passing it two arguments, as far as I can make out:





    Misleading comments are far worse than missing comments. Since you've read the javadocs, you either misunderstand what they say or misunderstand how casting in Java works or how object creation fits into the object oriented paradigm. There is no "null" buffered image to draw onto. As the documentation says:

    If the destination image is null, a BufferedImage with an appropriate ColorModel is created.

    You may be hoping that it will magically create a BufferedImage which happens to be a subclass of same type as the source image. There's no such magic. It just calls "new BufferedImage()" and passes the arguments that most people want to pass. After all, how would it know how to create a subclass of your object? What constructor would it use?

    The automatic creation thing is a convenience feature, as the documentation subtly indicates. You can pass a destination if you want but since most people just want a new BufferedImage with the same color model it can create one to save you a few lines of code. However in this you're not most people. That's not the behavior you want. So just pass the second argument!

    Aaron Roberts
    Ranch Hand

    Joined: Sep 10, 2002
    Posts: 174
    David -

    I had glossed over the fact that your return is the same as the dest if you supply it. Guess it makes more sense to do it the right way than add a new goofy method!

    Thanks.
    Martin Thorpe
    Ranch Hand

    Joined: May 25, 2004
    Posts: 45
    Thanks David that is spot on and does clear up a misunderstanding I had about bufferedImageOp and also educates me further with Java and classes, the reason I am building this app. is as an self-educational exercise, so again thank you for pointing me right.

    Thanks for your help too Aaron, great forum here.

    cheers
    Martin
    Martin Thorpe
    Ranch Hand

    Joined: May 25, 2004
    Posts: 45
    Yep that did the trick. Have now implemented with my app. as you demonstrated and yes works fine, thank you again.

    cheers
    Martin
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Extending BufferedImage