Error importing tiff virtual stack with size over 2^29 pixels

I created an issue on github as well and was suggested to post it here, too:

File->Import->TIFF Virtual Stack does not open files larger than 2^29 pixels properly, the bottom part of the image after that size is somehow shifted, it is probably some overflow error or signed-unsigned error, based on the match with the exact power of 2 where the shift happens. See visual example on the link above.

Note: i could not check if the simple “Open” function creates the same bug or not as I have not enough memory to open such large files that way (and with open I simply get a Java crash with memory overflow).

File>Open and File>Import>TIFF Virtual Stack open a single TIFF image in the same way. The only difference I can see is that File>Import>TIFF Virtual Stack reads the image twice. Both commands always cause ImageJ to crash on my Mac when opening a 30000x30000 RGB TIFF. Both are sometimes able to open a 23400x23400 TIFF created using this script:

  imp = IJ.createImage("Untitled", "RGB ramp", 23400, 23400, 1);
  IJ.saveAs(imp, "Tiff", "”);

but it is not displayed correctly. The bug that causes RGB images with more than 2^29 pixels to not be displayed correctly appears to be in the code that displays the image since the pixel data are correct, as you can see in the following screen shot. There may not be an easy fix for this bug since most of the code is in the Java runtime.


I tested this on Bio7 (displayed on a JPanel instead Canvas) with Windows 10 and OpenJDK 12 (OpenJDK 64-Bit Server VM (12+33).

I created a 30000x30000 RGB image in IrfanView and opened it as an image in ImageJ (crashed after resizing the image) and VirtualStack (see image below):

When loading normally a tiff it generates a:

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x000000048ca3587c

Also with Bioformats it displays a mess.

When I crop the image the subregion is displayed fine as @Wayne already mentioned:

@vasarhelyi I think it would be valuable if you can reproduce the error with Java and without Imagej to create a bug report in the Java Bug database.

The following Java program, which is completely independent of ImageJ, reproduces the bug. I reported the bug at and it can be tracked at

import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;
import javax.imageio.*;
import javax.swing.*;

// java -Xmx7000m DrawImageBug 
public class DrawImageBug extends Component {
    static final int SIZE = 23400;     
    static final int SCREEN_SIZE = SIZE/50;       
    BufferedImage img;
    public void paint(Graphics g) {
        g.drawImage(img, 0, 0, SCREEN_SIZE, SCREEN_SIZE, 0, 0, SIZE, SIZE, null);
    public DrawImageBug() {
       img  = new BufferedImage(SIZE, SIZE, BufferedImage.TYPE_INT_ARGB); 
        Graphics g = img.getGraphics();
       double inc = SIZE/255.0;
       for (int i=0; i<255; i++)  {
            g.setColor(new Color(i,i,i));
            g.fillRect((int)(i*inc), 0, (int)(inc+0.5), SIZE);  
    public Dimension getPreferredSize() {
        if (img == null)
             return new Dimension(100,100);
           return new Dimension(SCREEN_SIZE, SCREEN_SIZE);
    public static void main(String[] args) {
        JFrame f = new JFrame("Sample Image");            
        f.addWindowListener(new WindowAdapter(){
                public void windowClosing(WindowEvent e) {
        f.add(new DrawImageBug());

This is the output, with the display anomaly outlined in red:



Seems to be fixed on OpenJDK 13 (tested on Windows only).

1 Like

Tested with ImageJ plugin running with OpenJDK 13. Works fine, screenshot:

1 Like