Cannot enter BG pulse suppression values

[aso-toshihiko]

No problem for the same textbox during the Importing process, so maybe this is a simple GUI bug?

[jan-petr]

I see that the Labeling Duration is supposed to be entered in ms. Can you check if entering background suppression in seconds would help?
Alternatively, you can try [790, 2110, 3090, 3630], but I'm only guessing. Hopefully, Maurice will have a better answer.

[MauricePasternak]

Wanted to ask in this discussion thread: for many numerical fields that may remain in dataPar.json ... are the units still in milliseconds as per 1.10.0BETA docs? Or has ExploreASL completely transitioned to BIDS schema (which uses seconds in almost all cases)?

I've checked the codebase but it seems contradictory (you'll prioritize BIDS sidecars which use seconds in such fields, but the docstrings in the matlab functions themselves still mention milliseconds and some functions use values that imply milliseconds are still in play).

I'm wary to change the validation logic (and the min/max/step of these fields) until this is clarified.

[jan-petr]

I'm sorry for this schizophrenic logic. That's mostly there for historical reasons. All that comes in studyPar.json and all that's in ASL4D.json follows the standard of BIDS - which is in seconds in most cases. However, many internal ExploreASL parameters - which can be entered through dataPar.json - are for historical reasons in milliseconds. Normally, this should all be invisible to the user as the user is supposed to import data through our module and work externally with BIDS. However, if he decides to enter ASL parameters through dataPar.json (which we really discourage now), then he's confronted with the old format. So the codebase should be fine. It's only the documentation that is misleading - though not really wrong.

I plan to redo the documentation to made this clear and avoid all these confusions.

The question is - can you deal with that in the GUI. As I say - we should enter most ASL parameters through the import, so that it's all in BIDS and dataPar.json should be only used for entering the processing options (though again, I know that the name is for historical reasons completely misleading).

[MauricePasternak]

Okay, thanks for clarifying. Yes, the GUI can handle all the above because it uses different validation schemas for each section of the GUI. More code & some redundancy, but flexible for situations like this.

Just to summarize what it does:

• For anything to do with importing (studyPar.json , sourceStructure.json, etc.), it sticks strictly with BIDS (i.e. uses seconds as units).
• For anything to do with manipulating rawdata/**/*_asl.json files, it again sticks strictly with BIDS
• For dealing with dataPar.json, it will use "the old format" logic (i.e. milliseconds). So, indeed, [790, 2110, 3090, 3630] was the appropriate array to use; there was just a different bug that prevented the error message from visually rendering.

[MauricePasternak]

I am moving towards BIDS preference of using seconds, so Aso had it correct.

I'm uncertain why this had lead to an error in his use case, especially when it hasn't displayed any error message.

In light of recent changes to the GUI's handling of the import, I see that it doesn't complain given the same input:

The newer version of the GUI (0.4.0) will be released soon.

[aso-toshihiko]

Right, no problem with importing, but with Define Parameters part.

And looks like 790, 2110, 3090, 3630 works. Let me see the retuls!

[MauricePasternak]

I hope it worked out for you. Nevertheless, thank you for pointing out a hidden bug that I otherwise wouldn't have noticed: you were supposed to have received a red-text error message under the field. This bug has been addressed.