Hi Anderson,
I have set the tag with Emacs in hexl-mode - but I wouldn't suggest to try that at home ;-) Actually tiffset should probably do the trick, maybe you used the hex-number instead of decimal for the tag code?
- Manfred
Anderson Winkler wrote:
Hi Graham and Manfred,
Thanks for the help! Interesting is that the .tif created with mris_make_template in FS 5.0 contain the SampleFormat tag set, but not the .tif that are shipped with FS (maybe they were created with a previous version of the TIFF libraries?). But even so, SampleFormat is set as 0x2, which Google says is for signed integers.
Manfred: how are you changing the tags? I tried with tiffset, from the libtiff-tools package in Debian, but it doesn't seem to be changing anything, either in the original file with 9 frames or after splitting.
Thanks!
Anderson
On 03/21/2011 07:47 PM, Manfred G Kitzbichler wrote:
The problem seems to be that in the template TIFF image files the SampleFormat tag 0x153 is not set, so Matlab assumes by default 32bit means int32. I hacked one of the files by hand adding tag 0x153 with value 0x3 (IEEE floating point) which was consequently loaded by the Matlab imread() function as 'single' type instead of int32. Looking at the resulting matrix with imagesc() revealed the loop-like structures one can see on the weblink below, so I guess that's the expected result. Perhaps someone would want to patch all the template files accordingly (and more cleanly since I had to replace one of the regular tags in order to fit in the SampleFormat tag).
Best,
ManfredGraham Wideman wrote:
Hi Anderson,
This might be helpful (beware datedness though).
https://surfer.nmr.mgh.harvard.edu/fswiki/TemplateTifImageFiles
The data at the time I did that goc was evidently stored in 32-bit float format... that could lead to your wild number range if you interpret it as int-32.
-- Graham
At 3/21/2011 12:44 PM, Anderson Winkler wrote:
Means and variances are large too, around 1,000,000,000 for all 3 sets. I'm using imread in Matlab and I don't seem to find options to set endianess. The numbers apparently get less badly behaved (e.g. mean ~21,000 and var ~15,000) if I convert to PNG with ImageMagick, but I'm unfamiliar with these ranges anyway. The scaling, even in PNG, doesn't seem linear, but logarithmic.
Regardless..., knowing what is in each frame already solves what is needed... Thanks!
Anderson
On 03/21/2011 03:11 PM, Bruce Fischl wrote:
are they? I thought they were just stored as straight variances. Are the means large too? Make sure there are no byte-swapping issues
On Mon, 21 Mar 2011, Anderson Winkler wrote:
Hi Bruce,
Thanks! They appear to be stored as 32-bits integers and when I open I get very large numbers. How could I scale them back to the actual means/vars/dofs? I just tried to find a linear relation for the dof, but I get a non-integer result... maybe it's a log function (?)
Thanks again!
All the best,
Anderson
On 03/21/2011 02:00 PM, Bruce Fischl wrote:
> Hi Anderson, > > there are 3 sets of 3 frames each. In each set I store: > > Frame 1: means > Frame 2: variances > Frame 3: dofs (actually, there is only 1 dof for the whole map) > > these are stored for curv, sulc and inflated curvature. > > cheers > Bruce > > On Mon, 21 Mar 2011, Anderson Winkler wrote: > > > > > >> Hi all, >> >> The .tif files (templates) contain 9 pages each, which seem to be >> organized as 3+3+3. I think I understand that they are equirectangular >> projections of the latitude/longitude of curvature and sulcal depth, is >> this correct? But what exactly each of these 9 frames contain? >> >> Thanks! >> >> Anderson >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> >> >> >> > The information in this e-mail is intended only for the person to whom > it is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you > in error > but does not contain patient information, please contact the sender > and properly > dispose of the e-mail. > > > > > > _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer