Comment by Didier Vibert on 2022-03-30 16:59:00:
L'idée: première version sans aucun coeff d'intercalibration.

remplacer dans l'inputContext le membre @std::shared_ptr<CSpectrum> m_Spectrum@ par un container (std::vector ? ), idem pour @m_rebinnedSpectrum@, et partout où on référence ces objets.

commencer par modifier CTemplateFiitingSolve et COperatorTemplatefitting.
puis COperatorTemplateFittingLog et COperatorTemaplateFitttingPhot,
puis CTplCombinationSolve et COperatorTplcombination
puis CLinemodelSolve

note:
il faut rajouter dans le parameters.json autant de lambda range que de spectres...
idem dans l'inputContext::m_lambdaRange devient un container de range,

En revanche m_logGridStep est unique (ainsi que m_logRebin qui contient les zrange out) : => pour le mutli-obs avec traitement Fourrier, le logstep (lié au zstep) doit être identique.

orthogonalize template: on ne vas pas orthogonaliser différemment pour chaque spectre (ie chaque LSF) => utiliser la LSF la plus large (à voir comment le déterminer avec des LSF variables...)
idem pour le support à masquer avec l'option ignorelinesupport.

Comment by Ali Allaoui on 2022-12-07 10:24:26:
Comment identifier chacun des spectres et son lambda range associé ? se baser uniquement sur l'ordre (et donc dans le parameters.json avoir @"lambdarange":[[12510,18500],[19000,21000]@) est peut être risqué, on s'appuierait alors sur l'ordre des spectres dans l'inputspectrumlist (point de vue client), ou l'ordre d'ajout des spectres (point de vue api, l'appel à load_flux, load_error, load_wave). Ne vaudrait-il mieux pas avoir une information supplémentaire dans CSpectrum, qu'on puisse utiliser dans le parameters.json : @"lambdarange":

@

Comment by Pierre-yves Chabaud on 2022-12-07 14:59:31:
En plus de @lambdarange@, y a-t-il d'autres paramètres qui, pour une même source, peuvent avoir des valeurs différentes suivants les jeux observations ?
Les deux design que je vois sont :

*Premier design* (idem proposé par Ali)

<pre>
"lambdarange":

</pre>

*Deuxième design*

<pre>
"observations":[

,

]
</pre>

Dans tous les cas, cela nécessite d'avoir une information sur l'observation dans le CSpectrum ("obs1" ou "obs2" dans mon exemple). Information a remonter également dans le format v3 me semble-t-il.

Comment by Didier Vibert on 2022-12-07 15:12:53:
oui, il y a d'autres paramètres: les lsf. 2cas possibles:

1. elles sont dans les fichiers spectres (lsfytpe = "fromspectrumdata"), soit pas de paramètre supplémentaire dans ce cas
2. elles ne sont pas dans les fichiers, et viennent du parameters.json. Dans ce cas il faut prévoir de paramétrer la LSF pour chaque "observation", en reprenant ta terminologie de Pierre-Yves.
   On peut même imaginer utiliser la lsf dans les fichiers (lsfytpe = "fromspectrumdata") pour un type d'observation et parmétrée pour un autre type, si eg la lsf estimée par SIR s'avère bonne uniquement sur le bleu...