Closed cneidle closed 9 months ago
Another example.
This sign had been set up like this:
However, when the file is saved and reopened, this is what the Morph-Phon window displays:
Furthermore, the sign ROBOT was saved to the local sign bank with SAME, ALTERNATING handshapes.
This is how it looks in the sign bank.
And this is how it gets entered when you enter all data: DIFFERENT left/right handshapes (wrong).
Confirmed and reproduced.
also not retaining same/difft start end hs setting
This should be fixed prior to next release. This affects the data... Thanks.
This is not fixed. This is critical. Needs to be fixed prior to release. Sign information is not preserved when saving and reopening.
Example from pre-release 3.4.1: Set up as different handshapes on left and right; different start end on both hands.
Saved and re-opened. This is what appeared:
@gregorydimitriadis
The good news is that new files that are annotated with different handshapes on the dominant and non-dominant hands, when saved and re-opened, preserve that information.
The very much worse news, however, is that older files when opened with this new version of the software do NOT preserve the information that had already been annotated. e.g.
One consequence of this is that if you try to edit the handshapes, you totally lose all information from the non-dominant hand:
This is a huge problem. It means that ANYTHING that was annotated with the current release version will have to be RE-annotated, for all glosses of this kind. I had been telling students to annotate, but not to re-open the Gloss-phon window, and to hold off making any changes until we have a new version of the software that would enable them to edit the glosses without loss of information. (The information is clearly still there, because the handshapes are properly displayed in the Utterance Window.) However, this version does not do that!
Others using the current version are unaware that their work will be lost.
Is there a way to run some kind of conversion on files edited with the current release, to re-detect whether the handshapes on the two hands are the same or different based on whether the annotated handshapes are same or different? And same for start/end handshapes ???
Otherwise, we have to put out a HUGE disclaimer, about the pervasive errors that will be present in all files annotated with 3.4.0. And worse yet, the work that will be required to fix these issues will be astronomical.
If this kind of loss of data happened to me with a software program I had been using, I would swear off ever using it again, and I would spread the word... This is disastrous for our attempt to get people using SIgnStream, and it would be worth anything that can be done to avoid this major loss of information to anyone who has used 3.4.0.
Investigating...maybe something was missed.
THANK YOU !!! This is really critical.
@cneidle can you send the collection file you tested with?
@cneidle we can infer from the handshapes which are saved that a sign can be SAME or DIFFERENT in terms of their dom/ndom handshapes. But is there any way to infer a value of ALTERNATING? If there is not, there may be no way to recover that information.
Hi Greg,
OK.
There are relatively few cases of alternating signs, so…. We can live with that.
We also need to infer whether start and end handshapes are the same on each hand.
Thanks, Carol
On Mar 23, 2023, at 2:34 PM, Greg Dimitriadis @.***> wrote:
@cneidle https://github.com/cneidle we can infer from the handshapes which are saved that a sign can be SAME or DIFFERENT in terms of their dom/ndom handshapes. But is there any way to infer a value of ALTERNATING? If there is not, there may be no way to recover that information.
— Reply to this email directly, view it on GitHub https://github.com/DCS-LCSR/SignStream3/issues/622#issuecomment-1481707631, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADH7NQQCZS2FRH2M42WDA3LW5SJUHANCNFSM6AAAAAAUCUNZSU. You are receiving this because you were mentioned.
@cneidle to my knowledge, the start/end value has never been "enforced" in the sense that if a sign is marked as "same start/end" the handshapes could actually be different at the start and end (and vice versa) - is this an issue? (i.e. it could have been the case that it was annotated as "same" despite the start and end handshapes being different)
That’s true.
It might be disconcerting to open the Morph-Phon window after the user has annotated the start and end handshapes as clearly different, and to see that they are displayed as “same," but it should not result in in corruption of actual data for handshapes.
On Mar 24, 2023, at 2:11 PM, Greg Dimitriadis @.***> wrote:
@cneidle https://github.com/cneidle to my knowledge, the start/end value has never been "enforced" in the sense that if a sign is marked as "same start/end" the handshapes could actually be different at the start and end (and vice versa) - is this an issue? (i.e. it could have been the case that it was annotated as "same" despite the start and end handshapes being different)
— Reply to this email directly, view it on GitHub https://github.com/DCS-LCSR/SignStream3/issues/622#issuecomment-1483220890, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADH7NQQQPOXCSVNIYZOQRHTW5XPVLANCNFSM6AAAAAAUCUNZSU. You are receiving this because you were mentioned.
Just restating...
A collection file opened with a previously saved 2 handed sign saved as "Diff't L&R" with different Handshapes set for L and R, would open the Morph-Phon in the same manner...in SS v3.3.6.
In SS v3.4.0...after opening the same file, opening such a sign in the Morph-Phon window would change a "Diff't Dom & Ndom" or "Alternating Dom & Ndom" setting to "Same Dom & Ndom".
It would also unset any settings of "Same" or "Diff" Start and End of the Dom or Ndom. Replacing that with "Same START/END" for both.
It would NOT change the handshapes (unless reselecting handshapes).
On "Enter" or "Bypass" the altered settings would be entered.
The SS v3.3.6 behavior appears be restored in the latest 3-20-2023-pre-release.
@gregorydimitriadis
Can you (re)state what are the exact rules for any corrections being made when opening a file in the pre release?
Which files will the correct be applied to?
What is the check for a possible previous error?
What is the correction made?
(note there was an issue in 3.3.6 files in which 2h diff d/nd signs could be missing handshapes in one hand...was a previous detection and possible correction also made for this case in the 3.4.0 version?)
@douglas-motto-at-rutgers
The detection and correction will be:
Regarding the 3.3.6 thing, I don't believe so.
@gregorydimitriadis
Not sure if this is a github display issue, but I do not follow this...
if NO_OF_HANDS="2" and TWOHANDED_HANDSHAPES has no value, then: for both hands, get the handshapes and compare if they are equal then for both hands set the TWOHANDED_HANDSHAPES value as same or different depending on equal or not
The 2 handed examples I created in 3.6.0 (and resaved and created new in 3.4.0) all had a value for TWOHANDED_HANDSHAPES....Are there examples where this value for a 2 handed sign did not exist?
If not...I don't follow "TWOHANDED_HANDSHAPES has no value".
@douglas-motto-at-rutgers the issue I saw in the file Carol sent, saved in 3.4.0, was that the TWOHANDED_HANDSHAPES value was blank for seemingly every entity.
@gregorydimitriadis
that appears to be a different problem then.
@gregorydimitriadis
see my comment above.
start SS v3.4.0
create sign with "2handed" "different hanshapes dom & ndom" with "AA" on dom and "11" on ndom....
save
look inside the collection file, it has two entities both with "number of hands=2", "TWOHANDED_HANDSHAPES=Diff", and on dom..."AA"...and on ndom..."11".
all correct at this point.
now reopen that same file
click on that sign...open in Morph Phon...
it immediately shows "same handshapes dom & ndom".
several possibilities at this point...
Case A) click "Enter/Bypass". Save the collection. Look inside the collection file. It now has "TWOHANDED_HANDSHAPES=Same"...but still lists "AA" for dom and "11" for ndom....not correct.
Case B) in morph phone, if you re-select "diff"...the ndom handshapes disappear...click enter/bypass and save. Similar issue in collection, sign says "same" but now have lost ndom handshapes...not correct.
Case C) in morph phone select handshapes...but since "same", can only edit dom hands...again lost ndom handshapes....not correct.
@gregorydimitriadis
If someone did case b or c....data is now lost.
I think carol is hoping that if anything only case a has happened....and some data can be restored.
I want us to be very clear about what is being restored.
@douglas-motto-at-rutgers true, that is what happens. I don't know what the case is with the file I looked at earlier, but what you say there is correct.
So in any case, in either case of what was saved, the validation/correct would be:
One correction, on this:
Case B) in morph phone, if you re-select "diff"...the ndom handshapes disappear...click enter/bypass and save. Similar issue in collection, sign says "same" but now have lost ndom handshapes...not correct.
I'm using 3.4.0 now and this does not happen. If you try so save without selecting handshapes on the ndom, it prevents you. That maybe happens in 3.3.6 as you suggest in the other issue.
@gregorydimitriadis
You are correct...B) not possible to save in 3.4.0, but is possible to save in 3.3.6 without second hands...will follow up in that other issue.
if a twohanded sign, get the handshapes on dom hand and ndom hand, and if same validate that SAME is entered for the TWOHANDED_HANDSHAPES value, otherwise DIFFERENT - and if not do the correction to make it so.
You are currently able to set "DIFF" but then select the same handshapes on don & ndom. Your correction, would then change this to "SAME"....is that desired?
You ignore if the handshapes were the same, and the setting was ALTER. This would be valid. Are you still switching to SAME in this case also?
You do not mention how "SAME START/END" if/will be corrected. In 3.4.0 when reopening any presaved gloss...just like it will force "SAME handshape", no matter the previous setting it will also force "SAME START/END"...even if previously "Diff START/END". This is true even for glosses that were previously "SAME handshape" (which stays the same). At the very least the XML needs to be corrected for start/end attributes (if also corrected the XML for the 2h_hshapes attribute). When such a correction is made...are we looking at what the handshapes have...or simply just setting "SAME START/END" always?
Are we only applying this correction to 3.1 collection files?...or all future files?
And based on some of my questions above...I guess I'm asking the overall big picture. Is any of the SAME/Diff settings still necessary...if everything can be (should be) determined by the handshapes selected?...everything but "alternating".
@gregorydimitriadis
ps...just to add...if it's valid to have "Different START/END" or "Same START/END" conflict with the handshape images displayed...as in, the start/end has another "meaning" than the images...then for anything marked as "SAME Handshapes"...that start/end data is likely lost for that setting as well.
@douglas-motto-at-rutgers @cneidle
You are currently able to set "DIFF" but then select the same handshapes on don & ndom. Your correction, would then change this to "SAME"....is that desired?
Carol, what do you think of the above case? I am assuming it would be desired to mark it as same to be consistent, but I want to confirm.
You ignore if the handshapes were the same, and the setting was ALTER. This would be valid. Are you still switching to SAME in this case also?
Doug, this case was addressed by Carol in above comments.
Are we only applying this correction to 3.1 collection files?...or all future files?
This would be 3.1 validation.
Regarding the same/diff start/end - I believe Carol above mentioned it would be disconcerting but not result in data loss. Carol, do you wish anything done in this aspect? I recall you had said recently maybe that setting is not useful at all anyway, but taking it out right now might not be the quickest thing.
@gregorydimitriadis
You ignore if the handshapes were the same, and the setting was ALTER. This would be valid. Are you still switching to SAME in this case also?
Doug, this case was addressed by Carol in above comments.
My reading of Carol's comment is that there is no way to distinguish between when
So that data is lost, and Carol says to ignore that rare case.
But of if..
something that was "alternating" and is still now "alternating" (no resave happened) Shouldn't we leave it as "alternating"?
That's a valid one - if the value exists already and doesn't not "conflict" with the handshape information, it might make sense to keep it as is. I think this would only apply in the case where it's alternating.
Are we only applying this correction to 3.1 collection files?...or all future files?
This would be 3.1 validation.
So this change will effect this and any future version of SS.
if a twohanded sign, get the handshapes on dom hand and ndom hand, and if same validate that SAME is entered for the TWOHANDED_HANDSHAPES value, otherwise DIFFERENT - and if not do the correction to make it so.
As described, on "open" (but not while using or on save) it would always ...change alternating->same. ...same->diff...if the images on both hands did not match
it seem like if this is a forceful change...then why allow invalid options to be set in the UI. after the correction...some could set something...save/reopen...and it would be different.
Regarding the same/diff start/end - I believe Carol above mentioned it would be disconcerting but not result in data loss. Carol, do you wish anything done in this aspect? I recall you had said recently maybe that setting is not useful at all anyway, but taking it out right now might not be the quickest thing.
My primary point is that you need to fix this in the xml (which is not mentioned in your description). Whenever you change from same/alt to diff for handshapes (in xml)...the start/end attributes (in xml) must also change.
And since this is being changed...should there be an attempt to set it correctly for the ones we are already changing?
As I discussed with Greg, I would suggest removing the same/different start/end handshape dropdown menus from the interface. No need to change the existing XML information.
We definitely need to fix the setting for same/different handshapes on the dominant and non-dominant hand, based on the actual handshape information.
We certainly don't want to modify anything that is currently set as same hands, alternating.
I understand that we risk losing any data that was annotated in the current release version 3.4.0 that should have been same handshapes alternating, and which will now appear as same handshapes (without "alternating"). That's very unfortunate, but we have no way to know what needs to be restored.
We DEFINITELY do not want to change anything that is listed as alternating in such a way as to remove that!
The real data that we have annotated was, until recently, all annotated with SignStream 3.3.5.
Within the last few months, we have been using 3.4.0, and we have been encountering very serious problems because of these bugs. We are anxiously awaiting the new release, which will, to the extent possible, fix the existing issues.
We have no data (nor would anyone else) annotated with 3.3.6.
Please let me know if there's anything else you need from me. I'm not totally following all of this. Thanks.
This modification should only be applied to files that were annotated in 3.4.0, if possible. It should leave files annotated with prior versions untouched (with regard to this set of changes).
And future versions of SignStream should also leave files annotated with versions later than 3.4.0 untouched.
You are currently able to set "DIFF" but then select the same handshapes on don & ndom. Your correction, would then change this to "SAME"....is that desired?
The change should only go one-way. It should only change cases where there are different handshapes on the two hands from SAME HANDSHAPES ON BOTH HANDS to DIFFERENT HANDSHAPES ON BOTH HANDS. So far as I know, there are no errors that go in the other direction. Am I missing something ??
@douglas-motto-at-rutgers @cneidle
Updating with all information so far:
For all the below, when I refer to "the value" I'm referring to the SignStream "same/diff dom/ndom" value, aka the TWOHANDED_HANDSHAPES value in the collection xml.
From what I have seen of testing existing collections saved with SignStream version 3.4.0, there are some circumstances where the value is correctly saved in the XML, and other circumstances where it is blank (in xml). I do not see an issue with incorrect start/end information.
In 3.4.0, opening such collections
In the latest pre-release code, opening such collections:
The validation and correction (directly in xml) going forward into the next pre-release will be:
@gregorydimitriadis
if the handshapes are different on both hands, and if the current value is not already "DIFFERENT" then update it to "DIFFERENT"
For this...then you must also re/set the "Same/Diff Start/End" for both hands. Or the xml will be incorrectly formed.
In all cases if opened and resaved in 3.4.0 and if a 2 handed gloss was opened, it forced the gloss to "same dom/ndom"...and at the same time it forced "same start/end".
Now if manually changing "same dom/ndom" to "diff dom/ndom"...you must reset the attributes for "same/diff start/end". This is more than just the data being incorrect, it's the xml structure that is incorrect. Here's the attributes involved.
TWOHANDED_HANDSHAPES START_END_HANDSHAPES DOM_HAND_START_END_HANDSHAPES NDOM_HAND_START_END_HANDSHAPES
If "same dom/ndom" and "same start/end", the settings are...
TWOHANDED_HANDSHAPES="SAME HANDSHAPES DOM NOM" START_END_HANDSHAPES="SAME START/END HANDSHAPE" DOM_HAND_START_END_HANDSHAPES="" NDOM_HAND_START_END_HANDSHAPES=""
If "diff dom/ndom" and "same start/end", the settings are...
TWOHANDED_HANDSHAPES="DIFFERENT HANDSHAPES DOM NOM" START_END_HANDSHAPES="" DOM_HAND_START_END_HANDSHAPES="SAME START/END HANDSHAPE" NDOM_HAND_START_END_HANDSHAPES="SAME START/END HANDSHAPE"
@gregorydimitriadis
You could blindly set them to all "Same"...or you can do a check of the handshapes on each hand, setting "Same" if the first and last is the same, or "Diff" if the first and last is different.
But if you are doing a "smart" set for this change, then should you also do a "smart" set for the following change too...
if the handshapes are the same on both hands, and if the current value is not already "SAME" then update it to "SAME"
?
@gregorydimitriadis
And to referring back to Carol's statement...
I would suggest removing the same/different start/end handshape dropdown menus from the interface.
Perhaps it's best to remove these options from the morph phon all together and just always automatically set those fields onload/save...leaving them in the xml and setting properly every time, no matter the ss version or xml version.
@gregorydimitriadis
in case it's not clear
when changing... TWOHANDED_HANDSHAPES="SAME HANDSHAPES DOM NOM" to... TWOHANDED_HANDSHAPES="DIFFERENT HANDSHAPES DOM NOM"
unset this... START_END_HANDSHAPES=""
setting this... DOM_HAND_START_END_HANDSHAPES="SAME START/END HANDSHAPE" NDOM_HAND_START_END_HANDSHAPES="SAME START/END HANDSHAPE"
or this... DOM_HAND_START_END_HANDSHAPES="DIFFERENT START/END HANDSHAPE" NDOM_HAND_START_END_HANDSHAPES="DIFFERENT START/END HANDSHAPE"
...or just one diff and the other same.
I will also do the update of the start/end values appropriately.
And it is also possible for this check to be done only on files done in 3.4.0, so that will be done as well.
@gregorydimitriadis
I will also do the update of the start/end values appropriately.
for just "same d/nd" -> "diff d/nd" detected corrections?
or also for "same d/nd" -> "same d/nd" non detected changes?
as this might have also happened...
originally save as "same d/nd", "diff s/e"
re-opened and resaved as "same d/nd", "same s/e"
without knowing
@gregorydimitriadis
As for the "" value for one of the attributes you state above and have seen...
Recommend making new issue for that, as it's likely something that's needed as an error detection and validations for all future xml files.
Released in 3.4.1
This is a sign which had been set up with different handshapes on the two hands. This is not retained when the file is saved and reopened.