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

OIFITS version #14

Open
jsy1001 opened this issue Feb 15, 2022 · 11 comments
Open

OIFITS version #14

jsy1001 opened this issue Feb 15, 2022 · 11 comments
Assignees

Comments

@jsy1001
Copy link
Contributor

jsy1001 commented Feb 15, 2022

We should clarify which version(s) of the OIFITS standard applies to the files used by OImaging. Does it depend on the version of the OIFITS data given as input?

@GillesDuvert
Copy link

@jsy1001 could you elaborate a bit, I have no clear example, except that, if ever, pray God, the correlation matrix was used, the IR softwares should use it?

@jsy1001
Copy link
Contributor Author

jsy1001 commented Feb 17, 2022

I believe that OImaging will accept either version 1 or 2 OIFITS files. The same is true of BSMEM, MiRA, and WiSARD (I think). Do we care whether the image reconstruction backends write out OIFITS v2 when given OIFITS v1 as input (or perhaps the reverse) ? Or should OImaging convert v1 to v2?

At the moment I think v1 inputs are not converted to v2 anywhere, but we should confirm this.

@GillesDuvert
Copy link

Ah, I see... I guess WISARD writes more or less what it got, plus the extra model columns, so it should be v2 out if v2 in. never really tested it. Having to deal with those peculiarities would be better left outside the scope of the IR backends... until we face a problem.

@FerreolS
Copy link
Member

I agree with @GillesDuvert , up to now all software seems to accept both version as input. I propose to postpone this issue until we face it (e.g. when a software impose v2 input). We will probably be able to make patch in the GUI without bothering software people. Probably @GillesDuvert will be retired for a long time if it happens ;-)

@emmt
Copy link
Collaborator

emmt commented Feb 21, 2022

Since OIFITS-V2 is somewhat backward compatible, we could also read any version and write V2 when saving? I think this would be the simplest way to handle cases where mutilple files are provided that mix different versions of OI-FITS.

@jsy1001
Copy link
Contributor Author

jsy1001 commented Feb 21, 2022

I think that would be a good solution.

There isn't a way to specify multiple files in OImaging yet, is there?

@emmt
Copy link
Collaborator

emmt commented Feb 21, 2022

I don't think so.

@GillesDuvert
Copy link

The "merging" of various OIFITS files is better done within OIFitsExplorer, so I would let the job of merge and conversion to V2 to it. The OIFitsExplorer feature doing the merge can be plugged into OImaging if people do not want to use OIE beforehand.

@emmt
Copy link
Collaborator

emmt commented Feb 22, 2022

I agree, what I proposed was just a sensitive behavior of the image reconstruction algorithm when directly used from the command line.

@FerreolS
Copy link
Member

FerreolS commented Mar 1, 2022

As @GillesDuvert I think that the merging / filtering of OIFITS should be done with OIFitsExplorer .

If software just add keywords and HDU to the OIFITS file without suppressing anything else as mentioned in #12 , then it will be blind to the OIFITS version. The output will have the same version as the input.

If V2 seems mandatory, then we will probably be able to perform conversion in OImaging by the mean of https://github.com/JMMC-OpenDev/OITools

@jsy1001
Copy link
Contributor Author

jsy1001 commented Mar 14, 2022

BSMEM now always writes valid OIFITS v2 as output, regardless of whether the input is v1 or v2.

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

No branches or pull requests

4 participants