Using the umd_svo branch, the list of images for a round appears to being sent as a bytes object. A TA-2 system interacting with that version of the server needs to run the decoded version of that through ast.literal_eval, which then gets them a list of lists of strings.
The API during Phase 1 sent the lists of images as text strings that were effectively the contents of CSV files, comma-separated text lines. And I believe that that is also the format that the API expects TA-2 results to come in, to feed into Sail-On-Evaluate. (I haven't yet checked the formats in which you are sending feedback.)
If you folks are planning to change to bytes-encoded Python objects, will that change affect TA-2 results as well? If not, it seems like it might be simpler if you stuck with the CSV-style format that the API has traditionally used.
I also note that the API has a spec for test IDs, that the sample tests that UMD has supplied so far do not follow.
Using the umd_svo branch, the list of images for a round appears to being sent as a bytes object. A TA-2 system interacting with that version of the server needs to run the decoded version of that through ast.literal_eval, which then gets them a list of lists of strings.
The API during Phase 1 sent the lists of images as text strings that were effectively the contents of CSV files, comma-separated text lines. And I believe that that is also the format that the API expects TA-2 results to come in, to feed into Sail-On-Evaluate. (I haven't yet checked the formats in which you are sending feedback.)
If you folks are planning to change to bytes-encoded Python objects, will that change affect TA-2 results as well? If not, it seems like it might be simpler if you stuck with the CSV-style format that the API has traditionally used.
I also note that the API has a spec for test IDs, that the sample tests that UMD has supplied so far do not follow.
Lance