ImageIntegration - ignore or separate low range clip count

[bitli]

Currently ImageIntegration count the pixels rejected by LowRange/HighRange like any other rejection (which naturally make some sense)..
However I think that it would be useful to allow 'silent rejection' of the pixels at low range, as this is usually used for the pixels that are not part of the image due to alignment. Currently we have to crop each individual image (I know about ImageContainer), otherwise the low rejection statistics are polluted by the rejection of the borders. My understanding is that with ignored or separate statistics for LowRange, it would be easy to make ImageIntegration on the uncropped images and only cropped the final result. This would save time and space.

-- bitli

[chris.bailey]

You can save the crop individual images step by defining a region of interest within Image Integration. That seems to achieve the results you are looking for.

Chris

[bitli]

Thanks for the suggestion.  I did a try, this achieves what I was asking for but not what I intended.

The statistics used for scaling, noise evaluation, and so on are slightly different if I use the full image with the ROI or if a crop the image first. So ignoring the zero pixel is not good enough, as the other parameters seems to be impacted by the whole image anyhow (for example, if you change the ROI, the statistics will of the previous integration will still be read from the cache).  This is perfectly logical if you use the ROI for what it is intended for: have a faster evaluation of rejection parameters on a small area, before applying it to the whole image.

So what I would like is rather to have the an option to 'crop at ROI' in the same pass as Image Integration, so that only the ROI would be considered (there is no need of special processing of black pixel in that case).

However this may be somewhat more complex to implement, as this impact the cache and the Image Integration is already pretty complex.

-- bitli
 

[Juan Conejero]

Your request makes a lot of sense. I'll try to implement it as soon as possible, but please realize that this is a complex task. Separating rejection counts into statistically and range rejected pixels requires changes to internal working structures and routines that are not trivial.

Thank you for this suggestion. Count with it implemented, although not in the next version.

[bitli]

Thanks,
I fully realize the complexity of the task, I spent quite some time reading the code (the code is very readable, by the way, but c++ is not my mother tongue). I'll wait.
A small problem which should be easier to correct:
Currently if you select No Rejection, the check box 'Generate rejection map' is disabled (it stays checked or not checked as it was). But it is still taken into account (i.e. the map is generated or not) if either Clip low range or Clip high range is selected. A minor problem, but if 'Generate rejection map' were enabled when a clip range is selected, it would be more convenient and  would make it more visible that these ranges are active if checked even if No Rejection is selected (which makes perfect sense, even if the phrase sounds bizarre).
-- bitli

[Juan Conejero]

Actually, after a closer code inspection, it has been relatively easy to implement:

The new report range rejection and map range rejection parameters allow you to control inclusion of range rejected pixels in console rejection counts and rejection maps, respectively. Report range rejection is disabled by default. Let me know if this is what you expected.

The other bug that you have mentioned is also fixed. Everything will be available in the next version.

[bitli]

This is great as far as range rejection is concerned and clearer.

Where I did see the complication was in the part discussed in the replies 1 and 2 of this thread.  If we apply the integration to an image with black borders, the black borders will still impact the scale evaluation, if I am not mistaken. Taking an ROI restricts the rejected area, but not the calculation of the scaling factor (as it is intended as a preview of the full process).
May be I did a mistake and the scale is not impacted, or possibly it is negligible in real case?
--bitli

[bitli]

Tested the new ImageIntegration options (see post above) on 1092.  It works well.

An unexpected benefit is that the 'low rejection map' provides an easy to use visualization of the common area between all images, so it is much easier to make the crop without an additional "minimal integration".

Thanks
-- bitli