Posted by
Michael Schmid on
URL: http://imagej.273.s1.nabble.com/Log-Math-Function-tp5020510p5020524.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