oval profile plug in
Locked
 
|
I have some problems dowloading and running the oval profile plug in
(http://rsb.info.nih.gov/ij/plugins/oval-profile.html). Can sombody help me? thanks Marta -- Marta Mattotti, PhD student Bio/non-bio interactions for regenerative medicine group IBEC - Institute for Bioengineering of Catalonia, Barcelona, Spain tel (+34) 93 402 4288 fax (+34) 93 402 4249 [hidden email] http://www.ibecbarcelona.eu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
|
1. copy the oval_profile code text from the website.
2. paste it in notepad 3. save it as "oval_profile.java" in plugin directory. 4. open your image in imageJ. 5. make an oval selection. 6. plugin>compile and run... 7. select "overall_profile.java" in browse menu. you can also define a shorcut at next opening of imagej. ali... --- On Tue, 10/21/08, marta mattotti <[hidden email]> wrote: From: marta mattotti <[hidden email]> Subject: oval profile plug in To: [hidden email] Date: Tuesday, October 21, 2008, 7:31 AM I have some problems dowloading and running the oval profile plug in (http://rsb.info.nih.gov/ij/plugins/oval-profile.html). Can sombody help me? thanks Marta -- Marta Mattotti, PhD student Bio/non-bio interactions for regenerative medicine group IBEC - Institute for Bioengineering of Catalonia, Barcelona, Spain tel (+34) 93 402 4288 fax (+34) 93 402 4249 [hidden email] http://www.ibecbarcelona.eu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
|
In reply to this post by marta mattotti
Hi there,
sorry but I do not seem to easily find the answer: If I read in a JPEG file, will ImageJ correctly take into account that the Intensity data are stored nonlinearly with a gamma of (around) 2.2? I wonder because actually that would mean reading aJPEG needs to create at least a 16Bit image (not an 8Bit) to avoid loosing dynamics. I could not find details in the sourcecode, as the JPEG reader seems to rely on Java JDK )or similar) code. Sincerely Joachim ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
|
Hi Joachim,
See the ImageJ documentation for the menu command Analyze->Calibrate... for how you can use ImageJ to convert your image's pixel values to calibrated image density values. From there, you can use ImageJ image processing functions to convert the pixel values into approximate, linear 16 bit intensity values. But the calibration accuracy and precision is up to you. Your point about ImageJ needing to create a 16 bit image to preserve the information is wrong in the sense that the precise intensity information was lost when the image was compressed to the JPEG format. Depending of the JPEG "quality factor" used, your image data could have much less than 8 bits of precision, especially for small details in the image. JPEG image processing cameras also usually do other processing such as color boosting, noise filtering and edge enhancement that can distort your image data. That is why you should select and use a camera that offers non-destructive image formats such as TIFF or RAW, if the precise intensity data is important for your application. -- Harry Parker Senior Imaging Systems Engineer Digital Imaging Systems, Inc. ----- Original Message ---- From: Joachim Wesner <[hidden email]> To: [hidden email] Sent: Tuesday, October 21, 2008 3:51:59 PM Subject: JPEG Gamma Hi there, sorry but I do not seem to easily find the answer: If I read in a JPEG file, will ImageJ correctly take into account that the Intensity data are stored nonlinearly with a gamma of (around) 2.2? I wonder because actually that would mean reading aJPEG needs to create at least a 16Bit image (not an 8Bit) to avoid loosing dynamics. I could not find details in the sourcecode, as the JPEG reader seems to rely on Java JDK )or similar) code. Sincerely Joachim ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
|
Hi
first I know one should at best not use JPEG for quatitative imaging, however I happened to have some image from a cheap camera where I wanted to read off intensity at best as it can get and realizing that there is this HUGE gamma > 2 issue I was wondering what actually is going on..... Thanks for the answer, even if I don´t agree with part 2. Let´s forget about compression for the moment, what I´m trying to say here that a gamma encoded JPEG (and I think ALL are, even the "unboosted ones") actually has an intensity range much larger than 256, even more than 65536 if gamma is really > 2 if I understand the issue correctly. Talking about "Bits" of information is a bit misleading if nonlinear encoding is envolved and also only makes sense in connection with a noise model. Actually, if the sensor is photon noise limited (as most even cheap ones are today at least at intermediate light levels), there will be no *constant* additive noise involved, but noise that increases with the sqrt of the intensity. Using a quadratic encoding actually is optimal for that noise statistics as the nonlinear intensity levels of the 8 bits would be spread in an optimum way over the intensity range of up to 65536 relative to the varying noise "floor". If you would encode linearly and only use the upper 8 bits, you would loose a lot against the original data for low light intensity. It might be, and that was my question, that Imagej actually read in the still gamma compressed intensity data. THEN, Yes, there would be no loss in information, but one certainly should not try to read off any intensity info from the data or even try image processing. On the other hand to do the processing, one would need to restore the full 16 bit range even in bright regions most "bits" are only noise! (Actually I know that most cheap sensors have a so called full well capacity much less than 65000 electrons, so the useable dynamic range wrt lightinetsity would be much less than 65000, but certainly still higher than 256:1) I hope one can get my point, probably I am mislead here. See here http://en.wikipedia.org/wiki/Gamma_correction " In any case, binary data in still image files (as JPEG) are explicitly encoded (that is, they carry gamma-encoded values, not linear intensities), as are motion picture files (such as MPEG). " Joachim ____________________________________________ Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht Wetzlar HRB 2432 Geschäftsführer: Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy Martyr | Colin Davis Harry Parker <harrylparker@YAH OO.COM> An Gesendet von: [hidden email] ImageJ Interest Kopie Group <[hidden email]. Thema GOV> Re: JPEG Gamma 22.10.2008 17:04 Bitte antworten an Harry Parker <harrylparker@GMA IL.COM> Hi Joachim, See the ImageJ documentation for the menu command Analyze->Calibrate... for how you can use ImageJ to convert your image's pixel values to calibrated image density values. From there, you can use ImageJ image processing functions to convert the pixel values into approximate, linear 16 bit intensity values. But the calibration accuracy and precision is up to you. Your point about ImageJ needing to create a 16 bit image to preserve the information is wrong in the sense that the precise intensity information was lost when the image was compressed to the JPEG format. Depending of the JPEG "quality factor" used, your image data could have much less than 8 bits of precision, especially for small details in the image. JPEG image processing cameras also usually do other processing such as color boosting, noise filtering and edge enhancement that can distort your image data. That is why you should select and use a camera that offers non-destructive image formats such as TIFF or RAW, if the precise intensity data is important for your application. -- Harry Parker Senior Imaging Systems Engineer Digital Imaging Systems, Inc. ----- Original Message ---- From: Joachim Wesner <[hidden email]> To: [hidden email] Sent: Tuesday, October 21, 2008 3:51:59 PM Subject: JPEG Gamma Hi there, sorry but I do not seem to easily find the answer: If I read in a JPEG file, will ImageJ correctly take into account that the Intensity data are stored nonlinearly with a gamma of (around) 2.2? I wonder because actually that would mean reading aJPEG needs to create at least a 16Bit image (not an 8Bit) to avoid loosing dynamics. I could not find details in the sourcecode, as the JPEG reader seems to rely on Java JDK )or similar) code. Sincerely Joachim ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
|
Hi Joachim,
Your guess and understanding is correct. ImageJ does not manipulate the pixel values of JPEG images. The 8 bit values you read in ImageJ are the nonlinear mapping of the image's values as calculated in the camera and stored in the JPEG image. Also inversely nonlinear is the response of your display screen. Displays also have a range greater than 256, but not high enough to display the full range which can be captured by even moderately priced cameras. The 2 are only roughly matched. So consumer cameras do "tone mapping" in addition to gamma compression to match the higher dynamic range of scenes to the somewhat lower dynamic range of displays. This tone mapping is controlled in some cameras with a "contrast" setting. A "low" contrast setting may be close to a 1 to 1 tone mapping, but you need to measure it to know for sure. So the gamma formula is only approximately correct for a given camera image. Since human perception follows a geometric progression, the gamma intensity compression (in cameras) and expansion (in displays and printers) works well to keep the steps between the 256 levels invisible, unless significant processing has been applied to the signal. Consumer cameras have at most 12 bit digitizers in them, so 4000:1 is their best possible dynamic range. But the thermal noise sources are much greater than that, unless you take extra steps, like cooling the sensors to well below freezing, as astronomers do to take their images. You have a very good camera if the signal to noise ratio is better than, say 1000:1. You may also be interested to know that Kodak developed a proprietary format to encode extended dynamic range information in JPEG images. Kodak licensed printers know how to read and use that extended range information. That is one reason commercial prints may look better than what you can get on your home printer, or better than what you see on your screen. I'm not aware on any public domain software that can read that extra dynamic range information. The best you can do to get intensity data from a cheap camera is to take an image of a calibrated target with known density or transmission characteristics with a known lighting level, with as similar camera and scene conditions as possible, compared to the image you want to analyze. Then use ImageJ's calibration feature to find the mapping between digital values and density, which maps by a simple formula to reflectivity and intensity. -- Harry Parker Senior Imaging Systems Engineer Digital Imaging Systems, Inc. ----- Original Message ---- From: Joachim Wesner <[hidden email]> To: [hidden email] Sent: Wednesday, October 22, 2008 3:16:39 PM Subject: Antwort: Re: JPEG Gamma Hi first I know one should at best not use JPEG for quatitative imaging, however I happened to have some image from a cheap camera where I wanted to read off intensity at best as it can get and realizing that there is this HUGE gamma > 2 issue I was wondering what actually is going on..... Thanks for the answer, even if I don´t agree with part 2. Let´s forget about compression for the moment, what I´m trying to say here that a gamma encoded JPEG (and I think ALL are, even the "unboosted ones") actually has an intensity range much larger than 256, even more than 65536 if gamma is really > 2 if I understand the issue correctly. Talking about "Bits" of information is a bit misleading if nonlinear encoding is envolved and also only makes sense in connection with a noise model. Actually, if the sensor is photon noise limited (as most even cheap ones are today at least at intermediate light levels), there will be no *constant* additive noise involved, but noise that increases with the sqrt of the intensity. Using a quadratic encoding actually is optimal for that noise statistics as the nonlinear intensity levels of the 8 bits would be spread in an optimum way over the intensity range of up to 65536 relative to the varying noise "floor". If you would encode linearly and only use the upper 8 bits, you would loose a lot against the original data for low light intensity. It might be, and that was my question, that Imagej actually read in the still gamma compressed intensity data. THEN, Yes, there would be no loss in information, but one certainly should not try to read off any intensity info from the data or even try image processing. On the other hand to do the processing, one would need to restore the full 16 bit range even in bright regions most "bits" are only noise! (Actually I know that most cheap sensors have a so called full well capacity much less than 65000 electrons, so the useable dynamic range wrt lightinetsity would be much less than 65000, but certainly still higher than 256:1) I hope one can get my point, probably I am mislead here. See here http://en.wikipedia.org/wiki/Gamma_correction " In any case, binary data in still image files (as JPEG) are explicitly encoded (that is, they carry gamma-encoded values, not linear intensities), as are motion picture files (such as MPEG). " Joachim ____________________________________________ Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht Wetzlar HRB 2432 Geschäftsführer: Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy Martyr | Colin Davis Harry Parker <harrylparker@YAH OO.COM> An Gesendet von: [hidden email] ImageJ Interest Kopie Group <[hidden email]. Thema GOV> Re: JPEG Gamma 22.10.2008 17:04 Bitte antworten an Harry Parker <harrylparker@GMA IL.COM> Hi Joachim, See the ImageJ documentation for the menu command Analyze->Calibrate... for how you can use ImageJ to convert your image's pixel values to calibrated image density values. From there, you can use ImageJ image processing functions to convert the pixel values into approximate, linear 16 bit intensity values. But the calibration accuracy and precision is up to you. Your point about ImageJ needing to create a 16 bit image to preserve the information is wrong in the sense that the precise intensity information was lost when the image was compressed to the JPEG format. Depending of the JPEG "quality factor" used, your image data could have much less than 8 bits of precision, especially for small details in the image. JPEG image processing cameras also usually do other processing such as color boosting, noise filtering and edge enhancement that can distort your image data. That is why you should select and use a camera that offers non-destructive image formats such as TIFF or RAW, if the precise intensity data is important for your application. -- Harry Parker Senior Imaging Systems Engineer Digital Imaging Systems, Inc. ----- Original Message ---- From: Joachim Wesner <[hidden email]> To: [hidden email] Sent: Tuesday, October 21, 2008 3:51:59 PM Subject: JPEG Gamma Hi there, sorry but I do not seem to easily find the answer: If I read in a JPEG file, will ImageJ correctly take into account that the Intensity data are stored nonlinearly with a gamma of (around) 2.2? I wonder because actually that would mean reading aJPEG needs to create at least a 16Bit image (not an 8Bit) to avoid loosing dynamics. I could not find details in the sourcecode, as the JPEG reader seems to rely on Java JDK )or similar) code. Sincerely Joachim ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |