Question

I ai une petite fonction python VTK qui calcule le volume et la surface d'un objet incorporé dans une pile de TIFF images. Pour lire le TIFF's dans VTK, je l'ai utilisé vtkTIFFReader et traité le résultat en utilisant vtkImageThreshold. J'utilise ensuite vtkMassProperties pour extraire le volume et la surface de l'objet identifié après seuillage.

VTK-5.04, cette fonction retourne la valeur correcte pour une pile d'essai (3902 pixels). Cependant, en utilisant VTK-5.4.2 la même fonction retourne une valeur différente (422 pixels). Quelqu'un peut-il expliquer cela?


code

def testvtk():
    # read 36 TIFF images. Each TIFF is 27x27 pixels
    v16=vtk.vtkTIFFReader()
    v16.SetFilePrefix("d:/test/slice")
    v16.SetDataExtent(0,27,0,27,1,36)
    v16.SetFilePattern("%s%04d.tif")
    v16.SetDataSpacing (1,1,1)
    v16.Update()

    # Threshold level for seperating background/foreground pixels
    maxthres=81

    # Threshold the image stack
    thres=vtk.vtkImageThreshold()
    thres.SetInputConnection(v16.GetOutputPort())
    thres.ThresholdByLower(0)
    thres.ThresholdByUpper(maxthres)

    # create ISO surface from thresholded images
    iso=vtk.vtkImageMarchingCubes()
    iso.SetInputConnection(thres.GetOutputPort())

    # Have VTK calculate the Mass (volume) and surface area
    Mass = vtk.vtkMassProperties()
    Mass.SetInputConnection(iso.GetOutputPort())
    Mass.Update() 

    # just print the results
    print "Volume = ", Mass.GetVolume() 
    print "Surface = ", Mass.GetSurfaceArea()

Note

En testant les deux VTK-5.4.2 et 5.2.1 VTK, je rétrécis les choses un peu et croient que ce comportement a été introduit entre les versions 5.0.4 et 5.2.1.

Mise à jour

Il semble que dans VTK-5.4.2, vtkTIFFReader ignore le x et les valeurs y définies dans la méthode SetDataSpacing . Au lieu de cela vtkTIFFReader calcule la x et y dataspacing de la résolution rapportée par les fichiers TIFF.

Était-ce utile?

La solution

Je ne l'ai jamais entendu parler de VTK avant, mais ici il va.

est une bonne chose sur le logiciel opensource est que vous pouvez vérifier directement le code source. Mieux encore, s'il y a navigateur de contrôle de version en ligne, nous pouvons en parler en ligne comme celui-ci.

Voyons voir vtkMassProperties question. 5.0.4 utilise r1.28 et utilise r1.30 5.4.2. Voici le diff entre r1.28 et R.30 . La partie qui peuvent affecter les calculs de volume sont

vol[2] += (area * (double)u[2] * (double)zavg); // 5.0.4
vol[2] += (area * u[2] * zavg); // 5.4.2

et

kxyz[0] = (munc[0] + (wxyz/3.0) + ((wxy+wxz)/2.0)) /(double)(numCells); // 5.0.4
kxyz[0] = (munc[0] + (wxyz/3.0) + ((wxy+wxz)/2.0)) /numCells; // 5.4.2

mais tous les changements semblent ok pour moi.

Suivant suspects sont les vtkMarchingCubes . Diff entre r1.1.6. 1 et 1,5 .

self->UpdateProgress ((double) k / ((double) dims[2] - 1)); // 5.0.4
self->UpdateProgress (k / static_cast<double>(dims[2] - 1)); // 5.4.2

et

estimatedSize = (int) pow ((double) (dims[0] * dims[1] * dims[2]), .75); // 5.0.4
estimatedSize = static_cast<int>(
             pow(static_cast<double>(dims[0]*dims[1]*dims[2]),0.75)); // 5.4.2

Encore une fois, ils réparons choses sur la coulée, mais il semble ok.

Aussi bien voir vtkImageThreshold aussi. Diff entre r1.50 et r1. 52 .

lowerThreshold = (IT) inData->GetScalarTypeMin(); // 5.0.4
lowerThreshold = static_cast<IT>(inData->GetScalarTypeMin()); // 5.4.2

Il y a tas plus, mais ils sont tous les trucs casting.

Il devient plus intéressant avec vtkTIFFReader . Diff entre 1,51 et 1,63 . Comme vous pouvez le voir par la différence dans les numéros de révision, il y a eu un certain développement dans cette classe par rapport aux autres. Voici les commentaires de checkin:

  • ENH: Ajoutez un nom pour scalaires. Visible dans Paraview.
  • ENH: vtkDataArray a maintenant une nouvelle superclasse-vtkAbstractArray ...
  • ENH:. Définir le nombre par défaut de sampels par pixel pour les fichiers qui manquent cette méta-données
  • ENH. Lire seulement ce dont vous avez besoin
  • ENH: ajouter le support de fichier TIFF multipage
  • ENH: Ivars d'impression
  • BUG: TIFF lecteur ne tenait pas compte correctement pour les données codées RLE. En outre, ExecuteInformation espacement spécifié par l'utilisateur et l'origine a écrasé.
  • BUG:. Lors de la lecture beach.tif (du courant CVS vtkdata), l'image serait chargé à l'envers
  • STYLE: s / OrientationTypeSpecifiedFlag / OriginSpecifiedFlag / g et s / OrientationTypeSpecifiedFlag / SpacingSpecifiedFlag / g
  • BUG:. Lecteur n'a pas été correctement manipulation des degrés
  • COMP:. La fixation d'un avertissement
  • COMP: Se débarrasser d'un avertissement.

De la quantité de changements qui a été fait dans vtkTIFFReader, je suppose que la différence de comportement vient de là. Par exemple, il peut avoir commencé à reconnaître votre Tiff comme format différent et changé les valeurs de pixels internes. Essayez d'imprimer des valeurs de pixel et de voir s'il y a une différence. Si les valeurs de pixels ont changé maxthres=81 peut être trop élevé.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top