Hi Yves, Samuel, The bug I mentioned regarding pixel-shift in 2D rendering is still open... We need to take a closer look at how it occurred to make sure that our fix doesn't produce issues in other parts of handling resliced data. You can keep track of it on the bugzilla entry I posted in my last email.
Regarding the "loss of ROI at the extremities for large rotations": I believe you mean that the extracted (rotated) slice isn't large enough to contain the entire 2D image output of the reslicer. The issue becomes simpler to understand when you regard the extracted plane as fixed in space (e.g. the x-y-plane, with z=0), and imagine that, instead of the plane, the volume cuboid is rotated (with an inverse rotation). At non-rectangular angles the intersection of this plane with the cuboid can cover an area larger than any of the cuboid's sides. In MITK, the extent of the resulting plane is (optionally) adjusted to be large enough for this entire area. That is why in some cases, the xMin / yMin coordinates of the plane will be negative. In mitk::ExtractDirectedPlaneImageFilter the calculation of this plane extent is done in the method CalculateClippedPlaneBounds(). Note however that this only works correctly if the WorldGeometry of the image owns a ReferenceGeometry (see line 210). Otherwise, the plane extent will be too large (or too small) for rotated planes. CalculateClippedPlaneBounds() also checks if the passed ReferenceGeometry is an "ImageGeometry". When this flag is set to true, the extent is shifted by 0.5 voxels in each direction. It has been introduced to Geometry3D to make sure that voxels of an mitk::Image described by the Geometry are localized by their actual center, and not by their left upper corner. Possibly this is also the reason for the "pixel shift" that you observed in your program. As I understood from your emails, you intend to write on an extracted (rotated) 2D slices, and write the result back into the 3D image. I'm not sure if this will (or can) always work correctly. When mapping a voxel from 3D to 2D and again back to 3D, do you land at the exact same pixel always? If not, this could e.g. result in voxel gaps if your bounds are not set perfectly (or if the mapping algorithm used by the vtkImageReslicer is not perfectly bijective). Regards, Mathias > -----Original Message----- > From: Yves Martelli [mailto:ymarte...@cistib.upf.edu] > Sent: Monday, October 05, 2009 9:26 AM > To: mitk-users@lists.sourceforge.net > Subject: Re: [mitk-users] Segmentation on reoriented planes > > Dear Samuel, > Just to confirm that we are still at the same position I was when I wrote that > email 2 weeks ago: looking at fixing a ~1 pixel shift at drawing time and some > loss of ROI at the extremities for large rotations. > Regards, > Yves > > -----Original Message----- > From: Daniel Maleike [mailto:d.male...@dkfz-heidelberg.de] > Sent: lunes, 05 de octubre de 2009 8:02 > To: mitk-users@lists.sourceforge.net > Subject: Re: [mitk-users] Segmentation on reoriented planes > > On Thu, 2009-10-01 at 16:43 +0100, Samuel Silva wrote: > > Hi! > > > > I was wondering how are things going regarding segmentation on > > reoriented planes. This would be a valuable feature for me also. > > I will probably not be able to help much on the development but if you > > need anyone to test it I will be glad to help. > > Dear Samuel, > > segmentation on reoriented planes was kindly offered by Xavier P and > Chiara R. From what I understand they are still working on it (and Yves > obviously, too). > > I'd like to draw your attention to our bug tracker at bugs.mitk.org: > > http://bugs.mitk.org/show_bug.cgi?id=2210 > > Bug #2210 was opened to discuss progress in this work and exchange > source code (patches). If you create an account, you can set yourself CC > for this issue and follow its progress. > > Kind regards > Daniel > > -- > Dr. Daniel Maleike Phone: +49 6221 42 2326 > Deutsches Krebsforschungszentrum Im Neuenheimer Feld 280 > Medical and Biological Informatics (E130) 69120 Heidelberg > > > ------------------------------------------------------------------------ ------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > mitk-users mailing list > mitk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mitk-users > > Seitel Mathias wrote: > > > > Hi Yves, > > > > Thanks for your report. The mitk::ExtractDirectedPlaneImageFilter is > > mostly based on code from the MITK rendering module, namely from > > mitk::ImageMapper2D. Part of this code may be rendering-specific and > > therefore appear cumbersome when just using this filter to extract slices. > > > > You are mentioning that the output extent is sometimes set to negative > > values. Which values of xMin/xMax, yMin/yMax do you get in this case? > > > > Also, is "boundsInitialized" set to true in your case (lines 314ff in > > the current MITK SVN checkout)? > > > > We recently discovered a bug due to which a shift of one pixel appears > > in some cases of 2D image rendering which might be related to the > > behavior you observed (see http://bugs.mitk.org/show_bug.cgi?id=2401). > > We plan to look into this within the next one or two weeks. > > > > Regards, > > > > Mathias > > > > *From:* Yves Martelli [mailto:ymarte...@cistib.upf.edu] > > *Sent:* Thursday, September 17, 2009 11:47 AM > > *To:* mitk-users@lists.sourceforge.net > > *Subject:* [mitk-users] Segmentation on reoriented planes > > > > Hi, > > > > I'm part of the UPF in Barcelona and we are working on segmentations > > on reoriented planes. We are using the > > mitkExtractDirectedPlaneImageFilter to extract a slice from the mask > > volume to then write the user selected/deleted pixels on it. We then > > write them back to the mask volume using the slice index to world and > > then volume world to index transformations. > > > > Regarding the extraction, we were having troubles with black stripes > > in the extracted segmentation from the mask volume. We think we solved > > it by upsampling the extracted slice by a factor of two (no theory > > behind this!). But we are having troubles with the extent that is > > given to the output image of the VtkImageReslice filter. It can > > contain negative values which seem to result in strange output slices. > > Whenever we try to draw on this slice (using the > > mitk::ContourUtils::ProjectContourTo2DSlice method), previously > > created masks are shifted. When using the extent calculated by the > > VtkImageReslice filter (maximum range of int), this shift disappears. > > > > When thinking a bit on this strategy, it is a bit risky in the sense > > that you reprocess previously saved data and take the risk of > > modifying it (different resampling results), so we are thinking of not > > extracting the slice from the mask volume, but just create one with > > the proper geometry. > > > > These two modifications seem to fix our biggest problems but we still > > have issues: one being that there is a shift between the drawn contour > > and the saved one (roughly one pixel) and the second one with big > > angles which disable parts of the image (no contour can be drawn). > > > > Sorry for the long email, my question will be: is there a reason to > > set the extent of the output slice after the VtkImageReslice filter? > > And if you have any ideas on the drawing shift... > > > > Regards, > > > > Yves > > > ------------------------------------------------------------------------ ------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > mitk-users mailing list > mitk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
