search.noResults

search.searching

dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
NetNotes


then call it real data. I might add, just to finish the thought, don’t save data as JPEG or any “compressed” format. Tat also changes the sci- entific content. Use only fully non-compressed data formats (RAW, TIFF, PNG,HMSA….) Nestor Your Friendly Neighborhood SysOp


I generally agree with what’s been said, but I think the “it’s sci-


entific data and therefore should never be deleted” argument has its limits. Anybody who uses an annular dark field or bright field detec- tor in STEM is physically compressing “scientific data”; as a lot of people have been showing lately, there is more information in the full spatially-resolved diffraction pattern for many samples. However, recording a spatially-resolved diffraction pattern at every probe posi- tion is obviously inconvenient if you don’t have a fast camera, and since the compression that a STEM detector performs is generally well-characterized, we all accept the physical compression that hap- pens when you only use a STEM detector and not a pixelated detector as a necessary loss of “scientific data.” As Chris pointed out, this argument applies to TEM images as


well: if you just want to measure particle size, you can probably reduce bit depth and still produce a fully quantitative analysis. If there’s a good reason to compress your image and you know exactly what you did, it’s hard to argue that this is worse scientific practice than using a STEM detector. Tyler Harvey tyler.harvey@uni-goettingen.de


I agree with Reinhart Rachel and Paul Voyles. Always save the 16


bit image. Be careful and deliberate with image processing. Te prob- lem we face is that human eyes have a limited grayscale capacity and cannot distinguish all the gray levels in the 16 bit image. Te micros- copist’s job is to faithfully represent the image information in the report. Tere are color maps that one can use to display an extended range of values. If you choose to do that, it is important to use a color bar that shows the mappings. Some color mappings such as the “jet” mapping that was the default in matplotlib was widely criticized for being misleading. Te Viridis color map was developed to be a much better representation. I am a firm believer that no image should be distributed without


a description of how the image was recorded and processed. Reports with images with short captions and links to details are most helpful to your readers - and yourself. Te statistician Karl Broman wrote: “Your closest collaborator is you six months from now and you do not respond to email. “I did a lot of microscopy, image processing, and image analysis during my career. Having such information in my archived reports helped when a client came to my lab months or even years later and wanted me to extend an analysis with new samples. John Minter jrminter@gmail.com”


Te reason 8 bit images are so ubiquitous is that the human eye


can only distinguish ∼50 gray levels at one time. Rounding up to 64 levels gives 6 bits of dynamic range-then add one bit above and below to avoid clipping, and voila-8 bits! Any more for images displayed to humans is a waste. However, do what Nestor says: whatever raw data comes from the camera, save it. Storage costs today are infinitesimal. A. John Mardinly John.Mardinly@asu.edu


If I could redirect the question a slightly different direction,


how much of that data is useful and where does noise overwhelm the worthwhile data? I admit that once the data has been collected, it should be saved. Even if there is a lot of noise, it may be possible to tease some worthwhile information out of it. Understand that I ask my question from the SEM side of the world and probably need a tuto- rial from someone on the TEM side. Under normal circumstances on the SEM, even on good strong


signals, noise dominates bits 7 and 8, and maybe even bit 6 or 5. I do a little exercise with new users to demonstrate this and try to persuade them that 16-bit images are a waste of space - at least in the SEM. I adjust contrast for the sample. I then try to find a nice


58 We routinely use the Zeiss 880 for spectral detection. Te 34


channel detector tops out at 690 or 700 nm but we can use an addi- tional GaAsP detector to catch the light from 700 to 750 nm in one additional bin. We also demoed the Nikon A1 and were happy with the spectral detector but forget the specific wavelengths. Michael Cammer Michael.Cammer@med.nyu.edu


Tank you Craig and Michael for your responses. Te point about


light splitting and sensitivity is well taken. Our current Zeiss 710 is in heavy demand so we’re favoring parallel over sequential spectral for speed, with GaAsP in the spectral detector for sensitivity. I think


www.microscopy-today.com • 2019 July


homogeneous area, but to be sure, I take that area and raise the mag- nification to a hundred thousand times. Te entire image should be at the same gray level. I collect an image under normal recording conditions (or at least set the dwell time to the same value of 30 us), and then look at the gray level histogram. If the peak is more than one gray level wide for an 8-bit image, and it always is, then the last bits are nothing but random noise. If the peak is 8 channels wide, then the last three bits are basically noise. And if bits 6–8 are noise, then why would I want to record bits 9–16 where they are nothing but noise? Now this is where I need some instruction on the TEM side,


on the SEM, we are adjusting the brightness and contrast to nicely fill the working range of the ADC. We get as much as we can out of those 8 bits. I would suppose that STEM in some imag- ing modes (e.g., HAADF) would be similar - that the output of the detector is scaled and then digitized. In other modes where a CCD is used to record the image, I suppose the count per pixel is collected as the raw value without scaling. What range of counts is usual? I certainly would expect they would routinely exceed 256 (8 bits). Maybe it is less than 4096 (12 bits) and certainly less than 65536 (16 bits). The count would determine the necessary depth for each pixel. I thus infer that TEM soſtware must scale the raw data before


display. Te bits would have been shiſted by several positions to get a decent image. Tat might explain why a 16-bit TEM image fails to display properly in some applications. I suppose those apps simply cut off the lower 8 bits and display the upper 8 bits rather than scaling to the maximum value. If the most significant couple bits were zero, then the image would be confined to the lower quarter of the gray- scale, which would not be very satisfactory. If I have misunderstood, someone please instruct me - preferably gently. Warren Straszheim wesaia@iastate.edu


Light and Confocal Microscopy


Confocal Listserver Fastest Spectral Acquisition/Unmixing Speed (Thread


Started April 23, 2019) Does anyone have a sense for how different point-scanning con-


focals compare in terms of speed of spectral acquisition for unmix- ing? I know that Zeiss and Nikon both have 34 parallel spectral channels and this seems like the fastest solution over a broad range (with Zeiss using GaAsP detectors so probably faster), just wonder- ing what others have experienced. G. Esteban Fernandez g.esteban. fernandez@gmail.com Te Zeiss and Nikon systems are fastest because they acquire in


parallel. Our Nikon A1 can capture spectral in 1us per pixel. Just keep in mind you are splitting your signal up into a large number of chan- nels, so you need fairly bright signal. I suggest demoing both systems to see what works best for you. If you are really signal starved, the sequential spectral systems like Leica and Olympus are more sensi- tive, but take longer to acquire and may have photobleaching issues depending on the photostability of your fluorophore. Craig Brideau craig.brideau@gmail.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68