EBImage package now easier to install (no system dependencies)
1
0
Entering edit mode
Andrzej Oleś ▴ 750
@andrzej-oles-5540
Last seen 8 months ago
Heidelberg, Germany
We are happy to announce that with Bioconductor release 2.11 the package EBImage (>= 4.0.0) can be installed without any of the system dependencies that were required by previous versions (ImageMagick, GTK+). Further functionality upgrades include: - Perreault's constant time median filter, - self-complementary top-hat, - streamlined object feature computations, - improved 'rotate' / 'translate' functions and a new 'transpose' function, - alpha channel support, - and performance enhancements. See the package NEWS file and documentation for details. Andrzej Oles EBImage Development Team
EBImage EBImage • 886 views
ADD COMMENT
0
Entering edit mode
Robert Baer ▴ 70
@robert-baer-4660
Last seen 14 months ago
United States
On 10/7/2012 4:43 PM, Andrzej Ole? wrote: > We are happy to announce that with Bioconductor release 2.11 the > package EBImage (>= 4.0.0) can be installed without any of the system > dependencies that were required by previous versions (ImageMagick, > GTK+). > > Further functionality upgrades include: > - Perreault's constant time median filter, > - self-complementary top-hat, > - streamlined object feature computations, > - improved 'rotate' / 'translate' functions and a new 'transpose' function, > - alpha channel support, > - and performance enhancements. > > See the package NEWS file and documentation for details. > > > Andrzej Oles > EBImage Development Team > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor 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. If I do to use the built-in raster display: display(nuc, method = 'raster'), or better, display(nuc, method = 'raster', all = TRUE) the images display quite nicely. 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". I do not have Safari or Opera installed on this computer so I have not tried them. 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. Again, I'm grateful for what you've already contributed with the existing EBImage! Kudos to you on a terrific package! Rob Baer Thanks, Rob Baer
ADD COMMENT
0
Entering edit mode
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
ADD REPLY

Login before adding your answer.

Traffic: 557 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6