ImageJ on Linux (Suse,Ubuntu)

[Aryeh Weiss]

When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04
on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are
loaded but not displayed properly. The windows is white. The image is
there, but cannot be seen. Sometimes, after this happens, all subsequent
image windows will be white -- even small ones. BUt other times, the
small windows will be ok and only the large windows will be affected. If
I run Image>Scale... by 0.5 in each dimension, the downsized image will
appear and be displayed correctly..
If the cursor in moved over the large white window, the pixels values
are displayed in the main ImageJ window.

It seems that the images are created and valid, but the windows are not
refreshed properly.

More information:

1 Systems have 16GB or 64 GB of memory.

2. Problem occurs even with a fresh download of Fiji, with no extra
update sites selected.

3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji
specific.

4. The images that are being loaded are either TIFF or ZIP (with TIFF
inside).

5. One system has an Nvidia GTX650 graphics card. Problem occurred with
both the default display drivers and the latest Nvidia display drivers.
The other system is a Lenovo P50 with a Quadro M2000M graphics card.

6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
1.8_171, and probably a few others along the way. They all behaved the same.

7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.

I am sure that there are many people running Fiji/ImageJ on lInux
machines and loading large images.
What am I doing wrong?

By the way, these same images work fine on my macbook (macos 10.13.4).

Thanks in advance
--aryeh

--
Aryeh Weiss
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel

Ph:  972-3-5317638
FAX: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Thorsten Mielke]

I have similar problem running Fiji on a self-maintained Linux system provided by our IT: TIFF Images produced by Fiji (Stitching of TEM images in mrc format) larger than roughly 800 MB (for sure larger than 1 GB) are not displayed, only a white window pops up in Fiji 1.51. However, the same images are displayed properly in Fiji 1.49 and on Windows Systems. So far, my work-around was swapping between Fiji versions.
Best,
Thorsten

Von meinem iPhone gesendet

> Am 24.04.2018 um 20:05 schrieb Aryeh Weiss <[hidden email]>:
>
> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are loaded but not displayed properly. The windows is white. The image is there, but cannot be seen. Sometimes, after this happens, all subsequent image windows will be white -- even small ones. BUt other times, the small windows will be ok and only the large windows will be affected. If I run Image>Scale... by 0.5 in each dimension, the downsized image will appear and be displayed correctly..
> If the cursor in moved over the large white window, the pixels values are displayed in the main ImageJ window.
>
> It seems that the images are created and valid, but the windows are not refreshed properly.
>
> More information:
>
> 1 Systems have 16GB or 64 GB of memory.
>
> 2. Problem occurs even with a fresh download of Fiji, with no extra update sites selected.
>
> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji specific.
>
> 4. The images that are being loaded are either TIFF or ZIP (with TIFF inside).
>
> 5. One system has an Nvidia GTX650 graphics card. Problem occurred with both the default display drivers and the latest Nvidia display drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics card.
>
> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101, 1.8_171, and probably a few others along the way. They all behaved the same.
>
> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.
>
> I am sure that there are many people running Fiji/ImageJ on lInux machines and loading large images.
> What am I doing wrong?
>
> By the way, these same images work fine on my macbook (macos 10.13.4).
>
> Thanks in advance
> --aryeh
>
> --
> Aryeh Weiss
> Faculty of Engineering
> Bar Ilan University
> Ramat Gan 52900 Israel
>
> Ph:  972-3-5317638
> FAX: [phone]
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Aryeh,

on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
graphics) a 22655 x 32794 pixel image displays correctly at zoom levels
of 6.2% or larger. Sometimes it also works with 4.2%.
It remains white or does not update the screen at lower magnifications.

Scrolling is very sluggish at 6.2%, it works better at higher
magnifications.

I tried saving the file as png and using other programs:
ImageViewer and ImageMagick crash.
Okular has the same problem as ImageJ, it shows it only when zooming in
from the full image area.

So I guess that it is a problem of the Linux Windows Manager.

GIMP shows it, but becomes extremely slow. Firefox has no problem. I
guess that these programs handle the zooming by themselves, not via the
Linux Windows Manager or graphics.

Michael
________________________________________________________________
On 24/04/2018 20:05, Aryeh Weiss wrote:
 > When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels)
are loaded but not displayed properly. The windows is white. The image
is there, but cannot be seen. Sometimes, after this happens, all
subsequent image windows will be white -- even small ones. BUt other
times, the small windows will be ok and only the large windows will be
affected. If I run Image>Scale... by 0.5 in each dimension, the
downsized image will appear and be displayed correctly..
 > If the cursor in moved over the large white window, the pixels values
are displayed in the main ImageJ window.
 >
 > It seems that the images are created and valid, but the windows are
not refreshed properly.
 >
 > More information:
 >
 > 1 Systems have 16GB or 64 GB of memory.
 >
 > 2. Problem occurs even with a fresh download of Fiji, with no extra
update sites selected.
 >
 > 3. Problem also occurs with ImageJ (not the Fiji distro). It is not
Fiji specific.
 >
 > 4. The images that are being loaded are either TIFF or ZIP (with TIFF
inside).
 >
 > 5. One system has an Nvidia GTX650 graphics card. Problem occurred
with both the default display drivers and the latest Nvidia display
drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics
card.
 >
 > 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
1.8_171, and probably a few others along the way. They all behaved the same.
 >
 > 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu
16.04.
 >
 > I am sure that there are many people running Fiji/ImageJ on lInux
machines and loading large images.
 > What am I doing wrong?
 >
 > By the way, these same images work fine on my macbook (macos 10.13.4).
 >
 > Thanks in advance
 > --aryeh
 >

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Aryeh Weiss]

Thanks to Michael and Thorsten for their replies.

I can odd a discovery.  If I draw an ROI on the image that I loaded,
then the image appears inside that ROI.
If I then remove the ROi, the entire image appears -- quickly.

I tried this in a script

inputImp = ImagePlus(inputPath)
inputImp.show()
[width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
inputImp.setRoi(0,0,width,height)

Setting the ROI caused the image to be displayed.
With that line -- I only had a white display.
I verified this on two systems (both Ubuntu 16.04).

Another interesting thing - If I have ROIs in the roimanager, and I set
"show all" the overlay will appear correctly on the image. If I then
deselect show all, the overlay will remain on the image. If I then draw
an ROI on that image, the overly will disappear under the ROI. If I then
deselect the ROI, the overlay will disappear from the entire image.
Whatever draws the image when an ROI is created or deselected seems to
do that quickly and correctly.

It still happens that the computer will be very slow while loading or 
just after loading a large image. Once that is passed, then update is
fast when drawing an ROI.

Maybe this provides a hint of  what is happening.

Best regards
--aryeh


On 24/04/2018 22:30, Michael Schmid wrote:

> Hi Aryeh,
>
> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
> graphics) a 22655 x 32794 pixel image displays correctly at zoom
> levels of 6.2% or larger. Sometimes it also works with 4.2%.
> It remains white or does not update the screen at lower magnifications.
>
> Scrolling is very sluggish at 6.2%, it works better at higher
> magnifications.
>
> I tried saving the file as png and using other programs:
> ImageViewer and ImageMagick crash.
> Okular has the same problem as ImageJ, it shows it only when zooming
> in from the full image area.
>
> So I guess that it is a problem of the Linux Windows Manager.
>
> GIMP shows it, but becomes extremely slow. Firefox has no problem. I
> guess that these programs handle the zooming by themselves, not via
> the Linux Windows Manager or graphics.
>
> Michael
> ________________________________________________________________
> On 24/04/2018 20:05, Aryeh Weiss wrote:
> > When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
> 16.04 on two machines), large images (eg, 800MB , 22655 x 32794
> pixels) are loaded but not displayed properly. The windows is white.
> The image is there, but cannot be seen. Sometimes, after this happens,
> all subsequent image windows will be white -- even small ones. BUt
> other times, the small windows will be ok and only the large windows
> will be affected. If I run Image>Scale... by 0.5 in each dimension,
> the downsized image will appear and be displayed correctly..
> > If the cursor in moved over the large white window, the pixels
> values are displayed in the main ImageJ window.
> >
> > It seems that the images are created and valid, but the windows are
> not refreshed properly.
> >
> > More information:
> >
> > 1 Systems have 16GB or 64 GB of memory.
> >
> > 2. Problem occurs even with a fresh download of Fiji, with no extra
> update sites selected.
> >
> > 3. Problem also occurs with ImageJ (not the Fiji distro). It is not
> Fiji specific.
> >
> > 4. The images that are being loaded are either TIFF or ZIP (with
> TIFF inside).
> >
> > 5. One system has an Nvidia GTX650 graphics card. Problem occurred
> with both the default display drivers and the latest Nvidia display
> drivers. The other system is a Lenovo P50 with a Quadro M2000M
> graphics card.
> >
> > 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
> 1.8_171, and probably a few others along the way. They all behaved the
> same.
> >
> > 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu
> 16.04.
> >
> > I am sure that there are many people running Fiji/ImageJ on lInux
> machines and loading large images.
> > What am I doing wrong?
> >
> > By the way, these same images work fine on my macbook (macos 10.13.4).
> >
> > Thanks in advance
> > --aryeh
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
Aryeh Weiss
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel

Ph:  972-3-5317638
FAX: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

Hi Aryeh,

The latest ImageJ daily build (1.52b7) uses double buffering to work around the Linux problem with large images not showing at low magnification. This solution, proposed by Michael Schmid, is described below.

-wayne

> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]> wrote:
>
> Hi Wayne,
>
> concerning the large images not visible under Linux:
>
> Aryeh's hint with the problem disappearing with a ROI was a good one:
> In case there is a ROI, ImageJ uses double buffering.
> And the problem indeed goes away if one uses double buffering under Linux, also in absence of a ROI:
>
> This is the modification I did (ImageCanvas, line 210):
> //double buffering to avoid flickering of ROIs, also works around a Linux problem of large images not showing at low magnification
> if (roi!=null || overlay!=null || showAllOverlay!=null || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>
> The limit "magnification<0.25" is arbitrary. In my experience with a 700 MB image the problem was already gone at magnifications like 0.1, but it does not hurt to set the limit higher. Since it is unclear what causes the bug and when it can appear, you could also set the limit to 1.0.
>
> By the way, for a reason that I don't understand, without double buffering there can be also an unexpected "Out of Memory" failure.
> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp) throws the current ImageJ out of memory under my Linux, but after the patch it works (8 GBytes for ImageJ in both cases).
> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl image.
> I guess that the 'Out of memory' is related to the Java/Linux Window Manager bug that makes the image not display as it should.

> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>
> Thanks to Michael and Thorsten for their replies.
>
> I can odd a discovery.  If I draw an ROI on the image that I loaded, then the image appears inside that ROI.
> If I then remove the ROi, the entire image appears -- quickly.
>
> I tried this in a script
>
> inputImp = ImagePlus(inputPath)
> inputImp.show()
> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
> inputImp.setRoi(0,0,width,height)
>
> Setting the ROI caused the image to be displayed.
> With that line -- I only had a white display.
> I verified this on two systems (both Ubuntu 16.04).
>
> Another interesting thing - If I have ROIs in the roimanager, and I set "show all" the overlay will appear correctly on the image. If I then deselect show all, the overlay will remain on the image. If I then draw an ROI on that image, the overly will disappear under the ROI. If I then deselect the ROI, the overlay will disappear from the entire image.
> Whatever draws the image when an ROI is created or deselected seems to do that quickly and correctly.
>
> It still happens that the computer will be very slow while loading or  just after loading a large image. Once that is passed, then update is fast when drawing an ROI.
>
> Maybe this provides a hint of  what is happening.
>
> Best regards
> --aryeh
>
>
> On 24/04/2018 22:30, Michael Schmid wrote:
>> Hi Aryeh,
>>
>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of 6.2% or larger. Sometimes it also works with 4.2%.
>> It remains white or does not update the screen at lower magnifications.
>>
>> Scrolling is very sluggish at 6.2%, it works better at higher magnifications.
>>
>> I tried saving the file as png and using other programs:
>> ImageViewer and ImageMagick crash.
>> Okular has the same problem as ImageJ, it shows it only when zooming in from the full image area.
>>
>> So I guess that it is a problem of the Linux Windows Manager.
>>
>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I guess that these programs handle the zooming by themselves, not via the Linux Windows Manager or graphics.
>>
>> Michael
>> ________________________________________________________________
>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>> > When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are loaded but not displayed properly. The windows is white. The image is there, but cannot be seen. Sometimes, after this happens, all subsequent image windows will be white -- even small ones. BUt other times, the small windows will be ok and only the large windows will be affected. If I run Image>Scale... by 0.5 in each dimension, the downsized image will appear and be displayed correctly..
>> > If the cursor in moved over the large white window, the pixels values are displayed in the main ImageJ window.
>> >
>> > It seems that the images are created and valid, but the windows are not refreshed properly.
>> >
>> > More information:
>> >
>> > 1 Systems have 16GB or 64 GB of memory.
>> >
>> > 2. Problem occurs even with a fresh download of Fiji, with no extra update sites selected.
>> >
>> > 3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji specific.
>> >
>> > 4. The images that are being loaded are either TIFF or ZIP (with TIFF inside).
>> >
>> > 5. One system has an Nvidia GTX650 graphics card. Problem occurred with both the default display drivers and the latest Nvidia display drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics card.
>> >
>> > 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101, 1.8_171, and probably a few others along the way. They all behaved the same.
>> >
>> > 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.
>> >
>> > I am sure that there are many people running Fiji/ImageJ on lInux machines and loading large images.
>> > What am I doing wrong?
>> >
>> > By the way, these same images work fine on my macbook (macos 10.13.4).
>> >
>> > Thanks in advance
>> > --aryeh
>> >

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

This line of code leads me to ask: are there *demonstrated* negatives to using double-buffering *all* the time?
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>
> Hi Aryeh,
>
> The latest ImageJ daily build (1.52b7) uses double buffering to work around the Linux problem with large images not showing at low magnification. This solution, proposed by Michael Schmid, is described below.
>
> -wayne
>
>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]> wrote:
>>
>> Hi Wayne,
>>
>> concerning the large images not visible under Linux:
>>
>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>> In case there is a ROI, ImageJ uses double buffering.
>> And the problem indeed goes away if one uses double buffering under Linux, also in absence of a ROI:
>>
>> This is the modification I did (ImageCanvas, line 210):
>> //double buffering to avoid flickering of ROIs, also works around a Linux problem of large images not showing at low magnification
>> if (roi!=null || overlay!=null || showAllOverlay!=null || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>
>> The limit "magnification<0.25" is arbitrary. In my experience with a 700 MB image the problem was already gone at magnifications like 0.1, but it does not hurt to set the limit higher. Since it is unclear what causes the bug and when it can appear, you could also set the limit to 1.0.
>>
>> By the way, for a reason that I don't understand, without double buffering there can be also an unexpected "Out of Memory" failure.
>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp) throws the current ImageJ out of memory under my Linux, but after the patch it works (8 GBytes for ImageJ in both cases).
>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl image.
>> I guess that the 'Out of memory' is related to the Java/Linux Window Manager bug that makes the image not display as it should.
>
>
>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>
>> Thanks to Michael and Thorsten for their replies.
>>
>> I can odd a discovery.  If I draw an ROI on the image that I loaded, then the image appears inside that ROI.
>> If I then remove the ROi, the entire image appears -- quickly.
>>
>> I tried this in a script
>>
>> inputImp = ImagePlus(inputPath)
>> inputImp.show()
>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>> inputImp.setRoi(0,0,width,height)
>>
>> Setting the ROI caused the image to be displayed.
>> With that line -- I only had a white display.
>> I verified this on two systems (both Ubuntu 16.04).
>>
>> Another interesting thing - If I have ROIs in the roimanager, and I set "show all" the overlay will appear correctly on the image. If I then deselect show all, the overlay will remain on the image. If I then draw an ROI on that image, the overly will disappear under the ROI. If I then deselect the ROI, the overlay will disappear from the entire image.
>> Whatever draws the image when an ROI is created or deselected seems to do that quickly and correctly.
>>
>> It still happens that the computer will be very slow while loading or  just after loading a large image. Once that is passed, then update is fast when drawing an ROI.
>>
>> Maybe this provides a hint of  what is happening.
>>
>> Best regards
>> --aryeh
>>
>>
>> On 24/04/2018 22:30, Michael Schmid wrote:
>>> Hi Aryeh,
>>>
>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of 6.2% or larger. Sometimes it also works with 4.2%.
>>> It remains white or does not update the screen at lower magnifications.
>>>
>>> Scrolling is very sluggish at 6.2%, it works better at higher magnifications.
>>>
>>> I tried saving the file as png and using other programs:
>>> ImageViewer and ImageMagick crash.
>>> Okular has the same problem as ImageJ, it shows it only when zooming in from the full image area.
>>>
>>> So I guess that it is a problem of the Linux Windows Manager.
>>>
>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I guess that these programs handle the zooming by themselves, not via the Linux Windows Manager or graphics.
>>>
>>> Michael
>>> ________________________________________________________________
>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are loaded but not displayed properly. The windows is white. The image is there, but cannot be seen. Sometimes, after this happens, all subsequent image windows will be white -- even small ones. BUt other times, the small windows will be ok and only the large windows will be affected. If I run Image>Scale... by 0.5 in each dimension, the downsized image will appear and be displayed correctly..
>>>> If the cursor in moved over the large white window, the pixels values are displayed in the main ImageJ window.
>>>>
>>>> It seems that the images are created and valid, but the windows are not refreshed properly.
>>>>
>>>> More information:
>>>>
>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>
>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra update sites selected.
>>>>
>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji specific.
>>>>
>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF inside).
>>>>
>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred with both the default display drivers and the latest Nvidia display drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics card.
>>>>
>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101, 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>
>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.
>>>>
>>>> I am sure that there are many people running Fiji/ImageJ on lInux machines and loading large images.
>>>> What am I doing wrong?
>>>>
>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>
>>>> Thanks in advance
>>>> --aryeh
>>>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Aryeh Weiss]

Many thanks for Michael and Wayne for this fix..
I just tested it on the P50 (Ubuntu 16.04, 64GB RAM), and with the new
daily build the large images loaded immediately.

Best regards
--aryeh

On 26/04/2018 16:38, Wayne Rasband wrote:

> Hi Aryeh,
>
> The latest ImageJ daily build (1.52b7) uses double buffering to work around the Linux problem with large images not showing at low magnification. This solution, proposed by Michael Schmid, is described below.
>
> -wayne
>
>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]> wrote:
>>
>> Hi Wayne,
>>
>> concerning the large images not visible under Linux:
>>
>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>> In case there is a ROI, ImageJ uses double buffering.
>> And the problem indeed goes away if one uses double buffering under Linux, also in absence of a ROI:
>>
>> This is the modification I did (ImageCanvas, line 210):
>> //double buffering to avoid flickering of ROIs, also works around a Linux problem of large images not showing at low magnification
>> if (roi!=null || overlay!=null || showAllOverlay!=null || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>
>> The limit "magnification<0.25" is arbitrary. In my experience with a 700 MB image the problem was already gone at magnifications like 0.1, but it does not hurt to set the limit higher. Since it is unclear what causes the bug and when it can appear, you could also set the limit to 1.0.
>>
>> By the way, for a reason that I don't understand, without double buffering there can be also an unexpected "Out of Memory" failure.
>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp) throws the current ImageJ out of memory under my Linux, but after the patch it works (8 GBytes for ImageJ in both cases).
>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl image.
>> I guess that the 'Out of memory' is related to the Java/Linux Window Manager bug that makes the image not display as it should.
>
>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>
>> Thanks to Michael and Thorsten for their replies.
>>
>> I can odd a discovery.  If I draw an ROI on the image that I loaded, then the image appears inside that ROI.
>> If I then remove the ROi, the entire image appears -- quickly.
>>
>> I tried this in a script
>>
>> inputImp = ImagePlus(inputPath)
>> inputImp.show()
>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>> inputImp.setRoi(0,0,width,height)
>>
>> Setting the ROI caused the image to be displayed.
>> With that line -- I only had a white display.
>> I verified this on two systems (both Ubuntu 16.04).
>>
>> Another interesting thing - If I have ROIs in the roimanager, and I set "show all" the overlay will appear correctly on the image. If I then deselect show all, the overlay will remain on the image. If I then draw an ROI on that image, the overly will disappear under the ROI. If I then deselect the ROI, the overlay will disappear from the entire image.
>> Whatever draws the image when an ROI is created or deselected seems to do that quickly and correctly.
>>
>> It still happens that the computer will be very slow while loading or  just after loading a large image. Once that is passed, then update is fast when drawing an ROI.
>>
>> Maybe this provides a hint of  what is happening.
>>
>> Best regards
>> --aryeh
>>
>>
>> On 24/04/2018 22:30, Michael Schmid wrote:
>>> Hi Aryeh,
>>>
>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of 6.2% or larger. Sometimes it also works with 4.2%.
>>> It remains white or does not update the screen at lower magnifications.
>>>
>>> Scrolling is very sluggish at 6.2%, it works better at higher magnifications.
>>>
>>> I tried saving the file as png and using other programs:
>>> ImageViewer and ImageMagick crash.
>>> Okular has the same problem as ImageJ, it shows it only when zooming in from the full image area.
>>>
>>> So I guess that it is a problem of the Linux Windows Manager.
>>>
>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I guess that these programs handle the zooming by themselves, not via the Linux Windows Manager or graphics.
>>>
>>> Michael
>>> ________________________________________________________________
>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are loaded but not displayed properly. The windows is white. The image is there, but cannot be seen. Sometimes, after this happens, all subsequent image windows will be white -- even small ones. BUt other times, the small windows will be ok and only the large windows will be affected. If I run Image>Scale... by 0.5 in each dimension, the downsized image will appear and be displayed correctly..
>>>> If the cursor in moved over the large white window, the pixels values are displayed in the main ImageJ window.
>>>>
>>>> It seems that the images are created and valid, but the windows are not refreshed properly.
>>>>
>>>> More information:
>>>>
>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>
>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra update sites selected.
>>>>
>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji specific.
>>>>
>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF inside).
>>>>
>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred with both the default display drivers and the latest Nvidia display drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics card.
>>>>
>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101, 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>
>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.
>>>>
>>>> I am sure that there are many people running Fiji/ImageJ on lInux machines and loading large images.
>>>> What am I doing wrong?
>>>>
>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>
>>>> Thanks in advance
>>>> --aryeh
>>>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> .
>

--
Aryeh Weiss
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel

Ph:  972-3-5317638
FAX: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Kenneth,

well, I tried to be on the conservative side with my suggestion for
double buffering, but maybe not conservative enough:
I just discovered that ImageJ (actually Java) with double buffering
crashes when creating an RGB image of 20000*40000 on my computer (3 GB
image; 8 or 12 GB reserved for ImageJ):
Oracle Java 1.8.0_112 [64-bit]; Linux 4.4.0-119-generic; 8098MB (75%)
The threshold for crashing seems to be 2 GB image size (0.5 gigapixels).

Without double buffering, it does not show the image at small zoom
factors, but at least it does not crash as long as I create no ROI. It
crashes if I create a ROI at small zoom factors (creating a ROI switches
to double buffering). Increasing the memory for ImageJ to 12 GB does not
help.

With double buffering, ImageJ crashes immediately when it tries to show
the image.

It is not an issue at 1x zoom, there it works with or without double
buffering.

The crash log says the crash is in the EventQueue, in C native code
(lines with lowercase j are interpreted Java code):

C  [libawt.so+0x62cce]  IntRgbBilinearTransformHelper+0xce
C  [libawt.so+0x7a903]
Java_sun_java2d_loops_TransformHelper_Transform+0xe73
j
sun.java2d.loops.TransformHelper.Transform(Lsun/java2d/loops/MaskBlit;Lsun/java2d/SurfaceData;Lsun/java2d/SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;Ljava/awt/geom/AffineTransform;IIIIIIIII[III)V+0
j
sun.java2d.pipe.DrawImage.renderImageXform(Lsun/java2d/SunGraphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;IIIIILjava/awt/Color;)V+542
j
sun.java2d.pipe.DrawImage.transformImage(Lsun/java2d/SunGraphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;IIIIILjava/awt/Color;)V+120
j
sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;)Z+467
j
sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/ImageObserver;)Z+27
j
sun.java2d.pipe.ValidatePipe.scaleImage(Lsun/java2d/SunGraphics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/ImageObserver;)Z+33
...

The crash happens with the Oracle JRE.
With OpenJDK (1.8.0_162) creating a 3 GB RGB image leads to 'Out of
Memory', independent of whether double buffering is on.
With OpenJDK, there are also problems with 8-bit images; I can't do any
operations on a 1.5 GB image, I always get 'Out of Memory' even with 12
GB memory for ImageJ. With a somewhat smaller image where it is stable
(1.1 GB), "Monitor Memory" does not go above 2.3 GB (image plus undo
buffer), so there is no legitimate reason for "Out of Memory".

The bottom line:

It seems that Java does not work well with images above 1 GB at least
under Linux. Probably it is not worthwhile investing much effort until
the Oracle & OpenJDK developers fix these issues.


Michael
________________________________________________________________
On 26/04/2018 17:39, Kenneth Sloan wrote:

> This line of code leads me to ask: are there *demonstrated* negatives to using double-buffering *all* the time?
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>>
>> Hi Aryeh,
>>
>> The latest ImageJ daily build (1.52b7) uses double buffering to work around the Linux problem with large images not showing at low magnification. This solution, proposed by Michael Schmid, is described below.
>>
>> -wayne
>>
>>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]> wrote:
>>>
>>> Hi Wayne,
>>>
>>> concerning the large images not visible under Linux:
>>>
>>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>>> In case there is a ROI, ImageJ uses double buffering.
>>> And the problem indeed goes away if one uses double buffering under Linux, also in absence of a ROI:
>>>
>>> This is the modification I did (ImageCanvas, line 210):
>>> //double buffering to avoid flickering of ROIs, also works around a Linux problem of large images not showing at low magnification
>>> if (roi!=null || overlay!=null || showAllOverlay!=null || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>>
>>> The limit "magnification<0.25" is arbitrary. In my experience with a 700 MB image the problem was already gone at magnifications like 0.1, but it does not hurt to set the limit higher. Since it is unclear what causes the bug and when it can appear, you could also set the limit to 1.0.
>>>
>>> By the way, for a reason that I don't understand, without double buffering there can be also an unexpected "Out of Memory" failure.
>>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp) throws the current ImageJ out of memory under my Linux, but after the patch it works (8 GBytes for ImageJ in both cases).
>>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl image.
>>> I guess that the 'Out of memory' is related to the Java/Linux Window Manager bug that makes the image not display as it should.
>>
>>
>>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>>
>>> Thanks to Michael and Thorsten for their replies.
>>>
>>> I can odd a discovery.  If I draw an ROI on the image that I loaded, then the image appears inside that ROI.
>>> If I then remove the ROi, the entire image appears -- quickly.
>>>
>>> I tried this in a script
>>>
>>> inputImp = ImagePlus(inputPath)
>>> inputImp.show()
>>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>>> inputImp.setRoi(0,0,width,height)
>>>
>>> Setting the ROI caused the image to be displayed.
>>> With that line -- I only had a white display.
>>> I verified this on two systems (both Ubuntu 16.04).
>>>
>>> Another interesting thing - If I have ROIs in the roimanager, and I set "show all" the overlay will appear correctly on the image. If I then deselect show all, the overlay will remain on the image. If I then draw an ROI on that image, the overly will disappear under the ROI. If I then deselect the ROI, the overlay will disappear from the entire image.
>>> Whatever draws the image when an ROI is created or deselected seems to do that quickly and correctly.
>>>
>>> It still happens that the computer will be very slow while loading or  just after loading a large image. Once that is passed, then update is fast when drawing an ROI.
>>>
>>> Maybe this provides a hint of  what is happening.
>>>
>>> Best regards
>>> --aryeh
>>>
>>>
>>> On 24/04/2018 22:30, Michael Schmid wrote:
>>>> Hi Aryeh,
>>>>
>>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of 6.2% or larger. Sometimes it also works with 4.2%.
>>>> It remains white or does not update the screen at lower magnifications.
>>>>
>>>> Scrolling is very sluggish at 6.2%, it works better at higher magnifications.
>>>>
>>>> I tried saving the file as png and using other programs:
>>>> ImageViewer and ImageMagick crash.
>>>> Okular has the same problem as ImageJ, it shows it only when zooming in from the full image area.
>>>>
>>>> So I guess that it is a problem of the Linux Windows Manager.
>>>>
>>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I guess that these programs handle the zooming by themselves, not via the Linux Windows Manager or graphics.
>>>>
>>>> Michael
>>>> ________________________________________________________________
>>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are loaded but not displayed properly. The windows is white. The image is there, but cannot be seen. Sometimes, after this happens, all subsequent image windows will be white -- even small ones. BUt other times, the small windows will be ok and only the large windows will be affected. If I run Image>Scale... by 0.5 in each dimension, the downsized image will appear and be displayed correctly..
>>>>> If the cursor in moved over the large white window, the pixels values are displayed in the main ImageJ window.
>>>>>
>>>>> It seems that the images are created and valid, but the windows are not refreshed properly.
>>>>>
>>>>> More information:
>>>>>
>>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>>
>>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra update sites selected.
>>>>>
>>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not Fiji specific.
>>>>>
>>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF inside).
>>>>>
>>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred with both the default display drivers and the latest Nvidia display drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics card.
>>>>>
>>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101, 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>>
>>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu 16.04.
>>>>>
>>>>> I am sure that there are many people running Fiji/ImageJ on lInux machines and loading large images.
>>>>> What am I doing wrong?
>>>>>
>>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>>
>>>>> Thanks in advance
>>>>> --aryeh
>>>>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Michael,

> It seems that Java does not work well with images above 1 GB at least
> under Linux. Probably it is not worthwhile investing much effort until
> the Oracle & OpenJDK developers fix these issues.

Have you tested Java 9 and 10 as well?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Thu, Apr 26, 2018 at 7:34 PM, Michael Schmid <[hidden email]>
wrote:

> Hi Kenneth,
>
> well, I tried to be on the conservative side with my suggestion for double
> buffering, but maybe not conservative enough:
> I just discovered that ImageJ (actually Java) with double buffering
> crashes when creating an RGB image of 20000*40000 on my computer (3 GB
> image; 8 or 12 GB reserved for ImageJ):
> Oracle Java 1.8.0_112 [64-bit]; Linux 4.4.0-119-generic; 8098MB (75%)
> The threshold for crashing seems to be 2 GB image size (0.5 gigapixels).
>
> Without double buffering, it does not show the image at small zoom
> factors, but at least it does not crash as long as I create no ROI. It
> crashes if I create a ROI at small zoom factors (creating a ROI switches to
> double buffering). Increasing the memory for ImageJ to 12 GB does not help.
>
> With double buffering, ImageJ crashes immediately when it tries to show
> the image.
>
> It is not an issue at 1x zoom, there it works with or without double
> buffering.
>
> The crash log says the crash is in the EventQueue, in C native code (lines
> with lowercase j are interpreted Java code):
>
> C  [libawt.so+0x62cce]  IntRgbBilinearTransformHelper+0xce
> C  [libawt.so+0x7a903] Java_sun_java2d_loops_Transfor
> mHelper_Transform+0xe73
> j sun.java2d.loops.TransformHelper.Transform(Lsun/java2d/
> loops/MaskBlit;Lsun/java2d/SurfaceData;Lsun/java2d/
> SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;
> Ljava/awt/geom/AffineTransform;IIIIIIIII[III)V+0
> j sun.java2d.pipe.DrawImage.renderImageXform(Lsun/java2d/SunGr
> aphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
> IIIIILjava/awt/Color;)V+542
> j sun.java2d.pipe.DrawImage.transformImage(Lsun/java2d/SunGrap
> hics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
> IIIIILjava/awt/Color;)V+120
> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;)Z+467
> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/
> ImageObserver;)Z+27
> j sun.java2d.pipe.ValidatePipe.scaleImage(Lsun/java2d/SunGraph
> ics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/
> image/ImageObserver;)Z+33
> ...
>
> The crash happens with the Oracle JRE.
> With OpenJDK (1.8.0_162) creating a 3 GB RGB image leads to 'Out of
> Memory', independent of whether double buffering is on.
> With OpenJDK, there are also problems with 8-bit images; I can't do any
> operations on a 1.5 GB image, I always get 'Out of Memory' even with 12 GB
> memory for ImageJ. With a somewhat smaller image where it is stable (1.1
> GB), "Monitor Memory" does not go above 2.3 GB (image plus undo buffer), so
> there is no legitimate reason for "Out of Memory".
>
> The bottom line:
>
> It seems that Java does not work well with images above 1 GB at least
> under Linux. Probably it is not worthwhile investing much effort until the
> Oracle & OpenJDK developers fix these issues.
>
>
> Michael
> ________________________________________________________________
> On 26/04/2018 17:39, Kenneth Sloan wrote:
>
>> This line of code leads me to ask: are there *demonstrated* negatives to
>> using double-buffering *all* the time?
>> --
>> Kenneth Sloan
>> [hidden email]
>> Vision is the art of seeing what is invisible to others.
>>
>>
>>
>>
>>
>> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>>>
>>> Hi Aryeh,
>>>
>>> The latest ImageJ daily build (1.52b7) uses double buffering to work
>>> around the Linux problem with large images not showing at low
>>> magnification. This solution, proposed by Michael Schmid, is described
>>> below.
>>>
>>> -wayne
>>>
>>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]>
>>>> wrote:
>>>>
>>>> Hi Wayne,
>>>>
>>>> concerning the large images not visible under Linux:
>>>>
>>>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>>>> In case there is a ROI, ImageJ uses double buffering.
>>>> And the problem indeed goes away if one uses double buffering under
>>>> Linux, also in absence of a ROI:
>>>>
>>>> This is the modification I did (ImageCanvas, line 210):
>>>>                 //double buffering to avoid flickering of ROIs, also
>>>> works around a Linux problem of large images not showing at low
>>>> magnification
>>>>                 if (roi!=null || overlay!=null || showAllOverlay!=null
>>>> || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>>>
>>>> The limit "magnification<0.25" is arbitrary. In my experience with a
>>>> 700 MB image the problem was already gone at magnifications like 0.1, but
>>>> it does not hurt to set the limit higher. Since it is unclear what causes
>>>> the bug and when it can appear, you could also set the limit to 1.0.
>>>>
>>>> By the way, for a reason that I don't understand, without double
>>>> buffering there can be also an unexpected "Out of Memory" failure.
>>>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp)
>>>> throws the current ImageJ out of memory under my Linux, but after the patch
>>>> it works (8 GBytes for ImageJ in both cases).
>>>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl
>>>> image.
>>>> I guess that the 'Out of memory' is related to the Java/Linux Window
>>>> Manager bug that makes the image not display as it should.
>>>>
>>>
>>>
>>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>>>
>>>> Thanks to Michael and Thorsten for their replies.
>>>>
>>>> I can odd a discovery.  If I draw an ROI on the image that I loaded,
>>>> then the image appears inside that ROI.
>>>> If I then remove the ROi, the entire image appears -- quickly.
>>>>
>>>> I tried this in a script
>>>>
>>>> inputImp = ImagePlus(inputPath)
>>>> inputImp.show()
>>>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>>>> inputImp.setRoi(0,0,width,height)
>>>>
>>>> Setting the ROI caused the image to be displayed.
>>>> With that line -- I only had a white display.
>>>> I verified this on two systems (both Ubuntu 16.04).
>>>>
>>>> Another interesting thing - If I have ROIs in the roimanager, and I set
>>>> "show all" the overlay will appear correctly on the image. If I then
>>>> deselect show all, the overlay will remain on the image. If I then draw an
>>>> ROI on that image, the overly will disappear under the ROI. If I then
>>>> deselect the ROI, the overlay will disappear from the entire image.
>>>> Whatever draws the image when an ROI is created or deselected seems to
>>>> do that quickly and correctly.
>>>>
>>>> It still happens that the computer will be very slow while loading or
>>>> just after loading a large image. Once that is passed, then update is fast
>>>> when drawing an ROI.
>>>>
>>>> Maybe this provides a hint of  what is happening.
>>>>
>>>> Best regards
>>>> --aryeh
>>>>
>>>>
>>>> On 24/04/2018 22:30, Michael Schmid wrote:
>>>>
>>>>> Hi Aryeh,
>>>>>
>>>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
>>>>> graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of
>>>>> 6.2% or larger. Sometimes it also works with 4.2%.
>>>>> It remains white or does not update the screen at lower magnifications.
>>>>>
>>>>> Scrolling is very sluggish at 6.2%, it works better at higher
>>>>> magnifications.
>>>>>
>>>>> I tried saving the file as png and using other programs:
>>>>> ImageViewer and ImageMagick crash.
>>>>> Okular has the same problem as ImageJ, it shows it only when zooming
>>>>> in from the full image area.
>>>>>
>>>>> So I guess that it is a problem of the Linux Windows Manager.
>>>>>
>>>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I
>>>>> guess that these programs handle the zooming by themselves, not via the
>>>>> Linux Windows Manager or graphics.
>>>>>
>>>>> Michael
>>>>> ________________________________________________________________
>>>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>>>
>>>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
>>>>>> 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are
>>>>>> loaded but not displayed properly. The windows is white. The image is
>>>>>> there, but cannot be seen. Sometimes, after this happens, all subsequent
>>>>>> image windows will be white -- even small ones. BUt other times, the small
>>>>>> windows will be ok and only the large windows will be affected. If I run
>>>>>> Image>Scale... by 0.5 in each dimension, the downsized image will appear
>>>>>> and be displayed correctly..
>>>>>> If the cursor in moved over the large white window, the pixels values
>>>>>> are displayed in the main ImageJ window.
>>>>>>
>>>>>> It seems that the images are created and valid, but the windows are
>>>>>> not refreshed properly.
>>>>>>
>>>>>> More information:
>>>>>>
>>>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>>>
>>>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra
>>>>>> update sites selected.
>>>>>>
>>>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not
>>>>>> Fiji specific.
>>>>>>
>>>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF
>>>>>> inside).
>>>>>>
>>>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred
>>>>>> with both the default display drivers and the latest Nvidia display
>>>>>> drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics
>>>>>> card.
>>>>>>
>>>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
>>>>>> 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>>>
>>>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu
>>>>>> 16.04.
>>>>>>
>>>>>> I am sure that there are many people running Fiji/ImageJ on lInux
>>>>>> machines and loading large images.
>>>>>> What am I doing wrong?
>>>>>>
>>>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>>>
>>>>>> Thanks in advance
>>>>>> --aryeh
>>>>>>
>>>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Curtis & Everyone,

ok, I tried creating a 0.6 Gigapixel (2.4 GByte) RGB image with newer
versions of Java (double buffering on):

Oracle jre 1.8.0_172: crashes, same crash dump as Oracle Java 1.8.0_112
Oracle jre-10.0.1: out of memory (same problem as OpenJDK 1.8.0_162, but
I can't say whether it is for the same reason)

---
Coming back to Kenneth's yesterday question - I note that it remained
essentially unanswered.

A disadvantage of double buffering is higher memory consumption. These
days, I think one does not feel it any more since the extra memory
needed is not much by today's standards (I guess at most the memory
needed for the pixels at the screen, 33 MB for a full-size image on a
UHD (4k) display. It only makes a difference if one has very many open
windows.


Michael
________________________________________________________________
On 26/04/2018 23:43, Curtis Rueden wrote:

> Hi Michael,
>
>> It seems that Java does not work well with images above 1 GB at least
>> under Linux. Probably it is not worthwhile investing much effort until
>> the Oracle & OpenJDK developers fix these issues.
>
> Have you tested Java 9 and 10 as well?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Thu, Apr 26, 2018 at 7:34 PM, Michael Schmid <[hidden email]>
> wrote:
>
>> Hi Kenneth,
>>
>> well, I tried to be on the conservative side with my suggestion for double
>> buffering, but maybe not conservative enough:
>> I just discovered that ImageJ (actually Java) with double buffering
>> crashes when creating an RGB image of 20000*40000 on my computer (3 GB
>> image; 8 or 12 GB reserved for ImageJ):
>> Oracle Java 1.8.0_112 [64-bit]; Linux 4.4.0-119-generic; 8098MB (75%)
>> The threshold for crashing seems to be 2 GB image size (0.5 gigapixels).
>>
>> Without double buffering, it does not show the image at small zoom
>> factors, but at least it does not crash as long as I create no ROI. It
>> crashes if I create a ROI at small zoom factors (creating a ROI switches to
>> double buffering). Increasing the memory for ImageJ to 12 GB does not help.
>>
>> With double buffering, ImageJ crashes immediately when it tries to show
>> the image.
>>
>> It is not an issue at 1x zoom, there it works with or without double
>> buffering.
>>
>> The crash log says the crash is in the EventQueue, in C native code (lines
>> with lowercase j are interpreted Java code):
>>
>> C  [libawt.so+0x62cce]  IntRgbBilinearTransformHelper+0xce
>> C  [libawt.so+0x7a903] Java_sun_java2d_loops_Transfor
>> mHelper_Transform+0xe73
>> j sun.java2d.loops.TransformHelper.Transform(Lsun/java2d/
>> loops/MaskBlit;Lsun/java2d/SurfaceData;Lsun/java2d/
>> SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;
>> Ljava/awt/geom/AffineTransform;IIIIIIIII[III)V+0
>> j sun.java2d.pipe.DrawImage.renderImageXform(Lsun/java2d/SunGr
>> aphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>> IIIIILjava/awt/Color;)V+542
>> j sun.java2d.pipe.DrawImage.transformImage(Lsun/java2d/SunGrap
>> hics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>> IIIIILjava/awt/Color;)V+120
>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;)Z+467
>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/
>> ImageObserver;)Z+27
>> j sun.java2d.pipe.ValidatePipe.scaleImage(Lsun/java2d/SunGraph
>> ics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/
>> image/ImageObserver;)Z+33
>> ...
>>
>> The crash happens with the Oracle JRE.
>> With OpenJDK (1.8.0_162) creating a 3 GB RGB image leads to 'Out of
>> Memory', independent of whether double buffering is on.
>> With OpenJDK, there are also problems with 8-bit images; I can't do any
>> operations on a 1.5 GB image, I always get 'Out of Memory' even with 12 GB
>> memory for ImageJ. With a somewhat smaller image where it is stable (1.1
>> GB), "Monitor Memory" does not go above 2.3 GB (image plus undo buffer), so
>> there is no legitimate reason for "Out of Memory".
>>
>> The bottom line:
>>
>> It seems that Java does not work well with images above 1 GB at least
>> under Linux. Probably it is not worthwhile investing much effort until the
>> Oracle & OpenJDK developers fix these issues.
>>
>>
>> Michael
>> ________________________________________________________________
>> On 26/04/2018 17:39, Kenneth Sloan wrote:
>>
>>> This line of code leads me to ask: are there *demonstrated* negatives to
>>> using double-buffering *all* the time?
>>> --
>>> Kenneth Sloan
>>> [hidden email]
>>> Vision is the art of seeing what is invisible to others.
>>>
>>>
>>>
>>>
>>>
>>> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>>>>
>>>> Hi Aryeh,
>>>>
>>>> The latest ImageJ daily build (1.52b7) uses double buffering to work
>>>> around the Linux problem with large images not showing at low
>>>> magnification. This solution, proposed by Michael Schmid, is described
>>>> below.
>>>>
>>>> -wayne
>>>>
>>>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Hi Wayne,
>>>>>
>>>>> concerning the large images not visible under Linux:
>>>>>
>>>>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>>>>> In case there is a ROI, ImageJ uses double buffering.
>>>>> And the problem indeed goes away if one uses double buffering under
>>>>> Linux, also in absence of a ROI:
>>>>>
>>>>> This is the modification I did (ImageCanvas, line 210):
>>>>>                  //double buffering to avoid flickering of ROIs, also
>>>>> works around a Linux problem of large images not showing at low
>>>>> magnification
>>>>>                  if (roi!=null || overlay!=null || showAllOverlay!=null
>>>>> || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>>>>
>>>>> The limit "magnification<0.25" is arbitrary. In my experience with a
>>>>> 700 MB image the problem was already gone at magnifications like 0.1, but
>>>>> it does not hurt to set the limit higher. Since it is unclear what causes
>>>>> the bug and when it can appear, you could also set the limit to 1.0.
>>>>>
>>>>> By the way, for a reason that I don't understand, without double
>>>>> buffering there can be also an unexpected "Out of Memory" failure.
>>>>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp)
>>>>> throws the current ImageJ out of memory under my Linux, but after the patch
>>>>> it works (8 GBytes for ImageJ in both cases).
>>>>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl
>>>>> image.
>>>>> I guess that the 'Out of memory' is related to the Java/Linux Window
>>>>> Manager bug that makes the image not display as it should.
>>>>>
>>>>
>>>>
>>>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>>>>
>>>>> Thanks to Michael and Thorsten for their replies.
>>>>>
>>>>> I can odd a discovery.  If I draw an ROI on the image that I loaded,
>>>>> then the image appears inside that ROI.
>>>>> If I then remove the ROi, the entire image appears -- quickly.
>>>>>
>>>>> I tried this in a script
>>>>>
>>>>> inputImp = ImagePlus(inputPath)
>>>>> inputImp.show()
>>>>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>>>>> inputImp.setRoi(0,0,width,height)
>>>>>
>>>>> Setting the ROI caused the image to be displayed.
>>>>> With that line -- I only had a white display.
>>>>> I verified this on two systems (both Ubuntu 16.04).
>>>>>
>>>>> Another interesting thing - If I have ROIs in the roimanager, and I set
>>>>> "show all" the overlay will appear correctly on the image. If I then
>>>>> deselect show all, the overlay will remain on the image. If I then draw an
>>>>> ROI on that image, the overly will disappear under the ROI. If I then
>>>>> deselect the ROI, the overlay will disappear from the entire image.
>>>>> Whatever draws the image when an ROI is created or deselected seems to
>>>>> do that quickly and correctly.
>>>>>
>>>>> It still happens that the computer will be very slow while loading or
>>>>> just after loading a large image. Once that is passed, then update is fast
>>>>> when drawing an ROI.
>>>>>
>>>>> Maybe this provides a hint of  what is happening.
>>>>>
>>>>> Best regards
>>>>> --aryeh
>>>>>
>>>>>
>>>>> On 24/04/2018 22:30, Michael Schmid wrote:
>>>>>
>>>>>> Hi Aryeh,
>>>>>>
>>>>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
>>>>>> graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of
>>>>>> 6.2% or larger. Sometimes it also works with 4.2%.
>>>>>> It remains white or does not update the screen at lower magnifications.
>>>>>>
>>>>>> Scrolling is very sluggish at 6.2%, it works better at higher
>>>>>> magnifications.
>>>>>>
>>>>>> I tried saving the file as png and using other programs:
>>>>>> ImageViewer and ImageMagick crash.
>>>>>> Okular has the same problem as ImageJ, it shows it only when zooming
>>>>>> in from the full image area.
>>>>>>
>>>>>> So I guess that it is a problem of the Linux Windows Manager.
>>>>>>
>>>>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I
>>>>>> guess that these programs handle the zooming by themselves, not via the
>>>>>> Linux Windows Manager or graphics.
>>>>>>
>>>>>> Michael
>>>>>> ________________________________________________________________
>>>>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>>>>
>>>>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
>>>>>>> 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are
>>>>>>> loaded but not displayed properly. The windows is white. The image is
>>>>>>> there, but cannot be seen. Sometimes, after this happens, all subsequent
>>>>>>> image windows will be white -- even small ones. BUt other times, the small
>>>>>>> windows will be ok and only the large windows will be affected. If I run
>>>>>>> Image>Scale... by 0.5 in each dimension, the downsized image will appear
>>>>>>> and be displayed correctly..
>>>>>>> If the cursor in moved over the large white window, the pixels values
>>>>>>> are displayed in the main ImageJ window.
>>>>>>>
>>>>>>> It seems that the images are created and valid, but the windows are
>>>>>>> not refreshed properly.
>>>>>>>
>>>>>>> More information:
>>>>>>>
>>>>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>>>>
>>>>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra
>>>>>>> update sites selected.
>>>>>>>
>>>>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not
>>>>>>> Fiji specific.
>>>>>>>
>>>>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF
>>>>>>> inside).
>>>>>>>
>>>>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred
>>>>>>> with both the default display drivers and the latest Nvidia display
>>>>>>> drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics
>>>>>>> card.
>>>>>>>
>>>>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
>>>>>>> 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>>>>
>>>>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu
>>>>>>> 16.04.
>>>>>>>
>>>>>>> I am sure that there are many people running Fiji/ImageJ on lInux
>>>>>>> machines and loading large images.
>>>>>>> What am I doing wrong?
>>>>>>>
>>>>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>> --aryeh
>>>>>>>
>>>>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Aryeh Weiss]

On 27/04/2018 15:17, Michael Schmid wrote:
> Hi Curtis & Everyone,
>
> ok, I tried creating a 0.6 Gigapixel (2.4 GByte) RGB image with newer
> versions of Java (double buffering on):
>
> Oracle jre 1.8.0_172: crashes, same crash dump as Oracle Java 1.8.0_112
> Oracle jre-10.0.1: out of memory (same problem as OpenJDK 1.8.0_162,
> but I can't say whether it is for the same reason)
>
I tested large RGB images on my P50 (Ubuntu 16.04, 64GB RAM). The images
I used can be found at the following link:
https://drive.google.com/drive/folders/13Miix53V2nDUgy7Sv5a_sESdvag_831v?usp=sharing

There is a composite image, an RGB image that is scaled by 2x (in each
dimension, so it is 4x in size), and an RGB image that is scaled by
another 2x in each dimension (close to 8GB in size). There is a
sceenshot of how this image is displayed.

Up to 2 GB images work fine. Over 2GB , the program does not crash, but
the image is displayed incorrectly. The top part is ok, and then it
becomes a montage of image pieces. One of the images pointed to in teh
above link is a screenshot of that is seen. However, the image exists
correctly in memory, because I can downsize the image and recover the
correct original image.

On my mac (10.13.4, 16GB RAM), loading images larger than 2GB causes
Fiji to crash. Resizing images such that the result is over 2GB does not
cause a crash, but the result is cropped to 2GB.

I suspect that there is a 32bit signed variable somewhere that is
limiting the size of the file that can be displayed in a window.

Best regards
--aryeh

> ---
> Coming back to Kenneth's yesterday question - I note that it remained
> essentially unanswered.
>
> A disadvantage of double buffering is higher memory consumption. These
> days, I think one does not feel it any more since the extra memory
> needed is not much by today's standards (I guess at most the memory
> needed for the pixels at the screen, 33 MB for a full-size image on a
> UHD (4k) display. It only makes a difference if one has very many open
> windows.
>
>
> Michael
> ________________________________________________________________
> On 26/04/2018 23:43, Curtis Rueden wrote:
>> Hi Michael,
>>
>>> It seems that Java does not work well with images above 1 GB at least
>>> under Linux. Probably it is not worthwhile investing much effort until
>>> the Oracle & OpenJDK developers fix these issues.
>>
>> Have you tested Java 9 and 10 as well?
>>
>> Regards,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>> Did you know ImageJ has a forum? http://forum.imagej.net/
>>
>>
>> On Thu, Apr 26, 2018 at 7:34 PM, Michael Schmid
>> <[hidden email]>
>> wrote:
>>
>>> Hi Kenneth,
>>>
>>> well, I tried to be on the conservative side with my suggestion for
>>> double
>>> buffering, but maybe not conservative enough:
>>> I just discovered that ImageJ (actually Java) with double buffering
>>> crashes when creating an RGB image of 20000*40000 on my computer (3 GB
>>> image; 8 or 12 GB reserved for ImageJ):
>>> Oracle Java 1.8.0_112 [64-bit]; Linux 4.4.0-119-generic; 8098MB (75%)
>>> The threshold for crashing seems to be 2 GB image size (0.5
>>> gigapixels).
>>>
>>> Without double buffering, it does not show the image at small zoom
>>> factors, but at least it does not crash as long as I create no ROI. It
>>> crashes if I create a ROI at small zoom factors (creating a ROI
>>> switches to
>>> double buffering). Increasing the memory for ImageJ to 12 GB does
>>> not help.
>>>
>>> With double buffering, ImageJ crashes immediately when it tries to show
>>> the image.
>>>
>>> It is not an issue at 1x zoom, there it works with or without double
>>> buffering.
>>>
>>> The crash log says the crash is in the EventQueue, in C native code
>>> (lines
>>> with lowercase j are interpreted Java code):
>>>
>>> C  [libawt.so+0x62cce]  IntRgbBilinearTransformHelper+0xce
>>> C  [libawt.so+0x7a903] Java_sun_java2d_loops_Transfor
>>> mHelper_Transform+0xe73
>>> j sun.java2d.loops.TransformHelper.Transform(Lsun/java2d/
>>> loops/MaskBlit;Lsun/java2d/SurfaceData;Lsun/java2d/
>>> SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;
>>> Ljava/awt/geom/AffineTransform;IIIIIIIII[III)V+0
>>> j sun.java2d.pipe.DrawImage.renderImageXform(Lsun/java2d/SunGr
>>> aphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>>> IIIIILjava/awt/Color;)V+542
>>> j sun.java2d.pipe.DrawImage.transformImage(Lsun/java2d/SunGrap
>>> hics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>>> IIIIILjava/awt/Color;)V+120
>>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;)Z+467
>>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/
>>> ImageObserver;)Z+27
>>> j sun.java2d.pipe.ValidatePipe.scaleImage(Lsun/java2d/SunGraph
>>> ics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/
>>> image/ImageObserver;)Z+33
>>> ...
>>>
>>> The crash happens with the Oracle JRE.
>>> With OpenJDK (1.8.0_162) creating a 3 GB RGB image leads to 'Out of
>>> Memory', independent of whether double buffering is on.
>>> With OpenJDK, there are also problems with 8-bit images; I can't do any
>>> operations on a 1.5 GB image, I always get 'Out of Memory' even with
>>> 12 GB
>>> memory for ImageJ. With a somewhat smaller image where it is stable
>>> (1.1
>>> GB), "Monitor Memory" does not go above 2.3 GB (image plus undo
>>> buffer), so
>>> there is no legitimate reason for "Out of Memory".
>>>
>>> The bottom line:
>>>
>>> It seems that Java does not work well with images above 1 GB at least
>>> under Linux. Probably it is not worthwhile investing much effort
>>> until the
>>> Oracle & OpenJDK developers fix these issues.
>>>
>>>
>>> Michael
>>> ________________________________________________________________
>>> On 26/04/2018 17:39, Kenneth Sloan wrote:
>>>
>>>> This line of code leads me to ask: are there *demonstrated*
>>>> negatives to
>>>> using double-buffering *all* the time?
>>>> --
>>>> Kenneth Sloan
>>>> [hidden email]
>>>> Vision is the art of seeing what is invisible to others.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>>>>>
>>>>> Hi Aryeh,
>>>>>
>>>>> The latest ImageJ daily build (1.52b7) uses double buffering to work
>>>>> around the Linux problem with large images not showing at low
>>>>> magnification. This solution, proposed by Michael Schmid, is
>>>>> described
>>>>> below.
>>>>>
>>>>> -wayne
>>>>>
>>>>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Wayne,
>>>>>>
>>>>>> concerning the large images not visible under Linux:
>>>>>>
>>>>>> Aryeh's hint with the problem disappearing with a ROI was a good
>>>>>> one:
>>>>>> In case there is a ROI, ImageJ uses double buffering.
>>>>>> And the problem indeed goes away if one uses double buffering under
>>>>>> Linux, also in absence of a ROI:
>>>>>>
>>>>>> This is the modification I did (ImageCanvas, line 210):
>>>>>>                  //double buffering to avoid flickering of ROIs,
>>>>>> also
>>>>>> works around a Linux problem of large images not showing at low
>>>>>> magnification
>>>>>>                  if (roi!=null || overlay!=null ||
>>>>>> showAllOverlay!=null
>>>>>> || Prefs.paintDoubleBuffered || (IJ.isLinux() &&
>>>>>> magnification<0.25)) {
>>>>>>
>>>>>> The limit "magnification<0.25" is arbitrary. In my experience with a
>>>>>> 700 MB image the problem was already gone at magnifications like
>>>>>> 0.1, but
>>>>>> it does not hurt to set the limit higher. Since it is unclear
>>>>>> what causes
>>>>>> the bug and when it can appear, you could also set the limit to 1.0.
>>>>>>
>>>>>> By the way, for a reason that I don't understand, without double
>>>>>> buffering there can be also an unexpected "Out of Memory" failure.
>>>>>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a
>>>>>> ramp)
>>>>>> throws the current ImageJ out of memory under my Linux, but after
>>>>>> the patch
>>>>>> it works (8 GBytes for ImageJ in both cases).
>>>>>> In some cases, "Out of memory" can even appear when showing a 1.4
>>>>>> Gpxl
>>>>>> image.
>>>>>> I guess that the 'Out of memory' is related to the Java/Linux Window
>>>>>> Manager bug that makes the image not display as it should.
>>>>>>
>>>>>
>>>>>
>>>>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>>>>>
>>>>>> Thanks to Michael and Thorsten for their replies.
>>>>>>
>>>>>> I can odd a discovery.  If I draw an ROI on the image that I loaded,
>>>>>> then the image appears inside that ROI.
>>>>>> If I then remove the ROi, the entire image appears -- quickly.
>>>>>>
>>>>>> I tried this in a script
>>>>>>
>>>>>> inputImp = ImagePlus(inputPath)
>>>>>> inputImp.show()
>>>>>> [width, height, nChannels, nSlices, nFrames] =
>>>>>> inputImp.getDimensions()
>>>>>> inputImp.setRoi(0,0,width,height)
>>>>>>
>>>>>> Setting the ROI caused the image to be displayed.
>>>>>> With that line -- I only had a white display.
>>>>>> I verified this on two systems (both Ubuntu 16.04).
>>>>>>
>>>>>> Another interesting thing - If I have ROIs in the roimanager, and
>>>>>> I set
>>>>>> "show all" the overlay will appear correctly on the image. If I then
>>>>>> deselect show all, the overlay will remain on the image. If I
>>>>>> then draw an
>>>>>> ROI on that image, the overly will disappear under the ROI. If I
>>>>>> then
>>>>>> deselect the ROI, the overlay will disappear from the entire image.
>>>>>> Whatever draws the image when an ROI is created or deselected
>>>>>> seems to
>>>>>> do that quickly and correctly.
>>>>>>
>>>>>> It still happens that the computer will be very slow while
>>>>>> loading or
>>>>>> just after loading a large image. Once that is passed, then
>>>>>> update is fast
>>>>>> when drawing an ROI.
>>>>>>
>>>>>> Maybe this provides a hint of  what is happening.
>>>>>>
>>>>>> Best regards
>>>>>> --aryeh
>>>>>>
>>>>>>
>>>>>> On 24/04/2018 22:30, Michael Schmid wrote:
>>>>>>
>>>>>>> Hi Aryeh,
>>>>>>>
>>>>>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
>>>>>>> graphics) a 22655 x 32794 pixel image displays correctly at zoom
>>>>>>> levels of
>>>>>>> 6.2% or larger. Sometimes it also works with 4.2%.
>>>>>>> It remains white or does not update the screen at lower
>>>>>>> magnifications.
>>>>>>>
>>>>>>> Scrolling is very sluggish at 6.2%, it works better at higher
>>>>>>> magnifications.
>>>>>>>
>>>>>>> I tried saving the file as png and using other programs:
>>>>>>> ImageViewer and ImageMagick crash.
>>>>>>> Okular has the same problem as ImageJ, it shows it only when
>>>>>>> zooming
>>>>>>> in from the full image area.
>>>>>>>
>>>>>>> So I guess that it is a problem of the Linux Windows Manager.
>>>>>>>
>>>>>>> GIMP shows it, but becomes extremely slow. Firefox has no
>>>>>>> problem. I
>>>>>>> guess that these programs handle the zooming by themselves, not
>>>>>>> via the
>>>>>>> Linux Windows Manager or graphics.
>>>>>>>
>>>>>>> Michael
>>>>>>> ________________________________________________________________
>>>>>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>>>>>
>>>>>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
>>>>>>>> 16.04 on two machines), large images (eg, 800MB , 22655 x 32794
>>>>>>>> pixels) are
>>>>>>>> loaded but not displayed properly. The windows is white. The
>>>>>>>> image is
>>>>>>>> there, but cannot be seen. Sometimes, after this happens, all
>>>>>>>> subsequent
>>>>>>>> image windows will be white -- even small ones. BUt other
>>>>>>>> times, the small
>>>>>>>> windows will be ok and only the large windows will be affected.
>>>>>>>> If I run
>>>>>>>> Image>Scale... by 0.5 in each dimension, the downsized image
>>>>>>>> will appear
>>>>>>>> and be displayed correctly..
>>>>>>>> If the cursor in moved over the large white window, the pixels
>>>>>>>> values
>>>>>>>> are displayed in the main ImageJ window.
>>>>>>>>
>>>>>>>> It seems that the images are created and valid, but the windows
>>>>>>>> are
>>>>>>>> not refreshed properly.
>>>>>>>>
>>>>>>>> More information:
>>>>>>>>
>>>>>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>>>>>
>>>>>>>> 2. Problem occurs even with a fresh download of Fiji, with no
>>>>>>>> extra
>>>>>>>> update sites selected.
>>>>>>>>
>>>>>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is
>>>>>>>> not
>>>>>>>> Fiji specific.
>>>>>>>>
>>>>>>>> 4. The images that are being loaded are either TIFF or ZIP
>>>>>>>> (with TIFF
>>>>>>>> inside).
>>>>>>>>
>>>>>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred
>>>>>>>> with both the default display drivers and the latest Nvidia
>>>>>>>> display
>>>>>>>> drivers. The other system is a Lenovo P50 with a Quadro M2000M
>>>>>>>> graphics
>>>>>>>> card.
>>>>>>>>
>>>>>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
>>>>>>>> 1.8_171, and probably a few others along the way. They all
>>>>>>>> behaved the same.
>>>>>>>>
>>>>>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and
>>>>>>>> Ubuntu
>>>>>>>> 16.04.
>>>>>>>>
>>>>>>>> I am sure that there are many people running Fiji/ImageJ on lInux
>>>>>>>> machines and loading large images.
>>>>>>>> What am I doing wrong?
>>>>>>>>
>>>>>>>> By the way, these same images work fine on my macbook (macos
>>>>>>>> 10.13.4).
>>>>>>>>
>>>>>>>> Thanks in advance
>>>>>>>> --aryeh
>>>>>>>>

--
Aryeh Weiss
Faculty of Engineering
Bar Ilan University
Ramat Gan 52900 Israel

Ph:  972-3-5317638
FAX: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Wayne Rasband-2]

On Apr 29, 2018, at 4:29 AM, Aryeh Weiss <[hidden email]> wrote:

>
> On 27/04/2018 15:17, Michael Schmid wrote:
>> Hi Curtis & Everyone,
>>
>> ok, I tried creating a 0.6 Gigapixel (2.4 GByte) RGB image with newer versions of Java (double buffering on):
>>
>> Oracle jre 1.8.0_172: crashes, same crash dump as Oracle Java 1.8.0_112
>> Oracle jre-10.0.1: out of memory (same problem as OpenJDK 1.8.0_162, but I can't say whether it is for the same reason)
>>
> I tested large RGB images on my P50 (Ubuntu 16.04, 64GB RAM). The images I used can be found at the following link:
> https://drive.google.com/drive/folders/13Miix53V2nDUgy7Sv5a_sESdvag_831v?usp=sharing

You can duplicate this bug without downloading a 6GB image by using the File>New>Image command to open an RGB ramp image with width=23300, height=23300. Assuming Java does not crash, you will see an image like the following with a white band at the bottom. I tried Java 6, Java 8 and Java 10, and Java 6 was the least likely to crash. I suspect the band is the result of a Java bug.

-wayne

>
> There is a composite image, an RGB image that is scaled by 2x (in each dimension, so it is 4x in size), and an RGB image that is scaled by another 2x in each dimension (close to 8GB in size). There is a sceenshot of how this image is displayed.
>
> Up to 2 GB images work fine. Over 2GB , the program does not crash, but the image is displayed incorrectly. The top part is ok, and then it becomes a montage of image pieces. One of the images pointed to in teh above link is a screenshot of that is seen. However, the image exists correctly in memory, because I can downsize the image and recover the correct original image.
>
> On my mac (10.13.4, 16GB RAM), loading images larger than 2GB causes Fiji to crash. Resizing images such that the result is over 2GB does not cause a crash, but the result is cropped to 2GB.
>
> I suspect that there is a 32bit signed variable somewhere that is limiting the size of the file that can be displayed in a window.
>
> Best regards
> --aryeh
>
>> ---
>> Coming back to Kenneth's yesterday question - I note that it remained essentially unanswered.
>>
>> A disadvantage of double buffering is higher memory consumption. These days, I think one does not feel it any more since the extra memory needed is not much by today's standards (I guess at most the memory needed for the pixels at the screen, 33 MB for a full-size image on a UHD (4k) display. It only makes a difference if one has very many open windows.
>>
>>
>> Michael
>> ________________________________________________________________
>> On 26/04/2018 23:43, Curtis Rueden wrote:
>>> Hi Michael,
>>>
>>>> It seems that Java does not work well with images above 1 GB at least
>>>> under Linux. Probably it is not worthwhile investing much effort until
>>>> the Oracle & OpenJDK developers fix these issues.
>>>
>>> Have you tested Java 9 and 10 as well?
>>>
>>> Regards,
>>> Curtis
>>>
>>> --
>>> Curtis Rueden
>>> LOCI software architect - https://loci.wisc.edu/software
>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>> Did you know ImageJ has a forum? http://forum.imagej.net/
>>>
>>>
>>> On Thu, Apr 26, 2018 at 7:34 PM, Michael Schmid <[hidden email]>
>>> wrote:
>>>
>>>> Hi Kenneth,
>>>>
>>>> well, I tried to be on the conservative side with my suggestion for double
>>>> buffering, but maybe not conservative enough:
>>>> I just discovered that ImageJ (actually Java) with double buffering
>>>> crashes when creating an RGB image of 20000*40000 on my computer (3 GB
>>>> image; 8 or 12 GB reserved for ImageJ):
>>>> Oracle Java 1.8.0_112 [64-bit]; Linux 4.4.0-119-generic; 8098MB (75%)
>>>> The threshold for crashing seems to be 2 GB image size (0.5 gigapixels).
>>>>
>>>> Without double buffering, it does not show the image at small zoom
>>>> factors, but at least it does not crash as long as I create no ROI. It
>>>> crashes if I create a ROI at small zoom factors (creating a ROI switches to
>>>> double buffering). Increasing the memory for ImageJ to 12 GB does not help.
>>>>
>>>> With double buffering, ImageJ crashes immediately when it tries to show
>>>> the image.
>>>>
>>>> It is not an issue at 1x zoom, there it works with or without double
>>>> buffering.
>>>>
>>>> The crash log says the crash is in the EventQueue, in C native code (lines
>>>> with lowercase j are interpreted Java code):
>>>>
>>>> C  [libawt.so+0x62cce]  IntRgbBilinearTransformHelper+0xce
>>>> C  [libawt.so+0x7a903] Java_sun_java2d_loops_Transfor
>>>> mHelper_Transform+0xe73
>>>> j sun.java2d.loops.TransformHelper.Transform(Lsun/java2d/
>>>> loops/MaskBlit;Lsun/java2d/SurfaceData;Lsun/java2d/
>>>> SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;
>>>> Ljava/awt/geom/AffineTransform;IIIIIIIII[III)V+0
>>>> j sun.java2d.pipe.DrawImage.renderImageXform(Lsun/java2d/SunGr
>>>> aphics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>>>> IIIIILjava/awt/Color;)V+542
>>>> j sun.java2d.pipe.DrawImage.transformImage(Lsun/java2d/SunGrap
>>>> hics2D;Ljava/awt/Image;Ljava/awt/geom/AffineTransform;
>>>> IIIIILjava/awt/Color;)V+120
>>>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>>>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;)Z+467
>>>> j sun.java2d.pipe.DrawImage.scaleImage(Lsun/java2d/SunGraphics
>>>> 2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/image/
>>>> ImageObserver;)Z+27
>>>> j sun.java2d.pipe.ValidatePipe.scaleImage(Lsun/java2d/SunGraph
>>>> ics2D;Ljava/awt/Image;IIIIIIIILjava/awt/Color;Ljava/awt/
>>>> image/ImageObserver;)Z+33
>>>> ...
>>>>
>>>> The crash happens with the Oracle JRE.
>>>> With OpenJDK (1.8.0_162) creating a 3 GB RGB image leads to 'Out of
>>>> Memory', independent of whether double buffering is on.
>>>> With OpenJDK, there are also problems with 8-bit images; I can't do any
>>>> operations on a 1.5 GB image, I always get 'Out of Memory' even with 12 GB
>>>> memory for ImageJ. With a somewhat smaller image where it is stable (1.1
>>>> GB), "Monitor Memory" does not go above 2.3 GB (image plus undo buffer), so
>>>> there is no legitimate reason for "Out of Memory".
>>>>
>>>> The bottom line:
>>>>
>>>> It seems that Java does not work well with images above 1 GB at least
>>>> under Linux. Probably it is not worthwhile investing much effort until the
>>>> Oracle & OpenJDK developers fix these issues.
>>>>
>>>>
>>>> Michael
>>>> ________________________________________________________________
>>>> On 26/04/2018 17:39, Kenneth Sloan wrote:
>>>>
>>>>> This line of code leads me to ask: are there *demonstrated* negatives to
>>>>> using double-buffering *all* the time?
>>>>> --
>>>>> Kenneth Sloan
>>>>> [hidden email]
>>>>> Vision is the art of seeing what is invisible to others.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 26 Apr 2018, at 08:38 , Wayne Rasband <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Aryeh,
>>>>>>
>>>>>> The latest ImageJ daily build (1.52b7) uses double buffering to work
>>>>>> around the Linux problem with large images not showing at low
>>>>>> magnification. This solution, proposed by Michael Schmid, is described
>>>>>> below.
>>>>>>
>>>>>> -wayne
>>>>>>
>>>>>> On Apr 26, 2018, at 5:46 AM, Michael Schmid <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Wayne,
>>>>>>>
>>>>>>> concerning the large images not visible under Linux:
>>>>>>>
>>>>>>> Aryeh's hint with the problem disappearing with a ROI was a good one:
>>>>>>> In case there is a ROI, ImageJ uses double buffering.
>>>>>>> And the problem indeed goes away if one uses double buffering under
>>>>>>> Linux, also in absence of a ROI:
>>>>>>>
>>>>>>> This is the modification I did (ImageCanvas, line 210):
>>>>>>>                  //double buffering to avoid flickering of ROIs, also
>>>>>>> works around a Linux problem of large images not showing at low
>>>>>>> magnification
>>>>>>>                  if (roi!=null || overlay!=null || showAllOverlay!=null
>>>>>>> || Prefs.paintDoubleBuffered || (IJ.isLinux() && magnification<0.25)) {
>>>>>>>
>>>>>>> The limit "magnification<0.25" is arbitrary. In my experience with a
>>>>>>> 700 MB image the problem was already gone at magnifications like 0.1, but
>>>>>>> it does not hurt to set the limit higher. Since it is unclear what causes
>>>>>>> the bug and when it can appear, you could also set the limit to 1.0.
>>>>>>>
>>>>>>> By the way, for a reason that I don't understand, without double
>>>>>>> buffering there can be also an unexpected "Out of Memory" failure.
>>>>>>> Creating a 1.7 Gpxl, 60000x30000 pxl 8-bit image (filled with a ramp)
>>>>>>> throws the current ImageJ out of memory under my Linux, but after the patch
>>>>>>> it works (8 GBytes for ImageJ in both cases).
>>>>>>> In some cases, "Out of memory" can even appear when showing a 1.4 Gpxl
>>>>>>> image.
>>>>>>> I guess that the 'Out of memory' is related to the Java/Linux Window
>>>>>>> Manager bug that makes the image not display as it should.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 25, 2018, at 5:46 AM, Aryeh Weiss <[hidden email]> wrote:
>>>>>>>
>>>>>>> Thanks to Michael and Thorsten for their replies.
>>>>>>>
>>>>>>> I can odd a discovery.  If I draw an ROI on the image that I loaded,
>>>>>>> then the image appears inside that ROI.
>>>>>>> If I then remove the ROi, the entire image appears -- quickly.
>>>>>>>
>>>>>>> I tried this in a script
>>>>>>>
>>>>>>> inputImp = ImagePlus(inputPath)
>>>>>>> inputImp.show()
>>>>>>> [width, height, nChannels, nSlices, nFrames] = inputImp.getDimensions()
>>>>>>> inputImp.setRoi(0,0,width,height)
>>>>>>>
>>>>>>> Setting the ROI caused the image to be displayed.
>>>>>>> With that line -- I only had a white display.
>>>>>>> I verified this on two systems (both Ubuntu 16.04).
>>>>>>>
>>>>>>> Another interesting thing - If I have ROIs in the roimanager, and I set
>>>>>>> "show all" the overlay will appear correctly on the image. If I then
>>>>>>> deselect show all, the overlay will remain on the image. If I then draw an
>>>>>>> ROI on that image, the overly will disappear under the ROI. If I then
>>>>>>> deselect the ROI, the overlay will disappear from the entire image.
>>>>>>> Whatever draws the image when an ROI is created or deselected seems to
>>>>>>> do that quickly and correctly.
>>>>>>>
>>>>>>> It still happens that the computer will be very slow while loading or
>>>>>>> just after loading a large image. Once that is passed, then update is fast
>>>>>>> when drawing an ROI.
>>>>>>>
>>>>>>> Maybe this provides a hint of  what is happening.
>>>>>>>
>>>>>>> Best regards
>>>>>>> --aryeh
>>>>>>>
>>>>>>>
>>>>>>> On 24/04/2018 22:30, Michael Schmid wrote:
>>>>>>>
>>>>>>>> Hi Aryeh,
>>>>>>>>
>>>>>>>> on my Ubuntu 16.04 (16 GB RAM, 8 GB for ImageJ, i7 with built-in
>>>>>>>> graphics) a 22655 x 32794 pixel image displays correctly at zoom levels of
>>>>>>>> 6.2% or larger. Sometimes it also works with 4.2%.
>>>>>>>> It remains white or does not update the screen at lower magnifications.
>>>>>>>>
>>>>>>>> Scrolling is very sluggish at 6.2%, it works better at higher
>>>>>>>> magnifications.
>>>>>>>>
>>>>>>>> I tried saving the file as png and using other programs:
>>>>>>>> ImageViewer and ImageMagick crash.
>>>>>>>> Okular has the same problem as ImageJ, it shows it only when zooming
>>>>>>>> in from the full image area.
>>>>>>>>
>>>>>>>> So I guess that it is a problem of the Linux Windows Manager.
>>>>>>>>
>>>>>>>> GIMP shows it, but becomes extremely slow. Firefox has no problem. I
>>>>>>>> guess that these programs handle the zooming by themselves, not via the
>>>>>>>> Linux Windows Manager or graphics.
>>>>>>>>
>>>>>>>> Michael
>>>>>>>> ________________________________________________________________
>>>>>>>> On 24/04/2018 20:05, Aryeh Weiss wrote:
>>>>>>>>
>>>>>>>>> When running ImageJ or Fiji on linux (Suse 13.1, Leap, and Ubuntu
>>>>>>>>> 16.04 on two machines), large images (eg, 800MB , 22655 x 32794 pixels) are
>>>>>>>>> loaded but not displayed properly. The windows is white. The image is
>>>>>>>>> there, but cannot be seen. Sometimes, after this happens, all subsequent
>>>>>>>>> image windows will be white -- even small ones. BUt other times, the small
>>>>>>>>> windows will be ok and only the large windows will be affected. If I run
>>>>>>>>> Image>Scale... by 0.5 in each dimension, the downsized image will appear
>>>>>>>>> and be displayed correctly..
>>>>>>>>> If the cursor in moved over the large white window, the pixels values
>>>>>>>>> are displayed in the main ImageJ window.
>>>>>>>>>
>>>>>>>>> It seems that the images are created and valid, but the windows are
>>>>>>>>> not refreshed properly.
>>>>>>>>>
>>>>>>>>> More information:
>>>>>>>>>
>>>>>>>>> 1 Systems have 16GB or 64 GB of memory.
>>>>>>>>>
>>>>>>>>> 2. Problem occurs even with a fresh download of Fiji, with no extra
>>>>>>>>> update sites selected.
>>>>>>>>>
>>>>>>>>> 3. Problem also occurs with ImageJ (not the Fiji distro). It is not
>>>>>>>>> Fiji specific.
>>>>>>>>>
>>>>>>>>> 4. The images that are being loaded are either TIFF or ZIP (with TIFF
>>>>>>>>> inside).
>>>>>>>>>
>>>>>>>>> 5. One system has an Nvidia GTX650 graphics card. Problem occurred
>>>>>>>>> with both the default display drivers and the latest Nvidia display
>>>>>>>>> drivers. The other system is a Lenovo P50 with a Quadro M2000M graphics
>>>>>>>>> card.
>>>>>>>>>
>>>>>>>>> 6. I tried  Java 1.8_66 (which is distributed with Fiji), 1.8_101,
>>>>>>>>> 1.8_171, and probably a few others along the way. They all behaved the same.
>>>>>>>>>
>>>>>>>>> 7. As noted  above, problem occurs with Suce 13.1, leap, and Ubuntu
>>>>>>>>> 16.04.
>>>>>>>>>
>>>>>>>>> I am sure that there are many people running Fiji/ImageJ on lInux
>>>>>>>>> machines and loading large images.
>>>>>>>>> What am I doing wrong?
>>>>>>>>>
>>>>>>>>> By the way, these same images work fine on my macbook (macos 10.13.4).
>>>>>>>>>
>>>>>>>>> Thanks in advance
>>>>>>>>> --aryeh

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html