Log Math Function

[Jacob Keller-2]

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

[Gabriel Landini]

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

[Jacob Keller-2]

 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
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

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

[Herbie]

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
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Jacob Keller-2]

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
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Jim Peterson]

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

[Jacob Keller-2]

>
> 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
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

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

[Jacob Keller-2]

>
> >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

[Michael Schmid]

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

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Cammer, Michael]

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

[Jacob Keller-2]

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
>

... [show rest of quote]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html