Posted by
Kenneth Sloan-2 on
Jan 18, 2021; 12:19pm
URL: http://imagej.273.s1.nabble.com/Code-review-tp5024381p5024388.html
I have not tried that, yet. Intuitively, it seems possible to lose
precision in cases where the “Enhance” step further narrows the range.
But, perhaps the conversion to Byte is itself more careful than the
conversion from 32-bit directly to Color.
I will try it. It looks like I should write a comprehensive set of test
cases to sort this out.
For that matter, I should probably try to replicate the failures I saw
earlier. Perhaps the problem was with something unrelated to the
conversions.
I’m at the stage now where what I have works for the (moderately
challenging) set of test cases I have - but I don’t have a clear
understanding on WHY some steps are necessary. Perhaps they are not?
All I know is that the 32-to-color case was broken and now works. Now, I
should try to break it again.
This is a bit separate from my original question, which is: I know that
some(most) of my steps are NOT necessary for source images that are NOT
32-bit. I was wondering if anyone had an opinion that these steps were
actually harmful (other than wasting time or space.
On the one hand, I come from a long tradition of counting every cycle and
every byte. On the other hand I like straight line code that is easy to
read, without special cases.
Thank you for the suggestion. I will experiment further.
On Mon, Jan 18, 2021 at 03:04 Dimiter Prodanov (imec) <
[hidden email]> wrote:
> Dear Ken,
>
> Have you also tried first to convert to a ByteProcessor ?
> When I resetMinAndMax before conversion I don't see issues with the range
> during conversion.
>
> Best regards,
>
> Dimiter
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
-Kenneth Sloan
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html