Dear All,
We could do some things, but I would like to know more.
I would be against storing a delta value. If anything one should store the
current referencing, and possibly a 'previous' or 'last' or 'original'
referencing as well. But if people want deltas then the user interface can
show them like that no matter how they were stored.
There is already one thing in the model that might serve.
ExpDimRef.nominalRefValue, which is the reference value for the carrier
frequency (e.g. 4.73ppm for HDO). As described in the documentation this
is the setting you get from the spectrum file, before using temperature
corrections, internal referencing, ad-hoc changes etc. etc.
nominalRefValue allows you to calculate the actual referencing for any
DataSource, you just need a bit of algebra. Might this be OK?
Alternatively we could add an extra referencing. The 'actual' referencing
is simply the currently valid referencing. The problem is how to define
the other one. Is it simply any old referencing that people want to
remember for whatever reason? Is it the previous referencing when you make
a change? Is it the referencing you get from the spectrum file? Is it the
supposedly correct referncing, before ad-hoc corrections?
What do you say?
Rasmus
---------------------------------------------------------------------------
Dr. Rasmus H. Fogh Email: [log in to unmask]
Dept. of Biochemistry, University of Cambridge,
80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
On Wed, 20 Jun 2007, Patrick van der Wel wrote:
> > Right, I've fixed that bug. And the way this referencing dialog was set
> > up, it was meant that (say) if you hade dim 1 being mapped to dim 1 and
> > dim 2 to dim 2, and swapped dim 1 to be mapped to dim 2, then it would
> > automatically swap dim 2 to get mapped to dim 1. But what you want to do
> > below also makes sense in certain circumstances, so I've added in an
> > option to allow repeats in the fixed dim column. The default is the
> > original behaviour. And the value of this check button is not remembered
> > in between invocations (we could do but it doesn't seem worth it).
> That was what I figured was going on. Thanks for the fix and adding this
> feature. It is surely very useful for me.
>
> I would like to bring up an issue that I have indicated before. With the
> convenient (re) referencing of spectra based on overlaying peaks, I often
> find myself aligning spectra temporarily, for comparison, that I might not
> want to keep re-referenced like that. Also, once you re-reference a
> particular spectrum obtained on a particular day and instrument, you often
> end up applying the same 'shift' to other data sets (note that we often use
> external referencing).
>
> One feature I miss from Sparky is that one was able to put in a
> separate 'spectrum shift', which basically reflects the required chemical
> shift adjustment. I have previously been advised that one should do this by
> editing the reference frequency in Analysis. While this might be equivalent
> (or even 'proper') in principle, I find that in practice I would prefer to
> have that value (by default) be the value set in the data file / used on the
> spectrometer during acquisition, and have a separate value for the 'in
> retrospect' correction required.
>
> My feeling is that that would have several benefits, but perhaps others might
> disagree? I wonder if anyone else missing this (Sparky) feature or has a way
> around it?
>
> Patrick
>
|