[kepler-dev] Problem with ImageReader actor

[Christopher Hylands Brooks]

Interesting. 

I'm definitely the right person for this one.

I'm not so sure we want to always flush the image though.

This is an interesting case where the filename does not change, so 
attributeChanged is not called, yet the underlying data does change.
prefire() is what actually reads the file and creates the Image:

/** Read in an image.
     *  @exception IllegalActionException If an IO error occurs.
     */
    public boolean prefire() throws IllegalActionException {
        if (_url == null) {
            throw new IllegalActionException("sourceURL was null");
        }
        _fileRoot = _url.getFile();
        _image = new ImageIcon(_fileRoot).getImage();
        if (_image.getWidth(null) == -1
                && _image.getHeight(null) == -1) {
            throw new IllegalActionException(this,
                    "Image size is -1 x -1.  Failed to open '"
                    + _fileRoot + "'");
        }
        return super.prefire();
    }

I guess new ImageIcon() caches the name somewhere.

The docs for Image.flush() are:
--start--
Flushes all resources being used by this Image object. This includes
any pixel data that is being cached for rendering to the screen as
well as any system resources that are being used to store data or
pixels for the image. The image is reset to a state similar to when it
was first created so that if it is again rendered, the image data will
have to be recreated or fetched again from its source.

This method always leaves the image in a state such that it can be
reconstructed. This means the method applies only to cached or other
secondary representations of images such as those that have been
generated from an ImageProducer (read from a file, for example). It
does nothing for off-screen images that have only one copy of their
data. 
--end--

I can see where we might want to do what you are doing and get the
image each time even if it is unchanged, and also only get the image
if the name has changed.  I'm concerned about the overhead of always
flushing the image.

I suspect that the safe thing to do would be to add a boolean
parameter flushImage that if it was set to true, the fire() would
flush the image each time.

Let me chew on this a little.

-Christopher


--------

    Hi Christopher,
     
        Perhaps you can pass this message on the the appropriate person in 
    the Ptolemy group.
    
        I ran into a problem using the ImageReader actor in PTII4.0. I 
    created a workflow (using 'R') which created an image file (jpeg) and 
    then used the ImageReader and ImageDisplay actor to display this image. 
    This works just fine the first time the workflow is executed. But if I 
    change an input parameter, the workflow creates a new image file (with 
    the same name as the first run), but the OLD IMAGE (original image) is 
    displayed even though the contents of the file has changed on my disk! 
    The new file will not appear until I shut down PT and restart it! [A key 
    point is that the file name has not changed.]
    
        After some frustrating investigation, I discovered that the problem 
    seems to be related to how Java handles images. Apparently image data is 
    cached and not reloaded unless you call the 'flush()' method on the 
    image object. I just added the line
    
            _image.flush();
    
    to the 'fire' method in ptolemy/actor/lib/image/ImageReader after the 
    'output.broadcast(new AWTImageToken(_image));' line and the problem got 
    fixed!  :-) Apparently this forces the image to be reloaded even when 
    the file name has not been changed. There may be a better place to put 
    this fix; you may want to insert it somewhere before the next PT bug 
    release.
    
    Dan
    
    -- 
    ---------------------------------
    Dan Higgins
    Software Developer
    National Center for Ecological Analysis and Synthesis (NCEAS) 
    735 State St. Rm 205 
    Santa Barbara, CA 93101 
    805-892-2531 
    higgins at nceas.ucsb.edu 
    ---------------------------------
    
    _______________________________________________
    kepler-dev mailing list
    kepler-dev at ecoinformatics.org
    http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
--------