Does anyone know what is going on with the Log function in
process->math->Log? I have a post-Log'd image that goes up to 302, which seems rather high, esp considering that my pre-Log image maximum is 302. Does it just re-scale to the original min/max or something? Changing to 32-bit lowers the final numbers, but the numbers are still off. Any way to get the actual values for the logs? All the best, Jacob Keller -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
On Tuesday, 17 April 2018 20:08:10 BST you wrote:
> Does anyone know what is going on with the Log function in > process->math->Log? I have a post-Log'd image that goes up to 302, which > seems rather high, esp considering that my pre-Log image maximum is 302. > Does it just re-scale to the original min/max or something? > > Changing to 32-bit lowers the final numbers, but the numbers are still off. > Any way to get the actual values for the logs? Please read the online documentation. It is clearly explained. Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
By deductive reasoning from the documentation, the answer is that "log" in
imagej means base 2. I just found out that in general: - x = log y often means x = loge y in *mathematics* texts. - x = log y often means x = log10 y in *science* and *engineering* texts. - x = log y often means x = log2 y in *computer science* texts. This is pretty insane, almost guaranteeing we will stay in our fields and not understand each other. I had been used to Log = base10 and ln = base e, but never ran across the base2 parlance before. Maybe adding clarification to the imagej documentation below would help some of us non-computer-scientists? Here is the online documentation for the log function, clearly-explained for computer scientists ;) Log... For 8-bit images, applies the function *f(p) = log(p) * 255/log(255)* to each pixel (*p*) in the image or selection. For RGB images, this function is applied to all three color channels. For 16-bit images, the image min and max are used for scaling instead of 255. For float images, no scaling is done. To calculate log10 of the image, multiply the result of this operation by 0.4343 (1/log(10). On Tue, Apr 17, 2018 at 3:17 PM, Gabriel Landini <[hidden email]> wrote: > On Tuesday, 17 April 2018 20:08:10 BST you wrote: > > Does anyone know what is going on with the Log function in > > process->math->Log? I have a post-Log'd image that goes up to 302, which > > seems rather high, esp considering that my pre-Log image maximum is 302. > > Does it just re-scale to the original min/max or something? > > > > Changing to 32-bit lowers the final numbers, but the numbers are still > off. > > Any way to get the actual values for the logs? > > Please read the online documentation. It is clearly explained. > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
On Tuesday, 17 April 2018 20:55:48 BST [hidden email] wrote:
> By deductive reasoning from the documentation, the answer is that "log" in > imagej means base 2. No, the documentation specifies "ln", i.e. in base e. And it works fine and the conversion recipe to log10 is correct too. Perhaps you are getting confused because the command is listed in the menu as "Log". Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
In reply to this post by Jacob Keller-2
Good day Jacob,
I don't know what is insane for you but ImageJ uses the natural logarithm per default, i.e. the log_e. Other logarithms can easily be computed from log_e and the manual even explains it for log_10. BTW, the log_2 is used to compute entropy etc. Still some headaches? Hopefully not Herbie :::::::::::::::::::::::::::::::::::::::::: am 17.04.18 um 21:55 schrieb Jacob Keller: > By deductive reasoning from the documentation, the answer is that "log" in > imagej means base 2. I just found out that in general: > > - x = log y often means x = loge y in *mathematics* texts. > > - x = log y often means x = log10 y in *science* and *engineering* > texts. > > - x = log y often means x = log2 y in *computer science* texts. > > This is pretty insane, almost guaranteeing we will stay in our fields and > not understand each other. I had been used to Log = base10 and ln = base e, > but never ran across the base2 parlance before. Maybe adding clarification > to the imagej documentation below would help some of us > non-computer-scientists? Here is the online documentation for the log > function, clearly-explained for computer scientists ;) > Log... > For 8-bit images, applies the function *f(p) = log(p) * 255/log(255)* to > each pixel (*p*) in the image or selection. For RGB images, this function > is applied to all three color channels. For 16-bit images, the image min > and max are used for scaling instead of 255. For float images, no scaling > is done. To calculate log10 of the image, multiply the result of this > operation by 0.4343 (1/log(10). > > > > > > > > On Tue, Apr 17, 2018 at 3:17 PM, Gabriel Landini <[hidden email]> > wrote: > >> On Tuesday, 17 April 2018 20:08:10 BST you wrote: >>> Does anyone know what is going on with the Log function in >>> process->math->Log? I have a post-Log'd image that goes up to 302, which >>> seems rather high, esp considering that my pre-Log image maximum is 302. >>> Does it just re-scale to the original min/max or something? >>> >>> Changing to 32-bit lowers the final numbers, but the numbers are still >> off. >>> Any way to get the actual values for the logs? >> >> Please read the online documentation. It is clearly explained. >> >> Cheers >> >> Gabriel >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
In reply to this post by Gabriel Landini
I copied and pasted the documentation as found at
https://imagej.nih.gov/ij/docs/menus/process.html#math, and it does not specify natural log??? Is there another place for documentation? Again, here it is: Log...For 8-bit images, applies the function *f(p) = log(p) * 255/log(255)* to each pixel (*p*) in the image or selection. For RGB images, this function is applied to all three color channels. For 16-bit images, the image min and max are used for scaling instead of 255. For float images, no scaling is done. To calculate log10 of the image, multiply the result of this operation by 0.4343 (1/log(10). After a bit of searching, I found this page: http://imagej.net/docs/guide/146-29.html#toc-Subsection-29.9 where it seems to have been improved: 29.9.12 Log For 8-bit images, applies the function *f*(*p*) = ln(*p*) × 255 ⁄ ln(255) to each pixel (*p*) in the image or selection. For RGB images, this function is applied to all three color channels. For 16-bit images, the image min and max are used for scaling instead of 255. For float images, no scaling is done. To calculate log10 of the image, multiply the result of this operation by 0.4343 (1 ⁄ ln(10)). Anyway, perhaps, as you imply, the term "log" could be changed in future process>math> menus to "ln?" It certainly would have helped avoid my confusion. Who knows, there may be some scientific mistakes out there due to this notation issue. JPK On Tue, Apr 17, 2018 at 4:16 PM, Gabriel Landini <[hidden email]> wrote: > On Tuesday, 17 April 2018 20:55:48 BST [hidden email] wrote: > > By deductive reasoning from the documentation, the answer is that "log" > in > > imagej means base 2. > > No, the documentation specifies "ln", i.e. in base e. > And it works fine and the conversion recipe to log10 is correct too. > > Perhaps you are getting confused because the command is listed in the menu > as > "Log". > > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
The key point for the original question is that the final value is scaled, but has nothing to do with base.
Just remember that to convert from base a to base b: log_a(x) = log_b(x)/log_b(a). Apply this to the log quotient in the equation below and you'll see that the conversion factors in the numerator and denominator cancel, so the base is completely irrelevant. - Jim On 4/17/18, 4:52 PM, "Jacob Keller" <[hidden email]> wrote: I copied and pasted the documentation as found at https://imagej.nih.gov/ij/docs/menus/process.html#math, and it does not specify natural log??? Is there another place for documentation? Again, here it is: Log...For 8-bit images, applies the function *f(p) = log(p) * 255/log(255)* to each pixel (*p*) in the image or selection. For RGB images, this function is applied to all three color channels. For 16-bit images, the image min and max are used for scaling instead of 255. For float images, no scaling is done. To calculate log10 of the image, multiply the result of this operation by 0.4343 (1/log(10). After a bit of searching, I found this page: http://imagej.net/docs/guide/146-29.html#toc-Subsection-29.9 where it seems to have been improved: 29.9.12 Log For 8-bit images, applies the function *f*(*p*) = ln(*p*) × 255 ⁄ ln(255) to each pixel (*p*) in the image or selection. For RGB images, this function is applied to all three color channels. For 16-bit images, the image min and max are used for scaling instead of 255. For float images, no scaling is done. To calculate log10 of the image, multiply the result of this operation by 0.4343 (1 ⁄ ln(10)). Anyway, perhaps, as you imply, the term "log" could be changed in future process>math> menus to "ln?" It certainly would have helped avoid my confusion. Who knows, there may be some scientific mistakes out there due to this notation issue. JPK On Tue, Apr 17, 2018 at 4:16 PM, Gabriel Landini <[hidden email]> wrote: > On Tuesday, 17 April 2018 20:55:48 BST [hidden email] wrote: > > By deductive reasoning from the documentation, the answer is that "log" > in > > imagej means base 2. > > No, the documentation specifies "ln", i.e. in base e. > And it works fine and the conversion recipe to log10 is correct too. > > Perhaps you are getting confused because the command is listed in the menu > as > "Log". > > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html --- The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
>
> The key point for the original question is that the final value is scaled, > but has nothing to do with base. > > Just remember that to convert from base a to base b: > log_a(x) = log_b(x)/log_b(a). > > Apply this to the log quotient in the equation below and you'll see that > the conversion factors in the > numerator and denominator cancel, so the base is completely irrelevant. > It matters in my case since I want the actual values and not just relative ones. The documentation says there is no scaling for 32-bit images, so getting actual values should be doable now that I know "log" here means base e. Accordingly, my personal problem is solved, but perhaps it would be good, as I suggested already, to switch "log" to "ln" in the pull-down menu, and maybe even a warning window that the values will be scaled if not 32bit? Or is that overkill? JPK > > On 4/17/18, 4:52 PM, "Jacob Keller" <[hidden email]> wrote: > > I copied and pasted the documentation as found at > https://imagej.nih.gov/ij/docs/menus/process.html#math, and it does > not > specify natural log??? Is there another place for documentation? Again, > here it is: > > Log...For 8-bit images, applies the function *f(p) = log(p) * > 255/log(255)* to > each pixel (*p*) in the image or selection. For RGB images, this > function > is applied to all three color channels. For 16-bit images, the image > min > and max are used for scaling instead of 255. For float images, no > scaling > is done. To calculate log10 of the image, multiply the result of this > operation by 0.4343 (1/log(10). > > > After a bit of searching, I found this page: > http://imagej.net/docs/guide/146-29.html#toc-Subsection-29.9 where it > seems > to have been improved: > > > 29.9.12 Log > For 8-bit images, applies the function *f*(*p*) = ln(*p*) × 255 ⁄ > ln(255) to > each pixel (*p*) in the image or selection. For RGB images, this > function > is applied to all three color channels. For 16-bit images, the image > min > and max are used for scaling instead of 255. For float images, no > scaling > is done. To calculate log10 of the image, multiply the result of this > operation by 0.4343 (1 ⁄ ln(10)). > > > Anyway, perhaps, as you imply, the term "log" could be changed in > future > process>math> menus to "ln?" It certainly would have helped avoid my > confusion. Who knows, there may be some scientific mistakes out there > due > to this notation issue. > > JPK > > > > > On Tue, Apr 17, 2018 at 4:16 PM, Gabriel Landini <[hidden email] > > > wrote: > > > On Tuesday, 17 April 2018 20:55:48 BST [hidden email] wrote: > > > By deductive reasoning from the documentation, the answer is that > "log" > > in > > > imagej means base 2. > > > > No, the documentation specifies "ln", i.e. in base e. > > And it works fine and the conversion recipe to log10 is correct too. > > > > Perhaps you are getting confused because the command is listed in > the menu > > as > > "Log". > > > > > > Cheers > > > > Gabriel > > > > -- > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > > --- > > The information in this email, including attachments, may be confidential > and is intended solely for the addressee(s). If you believe you received > this email by mistake, please notify the sender by return email as soon as > possible. > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
In reply to this post by Jacob Keller-2
On Tuesday, 17 April 2018 21:52:27 BST [hidden email] wrote:
> Anyway, perhaps, as you imply, the term "log" could be changed in future > process>math> menus to "ln?" It certainly would have helped avoid my > confusion. Well, I am not implying to change it. I guess the command is named Log because in Java Math.log is the function that returns the natural logarithm (ln). See: https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#log(double) Note that there is a log10 function too, but there is no function ln. So whichever way one looks at this, it could eventually end up being confusing to somebody. Jim's comment I think applies to rescaled results in 8, 16 and 24bit images, but not to 32bit images. Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
>
> >So whichever way one looks at this, it could eventually end up being > confusing to somebody. > I don't think so; they could be notated as "Log_e," (or just "ln"--everyone knows what that means) "Log_2," "Log_10," etc., and everything would be peachy. Although I understand the reasons why it came to be, based on the Java function, "Log" is downright misleading. As for the scaling, I guess that's a fairly intuitive thing for the user that scaling would have to occur, but I wonder whether it would be useful to have a dialog pop up whenever scaling occurs "values rescaled"? Or just auto-convert to 32-bit? "Image calculator" asks whether you want to convert to 32 bit, and that might work here as well. I suspect the interest in doing this is pretty low, though. JPK Jim's comment I think applies to rescaled results in 8, 16 and 24bit > images, > but not to 32bit images. > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Jacob,
I think it would be a nuisance to have a pop-up dialog telling me that 'log' is natural logarithm, and/or that scaling was done. I would have to click it away. To me, it is pretty obvious that scaling needs to be done because an 'integer' image type (8 bit, 16 bit) would otherwise have very poor resolution for the log. Automatically converting to 32 bits would make existing macros work incorrectly if they use this function and rely on the current behavior. So I don't see much room for improvement. One could think of displaying a message in the status line, but probably it would be overlooked anyhow. By the way, most programming languages use 'log' for natural (base-e) logarithm: C, C++, Java, JavaScript, Fortran, Visual Basic, Python, Mathematica, Matlab, R, Wolfram Alpha, Ruby,... Only Pascal has ln; there log is for arbitrary base. In Maple one can use both, ln and log for base e; the latter can be also also used for arbitrary base. I am not aware of any programming language where 'log' stands for 10-base logarithm. Most pocket calculators use 'log' for base 10 (some use 'lg') - yes this is confusing, but I fear it's nothing that can be solved by ImageJ. --- For me, the only possible solution along your line of suggestions would be adding Process>Math>Log10 and Process>Math>LogE, which would convert to 32 bits. But this would be some work (There is no type conversion in ImageMath so far, it would require a different 'undo' strategy, etc.). Also, it would be unclear what to do with RGB images. And anyhow, it would not be self-explaining what the difference between Log, Log10 and LogE could be. More verbose names 'Log (Float Output)', 'Log10 (Float Output)' would be rather clumsy menu items. So I don't think it's worthwhile, if the user could simply convert the image to 32 bits before running 'Log'. So far my three cents... Michael ________________________________________________________________ On 17/04/2018 23:43, Jacob Keller wrote: >> >>> So whichever way one looks at this, it could eventually end up being >> confusing to somebody. >> > > I don't think so; they could be notated as "Log_e," (or just "ln"--everyone > knows what that means) "Log_2," "Log_10," etc., and everything would be > peachy. Although I understand the reasons why it came to be, based on the > Java function, "Log" is downright misleading. > > As for the scaling, I guess that's a fairly intuitive thing for the user > that scaling would have to occur, but I wonder whether it would be useful > to have a dialog pop up whenever scaling occurs "values rescaled"? Or just > auto-convert to 32-bit? "Image calculator" asks whether you want to convert > to 32 bit, and that might work here as well. I suspect the interest in > doing this is pretty low, though. > > JPK -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Am I missing something, or can these arguments be corrected with the following simple macro code?
newImage("256x256", "8-bit ramp", 256, 256, 1); run("32-bit"); run("Log"); run("Divide...", "value=2.302585"); // constant to convert to base 10 resetMinAndMax(); Michael Cammer, Sr Research Scientist, DART Microscopy Laboratory NYU Langone Health, 540 First Avenue, SK2 Microscopy Suite, New York, NY 10016 C: 914-309-3270 [hidden email] http://nyulmc.org/micros http://microscopynotes.com/ -----Original Message----- From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Michael Schmid Sent: Wednesday, April 18, 2018 7:07 AM To: [hidden email] Subject: Re: Log Math Function Hi Jacob, I think it would be a nuisance to have a pop-up dialog telling me that 'log' is natural logarithm, and/or that scaling was done. I would have to click it away. To me, it is pretty obvious that scaling needs to be done because an 'integer' image type (8 bit, 16 bit) would otherwise have very poor resolution for the log. Automatically converting to 32 bits would make existing macros work incorrectly if they use this function and rely on the current behavior. So I don't see much room for improvement. One could think of displaying a message in the status line, but probably it would be overlooked anyhow. ------------------------------------------------------------ This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email. ================================= -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Michael,
Your code and other workarounds are fine, but the problem is for unsuspecting users (like me two days ago) who assume log means Log10, and also who are not aware of the scaling issue. Also, I am not entirely clear why for 16-bit images the final range is not the entire 16-bit range but simply the original range. Is this for error propagation? The problem is basically the misleading nature of the menu item "log." But I appreciate the stickiness of redoing things. Couldn't one simply rename the menu item LogE, and keep the underlying "log" command intact somehow, in order not to break existing code? JPK Am I missing something, or can these arguments be corrected with the > following simple macro code? > > newImage("256x256", "8-bit ramp", 256, 256, 1); > run("32-bit"); > run("Log"); > run("Divide...", "value=2.302585"); // constant to convert to base 10 > resetMinAndMax(); > > Michael Cammer, Sr Research Scientist, DART Microscopy Laboratory > NYU Langone Health, 540 First Avenue, SK2 Microscopy Suite, New York, NY > 10016 > C: 914-309-3270 [hidden email] http://nyulmc.org/micros > http://microscopynotes.com/ > > > > -----Original Message----- > From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of > Michael Schmid > Sent: Wednesday, April 18, 2018 7:07 AM > To: [hidden email] > Subject: Re: Log Math Function > > Hi Jacob, > > I think it would be a nuisance to have a pop-up dialog telling me that > 'log' is natural logarithm, and/or that scaling was done. I would have to > click it away. > > To me, it is pretty obvious that scaling needs to be done because an > 'integer' image type (8 bit, 16 bit) would otherwise have very poor > resolution for the log. > > Automatically converting to 32 bits would make existing macros work > incorrectly if they use this function and rely on the current behavior. > > So I don't see much room for improvement. One could think of displaying a > message in the status line, but probably it would be overlooked anyhow. > > > ------------------------------------------------------------ > This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain information that is proprietary, > confidential, and exempt from disclosure under applicable law. Any > unauthorized review, use, disclosure, or distribution is prohibited. If you > have received this email in error please notify the sender by return email > and delete the original message. Please note, the recipient should check > this email and any attachments for the presence of viruses. The > organization accepts no liability for any damage caused by any virus > transmitted by this email. > ================================= > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Edit this page |