inetrpolation
Locked
12
12
|
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal I think actually that quite a few programs had that 'split' option including quite a few of the 3D rendering programs. But that was 20 years ago .... and there was never actually any need to collect stacks in that format - the system could collect a full-frame image from each channel. Of course you had to use a macro to do it, but in the original SOM software you had to use a macro to collect any sort of stack. Guy Optical Imaging Techniques in Cell Biology by Guy Cox CRC Press / Taylor & Francis http://www.guycox.com/optical.htm ______________________________________________ Associate Professor Guy Cox, MA, DPhil(Oxon) Electron Microscope Unit, Madsen Building F09, University of Sydney, NSW 2006 ______________________________________________ Phone +61 2 9351 3176 Fax +61 2 9351 7682 Mobile 0413 281 861 ______________________________________________ http://www.guycox.net -----Original Message----- From: Confocal Microscopy List [mailto:[hidden email]] On Behalf Of Eric Scarfone Sent: Wednesday, 14 May 2008 7:57 PM To: [hidden email] Subject: Re: old Biorad format Search the CONFOCAL archive at http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal Thanks Guy, Stephen et al.! I had also a macro but lost it when I moved and the old system was dismantled.... long time ago. I will check good old CAS! I believe though that an older version of Imaris had the option "split Biorad MRC600 images" but I am not so sure. Maybe it was lasersharp?? Greetings Eric Scarfone, PhD, CNRS, Center for Hearing and communication Research Department of Clinical Neuroscience Karolinska Institutet Postal Address: CFH, M1:02 Karolinska Hospital, SE-171 76 Stockholm, Sweden Work: +46 (0)8-517 79343, Cell: +46 (0)70 888 2352 Fax: +46 (0)8-301876 email: [hidden email] http://www.ki.se/cfh/ ----- Original Message ----- From: Guy Cox <[hidden email]> Date: Wednesday, May 14, 2008 7:42 am Subject: Re: old Biorad format To: [hidden email] > Search the CONFOCAL archive at > http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal > > I just checked, and it seems that Confocal Assistant does indeed also > split those side-by-side files. So now Eric has at least 3 options! > > Guy > > > -----Original Message----- > From: Confocal Microscopy List > [mailto:[hidden email]] On > Behalf Of Jerry Sedgewick > Sent: Wednesday, 14 May 2008 1:59 AM > To: [hidden email] > Subject: Re: old Biorad format > > Search the CONFOCAL archive at > http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal > > Hi Eric, > > I suspect that you are talking about Confocal Assistant, written > for > opening PIC files, etc. That can be downloaded at our site: > http://bipl.umn.edu/downloads. > > Jerry > > > Eric Scarfone wrote: > > Search the CONFOCAL archive at > > http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal > > > > Hello all > > I vaguely recall a small program that would cut out the infamous > > original biorad format (MRC600, 2 channels side by side on the > same > > image) into one two file stacks (one for each channel). Or was > it a > > patch in Imaris or another software? > > If this exists can somebody point it out? > > Amicalement > > Erics > > > > Eric Scarfone, PhD, CNRS, > > Center for Hearing and communication Research > > Department of Clinical Neuroscience > > Karolinska Institutet > > > > Postal Address: > > CFH, M1:02 > > Karolinska Hospital, > > SE-171 76 Stockholm, Sweden > > > > Work: +46 (0)8-517 79343, > > Cell: +46 (0)70 888 2352 > > Fax: +46 (0)8-301876 > > > > email: [hidden email] > > http://www.ki.se/cfh/ > > > > > > > > > > > --- Get FREE High Speed Internet from USFamily.Net! -- > http://www.usfamily.net/mkt-freepromo.html --- > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1429 - Release Date: > 12/05/2008 6:14 PM > > No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1431 - Release Date: 13/05/2008 7:55 PM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1431 - Release Date: 13/05/2008 7:55 PM |
|
|
In reply to this post by Eric Scarfone
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
G’day List,
Sorry there was an error in the html address on my web page. The error has now been corrected. Thanks to Daniel for bringing it to my attention. A description of the Bio-Rad macros “SOMBatch-IV” and the macros themselves may be downloaded from the following page.
http://www.ludwig.edu.au/confocal/Links.html
Cheers Stephen H. Cody Tip: Learn how to receive reminders about you microscope
booking: -----Original Message-----
Hi Stephen,
I saw your post on the confocal listserver where you mentioned your SOMBatch macros.
I would like to peruse and use these macros if that is OK for use on our MRC-600s?
However, on the link you quoted, the URL for the macros and associated txt file is incorrect – quotes a Z drive rather than a http address.
http://www.ludwig.edu.au/confocal/Links.html
Thanks,
Daniel
Daniel Brotchie
University of Liverpool, UK
This communication is intended only for the named recipient and may contain information that is confidential, legally privileged or subject to copyright; the Ludwig Institute for Cancer Research does not waiver any rights if you have received this communication in error. The views expressed in this communication are those of the sender and do not necessarily reflect the views of the Ludwig Institute for Cancer Research. |
|
|
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal Since I can't send an attachment, I am pasting in a hack of an ImageJ "Biorad Reader" plugin that I modified a few years back when we were still using an MRC-600 and ImageJ was young. It is for the 2-chan side-by-each format stacks. I haven't used it for a while, but assume it will still work with current versions of ImageJ. I'm not a java programmer so forgive bad style in my additions....... It looks like email and wordwrap may have mangled it? If it doesn't compile, I can email the original file to anyone interested. Dale /* *** PASTE INTO A FILE NAMED "Biorad_2ch_Z_Splitter.java" /* *** AND COMPILE /* ********* CUT HERE TO NEXT "CUT HERE" ************************* /* Credits: This is basically the Biorad_Reader plug-in, with a little code inserted. * * Modifications (marked) by: Dale A. Callaham * email: [hidden email] * * Splits a 2-channel Biorad Mrc-600 confocal Z-series image into 2 "stacks" * named "Red_Stack" and "Green_Stack". Assumes 768x512 dual-channel MRC-600 images. * * * Current limitations: * * 1) It adds a blank slice at the beginning of each stack created * Fix: This first blank slice can easily be deleted. * Eventually I will find a way to avoid this. * * 2) It leaves the stacks (all 3) positioned at the end. * This is a minor nusiance. Would be better if each were left at the beginning. * */ import ij.*; import ij.io.*; import ij.util.Tools; import ij.process.*; import ij.plugin.*; import java.io.*; import java.util.*; import ij.measure.*; /** Imports a Z series(image stack) from a Biorad MRC 600 confocal microscope. The width, height and number of images are extracted from the first 3 16-bit word in the 76 byte header. Use Image/Show Info to display the header information. */ public class Biorad_2ch_Z_Splitter extends ImagePlus implements PlugIn { private final int NOTE_SIZE = 96; private BufferedInputStream f; private String directory; private String fileName; private String notes = ""; public void run(String arg) { if (IJ.versionLessThan("1.16c")) return; OpenDialog od = new OpenDialog("Open Biorad...", arg); directory = od.getDirectory(); fileName = od.getFileName(); if (fileName==null) return; IJ.showStatus("Opening: " + directory + fileName); FileInfo fi = null; try {fi = getHeaderInfo();} catch (Exception e) { IJ.showStatus(""); IJ.showMessage("BioradReader", ""+e); return; } if (fi!=null) { FileOpener fo = new FileOpener(fi); ImagePlus imp = fo.open(false); if (imp==null) return; if (imp.getStackSize()>1) setStack(fileName, imp.getStack()); else setProcessor(fileName, imp.getProcessor()); imp.setCalibration(getBioRadCalibration(fi.width, fi.height, fi.nImages) ); if (!notes.equals("")) setProperty("Info", notes); copyScale(imp); if (arg.equals("")) show(); } /* Start code added by Dale Callaham */ int numImages = fi.nImages; if (numImages>1) { IJ.run("New...", "name=Green_Stack type='8-bit Unsigned' fill=Black width=384 height=512 slices=0"); IJ.run("New...", "name=Red_Stack type='8-bit Unsigned' fill=Black width=384 height=512 slices=0"); } for (int i=0; i<numImages; i++) { IJ.selectWindow(fileName); IJ.makeRectangle(0, 0, 383, 511); IJ.run("Copy"); IJ.selectWindow("Green_Stack"); IJ.run("Select All"); IJ.run("Paste"); if (i<(numImages-1)) IJ.run("Add Slice"); IJ.run("Select None"); IJ.selectWindow(fileName); IJ.makeRectangle(384, 0, 767, 511); IJ.run("Copy"); IJ.selectWindow("Red_Stack"); IJ.run("Select All"); IJ.run("Paste"); if (i<(numImages-1)) IJ.run("Add Slice"); IJ.run("Select None"); IJ.selectWindow(fileName); IJ.run("Select None"); IJ.run("Next Slice [>]"); } /* End code added by Dale Callaham */ } int getByte() throws IOException { int b = f.read(); if (b ==-1) throw new IOException("unexpected EOF"); return b; } int getShort() throws IOException { int b0 = getByte(); int b1 = getByte(); return ((b1 << 8) + b0); } FileInfo getHeaderInfo() throws IOException { f = new BufferedInputStream(new FileInputStream(directory+fileName)); FileInfo fi = new FileInfo(); fi.fileFormat = fi.RAW; fi.fileName = fileName; fi.directory = directory; fi.width = getShort(); fi.height = getShort(); fi.nImages = getShort(); fi.offset = 76; if (fi.width<128||fi.width>2048||fi.height<128||fi.height>2048||fi.nImages<1||fi.nImages>1024) throw new IOException("This does not seem to be a Biorad Z Series"); f.close(); return fi; } /** Extracts the calibration info from the ASCII "notes" at the end of Biorad pic files. */ Calibration getBioRadCalibration(int width, int height, int nImages) { Calibration BioRadCal = new Calibration(); long NoteFlag; int NoteType, Offset; String NoteContent = new String(); byte[] TempByte = new byte[NOTE_SIZE]; double ScaleX, ScaleY, ScaleZ; int maxNotes = nImages*2+50; FileInfo fi = new FileInfo(); fi.fileFormat = fi.RAW; fi.fileName = fileName; fi.directory = directory; fi.width = maxNotes*NOTE_SIZE; fi.height = 1; fi.offset = 76+height*width*nImages; ImagePlus imp = new FileOpener(fi).open(false); if (imp==null) return BioRadCal; ImageProcessor ip = imp.getProcessor(); Offset = 0; // Do ... While : cycle through notes until you reach the last note (indicated by bytes 2-5) // For each note, different from 'live note', see if it contains axis calibration data. // of so, extract the necessary values. do { // Decode bytes 2-5 (32-bit integer), if = 0, last note NoteFlag = ip.getPixel(Offset+2,0) + (ip.getPixel(Offset+3,0) << 8)+(ip.getPixel(Offset+4,0) << 16)+(ip.getPixel(Offset+5,0) << 24); // Decode bytes 10-11 (16-bit integer), contains type of note NoteType = ip.getPixel(Offset+10,0) + (ip.getPixel(Offset+11,0) << 8); // store bytes 16-95 in a byte array, stopping at first illegal character.... int byteCount = 0; for (int i=0; i<NOTE_SIZE; i++) { byte ch = (byte)ip.getPixel(Offset+16+i,0); byteCount++; if (ch<32 || ch>127) { TempByte[i] = 32; break; } TempByte[i] = (ch>=32 && ch<=126)?ch:32; } String Note = new String(TempByte, 0, byteCount); notes += Note + "\n"; // save note for Image/Show Info command // only analyze notes != 1, so skip all the notes that say 'Live ...', they don't contain calibration info if (NoteType!=1) { NoteContent = getField(Note,1); // See if first field contains keyword "AXIS_2" --> X-axis calibration (don't know why Biorad calls it '2'. if (NoteContent.indexOf("AXIS_2") >= 0 ) { //IJ.showMessage(Note); //IJ.showMessage(getField(Note, 4)); ScaleX = s2d(getField(Note, 4)); BioRadCal.pixelWidth = ScaleX; // fifth field contains units (mostly microns) BioRadCal.setUnit(getField(Note, 5)); } else if ( NoteContent.indexOf("AXIS_3") >= 0 ) { // contains Y-axis calibration //IJ.showMessage(Note); //IJ.showMessage(getField(Note, 4)); ScaleY = s2d( getField(Note, 4)); BioRadCal.pixelHeight = ScaleY; BioRadCal.setUnit(getField(Note, 5)); } else if ( NoteContent.indexOf("AXIS_4") >= 0 ) { // contains Z-axis calibration //IJ.showMessage(Note); //IJ.showMessage(getField(Note, 4)); ScaleZ = s2d( getField(Note, 4)); BioRadCal.pixelDepth = ScaleZ; /** ImageJ does not contain seperate units for the Z-direction. This could be a usefull extension because for a stack you can have 'space' or 'time' as the extra dimension. In the time-case, the fifth field of the Z-scaling contains the time units */ } } Offset += NOTE_SIZE; // Jump to next note } while ( NoteFlag != 0 ); // stop if this was the last note return BioRadCal; // return the filled biorad calibration } /* Extracts a certain field from a string. A space is considered as the field delimiter. */ String getField(String str, int fieldIndex) { char delimiter = ' '; int startIndex=0, endIndex; for (int i=1; i<fieldIndex; i++) startIndex = str.indexOf(delimiter, startIndex+1); endIndex = str.indexOf(delimiter, startIndex+1); if (startIndex>=0 && endIndex>=0) return str.substring(startIndex, endIndex); else return ""; } // Converts a string to a double. Returns 1.0 if the string does not contain a valid number. */ double s2d(String s) { Double d = null; try {d = new Double(s);} catch (NumberFormatException e) {} return d!=null?d.doubleValue():1.0; } } /* Bio-Rad(TM) .PIC Image File Information (taken from: "Introductory Edited Version 1.0", issue 1/12/93.) (Location of Image Calibration Parameters in Comos 6.03 and MPL .PIC files) The general structure of Bio-Rad .PIC files is as follows: HEADER (76 bytes) Image data (#1) . . Image data (#npic) NOTE (#1) . ; NOTES are optional. . NOTE (#notes) RGB LUT (color Look Up Table) Header Information: The header of Bio-Rad .PIC files is fixed in size, and is 76 bytes. ------------------------------------------------------------------------------ 'C' Definition byte size Information (bytes) ------------------------------------------------------------------------------ int nx, ny; 0 2*2 image width and height in pixels int npic; 4 2 number of images in file int ramp1_min, ramp1_max; 6 2*2 LUT1 ramp min. and max. NOTE *notes; 10 4 no notes=0; has notes=non zero BOOL byte_format; 14 2 bytes=TRUE(1); words=FALSE(0) int n; 16 2 image number within file char name[32]; 18 32 file name int merged; 50 2 merged format unsigned color1; 52 2 LUT1 color status unsigned file_id; 54 2 valid .PIC file=12345 int ramp2_min, ramp2_max; 56 2*2 LUT2 ramp min. and max. unsigned color2; 60 2 LUT2 color status BOOL edited; 62 2 image has been edited=TRUE(1) int _lens; 64 2 Integer part of lens magnification float mag_factor; 66 4 4 byte real mag. factor (old ver.) unsigned dummy[3]; 70 6 NOT USED (old ver.=real lens mag.) ------------------------------------------------------------------------------ Additional information about the HEADER structure: Bytes Description Details ------------------------------------------------------------------------------ 0-9 nx, ny, npic, ramp1_min, ramp1_max; (all are 2-byte integers) 10-13 notes NOTES are present in the file, otherwise there are none. NOTES follow immediately after image data at the end of the file. Each note os 96 bytes long. 14-15 byte_format Read as a 2 byte integer. If this is set to 1, then each pixel is 8-bits; otherwise pixels are 16-bits. 16-17 n Only used in COMOS/SOM when the file is loaded into memory. 18-49 name The name of the file (without path); zero terminated. 50-51 merged see Note 1. 52-53 colour1 54-55 file_id Read as a 2 byte integer. Aways set to 12345. Just a check that the file is in Bio-Rad .PIC format. 56-59 ramp2_min/max Read as 2 byte integers. 60-61 color2 Read as a 2 byte integer. 62-63 edited Not used in disk files. 64-65 int_lens Read as a 2 byte integer. Integer part of the objective lens used. 66-69 mag_factor Read as a 4-byte real. mag. factor=(float)(dispbox.dy*2)/(float)(512.0*scandata.ly) where: dispbox.dy = the width of the image. scandata.ly = the width of the scan region. the pixel size in microns can be calculated as follows: pixel size = scale_factor/lens/mag_factor where: lens = the objective lens used as a floating pt. number scale_factor = the scaling number setup for the system on which the image was collected. 70-75 dummy[3] Last 6 bytes not used in current version of disk file format. (older versions stored a 4 byte real lens mag here.) ------------------------------------------------------------------------------ Note 1 : Values stored in bytes 50-51 : 0 : Merge off 1 : 4-bit merge 2 : Alternate 8-bit merge 3 : Alternate columns merge 4 : Alternate rows merge 5 : Maximum pixel intensity merge 6 : 256 colour optimised merge with RGB LUT saved at the end of each merge. 7 : As 6 except that RGB LUT saved after all the notes. Information about NOTE structure and the RGB LUT are not included in this file. Please see the Bio-Rad manual for more information. ============================================================================== Info added by Geert Meesen from MRC-600 and MRC-1024 Manuals. ------------------------------------------------------------- Note Structure : Bytes Description Details ------------------------------------------------------------------------------ 0-1 Display level of this note 2-5 =0 if this is the last note, else there is another note (32 bit integer) 10-11 Note type := 1 for live collection note, := 2 for note including file name, := 3 if note for multiplier file, := 4, 5, etc.,; additional descriptive notes 16-95 Text of note (80 bytes) ============================================================================= Info added by Geert Meesen from personal experiments. ------------------------------------------------------------ - Until now I only have experience with 8-bit images from the MRC-1024 confocal microscope. The newer microscopes (Radiance 2000, for example) are capable of generating 16 bit images, I think. I have access to such a microscope and will try to find out later. For now it should be possible to look at the byte-word flag in the header. - I have experience with two types of images : --- One slice in the Z-direction, 3 channels of recording. This type is stored as a three-slice image with the 3 channels in consecutive layers. (Single-Slice) --- Different Z slices with only one channel. (Z-stack) - The header should contain some info about the pixel-size, but until now I was not really able to interpret this info. It's easier to extract the info from the notes at the end. You can find 3 notes saying something like (from AUPCE.NOT, a Z-stack file) AXIS_2 001 0.000000e+00 2.999667e-01 microns AXIS_3 001 0.000000e+00 2.999667e-01 microns AXIS_4 001 0.000000e+00 1.000000e+00 microns AXIS_9 011 0.000000e+00 1.000000e+00 RGB channel These lines give the pixelsize for the X (axis_2), Y (axis_3) and Z (axis_4) axis in the units mentioned. I don't know if this unit is always 'microns'. For a Single-Slice images you get ( from AB003A.NOT, a Single-Slice image) : AXIS_2 001 0.000000e+00 1.799800e+00 microns AXIS_3 001 0.000000e+00 1.799800e+00 microns AXIS_4 011 0.000000e+00 1.000000e+00 RGB channel It seems that AXIS_4 is used for indicating an RGB channel image. */ *************************** CUT HERE ************************* |
 
|
Bill Oliver-3 |
Re: interpolation Note of Caution
|
|
In reply to this post by Chris Tully
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal This is, as you might expect, a big issue in forensic image processing. In that arena, there are numerous guidelines promulgated by the Scientific Working Group on Imaging Technologies. Our guidelines suggest the following for evidentiary image processing: The most important thing to remember is that an image data file is not an image. An image is something that you *look* at that is *interpreted" by the brain. An image data file does not become an image until it is displayed. Two images are the same if they *look* the same (e.g. represent a "fair and accurate" representation of the scene at the level of examination pertinent for a specific forensic use. For decades, that has been the standard measure for the evaluation of film-based imagery. Visual verification. In the forensic world for film-based imagery, all images created from the same negative using generally accepted printing methods are considered "original" images. If you were to take five photographic prints made from one negative under essentially the same darkroom methods and digitize them, you would find that no two were bit-for-bit the same. Nonetheless, they would be essentially the same visually, which is sufficient for almost any evidentiary issue. These darkroom techniques are image-processing when performed on digital images, and thus the degree of documentation is analogous to that necessary for the creation of these prints. That is, it is necessary to describe processing to the degree that a similarly-trained professional would come to the same *conclusion* about the image that you did, not that the similarly-trained professional would create a bit-for-bit duplicate of the image you created. Thus, for simple techniques that have darkroom analogues such as simple color balancing, brightening, etc., it is sufficient to simply say you did it. For more advanced techniques -- adaptive contrast enhancement, deblurring, stabilization, regularization, etc. -- it is necessary to document the methods and paramaters to the degree that a colleague can replicate the results to the degree that a similar result would be obtained, but we specifically *reject* the notion that it is necessary to do the keystroke-by-keystroke logging that some software products try to push as somehow necessary for evidentiary use. the fact that you *can* do something is not itself an argument that you *should* or *must.* We certainly have nothing *against* that level of logging if it floats your boat, but it is not a requirement. One of the most annoying things about folk who push the requirement for this keystroke-by-keystroke stuff is that they ignore the processing that occurs in the camera itself (which, depending on the camera and settings, can be as much or more than any processing that occurs after the image data is moved from the camera to the computer). That being said, this analogy applies to the photographic prints, not the negative. For that, we distinguish between a "primary" image data file and an "original" image data file. The "primary" data file is that first data that is downloaded from the camera or sensor device -- e.g. the file in the flash card, cut into the on-camera CD, etc. That data can be copied bit-for-bit onto archival media and becomes the "original" image data file. After creating the archival image, the primary image datai can be deleted -- thus you don't have to use a different flash card for every case. All bit-for-bit copies of the archival original image data file are also considered "original" images. When those original images are used as the basis for processing, they become "working" images. Thus, if one were to extend these ideas to microscopy, the requirement would be that the investigator archive a bit-for-bit copy of the image that goes to the temporary storage associated with the sensor, and a bit-for-bit copy of that be used as the basis for any other processing. That archival image would remain for the creation of original images in case there were any issues with the images used in a paper. Any modification of that image for publication or demonstration would have to be acknowledged and described, but only to the degree that another scientist could replicate the *significant* findings for which the image is used. For instance, it would be adequate to simply say "Following capture, basic color-balancing is performed. Contrast is enhanced by simple histogram stretching followed by a contrast-limited adaptive histogram equalization using the Pizer algorithm with 20 square adaptive regions and a cliplevel of 6." We specifically, however, reject the requirement for a keystroke-by-keystroke audit trail. For a look at the SWGIT Guidelines, see: http://www.theiai.org/guidelines/swgit/index.php billo On Mon, 12 May 2008, Chris Tully wrote: > Search the CONFOCAL archive at > http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal > > List members, > > First let me explain that although I am no longer associated with them, I > have previously worked for Media Cybernetics. > > One extremely valuable set of features in Image-Pro Plus (www.mediacy.com) > is the Audit Trail and Image or File Signature. The Audit Trail logs every > action taken on every open image. This allows you to document exactly what > was done with or to the image. The Image and File Signatures are 32 bit > check sums that are automatically recorded in the Audit trail at relevant > times (Acquisition, save, load...), and are sensitive enough to detect a > change of +/- one gray level in one pixel! Paired with the Capture module's > Auto Save function, it is possible to: > > 1) Document that a published image is unchanged. You will need to carefully > track such things as cropping to demonstrate this completely, but this is > entirely possible. > > 2) If the image has been altered use successive image signatures (before and > after each alteration) to demonstrate that the logged alterations are the > only ones that have occurred. If you are going to do this I would recommend > saving the image with a new name immediately before any such alteration so > that you can demonstrate the alteration again if challenged. > > Another approach that I often use is to work on a duplicate of the original > image. Change away as much as I need to to do the desired analysis. As the > last step of my analysis though I generate outlines of the objects that I am > measuring and place them back on the unaltered original image. This both > allows me to make some measurements that can only be made on the original > image and to demonstrate that the identified objects are still relevant to > the original image and therefore to the sample. > > Chris > |
|
|
Phillips, Thomas E. |
BioRad Radiance 2000 service contract
|
|
In reply to this post by Stephen Cody
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
Perhaps I am the last to learn
of this date but the topic of when exactly Zeiss would stop service contracts
on the BioRad Radiance 2000 has been a topic in the past. When we recently went
to renew our current contract, they included a letter (date 10/29/07) that
states they will not offer service contracts past Sept. 30, 2009. Only “time
and material” basis repairs will be offered after that date with no guarantee
of parts availability. Thomas E. Phillips, Ph.D. Professor of Biological Sciences Director, Molecular Cytology
Core 2 Tucker Hall Biological Sciences University of Missouri Columbia, MO 65211-7400 573-882-4712 (voice) 573-882-0123 (fax) |
|
|
Mayandi Sivaguru |
Re: BioRad Radiance 2000 service contract
|
|
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
Tom, Also I heard that countdown for LSM 510 support already began. Zeiss will provide 8 years full support from now on all the existing LSM 510s. It is time to get the LSM 710?!. Shiv At 02:31 PM 6/4/2008, you wrote: Search the CONFOCAL archive at http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal Microscopy Facility Manager 8, Institute for Genomic Biology University of Illinois at Urbana-Champaign 1206 West Gregory Dr. Urbana, IL 61801 USA Office: 217.333.1214 Fax: 217.244.2496 [hidden email] http://core.igb.uiuc.edu |
|
|
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
Sounds like absolutely NOT the time to get
the 710 if Zeiss are going to have that sort of attitude to continuing support!
Even car manufacturers offer minimum 10 years after end of model.
Guy Optical Imaging Techniques in Cell Biology by Guy Cox CRC Press / Taylor & Francis http://www.guycox.com/optical.htm ______________________________________________ Associate Professor Guy Cox, MA, DPhil(Oxon) Electron Microscope Unit, Madsen Building F09, ______________________________________________ Phone +61 2 9351 3176 Fax +61 2 9351 7682 Mobile 0413 281 861 ______________________________________________ From:
Search the CONFOCAL archive at http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
No virus found in this incoming message. |
|
|
Carlos Sanchez-8 |
Re: BioRad Radiance 2000 service contract
|
|
In reply to this post by Mayandi Sivaguru
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
Hello, So, it will be a good point to take into account when acquiring new systems. We are having many problems in Spain with BioRad systems support and we wouldn’t like to have these same problems with Zeiss confocals. Actually, in Spain the support for old Biorad confocals is being given by another enterprise; Zeiss is just providing the material as far as I know. I hope that microscope enterprises realize sometime that for users and facilities the Service support is so important, if not more, than the purchase of the system.
Regards,
Carlos Sánchez Martín Servicio de Microscopía Optica y Confocal (SMOC) (Lab.310) Centro de Biología Molecular "Severo Ochoa" (CSIC-UAM) C/Nicolás Cabrera,1 Universidad Autónoma de Madrid. Cantoblanco. 28049. Madrid Tlfs. 91 196 4613/4643 Fax. 91 196 4420 E-mail: [hidden email]
|
|
|
Rosemary.White |
Re: BioRad Radiance 2000 service contract
|
|
In reply to this post by Guy Cox
Search the CONFOCAL archive at
http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal
Rosemary Rosemary White [hidden email] CSIRO Plant Industry ph. 61 (0)2-6246 5475 GPO Box 1600 fax. 61 (0)2-6246 5334 Canberra, ACT 2601 Australia On 5/6/08 1:56 PM, "Guy Cox" <[hidden email]> wrote: Search the CONFOCAL archive at http://listserv.acsu.buffalo.edu/cgi-bin/wa?S1=confocal |
«
Return to Confocal Microscopy List
|
1 view|%1 views
| Free forum by Nabble | Edit this page |