Hi Manfred, Thanks again! It seems it was bad syntax: have to type the full name of the tag, not just its code (339), though in an earlier version of this library (as in CentOS) it seems it's different.
In any way, just knowing what each frame means already solves what I needed. I had thought about doing stuff in Matlab, but it seems mrisp_paint can do what I was thinking, so it's solved -- unless this issue is propagated to other commands, which I don't think would be the case (and will be clear when run). If it fails, then fix the tag is the way to go until it's fixed in a future version. Thanks again everyone! All the best, Anderson On 03/21/2011 08:28 PM, Manfred G Kitzbichler wrote: > 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, >>> >>> Manfred >>> >>> >>> >>> Graham 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 >> >> >> >> > > _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
