[Image normalization workflow]: Normalize by ROI

[damskii9992]

Executive summary

It should be possible in the reduction workflow after normal normalization to also re-normalize again by the spectrum of a chosen ROI

Context and background knowledge

This requirement came up in a meeting with the ODIN team today where we saw Shuqi's work on reducing and analyzing a data-set on duplex steel. In his reduction, he noticed that the regions of the normalized image without a sample wasn't a horizontal line close to 1, as such he re-normalized his image using the spectrum from a region without the sample, a so-called open-area, which provided a much better reduced data-set that was easier to analyze.

Inputs

The normalized image after normal reduction and a chosen region of interest to re-normalize it with.

Methodology

Dividing the time-of-flight spectrum for each pixel with the spectrum gained from summing up a specific region-of-interest.

Outputs

A re-normalized image.

Which interfaces are required?

Integrated into reduction workflow

Test cases

We can try to get Shuqi's data to use for testing. I do not currently have it.

Existing implementations

No response

Comments

No response

[damskii9992]

I really dislike the template for creating an issue. Its too complicated and has too many required fields and it made me wanna not open this issue at all . . .
Just mentioning it since if that is how I felt, I don't wanna know what potential users might feel or non-IT specialists from ESS.

[nvaytet]

I really dislike the template for creating an issue. Its too complicated and has too many required fields and it made me wanna not open this issue at all . . .

Maybe some suggestions for improvement and a friendlier tone about other people's work would be more constructive?

[damskii9992]

I really dislike the template for creating an issue. Its too complicated and has too many required fields and it made me wanna not open this issue at all . . .

Maybe some suggestions for improvement and a friendlier tone about other people's work would be more constructive?

Fair enough. Thanks for calling out the tone — that wasn’t my intention.

I understand the goal of making sure issues have enough info to be actionable, and I agree with that. My concern is that the current number of required fields makes it harder than it needs to be to open an issue.

If people — especially non‑IT folks — are faced with a lot of mandatory fields with concepts they’re not fully comfortable with, there’s a real risk they’ll just give up and not file the issue at all. At that point, even a well‑designed template is working against us.

The fields "Inputs", "Methodology", "Outputs", and "Test cases" are the main ones I’m thinking about. In particular, "Methodology" and "Test cases" feel like they should be optional, since they’re sometimes not relevant at the time someone is opening an issue.