Re: Code review?7)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Code review?7)

Dimiter Prodanov (imec)
Hi Ken,

The contrast enhancement of a FloatProcessor does not change the pixel values.
It is used only for display purposes and during conversion to adjust to the proper visual(!) dynamic range.
You compute the contrast map by calling resetMinAndMax. This takes the active selection as an input.
Or if there is none - the entire image.
This is in contrast with the ByteProcessor where adjustment of contrast updates the byte array and hence is irreversible in the general case.

I am used to first converting to ByteProcessor, then selecting an appropriate LUT, and then converting to RGB for display/publication purposes.

Best regards,

Dimiter
 

------------------------------

Date:    Mon, 18 Jan 2021 06:19:55 -0600
From:    Kenneth R Sloan <[hidden email]>
Subject: Re: Code review?

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:
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage
> j.nih.gov%2Fij%2Flist.html&amp;data=04%7C01%7CDimiter.Prodanov%40imec.
> be%7C4844a004c0554b20b73c08d8bc372905%7Ca72d5a7225ee40f09bd1067cb5b770
> d4%7C0%7C0%7C637466292408282548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=
> bvYljXdghvLFXbo4XbE%2F6L6oXnb%2BFdzlUmwPUIf9o7Y%3D&amp;reserved=0
>
--
-Kenneth Sloan

--
ImageJ mailing list: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&amp;data=04%7C01%7CDimiter.Prodanov%40imec.be%7C4844a004c0554b20b73c08d8bc372905%7Ca72d5a7225ee40f09bd1067cb5b770d4%7C0%7C0%7C637466292408282548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bvYljXdghvLFXbo4XbE%2F6L6oXnb%2BFdzlUmwPUIf9o7Y%3D&amp;reserved=0
 

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