non-uniform of mixed sub-brick types: what does this mean?

AFNI Message Board
1

Hello! I’d like more detailed info on AFNI error messages referring to mixed sub-brick types. I can’t find information on what the supposed “types” are (float vs short? something else?). It comes up sporadically in my data despite using identical processing pipelines and I’m having trouble debugging it since I don’t know what generates these type differences. Is there any info on what preprocessing algorithm could produce or affect types, and how to address it? Thank you!

2

Sorry for being slow.

Yes, it is dangerous to mix data types (short, byte, float) across volumes within a single dataset. With a script and 3dinfo details on offending datasets, I could try to help diagnose where it is coming from. Please feel free to send me info via email (click on my name).

  • rick
3

Hi Rick,

Although this was a while ago (and I found some hacky workaround) I really appreciate your response. I just found that you posted a solution to my problem in another post: https://afni.nimh.nih.gov/afni/community/board/read.php?1,157934,158150#msg-158150 . That was also the root of my issue – Dimon was converting some of my data to floats but not all, so the ushort2float option has solved all of this. I hope this is helpful to others who might encounter this error. I am so thankful that you were able to fix this – Thank you!

Anna

4

Thanks for the update, Anna!

  • rick
5

Anna-

I can replicate your issue. It seems that some AFNI tools are unable to mix data types. This problem can be elicited by dcm2niix, which uses INT16 where possible (which AFNI preserves) but defaults to UINT16 when required (which AFNI converts to 32-bit floats). I discuss this problem and solutions at
Issue 338.