Open nes-cgn opened 3 years ago
I think it could be solved at the level of zones table edition, I found that we avoid the replication of zones/ranges from the automatic zones/ranges detection and it is needed in order to detect zones/ranges from differents regions
Sure. Still, as I have mentioned many times, there will be situations where a manual editing of the shift value (or directly: manual definition of peaks) will be needed. Currently, one can edit the shift values in zones/ranges tables, but only for referencing purposes. It should be possible to change only one individual shift/pair of shifts, in those tables, however.
In ranges you can edit the signals manually for over one year now. It may not yet be very intuitive however. @nes-cgn did you try it ?
And we are improving this edition dialog as well.
See #1076 #1077 #1078 #1079
Yes, I have seen this. But what I would need is changes in zones. For some examples, there is no 1D 13C for instance, and in general it would be more convenient to change directly in the correlation table, thereby affecting the corresponding frequencies in the zones/ranges.
@nes-cgn @lpatiny Since each correlation knows the IDs for linked signals in ranges and zones, which is also used for the highlighting across all spectra, one could think about a limited set of direct changes in the correlation table. For example to change/equalise the shift values of grouped signals in all spectra or to delete them by just "one click" in the correlation table.
Hello Michael,
this is also what I would envision,
thanks, Nils
Quoting Michael Wenk @.***>:
@nes-cgn @lpatiny Since each correlation knows the IDs for linked
signals in ranges and zones, which is also used for the highlighting
across all spectra, one could think about a direct change in the
correlation table. For example to change the shift value of all
grouped signals or to delete them in all spectra by just "one click".
I present here two cases that demonstrate, that with the setting of a more coarse or fine-grained tolerance of shifts, not all the assignment problems can be issued by now. (1) there is a range where two 1H signals reside on top of each other, but the 13C is different. One would need to manually define that there is an extra 1H at the same shift, and then (manually) define e.g. in the long range who is coupled to whom. (2) there are 13C signals that are too close or isochrone. In that case, one needs to be able to define that manually, too. In that case, if I select e.g. the 13C tolerance too small, then, other pickings from the HMBC that are not so accurate get messed up.
I add some illustration to show what I am talking about