JDK-6427776 : Method Graphics2D.drawImage(...) stops a run of program
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-05-19
  • Updated: 2015-11-03
Related Reports
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
5.0_06

A DESCRIPTION OF THE PROBLEM :
Method Graphics2D.drawImage(...) stops a run of program in case, the image is modified by Photoshop version 8.0.1 . See source code for detail.

Notes:
- no exception appears
- using the method setRenderingHint(...) is fundamental
- the method drawImage() envokes an never ending loop probably.
- resize solution by AfineTransformOp class is the same wrong.
- the image files are not corrupted and can be opened simply by MSIE, Mozilla and more viewers.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Resize an image.
ACTUAL -
Method Graphics2D.drawImage(...) stops a program

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/*  Source include Photoshop image:
*   http://java_img_test.pponec.net/TEST.ZIP
*/

package test;

import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.image.BufferedImage;
import java.io.InputStream;
import java.util.Iterator;
import javax.imageio.ImageIO;
import javax.imageio.ImageReadParam;
import javax.imageio.ImageReader;
import javax.imageio.stream.ImageInputStream;


public class PhotoTest {
    
    public void test() throws Throwable {
        // The Image was modifiled by Photoshop:
        InputStream file = getClass().getResourceAsStream("/test/img.jpg");
        
        Iterator readers = ImageIO.getImageReadersBySuffix("jpg");
        ImageReader reader = (ImageReader) readers.next();
        ImageInputStream iis = ImageIO.createImageInputStream(file);
        reader.setInput(iis, true); // true means SingleFrame
        ImageReadParam param = reader.getDefaultReadParam();
        BufferedImage imgOriginal = reader.read(0, param);
        iis.close();
        
        // Make a thumbnail:
        BufferedImage imgSmall = new BufferedImage(700, 75, imgOriginal.getType());
        Graphics2D graphics2D = imgSmall.createGraphics();
        graphics2D.setRenderingHint
        ( RenderingHints.KEY_INTERPOLATION
        , RenderingHints.VALUE_INTERPOLATION_BILINEAR
        ) ;
        
        System.out.println("STARTING drawImage(...)");
        // --- THE LAST STATEMENT: ----
        graphics2D.drawImage(imgOriginal, 0, 0, 100, 75, null);
        System.out.println("FINISHED drawImage(...)");
        graphics2D.dispose();
    }
    
    /** Run the class */
    public static void main(String[] args) {
        try {
            new PhotoTest().test();
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
}

---------- END SOURCE ----------

Comments
Please re-open if - if fix is in progress or on the plan to fix soon - if this is a P3 (file as P3, not P4)
18-03-2014

EVALUATION Technically true that fix for 4705399 (together with subsequent fix for 6399616) help to eliminate performance degradation observed on original testcase. I believe that backport of these fixes will likely help if problem will be escalated. However, the root issue here is performance issues related to images with custom color profiles not only for AffineTransformOp but for blits too. As a result of aforementioned fixes ImageIO reader produces buffered images based on sRGB color space for given testcase. Such images are handled very well by blitting code and slightly worse but still with reasonable performance by medialib code. Note that if we explicitly force ImageIO to produce custom images based on some custom color space performance will drop significantly for both blitting or medialib-based approaches. E.g. test execution time on sRGB data is 10ms and it is about 5000ms if custom profiles are used. Results of profiling shows that most of the time (about 98%) is spent to ICC_ColorSpace.toRGB() and this is because this method is called for every single pixel separately from ComponentColorModel.getRGB() from OpaqueCopyAnyToArgb.Blit() (and some other places, including medialib too). I am not exactly sure what we can do to improve performance here probably we can get better performance is such cases if we do some kind of batch processing but how much we can win this way is still unclear. I lean to keep this bug open but focused on more generic performance issues related to images with custom profiles. Obviously it is too late to try to address this generic problem in mustang timeframe.
05-07-2006

EVALUATION The test case does complete, but it takes a long time to do so (a minute or 2 on my 1.2GHz Sparc box). So, it is not an infinite loop, but there are definitely some large amount of calculations going on for this case. Mustang no longer uses AffineTransformOp to scale or transform images in the rendering pipeline and the new code does not suffer from whatever bug was experienced by the 1.4.2 and 1.5.0_06 code. Unfortunately, this new transform pipeline is too complex to backport to older releases and it doesn't solve the problem when using AffineTransformOp directly anyway so that code would not make a good candidate for back-porting to earlier releases. But, modifying the test to use AffineTransformOp directly instead of implicitly inside the rendering pipeline shows the problem as well and also shows that the bug was fixed in a later build of Mustang. I added the following lines of code to the test case (and adjusted the imports): AffineTransform tx = new AffineTransform(); tx.scale(100.0/700.0, 1.0); AffineTransformOp ato = new AffineTransformOp(tx, AffineTransformOp.TYPE_BILINEAR); System.out.println("STARTING AffineTransformOp"); ato.filter(imgOriginal, null); System.out.println("FINISHED AffineTransformOp"); and the problem showed up in Mustang up through build 76, but was no longer reproducible in build 77. Thus, it looks like there is a potential fix for this bug in build 77 that might be a good candidate for backporting to prior releases if this bug is escalated. In looking through the list of bugs fixed by 2D in build 77 the most likely candidate is 4705399 (or 6372769) which are bugs about using a non-default profile in a JPG image (likely the case for the test image included in this bug report). I am transferring this bug to the engineer who fixed those bugs for confirmation before it is closed as a duplicate (possibly awaiting escalation for a backport).
24-05-2006