boldref conversions should have the same datatype of corresponding bold

[oesteban]

Currently, they are float32 even when the _bold files are int16

[effigies]

It's unclear what the problem is, here. We're reporting what we're using internally as a reference image, which is float32.

Is this aesthetic or is there a use case that makes matching dtypes necessary?

[effigies]

Also, this will change outputs for non-erroring runs, so I would suggest making it 20.1, not 20.0.1.

[oesteban]

We're reporting what we're using internally as a reference image, which is float32.

In my head, the outputs should not be a report of what internally happened rather than the ingredients for downstream analysis. With that mindset, the bold reference should be as consistent as possible w.r.t. the corresponding bold and data type is one of the most obvious features to do that.

For example, maybe in the future, we might switch the internal reference to a super-sampled reference for whatever reason. However, for downstream processing, it doesn't much sense to have a boldref with a resolution different to the bold it references (perhaps with the exception of sbrefs, and I'd be doubtful on this one too).

I would be happy to report that the internal boldref is float32 for the sake of transparency, but I don't think propagating the internal datatype helps shareability and ease-of-use in any way.

It's unclear what the problem is, here.

Given the argumentation above, the problem would be the inconsistency of the data type of bold-refs with that of the bold they reference.

[effigies]

I might also just be missing what downstream uses there are... I thought it really was mostly a reporting thing.

[oesteban]

The only use-case I can think of quickly is having an actual file to link from a SpatialReference field of another derivative.

[effigies]

Okay. In that case the dtype is kind of irrelevant. I guess saving 50% on 3MB * 10k subjects (~15GB) is worth it.

[oesteban]

Agreed, the proposal is for consistency rather than storage savings.