Bug in image display

[Michel Julier]

Hello,

I am not a usual user of ImageJ, but I have just met a very strange bug.
I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).

I have a stack of 10 images, 1024x1024, in float 32 bit, with average
value 0.

When displaying the image at zoom 75%, when I scroll between the images
using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
It may not be obvious, but there are unexpected triangles on it.

When I click on the image (example: zooming, selecting,...), I get what
appears on "imagej_click2.png".
This time, there is no problem.

Making two screen captures and calculating the difference between them,
I obtain the strange triangles displayed on "imagej_diff2.png".

I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
here. I can provide it to anybody who might be interested.

Regards,
Michel Julier

[Joel Sheffield]

Does this happen when you view the stack at full size, i.e. not at 75%?  I
am wondering if you are getting some sort of "Moire" effect due to the
attempt of the system to interpolate from 1024 to 768.

Joel


On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier <[hidden email]> wrote:

> Hello,
>
> I am not a usual user of ImageJ, but I have just met a very strange bug.
> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>
> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
> value 0.
>
> When displaying the image at zoom 75%, when I scroll between the images
> using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
> It may not be obvious, but there are unexpected triangles on it.
>
> When I click on the image (example: zooming, selecting,...), I get what
> appears on "imagej_click2.png".
> This time, there is no problem.
>
> Making two screen captures and calculating the difference between them, I
> obtain the strange triangles displayed on "imagej_diff2.png".
>
> I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
> here. I can provide it to anybody who might be interested.
>
> Regards,
> Michel Julier
>
>

--


Joel B. Sheffield, Ph.D
Department of Biology
Temple University
Philadelphia, PA 19122
Voice: 215 204 8839
e-mail: [hidden email]
URL:  http://astro.temple.edu/~jbs

[Cammer, Michael]

I believe this has been discussed before in a thread a few months ago begun by Ved Sharma.  Look in the archives.

Our own experience is that Windows7, with many different video cards, has this behavior with ImageJ with Java 1.6 except with zooms simply divisible by two.  So 75% and 66% bad, 50% and 25% ok.  When people in my lab complain about this, I tell them to change the zoom or just ignor it.  I figure fractional zooms are just a convenience feature to see the overall image and if you want pixel-by-pixel clarity, look 1:1 or zoom up.

_________________________________________
Michael Cammer, Assistant Research Scientist
Skirball Institute of Biomolecular Medicine
Lab: [phone]  Cell: [phone]

________________________________________
From: ImageJ Interest Group [[hidden email]] On Behalf Of JOEL B. SHEFFIELD [[hidden email]]
Sent: Friday, December 30, 2011 9:52 AM
To: [hidden email]
Subject: Re: Bug in image display

Does this happen when you view the stack at full size, i.e. not at 75%?  I
am wondering if you are getting some sort of "Moire" effect due to the
attempt of the system to interpolate from 1024 to 768.

Joel


On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier <[hidden email]> wrote:

> Hello,
>
> I am not a usual user of ImageJ, but I have just met a very strange bug.
> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>
> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
> value 0.
>
> When displaying the image at zoom 75%, when I scroll between the images
> using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
> It may not be obvious, but there are unexpected triangles on it.
>
> When I click on the image (example: zooming, selecting,...), I get what
> appears on "imagej_click2.png".
> This time, there is no problem.
>
> Making two screen captures and calculating the difference between them, I
> obtain the strange triangles displayed on "imagej_diff2.png".
>
> I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
> here. I can provide it to anybody who might be interested.
>
> Regards,
> Michel Julier
>
>

--


Joel B. Sheffield, Ph.D
Department of Biology
Temple University
Philadelphia, PA 19122
Voice: 215 204 8839
e-mail: [hidden email]
URL:  http://astro.temple.edu/~jbs

------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================

[Michel Julier]

No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or 12.5%.
But there is a similar (although less obvious) phenomenon at 150%.
And there are also some hardly visible problem at 33.3% and 16.7%.
I am sending the images attached.

I did some screen captures, and I adjusted the color scale for enhancing
the differences.

I guess there are two different methods for calculating the fractional
zooms, one (good) when working on an image, and the other one (not as
good) when switching to another image in a stack.

This is not desirable, for instance at "33.3%" I would expect that each
screen pixel represents exactly 3x3 image pixels, not that the zoom
factor is 33.30000%, and I would expect that it is always displayed the
same way.

But what I get at 75% is worst than that, because it is not consistent.
I mean: when scrolling between the images in the stack, not all pixels
in one row are calculated in the same way.

So, looking at the image, I had the impression that there was some
strange problem with my image sensor, whereas it was with ImageJ.

Michel

Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :

> Does this happen when you view the stack at full size, i.e. not at 75%?  I
> am wondering if you are getting some sort of "Moire" effect due to the
> attempt of the system to interpolate from 1024 to 768.
>
> Joel
>
>
> On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>  wrote:
>
>> Hello,
>>
>> I am not a usual user of ImageJ, but I have just met a very strange bug.
>> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>
>> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
>> value 0.
>>
>> When displaying the image at zoom 75%, when I scroll between the images
>> using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
>> It may not be obvious, but there are unexpected triangles on it.
>>
>> When I click on the image (example: zooming, selecting,...), I get what
>> appears on "imagej_click2.png".
>> This time, there is no problem.
>>
>> Making two screen captures and calculating the difference between them, I
>> obtain the strange triangles displayed on "imagej_diff2.png".
>>
>> I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
>> here. I can provide it to anybody who might be interested.
>>
>> Regards,
>> Michel Julier

[Herbie-6]

Sorry Michel,

but I don't get the point of your complaint.

I guess you are speaking about display zoom and
not about scaling images (with interpolation). So
if it is diplay zoom, then the observed effects
are a purely cosmetic problem. Display zoom must
be fast, hence interpolation is nil or simple.

Making screen shots of display zoomed images is
somehow way off, especially if they are to serve
quantitative purposes. If they are made to only
demonstrate zoom effects its ok but why do you
care about display zoom effects?

However, there is an IJ-option "edit > options >
appearence > interpolate zoomed images". Did you
try that?

HTH

                  Herbie

          ------------------------
          <http://www.gluender.de>

>No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or 12.5%.
>But there is a similar (although less obvious) phenomenon at 150%.
>And there are also some hardly visible problem at 33.3% and 16.7%.
>I am sending the images attached.
>
>I did some screen captures, and I adjusted the
>color scale for enhancing the differences.
>
>I guess there are two different methods for
>calculating the fractional zooms, one (good)
>when working on an image, and the other one (not
>as good) when switching to another image in a
>stack.
>
>This is not desirable, for instance at "33.3%" I
>would expect that each screen pixel represents
>exactly 3x3 image pixels, not that the zoom
>factor is 33.30000%, and I would expect that it
>is always displayed the same way.
>
>But what I get at 75% is worst than that,
>because it is not consistent. I mean: when
>scrolling between the images in the stack, not
>all pixels in one row are calculated in the same
>way.
>
>So, looking at the image, I had the impression
>that there was some strange problem with my
>image sensor, whereas it was with ImageJ.
>
>Michel
>
>Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :
>>Does this happen when you view the stack at full size, i.e. not at 75%?  I
>>am wondering if you are getting some sort of "Moire" effect due to the
>>attempt of the system to interpolate from 1024 to 768.
>>
>>Joel
>>
>>
>>On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>  wrote:
>>
>>>Hello,
>>>
>>>I am not a usual user of ImageJ, but I have just met a very strange bug.
>>>I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>>
>>>I have a stack of 10 images, 1024x1024, in float 32 bit, with average
>>>value 0.
>>>
>>>When displaying the image at zoom 75%, when I scroll between the images
>>>using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
>>>It may not be obvious, but there are unexpected triangles on it.
>>>
>>>When I click on the image (example: zooming, selecting,...), I get what
>>>appears on "imagej_click2.png".
>>>This time, there is no problem.
>>>
>>>Making two screen captures and calculating the difference between them, I
>>>obtain the strange triangles displayed on "imagej_diff2.png".
>>>
>>>I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
>>>here. I can provide it to anybody who might be interested.
>>>
>>>Regards,
>>>Michel Julier

[Michel Julier]

Hello,

Yes, I am speaking about display zoom.
Yes, it is "purely cosmetic", but when working on images we may be
looking at "cosmetic" effects!
Why do I care: because I am tracking defects on some images, because
using several zoom levels is very convenient for that, because 75% is
sometimes the default zoom, and because it displays unexisting
separation lines on the images, as if the detector surface was uneven.

I understand that the algorithm must be fast, but to me this is not a
reason for being inconsistent.
It could be "take the closest pixel" or "plain average of the pixels in
this area", no problem.

But what appears here, is that there are those strange triangles, which
vertical, horizontal, and oblique lines. It looks like, on one side of
the triangle one algorithm is used, and on the other side another
algorithm is used. When I see these "y=x" lines, I even tend to believe
that there is a mistake somewhere, like a mixing between X and Y variables.

Using "interpolate zoomed images" works for zoom levels < 100%. However,
it also interpolates images for zoom levels > 100%, which is desirable
in some cases (like displaying a photo) but not in other cases (like
seeking bad pixels on a detector).


Well, if you tell me that the "fast" display code is using a zoom made
by Windows, and that the bug is actually in Windows, in my graphic card,
or in its driver, I would accept it.

But wait! I tried to display the same image in several programs (Paint
Shop Pro, Powerpoint 2003 and 2010, Firefox, Internet Explorer,
Paint.NET, Windows Photo Viewer), many of which I expect to use
accelerated display methods, and none of them show these strange
triangles. This is why I am not sure that the problem comes from
Windows. I do not have any easy way to check whether it comes from Java
for Windows.

Regards
Michel

Le 30/12/2011 19:26, Herbie a écrit :

> Sorry Michel,
>
> but I don't get the point of your complaint.
>
> I guess you are speaking about display zoom and not about scaling
> images (with interpolation). So if it is diplay zoom, then the
> observed effects are a purely cosmetic problem. Display zoom must be
> fast, hence interpolation is nil or simple.
>
> Making screen shots of display zoomed images is somehow way off,
> especially if they are to serve quantitative purposes. If they are
> made to only demonstrate zoom effects its ok but why do you care about
> display zoom effects?
>
> However, there is an IJ-option "edit > options > appearence >
> interpolate zoomed images". Did you try that?
>
> HTH
>
>                  Herbie
>
>          ------------------------
> <http://www.gluender.de>
>
>
>
>> No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or 12.5%.
>> But there is a similar (although less obvious) phenomenon at 150%.
>> And there are also some hardly visible problem at 33.3% and 16.7%.
>> I am sending the images attached.
>>
>> I did some screen captures, and I adjusted the color scale for
>> enhancing the differences.
>>
>> I guess there are two different methods for calculating the
>> fractional zooms, one (good) when working on an image, and the other
>> one (not as good) when switching to another image in a stack.
>>
>> This is not desirable, for instance at "33.3%" I would expect that
>> each screen pixel represents exactly 3x3 image pixels, not that the
>> zoom factor is 33.30000%, and I would expect that it is always
>> displayed the same way.
>>
>> But what I get at 75% is worst than that, because it is not
>> consistent. I mean: when scrolling between the images in the stack,
>> not all pixels in one row are calculated in the same way.
>>
>> So, looking at the image, I had the impression that there was some
>> strange problem with my image sensor, whereas it was with ImageJ.
>>
>> Michel
>>
>> Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :
>>> Does this happen when you view the stack at full size, i.e. not at
>>> 75%?  I
>>> am wondering if you are getting some sort of "Moire" effect due to the
>>> attempt of the system to interpolate from 1024 to 768.
>>>
>>> Joel
>>>
>>>
>>> On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>  wrote:
>>>
>>>> Hello,
>>>>
>>>> I am not a usual user of ImageJ, but I have just met a very strange
>>>> bug.
>>>> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>>>
>>>> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
>>>> value 0.
>>>>
>>>> When displaying the image at zoom 75%, when I scroll between the
>>>> images
>>>> using the horizontal scrollbar, I get what appears on
>>>> "imagej_scroll2.png".
>>>> It may not be obvious, but there are unexpected triangles on it.
>>>>
>>>> When I click on the image (example: zooming, selecting,...), I get
>>>> what
>>>> appears on "imagej_click2.png".
>>>> This time, there is no problem.
>>>>
>>>> Making two screen captures and calculating the difference between
>>>> them, I
>>>> obtain the strange triangles displayed on "imagej_diff2.png".
>>>>
>>>> I can reproduce the bug, but the file is big (40 Mo) so I cannot
>>>> send it
>>>> here. I can provide it to anybody who might be interested.
>>>>
>>>> Regards,
>>>> Michel Julier
>
>

[Michael Schmid]

Hi Michel,

I am not sure whether this leads us anywhere, but just to make sure:

As I understand it, it is a problem with stacks only, not with single images. Is this true?
Also, to make sure, is it correct that you have 'normal' stacks (in memory), not virtual stacks (on disk)?

It looks a bit like a race condition to me; maybe the graphics try to access the BufferedImage before it is finished? (though I don't see how this could happen).
A race condition would mean that the pattern seen in a given image should not be reproducible. Can you confirm this?

---
If it can't be fixed in ImageJ:
Would an option "zoom levels are a power of 2" help? Then the default zoom levels would be only 50%, 25% etc; and you won't get the problematic zoom ratios unless you set them directly or maximize the image.


Michael
________________________________________________________________
On Jan 2, 2012, at 10:13, Michel Julier wrote:

> Hello,
>
> Yes, I am speaking about display zoom.
> Yes, it is "purely cosmetic", but when working on images we may be looking at "cosmetic" effects!
> Why do I care: because I am tracking defects on some images, because using several zoom levels is very convenient for that, because 75% is sometimes the default zoom, and because it displays unexisting separation lines on the images, as if the detector surface was uneven.
>
> I understand that the algorithm must be fast, but to me this is not a reason for being inconsistent.
> It could be "take the closest pixel" or "plain average of the pixels in this area", no problem.
>
> But what appears here, is that there are those strange triangles, which vertical, horizontal, and oblique lines. It looks like, on one side of the triangle one algorithm is used, and on the other side another algorithm is used. When I see these "y=x" lines, I even tend to believe that there is a mistake somewhere, like a mixing between X and Y variables.
>
> Using "interpolate zoomed images" works for zoom levels < 100%. However, it also interpolates images for zoom levels > 100%, which is desirable in some cases (like displaying a photo) but not in other cases (like seeking bad pixels on a detector).
>
>
> Well, if you tell me that the "fast" display code is using a zoom made by Windows, and that the bug is actually in Windows, in my graphic card, or in its driver, I would accept it.
>
> But wait! I tried to display the same image in several programs (Paint Shop Pro, Powerpoint 2003 and 2010, Firefox, Internet Explorer, Paint.NET, Windows Photo Viewer), many of which I expect to use accelerated display methods, and none of them show these strange triangles. This is why I am not sure that the problem comes from Windows. I do not have any easy way to check whether it comes from Java for Windows.
>
> Regards
> Michel
>
> Le 30/12/2011 19:26, Herbie a écrit :
>> Sorry Michel,
>>
>> but I don't get the point of your complaint.
>>
>> I guess you are speaking about display zoom and not about scaling images (with interpolation). So if it is diplay zoom, then the observed effects are a purely cosmetic problem. Display zoom must be fast, hence interpolation is nil or simple.
>>
>> Making screen shots of display zoomed images is somehow way off, especially if they are to serve quantitative purposes. If they are made to only demonstrate zoom effects its ok but why do you care about display zoom effects?
>>
>> However, there is an IJ-option "edit > options > appearence > interpolate zoomed images". Did you try that?
>>
>> HTH
>>
>>                 Herbie
>>
>>         ------------------------
>> <http://www.gluender.de>
>>
>>
>>
>>> No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or 12.5%.
>>> But there is a similar (although less obvious) phenomenon at 150%.
>>> And there are also some hardly visible problem at 33.3% and 16.7%.
>>> I am sending the images attached.
>>>
>>> I did some screen captures, and I adjusted the color scale for enhancing the differences.
>>>
>>> I guess there are two different methods for calculating the fractional zooms, one (good) when working on an image, and the other one (not as good) when switching to another image in a stack.
>>>
>>> This is not desirable, for instance at "33.3%" I would expect that each screen pixel represents exactly 3x3 image pixels, not that the zoom factor is 33.30000%, and I would expect that it is always displayed the same way.
>>>
>>> But what I get at 75% is worst than that, because it is not consistent. I mean: when scrolling between the images in the stack, not all pixels in one row are calculated in the same way.
>>>
>>> So, looking at the image, I had the impression that there was some strange problem with my image sensor, whereas it was with ImageJ.
>>>
>>> Michel
>>>
>>> Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :
>>>> Does this happen when you view the stack at full size, i.e. not at 75%?  I
>>>> am wondering if you are getting some sort of "Moire" effect due to the
>>>> attempt of the system to interpolate from 1024 to 768.
>>>>
>>>> Joel
>>>>
>>>>
>>>> On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am not a usual user of ImageJ, but I have just met a very strange bug.
>>>>> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>>>>
>>>>> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
>>>>> value 0.
>>>>>
>>>>> When displaying the image at zoom 75%, when I scroll between the images
>>>>> using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
>>>>> It may not be obvious, but there are unexpected triangles on it.
>>>>>
>>>>> When I click on the image (example: zooming, selecting,...), I get what
>>>>> appears on "imagej_click2.png".
>>>>> This time, there is no problem.
>>>>>
>>>>> Making two screen captures and calculating the difference between them, I
>>>>> obtain the strange triangles displayed on "imagej_diff2.png".
>>>>>
>>>>> I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
>>>>> here. I can provide it to anybody who might be interested.
>>>>>
>>>>> Regards,
>>>>> Michel Julier
>>
>>

[Michel Julier]

Hello,

Yes, this is only with stacks, not with single images
Yes, they are normal stacks in memory

The pattern is perfectly reproducible.
It does not depend on the window position.
It does not depend either on which image was displayed before (the
previous one or the next one).

The option "only zoom power of 2" would be useful only if people find it
in the doc: maybe not so easy. Once you know it, you can learn to avoid
it anyway. The problem is that at first you don't know it.

I could however not reproduce the phenomenon on two other PCs, including
one with Windows 7 32-bit (which I use). So it seems to be
hardware-dependent. Maybe a bug in the graphic board, which for some
reason does not show up in other software:

OS:
     PC#1: Windows XP Pro 2002 SP3
     PC#2, MyPC: Windows 7 SP1 32 bits
CPU:
     PC#1: AMD Athlon XP2000+
     PC#2: Intel Core2
     MyPC: Intel Core2 Quad
Graphic board:
     PC#1: ATI Radeon 7000 Series (tried with driver from Microsoft and
from ATI)
     PC#2: ATI Radeon HD 2600 XT (driver from Microsoft)
     MyPC: Nvidia GeForce 9500 GT (driver from Nvidia, tried with two
versions)
Software:
     All PCs: ImageJ 1.46d + Java 1.6.0_20 (32 bits)
Results:
     PC#1, PC#2: no problem
     MyPC: strange triangles appear at zoom 75% and 150%


Regards,

Michel Julier


Le 02/01/2012 12:35, Michael Schmid a écrit :

> Hi Michel,
>
> I am not sure whether this leads us anywhere, but just to make sure:
>
> As I understand it, it is a problem with stacks only, not with single images. Is this true?
> Also, to make sure, is it correct that you have 'normal' stacks (in memory), not virtual stacks (on disk)?
>
> It looks a bit like a race condition to me; maybe the graphics try to access the BufferedImage before it is finished? (though I don't see how this could happen).
> A race condition would mean that the pattern seen in a given image should not be reproducible. Can you confirm this?
>
> ---
> If it can't be fixed in ImageJ:
> Would an option "zoom levels are a power of 2" help? Then the default zoom levels would be only 50%, 25% etc; and you won't get the problematic zoom ratios unless you set them directly or maximize the image.
>
>
> Michael
> ________________________________________________________________
> On Jan 2, 2012, at 10:13, Michel Julier wrote:
>
>> Hello,
>>
>> Yes, I am speaking about display zoom.
>> Yes, it is "purely cosmetic", but when working on images we may be looking at "cosmetic" effects!
>> Why do I care: because I am tracking defects on some images, because using several zoom levels is very convenient for that, because 75% is sometimes the default zoom, and because it displays unexisting separation lines on the images, as if the detector surface was uneven.
>>
>> I understand that the algorithm must be fast, but to me this is not a reason for being inconsistent.
>> It could be "take the closest pixel" or "plain average of the pixels in this area", no problem.
>>
>> But what appears here, is that there are those strange triangles, which vertical, horizontal, and oblique lines. It looks like, on one side of the triangle one algorithm is used, and on the other side another algorithm is used. When I see these "y=x" lines, I even tend to believe that there is a mistake somewhere, like a mixing between X and Y variables.
>>
>> Using "interpolate zoomed images" works for zoom levels<  100%. However, it also interpolates images for zoom levels>  100%, which is desirable in some cases (like displaying a photo) but not in other cases (like seeking bad pixels on a detector).
>>
>>
>> Well, if you tell me that the "fast" display code is using a zoom made by Windows, and that the bug is actually in Windows, in my graphic card, or in its driver, I would accept it.
>>
>> But wait! I tried to display the same image in several programs (Paint Shop Pro, Powerpoint 2003 and 2010, Firefox, Internet Explorer, Paint.NET, Windows Photo Viewer), many of which I expect to use accelerated display methods, and none of them show these strange triangles. This is why I am not sure that the problem comes from Windows. I do not have any easy way to check whether it comes from Java for Windows.
>>
>> Regards
>> Michel
>>
>> Le 30/12/2011 19:26, Herbie a écrit :
>>> Sorry Michel,
>>>
>>> but I don't get the point of your complaint.
>>>
>>> I guess you are speaking about display zoom and not about scaling images (with interpolation). So if it is diplay zoom, then the observed effects are a purely cosmetic problem. Display zoom must be fast, hence interpolation is nil or simple.
>>>
>>> Making screen shots of display zoomed images is somehow way off, especially if they are to serve quantitative purposes. If they are made to only demonstrate zoom effects its ok but why do you care about display zoom effects?
>>>
>>> However, there is an IJ-option "edit>  options>  appearence>  interpolate zoomed images". Did you try that?
>>>
>>> HTH
>>>
>>>                  Herbie
>>>
>>>          ------------------------
>>> <http://www.gluender.de>
>>>
>>>
>>>
>>>> No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or 12.5%.
>>>> But there is a similar (although less obvious) phenomenon at 150%.
>>>> And there are also some hardly visible problem at 33.3% and 16.7%.
>>>> I am sending the images attached.
>>>>
>>>> I did some screen captures, and I adjusted the color scale for enhancing the differences.
>>>>
>>>> I guess there are two different methods for calculating the fractional zooms, one (good) when working on an image, and the other one (not as good) when switching to another image in a stack.
>>>>
>>>> This is not desirable, for instance at "33.3%" I would expect that each screen pixel represents exactly 3x3 image pixels, not that the zoom factor is 33.30000%, and I would expect that it is always displayed the same way.
>>>>
>>>> But what I get at 75% is worst than that, because it is not consistent. I mean: when scrolling between the images in the stack, not all pixels in one row are calculated in the same way.
>>>>
>>>> So, looking at the image, I had the impression that there was some strange problem with my image sensor, whereas it was with ImageJ.
>>>>
>>>> Michel
>>>>
>>>> Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :
>>>>> Does this happen when you view the stack at full size, i.e. not at 75%?  I
>>>>> am wondering if you are getting some sort of "Moire" effect due to the
>>>>> attempt of the system to interpolate from 1024 to 768.
>>>>>
>>>>> Joel
>>>>>
>>>>>
>>>>> On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>   wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am not a usual user of ImageJ, but I have just met a very strange bug.
>>>>>> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>>>>>
>>>>>> I have a stack of 10 images, 1024x1024, in float 32 bit, with average
>>>>>> value 0.
>>>>>>
>>>>>> When displaying the image at zoom 75%, when I scroll between the images
>>>>>> using the horizontal scrollbar, I get what appears on "imagej_scroll2.png".
>>>>>> It may not be obvious, but there are unexpected triangles on it.
>>>>>>
>>>>>> When I click on the image (example: zooming, selecting,...), I get what
>>>>>> appears on "imagej_click2.png".
>>>>>> This time, there is no problem.
>>>>>>
>>>>>> Making two screen captures and calculating the difference between them, I
>>>>>> obtain the strange triangles displayed on "imagej_diff2.png".
>>>>>>
>>>>>> I can reproduce the bug, but the file is big (40 Mo) so I cannot send it
>>>>>> here. I can provide it to anybody who might be interested.
>>>>>>
>>>>>> Regards,
>>>>>> Michel Julier

[Michel Julier]

Hello everybody,

I found that my problem comes (probably) from a bug in my graphic board,
or (maybe) in the way Java uses it. I found this message that refers to
some similar problem:
http://coding.derkeiler.com/Archive/Java/comp.lang.java.programmer/2004-08/3135.html

I found a workaround this is OK for me: disabling DirectDraw.
In ImageJ.cfg, I just added the following option:
     -Dsun.java2d.noddraw=true

I may suggest that some option of this kind are proposed for people who
encounter display problems.

Thank you to Wayne for his help.

Michel Julier

Le 02/01/2012 14:49, Michel Julier a écrit :

> Hello,
>
> Yes, this is only with stacks, not with single images
> Yes, they are normal stacks in memory
>
> The pattern is perfectly reproducible.
> It does not depend on the window position.
> It does not depend either on which image was displayed before (the
> previous one or the next one).
>
> The option "only zoom power of 2" would be useful only if people find
> it in the doc: maybe not so easy. Once you know it, you can learn to
> avoid it anyway. The problem is that at first you don't know it.
>
> I could however not reproduce the phenomenon on two other PCs,
> including one with Windows 7 32-bit (which I use). So it seems to be
> hardware-dependent. Maybe a bug in the graphic board, which for some
> reason does not show up in other software:
>
> OS:
>     PC#1: Windows XP Pro 2002 SP3
>     PC#2, MyPC: Windows 7 SP1 32 bits
> CPU:
>     PC#1: AMD Athlon XP2000+
>     PC#2: Intel Core2
>     MyPC: Intel Core2 Quad
> Graphic board:
>     PC#1: ATI Radeon 7000 Series (tried with driver from Microsoft and
> from ATI)
>     PC#2: ATI Radeon HD 2600 XT (driver from Microsoft)
>     MyPC: Nvidia GeForce 9500 GT (driver from Nvidia, tried with two
> versions)
> Software:
>     All PCs: ImageJ 1.46d + Java 1.6.0_20 (32 bits)
> Results:
>     PC#1, PC#2: no problem
>     MyPC: strange triangles appear at zoom 75% and 150%
>
>
> Regards,
>
> Michel Julier
>
>
> Le 02/01/2012 12:35, Michael Schmid a écrit :
>> Hi Michel,
>>
>> I am not sure whether this leads us anywhere, but just to make sure:
>>
>> As I understand it, it is a problem with stacks only, not with single
>> images. Is this true?
>> Also, to make sure, is it correct that you have 'normal' stacks (in
>> memory), not virtual stacks (on disk)?
>>
>> It looks a bit like a race condition to me; maybe the graphics try to
>> access the BufferedImage before it is finished? (though I don't see
>> how this could happen).
>> A race condition would mean that the pattern seen in a given image
>> should not be reproducible. Can you confirm this?
>>
>> ---
>> If it can't be fixed in ImageJ:
>> Would an option "zoom levels are a power of 2" help? Then the default
>> zoom levels would be only 50%, 25% etc; and you won't get the
>> problematic zoom ratios unless you set them directly or maximize the
>> image.
>>
>>
>> Michael
>> ________________________________________________________________
>> On Jan 2, 2012, at 10:13, Michel Julier wrote:
>>
>>> Hello,
>>>
>>> Yes, I am speaking about display zoom.
>>> Yes, it is "purely cosmetic", but when working on images we may be
>>> looking at "cosmetic" effects!
>>> Why do I care: because I am tracking defects on some images, because
>>> using several zoom levels is very convenient for that, because 75%
>>> is sometimes the default zoom, and because it displays unexisting
>>> separation lines on the images, as if the detector surface was uneven.
>>>
>>> I understand that the algorithm must be fast, but to me this is not
>>> a reason for being inconsistent.
>>> It could be "take the closest pixel" or "plain average of the pixels
>>> in this area", no problem.
>>>
>>> But what appears here, is that there are those strange triangles,
>>> which vertical, horizontal, and oblique lines. It looks like, on one
>>> side of the triangle one algorithm is used, and on the other side
>>> another algorithm is used. When I see these "y=x" lines, I even tend
>>> to believe that there is a mistake somewhere, like a mixing between
>>> X and Y variables.
>>>
>>> Using "interpolate zoomed images" works for zoom levels<  100%.
>>> However, it also interpolates images for zoom levels>  100%, which
>>> is desirable in some cases (like displaying a photo) but not in
>>> other cases (like seeking bad pixels on a detector).
>>>
>>>
>>> Well, if you tell me that the "fast" display code is using a zoom
>>> made by Windows, and that the bug is actually in Windows, in my
>>> graphic card, or in its driver, I would accept it.
>>>
>>> But wait! I tried to display the same image in several programs
>>> (Paint Shop Pro, Powerpoint 2003 and 2010, Firefox, Internet
>>> Explorer, Paint.NET, Windows Photo Viewer), many of which I expect
>>> to use accelerated display methods, and none of them show these
>>> strange triangles. This is why I am not sure that the problem comes
>>> from Windows. I do not have any easy way to check whether it comes
>>> from Java for Windows.
>>>
>>> Regards
>>> Michel
>>>
>>> Le 30/12/2011 19:26, Herbie a écrit :
>>>> Sorry Michel,
>>>>
>>>> but I don't get the point of your complaint.
>>>>
>>>> I guess you are speaking about display zoom and not about scaling
>>>> images (with interpolation). So if it is diplay zoom, then the
>>>> observed effects are a purely cosmetic problem. Display zoom must
>>>> be fast, hence interpolation is nil or simple.
>>>>
>>>> Making screen shots of display zoomed images is somehow way off,
>>>> especially if they are to serve quantitative purposes. If they are
>>>> made to only demonstrate zoom effects its ok but why do you care
>>>> about display zoom effects?
>>>>
>>>> However, there is an IJ-option "edit>  options>  appearence>  
>>>> interpolate zoomed images". Did you try that?
>>>>
>>>> HTH
>>>>
>>>>                  Herbie
>>>>
>>>>          ------------------------
>>>> <http://www.gluender.de>
>>>>
>>>>
>>>>
>>>>> No, this does not happen at zoom 100%, nor at 200%, 50%, 25%, or
>>>>> 12.5%.
>>>>> But there is a similar (although less obvious) phenomenon at 150%.
>>>>> And there are also some hardly visible problem at 33.3% and 16.7%.
>>>>> I am sending the images attached.
>>>>>
>>>>> I did some screen captures, and I adjusted the color scale for
>>>>> enhancing the differences.
>>>>>
>>>>> I guess there are two different methods for calculating the
>>>>> fractional zooms, one (good) when working on an image, and the
>>>>> other one (not as good) when switching to another image in a stack.
>>>>>
>>>>> This is not desirable, for instance at "33.3%" I would expect that
>>>>> each screen pixel represents exactly 3x3 image pixels, not that
>>>>> the zoom factor is 33.30000%, and I would expect that it is always
>>>>> displayed the same way.
>>>>>
>>>>> But what I get at 75% is worst than that, because it is not
>>>>> consistent. I mean: when scrolling between the images in the
>>>>> stack, not all pixels in one row are calculated in the same way.
>>>>>
>>>>> So, looking at the image, I had the impression that there was some
>>>>> strange problem with my image sensor, whereas it was with ImageJ.
>>>>>
>>>>> Michel
>>>>>
>>>>> Le 30/12/2011 15:52, JOEL B. SHEFFIELD a écrit :
>>>>>> Does this happen when you view the stack at full size, i.e. not
>>>>>> at 75%?  I
>>>>>> am wondering if you are getting some sort of "Moire" effect due
>>>>>> to the
>>>>>> attempt of the system to interpolate from 1024 to 768.
>>>>>>
>>>>>> Joel
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 30, 2011 at 8:16 AM, Michel Julier<[hidden email]>  
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am not a usual user of ImageJ, but I have just met a very
>>>>>>> strange bug.
>>>>>>> I am using ImageJ 1.46c 32 bit on Windows 7 (32 bit).
>>>>>>>
>>>>>>> I have a stack of 10 images, 1024x1024, in float 32 bit, with
>>>>>>> average
>>>>>>> value 0.
>>>>>>>
>>>>>>> When displaying the image at zoom 75%, when I scroll between the
>>>>>>> images
>>>>>>> using the horizontal scrollbar, I get what appears on
>>>>>>> "imagej_scroll2.png".
>>>>>>> It may not be obvious, but there are unexpected triangles on it.
>>>>>>>
>>>>>>> When I click on the image (example: zooming, selecting,...), I
>>>>>>> get what
>>>>>>> appears on "imagej_click2.png".
>>>>>>> This time, there is no problem.
>>>>>>>
>>>>>>> Making two screen captures and calculating the difference
>>>>>>> between them, I
>>>>>>> obtain the strange triangles displayed on "imagej_diff2.png".
>>>>>>>
>>>>>>> I can reproduce the bug, but the file is big (40 Mo) so I cannot
>>>>>>> send it
>>>>>>> here. I can provide it to anybody who might be interested.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michel Julier
>

[dscho]

Hi Michel,

On Mon, 16 Jan 2012, Michel Julier wrote:

> I found a workaround this is OK for me: disabling DirectDraw.
> In ImageJ.cfg, I just added the following option:
>     -Dsun.java2d.noddraw=true

FYI this setting is the default in the Fiji launcher (which has recently
been renamed to ImageJ launcher) since February last year:

https://github.com/fiji/fiji/commit/641e90880bf537a414c34133dd53cdb3fd13384b#fiji.c

Ciao,
Johannes