NetNotes
I would bet that a typical user could not pick which image is at what bit depth.
Having said all that, I know that most common image handlers,
like ImageJ, will handle most anything you throw at them. I’m a bit of a data hoarder, and with most universities offering unlimited google drive storage, I find that saving in both 16 bit and 8 bit gives me my cake and lets me eat it too (not at the microscope console, though!). If you don’t have unlimited Google Drive storage, you can find
10 TB hard drives on sale. Tat’s a lot of storage! Tanks for starting this interesting discussion. Looking for-
ward to reading other thoughts on this matter. Chris microwink@
gmail.com
> I have a similar question for TEM data. Te new cameras on
TEMs result in 16 bit images.< Tis is not new, at all. First, aſter analog recording on negatives,
and later digitization, I cannot remember having stored only 8 bit data back in my early times in the 1980s. I have ALWAYS stored all data in 16 bit mode. Te first camera we bought in the 1990s (it was a used one), a TVIPS 1k×1k camera, already recorded data with 12 bit depth and stored them as 16 bit files. Tese files could easily be handled in the 1990s by either ImageJ (which at that time already existed), or could be converted and saved as an extra file in 8 bit mode using the commercial TVIPS soſtware EM-MENU3 (today, v.4). And I think, the same holds true for quite a number of the early EM cam- eras (maybe I am wrong?). Doing all this was part of my training of people using the EM. > When reducing bit depth, what is the best algorithm? < I would
not trust any algorithm. Tis is part of the early steps in image pro- cessing, and people have to learn this as one of the first steps (in any lab, my argument). If you do not want to use commercial soſtware I would recommend ImageJ/Fiji - a soſtware package which is “free.” > Is it ok to save only the 8 bit data and not bother with the 16 bit
data? < simply, NO. Saving 8bit only is not ok, IMO. > Most people may not be prepared to deal with 16 bit data or
consider it inconvenient.< this is loss of scientific data … just make people aware of this. >to Chris “microwink” < 1. Gatan hardware and soſtware is widely distributed, and Gatan’s sw can handle most of these tasks easily. Tere are image converters for Gatan’s unique file format everywhere, and the rest, people have to learn. - I assume (although do not know) that other camera manufacturer offer similar soſtware. At least TVIPS does.
2. 16 bit vs 8 bit data on Windows / Mac: this is not so much a problem of the operating system but of the 8bit displays we have. Tis is a longer story to explain. - But at the end, people have to learn to use proper SOFTWARE for analyzing EM data and histograms, and to save data in the proper format, for (a) scientific purposes , and for (b) generating slides for presenta- tions and for publications. Again, there is a learning curve …
3. It all depends what the user wants to do … but people have to be aware of data compression and to become familiar with the soſtware. We are not taking pictures; we do generate sci- entific data.
4. Sorry, Chris - NO: I do not tell people to store primary sci- entific data on a Google server. NEVER. Data are stored on University servers (tape roboter, etc.). Reinhard Rachel rein-
hard.rachel@biologie.uni-regensburg.de
Excellent points. For universities using the Google Suite ser-
vices integration, it’s actually the university IT department who is in charge of data management, retention, and oversight. Of course, Google could peer into your data if they wanted, or were compelled to by a government agency, but there are easy ways to encrypt data uploaded to the cloud automatically using soſtware like rsync or rclone. For sensitive data, like ITAR or corporate R&D,
56
then obviously storing data on the cloud is prohibited. I’m not sure that images of gold nanoparticles, for example, warrant such care- ful scrutiny, but ultimately each user is responsible their own data. Chris
microwink@gmail.com
From the prospective of a materials science TEMmer, I believe
it is never wise to discard the original, full bit-depth images acquired from the detector. For much of my work, the absolute value of the detected intensity (the number of high energy electrons per pixel) is important. Te connection between the digital counts and the data we want is best known and most consistent for full bit depth images. A fixed, linear mapping from 16 to 8 bits could be OK if the number of detected electrons is small. However, conversions to 8 bit designed for desktop publishing are dangerous because the look-up table used for conversion both changes for every image and (in general) is not preserved with the file. Once an unknown, undocumented transfor- mation of the data has been made, the original intensity values are lost. We routinely convert to 8 bit images to make figures or to share images conveniently with colleagues, but we always keep the original data as close to the detector as we can. Disk space is cheap - keep your images! Paul Voyles
paul.voyles@wisc.edu
I just wanted to add a comment to reducing things to 8 bit
from the original image. An old mentor of mine would always run around reminding people that 1) data is data, you don’t change it and 2) microscopy images are data. You wouldn’t run an assay, than only save an interpretation of the data and not the original data. Should be the same here, you wouldn’t take an image, then reduce bit depth requiring a loss of “scientific data” as Dr. Reinhard mentioned, and only save that. You should always be able to get back to the original image as taken from the microscope. Te only argument against this may be that more data intensive techniques like light-sheet, but even then there is some debate on what would be considered the original image that needs to be saved for archival reasons. Te only real problem with 12/16 bit may be displaying it on
Windows, which if you are using the photo viewer it shouldn’t be real analysis. So for my users on a Leica confocal, I’ll teach them how to manipulate the .lif file in ImageJ, and guide them towards using that for their analysis (at the very least how to open, mark, and save tiff files from) and then also save the final image from there, so they have the original image with all metadata and whatever bit depth it was taken at, and reduced images for easy presentation. I would avoid any automated reduction if possible. Photoshop used
to show you clipped pixels when changing curves, unsure if there is an easy option to do so in ImageJ but certainly possible. Ten it becomes a question of whether what is being clipped either from the dark or bright regions is of value and how much is acceptable loss for the downstream analysis (if only presenting the image you generally need to way over- saturate it, if doing mean intensity then you want to avoid any over- saturation in ROIs). Jason Saredy
rockman507@gmail.com
Tis topic has a very long history. I will agree with Reinhard and
others. Don’t go to 8 bits. Upgrade your data visualization/analysis programs! I also will refer everyone reading this post to the Micros- copy Society of America Scientific Data Resource page which also addresses
this issue:
https://www.microscopy.org/resources/scien-
tific_data Te MSA policy which has been in place since 2003 (and I helped
establish this policy) is below. It clearly elucidates that all data needs to be saved in the original “raw” data format. Compressing/altering in any form must be documented in all cases. Te argument that Win- dows and the users cannot display the data holds no water. Windows is not a scientist, you and your users are, and you must control your data. Not a poorly written operating system, and the users also need to get properly trained to understand why. Te simple message is: if you recorded data at 8 bits that is fine, but don’t down sample (which changes the scientific content), and
www.microscopy-today.com • 2019 July
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
