<div dir="ltr">hi matthew,<div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure what you mean by 'did not interpret this' unless you are<br>
agreeing with me that the niftiio library gives no clues as what the<br>
intention for the in-memory type was.  If anything I think that<br>
supports my reading that the authors had not considered the<br>
interpretation of "scl_slope != 0 -> in-memory float".<br></blockquote><div><br></div><div>i simply meant they left any interpretation of how to scale or change of in-memory data type to the end developer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can surely attach the raw scalefactors to the array proxy (dataobj),<br></blockquote><div><br></div><div>that would be great</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but I think it's a terrible idea to use the scl_slope == 0 as an<br>
indication for in-memory type, because it's not a convention that (as<br>
far as I know) anyone else uses,<br></blockquote><div><br></div><div>all the examples of the code bases i provided in fact leave the in-memory type to be the same as the native dtype for scalefactors (0, X) and (1, 0). i agree, that this is an implementation of the standard as interpreted by those developers, similar to present nibabel. i do agree that nifti authors had nothing to say about such an interpretation.</div><div><br></div><div>cheers,</div><div><br></div><div>satra</div></div></div></div>