Hi,
We are using an Olympus Fluoview confocal to take z-stacks before bringing them into Image J. Because we want to analyze a large area, we have to take 2 side-by-side stacks and then use the "stitch" function in Image J to create a montage. It turns out that the staining that we are looking at is overall, brighter on one side of the montage than the other. Although we leave the confocal settings identical for the two photos, it seems as if the difference between the two sides may be exaggerated in Image J; the "seam" between the 2 is clearly visible regardless of the blending method we try. I am wondering if the fact that the confocal is taking 12 bit images, but the tifs are imported as 8 bit images is somehow exaggerating the contrast between them. Does this make sense to anyone and is there a workaround that anyone knows of? Thanks so much, Susan Travers Ohio State University |
On 6/16/11 11:46 PM, Susan Travers wrote:
> Hi, > > We are using an Olympus Fluoview confocal to take z-stacks before > bringing them into Image J. Because we want to analyze a large area, we > have to take 2 side-by-side stacks and then use the "stitch" function in > Image J to create a montage. > > It turns out that the staining that we are looking at is overall, > brighter on one side of the montage than the other. Although we leave > the confocal settings identical for the two photos, it seems as if the > difference between the two sides may be exaggerated in Image J; the > "seam" between the 2 is clearly visible regardless of the blending > method we try. > > I am wondering if the fact that the confocal is taking 12 bit images, > but the tifs are imported as 8 bit images is somehow exaggerating the > contrast between them. > > Does this make sense to anyone and is there a workaround that anyone > knows of? > I suspect that you see this seam because you have an uneven background. This is especially seen in images from the DIC channel. Just yesterday I had to deal with this, and found that for a mosaic of the DIC images from an FV1000, I could make a seamless montage by flattening the images and also adjusting their average to be the same for all tiles. Here is part of the relevant macro: /* This macro will take a directory of dic images (which were presumably tiled) * flatten their background and then cause their average brightness to be 128. * This will make the ensuing tiling "seemless". * The operations are: * 1 create a psuedo-background with very strong averaging (mean with radius 100) * 2. Divide original image by this average * 3. multiply result by 128/histogram_mean, so that tehnew average is 128. */ ===a bunch of "book-keeping" to deal with the file===== // here I had just extracted the DIC channel from the OIB dicId = getImageID(); dicTitle = getTitle(); resetMinAndMax(); // We create a background image with heavy low pass filtering // This is good for a DIC image where the gray level variations // are not usually extreme run("Duplicate...", "title=["+graySelection+"]"); bgId = getImageID(); bgTitle = getTitle(); run("Mean...", "radius=100"); // Here we divide by the filtered image to flatten the original imageCalculator("Divide create 32-bit", dicId, bgId); dicNormId = getImageID(); dicNormTitle = getTitle(); // conversion to 8-bit caused no problems. run("8-bit"); resetMinAndMax(); // Here, we get the histogram mean, and then multiply the image // by 128/mean. 128 is good for DIC images. If you are looking // fluorescence images, I suggest a better estimate (eg, the mean // of the histogram of your entire stack getStatistics(area, mean, min, max, std, histogram); brightnessFactor = 128/mean; run("Multiply...","value="+d2s(brightnessFactor,2)); ====end of macro fragments====== After I did this, not only was the merge seamless, but the image stitching function found the correct tile arrangement. It coudl nto do it when the background was nonuniform, because overlapping parts had different background distributions. One other thing -- if your image has strong fluorescence in lines and spots, on a relatively dark background, then the strong averaging will not make a good background estimate. In that case, try using the background subtraction (in Process), and use it to generate a background image, which you can then smooth if needed. I will be happy to send you the macro, which has some handy oib file handling, if you need it. I posted to the list because I think the reply may be of general interest. Thanks to Stephan Preibisch for the great stitching plugin set. --aryeh -- Aryeh Weiss School of Engineering Bar Ilan University Ramat Gan 52900 Israel Ph: 972-3-5317638 FAX: 972-3-7384051 |
In reply to this post by spt
Hi Susan,
On Jun 17, 2011, at 6:02 AM, IMAGEJ automatic digest system wrote: > > Date: Thu, 16 Jun 2011 16:46:16 -0400 > From: Susan Travers <[hidden email]> > Subject: converting oib 12 bit stacks to 8 bit tif stacks- potential problem? > > Hi, > > We are using an Olympus Fluoview confocal to take z-stacks before > bringing them into Image J. Because we want to analyze a large area, we > have to take 2 side-by-side stacks and then use the "stitch" function in > Image J to create a montage. > Are you using the Stitching plugin from Fiji (is just imageJ, batteries included) Thats the best solution. http://pacific.mpi-cbg.de/wiki/index.php/Stitching_2D/3D Use the 3D stitching version of the plugin if you only stitch 2 z stacks. > > > It turns out that the staining that we are looking at is overall, > brighter on one side of the montage than the other. Although we leave > the confocal settings identical for the two photos, it seems as if the > difference between the two sides may be exaggerated in Image J; the > "seam" between the 2 is clearly visible regardless of the blending > method we try. > > I am wondering if the fact that the confocal is taking 12 bit images, > but the tifs are imported as 8 bit images is somehow exaggerating the > contrast between them. > > Does this make sense to anyone and is there a workaround that anyone > knows of? Yes, it can make a certain amount of sense, if things are going a little wrong here: Make sure that you use the bioformats importer to open the oib files. When imageJ opens the files, since they are 12 bit, it must rescale the display to fit in the 8 bit range of your screen. the problem is that it tried to help you see what it there by setting the display range according to the pixel values in the images, which as you say are rather different in mean and range. In the next step, converting the images to 8 bit, so the stitching plugin can work, it uses the DISPLAY range so set the values from 0-255, and since the display ranges are different for the 2 images, one ends up being too bright compared to the other! This is a very very common mistake, and its very easy to make if you are not aware how the 8bit conversion uses the current display range. So, to avoid that, in the brightness/contrast tool (shift C) set the display range manually using the SET button for BOTH images Set min to 0 and max to the brightest pixel value in both images, or a high values that will not clip off too many pixels having even higher intensities that that. (look at the image intensity histogram, HISTOGRAM menu item) Now the images can be set to 8 bit and they will have the same relative brightness. And the stitching will give the proper result with no nasty artifact at the join of the tiles. cheers Dan > > Thanks so much, > > Susan Travers > > Ohio State University Dr. Daniel James White BSc. (Hons.) PhD Senior Microscopist / Image Visualisation, Processing and Analysis Light Microscopy and Image Processing Facilities Max Planck Institute of Molecular Cell Biology and Genetics Pfotenhauerstrasse 108 01307 DRESDEN Germany +49 (0)15114966933 (German Mobile) +49 (0)351 210 2627 (Work phone at MPI-CBG) +49 (0)351 210 1078 (Fax MPI-CBG LMF) http://www.bioimagexd.net BioImageXD http://pacific.mpi-cbg.de Fiji - is just ImageJ (Batteries Included) http://www.chalkie.org.uk Dan's Homepages https://ifn.mpi-cbg.de Dresden Imaging Facility Network dan (at) chalkie.org.uk ( white (at) mpi-cbg.de ) |
Free forum by Nabble | Edit this page |