Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add image extraction parameters to the metadata of the dl1 images table #2614

Open
TjarkMiener opened this issue Sep 9, 2024 · 3 comments
Open

Comments

@TjarkMiener
Copy link
Member

Please describe the use case that requires this feature.
For calculating the pedestal level (per sample), the charge median needs to be divided by the window width of the extractor. Since charge extraction and calculation of camera calibration coefficients are now separated, we'd need to propagate the information of the image extraction parameters in the metadata.

Describe the solution you'd like
Add the parameters of the image extractor in the metadata.

Describe alternatives you've considered
Use the same config file for the process-tool and camcalib-calculation-tool and read the parameters from the config.

Additional context
Maybe the information is already stored somewhere in the data format. If so, please point me there. Thanks!

@kosack
Copy link
Contributor

kosack commented Sep 9, 2024

Use the same config file for the process-tool and camcalib-calculation-tool and read the parameters from the config.

That sounds error prone since you would have to ensure you sync the config files, so I agree this should be propagated in the table metadata or as a table like /configuration/process. This is also a more general problem: right now the pipeline configuration info only goes into the provenance log, which is not really intended to be read by another processing step, so it would be good to write it somewhere properly.

@maxnoe
Copy link
Member

maxnoe commented Sep 9, 2024

This is basically the same as #1610 I would say

@TjarkMiener
Copy link
Member Author

This is basically the same as #1610 I would say

Yes, I agree! Can you please provide me with a time estimate for #1610 implementation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants