1. Why is xASL_im_MergePWI4D a separate function, and is all the other merging defined in a subfunction? (I don't mind much, just asking)

It's a separate function that handles the merging of parameters and images. We have agreed upon that. There are no important subfunctions in it. Is that good as an answer to your question?

HENK: No I know that :) My question is why this is a separate function and the merging admin (variables definition etc) is a subfunction. It seems arbitrary why one thing is a separate function and the other is not. Not very important.

JAN: I don't see which subfunction you mean. But lets leave it if it is unimportant.

2. You added this statement for merging:
   x.mutex.HasState(StateName{iState-4}) && (~x.mutex.HasState(StateName{iState}) || bOutput)

which I don't understand. Why do you only want to define path_PWI4D_used when you have finished resampling && not yet quantification or you want output? A) it is IMHO too little overhead to add an if-statement (just add an if exist and we always run the same code B) how does bOutput make sense, we never need PWI4D_used as output?

It had a very good reason to do it like this:

1. In case we finished ASL module completely in the first run, we of course don't need this extra IF.
2. However, if we run the ASL module again (e.g. adding an extra subject), it will do the merging again for all subjects. Which is an extra overhead. And what is worse - it could mean (if dataPar.json was modified but the quantification isn't run again) that the merged PWI and CBF are done on different images. So that's why I added the mutex.
3. But in case quantification was done, but QC not, you wanna make sure that the PWI_used is initialized, that's why I added bOutput, which is false when the module is fully completed, but true otherwise.

HENK: Is the merging a lot of overhead? It only reads a json, that is not a lot of overhead right?

JAN: It's a cosiderable overhead when you have 100+ subjects. It's definitively 1000 times larger overhead to I/O NII instead of keeping a single IF :)

HENK: In the past we had something that would return xASL_module_ASL when it had 999_ready, not sure why we removed this.
JAN: We still have 999_ready. But 999_ready doesn't skip the entire module, but still runs through with bOutput turned OFF. So that's why I used bOutput as a proxy of 999_ready. We can of course do it some other way, but some kind of a check is needed.

So the if statement had a very good reason to avoid unnecessary calculations, reduce overhead, avoid inconsistencies.
I agree that we could check for QC-mutex instead of bOutput instead if you want. We also need to rewrite the code accordingly or revert your commit.

HENK: Probably checking that quantification OR QC mutex doesn't exist is then the best indeed. You can keep my "improved comments" and move this improved mutex checking back?
JAN: OK, so I'll move in all the mutexes, but instead of bOutput, I'll put in a QC-mutex. See my fix committed.