[BioC] EBImage (>= 4.0.0) - browser-dependency display() issue

[Andrzej Oleś]

Dear Rob,

first of all thank you for your feedback! I appreciate your detailed
description and the time you took to investigate the problem.


On Wed, Oct 10, 2012 at 12:51 AM, Robert Baer <rbaer at atsu.edu> wrote:
> It used to take forever to get GTK+ and ImageMagick installed and working
> properly, so I really appreciate your new approach. However, there is a
> browser-dependency with the new display() function.
>
>> nuc = readImage(system.file('images', 'nuclei.tif', package='EBImage'))
> image 510 x 510 x 0, tiles 0 x 0, bps = 8, spp = 1 (output 1), config = 1,
> colormap = no
> image 510 x 510 x 0, tiles 0 x 0, bps = 8, spp = 1 (output 1), config = 1,
> colormap = no
> image 510 x 510 x 0, tiles 0 x 0, bps = 8, spp = 1 (output 1), config = 1,
> colormap = no
> image 510 x 510 x 0, tiles 0 x 0, bps = 8, spp = 1 (output 1), config = 1,
> colormap = no
>> display(nuc)
>
> On Windows 7 64-bit with IE 9.0 as my default browser, I get the browser
> starting with the message, "Internet Explorer restricted this web page from
> running scripts or ActiveX controls".  If I click the button,"Allow Blocked
> Content", I still get no display of the images.  The display command
> therefore appears to fail.

The reported behavior is related to the Local Machine Zone Lockdown,
an IE security feature which prevents local web pages from running
JavaScript content. Normally, you should be able to view the images
upon allowing active content by selecting 'Yes' in the message box
which appears when you click on the prompt in the information bar (at
least, this is how things work in IE 8). Unfortunately, I do not have
access to a machine with IE 9 right now, so I cannot confirm whether
there is a actual problem with this browser version.

However, disabling the 'lockdown' might be helpful in your case.
Typically, each time you issue a new 'display' call you will
keep receiving the notification and will have to re-allow active
content. To get rid of this you should allow any local web site to run
scripts and ActiveX controls. This can be accomplished as follows:

in Internet Explorer select 'Internet Options' from the 'Tools' menu.
Change to the 'Advanced' tab, scroll down to the Security section of
the list and check the 'Allow active content to run in files on My
Computer' box, then click 'OK' to approve. You might have to restart
your browser to have your changes take effect.

Please report back to me whether this worked for you or not.


> I'm not quite sure why you picked "browser-based display" as the default,
> but it seems there should be checking to see if the appropriate browser
> controls are available if the browser display is to be the default.  Just
> for completeness, if Chrome (my more common default browser) or Mozilla
> Firefox are my defaults, the browser based display works fine.  Note here
> though, that I have a current and well-functioning Java that didn't exist by
> default on the Windows platform.  Do you have code that should install an
> ActiveX control in IE that is not functioning properly?  The issue with
> browser-based display as the default is "reliability" not "flexibility".

The browser based viewer was chosen as the default one because of its
superior functionality and flexibility compared to the 'raster'
method. Please note that even though it is possible to display several
frames side by side using the latter method, this approach does not
allow any user interaction like zooming and panning present in the
browser viewer. From the technical side, the browser viewer relies
solely on JavaScript and does not use any ActiveX controls.
Furthermore, JavaScript itself has, except similar name, little to do
with Java and so the particular Java system configuration shouldn't be
an issue here.


> I do not have Safari or Opera installed on this computer so I have not tried
> them.

Both these browsers passed our in-house tests and should be compatible
with EBImage.


> Let me finish with a wishlist item.  I would be terrific if there were a way
> to directly tie the OME data model
> http://www.openmicroscopy.org/site/support/file-formats to EBImage
> processing in R.  Being able to deal with multidimensional data and manage
> the mass of metadata associated with images seems destined to be the future.
> I know this is a BIG WISH not easily fulfilled, but I thought I'd express it
> anyway.

Thank you for your inspiring remark! The OME data model is certainly
something we will take into consideration in our future development
plans. What exactly do you mean by 'tying the OME data model to
EBImage processing in R' and what are your expectations towards this?

Best regards,

Andrzej Oles
EBImage Development Team