Open thehabes opened 6 years ago
There is a bit of ambiguity around why. The macro says
if (acRtiDesired) {
//do a for loop over hemisphere captures and create jpegs
}
if (acRakingDesired) {
//do a for loop over hemisphere captures and create jp2
}
if (xsRtiDesired || xsRakingDesired) {
//process stacks
//do a for loop over hemisphere captures
//if xsRTIDesired, create jpeg
//if xsRakingDesired, create jp2
}
if (psRtiDesired || psRakingDesired) {
//process no-gamma folder
//do a for loop over no-gamma captures
//if psRTIDesired, create jpeg
//if listOfRakingDirections[i+1] is true, create jp2
}
This order of operations was brought into the plugin. It is possible to rewrite the AC process so it does all the processing in one loop, so long as you check if acRakingDesired vs acRTIDesired inside the loop. I am not entirely sure of the consequences, perhaps there is a deeper underlying reason why the logic was separated as such.
The code notes where this change could be possible. This may be out of scope to change at this point and would be a great first issue for the next round.
From Todd: Today I noticed that with Xs it created the jp2 files in the same run as creating the jpeg files, while with Ac it created all the jpeg and then went back to do the jp2. The behavior observed in Xs seems preferable because the core processing is not duplicated. This would be noticeable if someone wanted all the positions created for static raking (plausible).