From will.schroeder at kitware.com Wed Mar 1 06:16:59 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 1 Mar 2017 06:16:59 -0500 Subject: [vtk-developers] vtkPointInterpolator algorithm? In-Reply-To: References: Message-ID: Check out: https://blog.kitware.com/point-and-smoothed-particle-hydrodynamics-sph-interpolation-in-vtk/ for an introduction and additional references. Note the difference between SPH and generalized point interpolation (SPH is a spline interpolation which is subject to conservation properties). In general the algorithm is very simple. For each point p to be interpolated onto, find the neighborhood of points around p (defined by a radius, number of points, etc) and use these neighboring points to interpolate onto p. (This operation is carried out in parallel using vtkSMPTools.) The manner in which the interpolation occurs is a function of the interpolating kernel. One twist to all of this is that efficiently finding neighboring points requires some sort of point locator. Typically vtkStaticPointLocator is used because it is very fast to build and delete, has modest memory requirements, and builds in parallel. On Tue, Feb 28, 2017 at 8:44 PM, Joshua Murphy < Joshua.Murphy at lasp.colorado.edu> wrote: > Hello, > > I am working on my dissertation, and I am trying to find a source that > explains how the vtkPointInterpolator works in 7.1. Specifically, I would > like some information on how the SMP version works. Could someone point me > to a source that describes the algorithm? Or describe it to me via email? > > Thanks, > Josh Murphy > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pandia005 at gmail.com Mon Mar 6 05:40:19 2017 From: pandia005 at gmail.com (Pandia raja) Date: Mon, 6 Mar 2017 16:10:19 +0530 Subject: [vtk-developers] Reg:Oblique MPR Message-ID: Hi, Could you please help me to generate Oblique MPR. I can able to generate Orthogonal MPR using the below code.My requirement is based on the angle seletion I need to generate sagittal and coronal images, dicomImageReader.SetDirectoryName ( dicomImagePath ); dicomImageReader.Update (); xyminmax = dicomImageReader.GetOutput ().GetExtent (); xMin = xyminmax[0]; xMax = xyminmax[1]; yMin = xyminmax[2]; yMax = xyminmax[3]; zMin = xyminmax[4]; zMax = xyminmax[5]; spacing = dicomImageReader.GetOutput ().GetSpacing (); sx = spacing[0]; sy = spacing[1]; sz = spacing[2]; origin = dicomImageReader.GetOutput ().GetOrigin (); ox = origin[0]; oy = origin[1]; oz = origin[2]; //Display mpr image double cx = (ox + (0.5 * (xMax - xMin)) * sx); double cy = (oy + (0.5 * (yMax - yMin)) * sy); double cz = (oy + (0.5 * (zMax - zMin)) * sz); double[] axialElements = { 1, 0, 0, cx, 0, 1, 0, cy, 0, 0, 1, cz, 0, 0, 0, 1 }; double[] coronalElements = { 1, 0, 0, cx, 0, 0, 1, cy, 0, -1, 0, cz, 0, 0, 0, 1 }; double[] sagittalElements = { 0, 0, -1, cx, -1, 0, 0, cy, 0, -1, 0, cz, 0, 0, 0, 1 }; // For display the Axial Slice... // Set the slice orientation... vtkMatrix4x4 axialResliceAxes = new vtkMatrix4x4(); axialResliceAxes.DeepCopy(axialElements); // Extract a slice in the desired orientation... axialReslice = new vtkImageReslice(); //axialReslice.SetSlabNumberOfSlices ( 1 ); axialReslice.SetInputConnection(dicomImageReader.GetOutputPort()); axialReslice.SetOutputDimensionality(2); axialReslice.SetResliceAxes(axialResliceAxes); axialReslice.SetInterpolationModeToLinear(); axialReslice.SetResliceAxes(axialResliceAxes); // For display the Coronal Slice... // Set the slice orientation... vtkMatrix4x4 coronalResliceAxes = new vtkMatrix4x4(); coronalResliceAxes.DeepCopy(coronalElements); // Extract a slice in the desired orientation... coronalReslice = new vtkImageReslice(); coronalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); coronalReslice.SetOutputDimensionality(2); coronalReslice.SetResliceAxes(coronalResliceAxes); coronalReslice.SetInterpolationModeToLinear(); coronalReslice.SetResliceAxes(coronalResliceAxes); // For display the Sagittal Slice... // Set the slice orientation... vtkMatrix4x4 sagittalResliceAxes = new vtkMatrix4x4(); sagittalResliceAxes.DeepCopy(sagittalElements); // Extract a slice in the desired orientation sagittalReslice = new vtkImageReslice(); sagittalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); sagittalReslice.SetOutputDimensionality(2); sagittalReslice.SetResliceAxes(sagittalResliceAxes); sagittalReslice.SetInterpolationModeToLinear(); sagittalReslice.SetResliceAxes(sagittalResliceAxes); dicomImageReader.Delete (); Thanks, Pandiyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankhesh.jhaveri at kitware.com Mon Mar 6 09:05:45 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Mon, 06 Mar 2017 14:05:45 +0000 Subject: [vtk-developers] Reg:Oblique MPR In-Reply-To: References: Message-ID: Hi Pandiyan, You should be able to use the same class (vtkImageReslice) to generate oblique MPR. Just use the appropriate reslice axes direction cosines and origin. Hope that helps. Sankhesh ? On Mon, Mar 6, 2017 at 5:40 AM Pandia raja wrote: > Hi, > > Could you please help me to generate Oblique MPR. I can able to generate > Orthogonal MPR using the below code.My requirement is based on the angle > seletion I need to generate sagittal and coronal images, > > > dicomImageReader.SetDirectoryName ( dicomImagePath ); > dicomImageReader.Update (); > xyminmax = dicomImageReader.GetOutput ().GetExtent (); > xMin = xyminmax[0]; > xMax = xyminmax[1]; > yMin = xyminmax[2]; > yMax = xyminmax[3]; > zMin = xyminmax[4]; > zMax = xyminmax[5]; > > spacing = dicomImageReader.GetOutput ().GetSpacing (); > sx = spacing[0]; > sy = spacing[1]; > sz = spacing[2]; > > origin = dicomImageReader.GetOutput ().GetOrigin (); > ox = origin[0]; > oy = origin[1]; > oz = origin[2]; > //Display mpr image > double cx = (ox + (0.5 * (xMax - xMin)) * sx); > double cy = (oy + (0.5 * (yMax - yMin)) * sy); > double cz = (oy + (0.5 * (zMax - zMin)) * sz); > > double[] axialElements = { 1, 0, 0, cx, 0, 1, 0, cy, 0, 0, 1, cz, 0, 0, 0, > 1 }; > double[] coronalElements = { 1, 0, 0, cx, 0, 0, 1, cy, 0, -1, 0, cz, 0, 0, > 0, 1 }; > double[] sagittalElements = { 0, 0, -1, cx, -1, 0, 0, cy, 0, -1, 0, cz, 0, > 0, 0, 1 }; > > // For display the Axial Slice... > // Set the slice orientation... > vtkMatrix4x4 axialResliceAxes = new vtkMatrix4x4(); > axialResliceAxes.DeepCopy(axialElements); > > // Extract a slice in the desired orientation... > axialReslice = new vtkImageReslice(); > //axialReslice.SetSlabNumberOfSlices ( 1 ); > axialReslice.SetInputConnection(dicomImageReader.GetOutputPort()); > axialReslice.SetOutputDimensionality(2); > axialReslice.SetResliceAxes(axialResliceAxes); > axialReslice.SetInterpolationModeToLinear(); > axialReslice.SetResliceAxes(axialResliceAxes); > > // For display the Coronal Slice... > // Set the slice orientation... > vtkMatrix4x4 coronalResliceAxes = new vtkMatrix4x4(); > coronalResliceAxes.DeepCopy(coronalElements); > > // Extract a slice in the desired orientation... > coronalReslice = new vtkImageReslice(); > coronalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); > coronalReslice.SetOutputDimensionality(2); > coronalReslice.SetResliceAxes(coronalResliceAxes); > coronalReslice.SetInterpolationModeToLinear(); > coronalReslice.SetResliceAxes(coronalResliceAxes); > > // For display the Sagittal Slice... > // Set the slice orientation... > vtkMatrix4x4 sagittalResliceAxes = new vtkMatrix4x4(); > sagittalResliceAxes.DeepCopy(sagittalElements); > > // Extract a slice in the desired orientation > sagittalReslice = new vtkImageReslice(); > sagittalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); > sagittalReslice.SetOutputDimensionality(2); > sagittalReslice.SetResliceAxes(sagittalResliceAxes); > sagittalReslice.SetInterpolationModeToLinear(); > sagittalReslice.SetResliceAxes(sagittalResliceAxes); > dicomImageReader.Delete (); > > Thanks, > Pandiyan > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Mar 6 09:28:17 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 6 Mar 2017 07:28:17 -0700 Subject: [vtk-developers] Reg:Oblique MPR In-Reply-To: References: Message-ID: I'll add that you can use SetResliceAxes() and SetResliceTransform() together. Use the former to define a set of axes, and use the latter to apply a rotation. - David On Mon, Mar 6, 2017 at 7:05 AM, Sankhesh Jhaveri < sankhesh.jhaveri at kitware.com> wrote: > Hi Pandiyan, > > You should be able to use the same class (vtkImageReslice) to generate > oblique MPR. Just use the appropriate reslice axes direction cosines and > origin. > > Hope that helps. > > Sankhesh > ? > > On Mon, Mar 6, 2017 at 5:40 AM Pandia raja wrote: > >> Hi, >> >> Could you please help me to generate Oblique MPR. I can able to generate >> Orthogonal MPR using the below code.My requirement is based on the angle >> seletion I need to generate sagittal and coronal images, >> >> >> dicomImageReader.SetDirectoryName ( dicomImagePath ); >> dicomImageReader.Update (); >> xyminmax = dicomImageReader.GetOutput ().GetExtent (); >> xMin = xyminmax[0]; >> xMax = xyminmax[1]; >> yMin = xyminmax[2]; >> yMax = xyminmax[3]; >> zMin = xyminmax[4]; >> zMax = xyminmax[5]; >> >> spacing = dicomImageReader.GetOutput ().GetSpacing (); >> sx = spacing[0]; >> sy = spacing[1]; >> sz = spacing[2]; >> >> origin = dicomImageReader.GetOutput ().GetOrigin (); >> ox = origin[0]; >> oy = origin[1]; >> oz = origin[2]; >> //Display mpr image >> double cx = (ox + (0.5 * (xMax - xMin)) * sx); >> double cy = (oy + (0.5 * (yMax - yMin)) * sy); >> double cz = (oy + (0.5 * (zMax - zMin)) * sz); >> >> double[] axialElements = { 1, 0, 0, cx, 0, 1, 0, cy, 0, 0, 1, cz, 0, 0, >> 0, 1 }; >> double[] coronalElements = { 1, 0, 0, cx, 0, 0, 1, cy, 0, -1, 0, cz, 0, >> 0, 0, 1 }; >> double[] sagittalElements = { 0, 0, -1, cx, -1, 0, 0, cy, 0, -1, 0, cz, >> 0, 0, 0, 1 }; >> >> // For display the Axial Slice... >> // Set the slice orientation... >> vtkMatrix4x4 axialResliceAxes = new vtkMatrix4x4(); >> axialResliceAxes.DeepCopy(axialElements); >> >> // Extract a slice in the desired orientation... >> axialReslice = new vtkImageReslice(); >> //axialReslice.SetSlabNumberOfSlices ( 1 ); >> axialReslice.SetInputConnection(dicomImageReader.GetOutputPort()); >> axialReslice.SetOutputDimensionality(2); >> axialReslice.SetResliceAxes(axialResliceAxes); >> axialReslice.SetInterpolationModeToLinear(); >> axialReslice.SetResliceAxes(axialResliceAxes); >> >> // For display the Coronal Slice... >> // Set the slice orientation... >> vtkMatrix4x4 coronalResliceAxes = new vtkMatrix4x4(); >> coronalResliceAxes.DeepCopy(coronalElements); >> >> // Extract a slice in the desired orientation... >> coronalReslice = new vtkImageReslice(); >> coronalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); >> coronalReslice.SetOutputDimensionality(2); >> coronalReslice.SetResliceAxes(coronalResliceAxes); >> coronalReslice.SetInterpolationModeToLinear(); >> coronalReslice.SetResliceAxes(coronalResliceAxes); >> >> // For display the Sagittal Slice... >> // Set the slice orientation... >> vtkMatrix4x4 sagittalResliceAxes = new vtkMatrix4x4(); >> sagittalResliceAxes.DeepCopy(sagittalElements); >> >> // Extract a slice in the desired orientation >> sagittalReslice = new vtkImageReslice(); >> sagittalReslice.SetInputConnection(dicomImageReader.GetOutputPort()); >> sagittalReslice.SetOutputDimensionality(2); >> sagittalReslice.SetResliceAxes(sagittalResliceAxes); >> sagittalReslice.SetInterpolationModeToLinear(); >> sagittalReslice.SetResliceAxes(sagittalResliceAxes); >> dicomImageReader.Delete (); >> >> Thanks, >> Pandiyan >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Mar 6 16:18:10 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Mar 2017 16:18:10 -0500 Subject: [vtk-developers] [Buildbot] dash1win7 removed Message-ID: <20170306211810.GA26694@megas.kitware.com> Hi all, The machine had a hard drive failure and is gone. The hardware was 2010-era and it's not really worth resurrecting it for how long it took to do builds. This was the only 32bit, static, or Visual Studio dashboard on buildbot, but tarvalon is available (again) and will probably come back some time this month and the missing configurations (except maybe 32bit?) distributed over the available machines. --Ben From simon.esneault at gmail.com Wed Mar 8 04:35:26 2017 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Wed, 8 Mar 2017 10:35:26 +0100 Subject: [vtk-developers] [vtkusers] VTK 7.1 error "Shader failed to compile" with GPU Volume rendering and clipping planes Message-ID: Hello, After the migration to VTK 7.1, we get a crash in the shader program (it can't be build) when trying to use clipping planes on GPU volume rendering mapper The error is : Error: ERROR: In C:\Dev\ES-Externals\superbuild\VTK\src\Rendering\OpenGL2\vtkShaderProgram.cxx, line 395 vtkShaderProgram (000001FEBFB646D0): 0(474) : error C1038: declaration of "temp" conflicts with previous declaration at 0(426) it appears the variable Vec4 temp is declared twice... Here is the full log https://paste.ee/p/FsdWx On Windows 10, VTK is built in 64 bits with Visual Studio 2013 along with Qt 5.3.2 and other libraries. Ring a bell to anyone ? Thanks Simon -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Wed Mar 8 17:03:47 2017 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Wed, 8 Mar 2017 23:03:47 +0100 Subject: [vtk-developers] [vtkusers] Simple vertex is square with VTK 7.1, was round with VTK 6.3 (old backend) In-Reply-To: References: Message-ID: Hello VTK developers This simple program does not give the same result with VTK 7.1 (OpenGL2 backend) than it did with VTK 6.3 (old OpenGL backend) //---------------------------------------------------------- ------------------------------------------------------ #include "vtkIdList.h" #include "vtkPNGWriter.h" #include "vtkPolyData.h" #include "vtkPolyDataMapper.h" #include "vtkProperty.h" #include "vtkRenderWindow.h" #include "vtkRenderWindowInteractor.h" #include "vtkRenderer.h" #include "vtkWindowToImageFilter.h" int main( int argc, char *argv[] ){ vtkSmartPointer l_vertex = vtkSmartPointer::New(); l_vertex->SetNumberOfPoints( 1 ); vtkSmartPointer l_pix_cell = vtkSmartPointer:: New(); l_pix_cell->InsertNextId( 0 ); vtkSmartPointer l_polydata = vtkSmartPointer:: New(); l_polydata->Allocate( 1 ); l_polydata->SetPoints( l_vertex ); l_polydata->InsertNextCell( VTK_VERTEX, l_pix_cell ); vtkSmartPointer l_mapper = vtkSmartPointer< vtkPolyDataMapper>::New(); l_mapper->SetInputData( l_polydata ); vtkSmartPointer l_actor = vtkSmartPointer::New(); l_actor->SetMapper( l_mapper ); l_actor->GetProperty()->SetPointSize( 20 ); vtkSmartPointer l_renderer = vtkSmartPointer:: New(); l_renderer->AddActor( l_actor ); vtkSmartPointer l_render_window = vtkSmartPointer< vtkRenderWindow>::New(); l_render_window->AddRenderer( l_renderer ); l_render_window->Render(); vtkSmartPointer l_window_to_image = vtkSmartPointer::New(); l_window_to_image->SetInput( l_render_window ); vtkSmartPointer l_writer = vtkSmartPointer: :New(); l_writer->SetFileName( "simple-vertex.png" ); l_writer->SetInputConnection( l_window_to_image->GetOutputPort() ); l_writer->Write(); } //---------------------------------------------------------- ------------------------------------------------------ The VTK 6.3 vertex was a disk while the VTK 7.1 is a square, see the attached screenshot ... Is there some additional parameters/settings that need to be turned on somewhere to restore that functionality ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-vertex-vtk-6.3.png Type: image/png Size: 574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-vertex-vtk-7.1.png Type: image/png Size: 401 bytes Desc: not available URL: From sean at rogue-research.com Thu Mar 9 13:27:08 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 9 Mar 2017 13:27:08 -0500 Subject: [vtk-developers] open.cdash.org updated In-Reply-To: References: Message-ID: <20170309182708.766732742@mail.rogue-research.com> On Tue, 21 Feb 2017 09:57:31 -0500, Zack Galbreath said: >I just upgraded open.cdash.org. The most visible change you'll notice is >that the Update column now shows the commit that was built rather than the >number of files that changed. I notice it doesn't show this for my cppcheck VTK dashboards. Is that a cdash bug, or something about the way I submit the results? Would be nice to have it there... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Thu Mar 9 13:39:34 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 9 Mar 2017 11:39:34 -0700 Subject: [vtk-developers] open.cdash.org updated In-Reply-To: References: Message-ID: It looks like cdash is confused by certain hexadecimal numbers. For example, 312e67 is shown as 3.12e69 https://open.cdash.org/index.php?project=VTK&date=2017-03-03 - David On Tue, Feb 21, 2017 at 7:57 AM, Zack Galbreath wrote: > Hi folks, > > I just upgraded open.cdash.org. The most visible change you'll notice is > that the Update column now shows the commit that was built rather than the > number of files that changed. > > Going forward, I've set a reminder for myself to upgrade open.cdash.org > once a month around this time (the 21st). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.esneault at gmail.com Fri Mar 10 08:52:18 2017 From: simon.esneault at gmail.com (Simon ESNEAULT) Date: Fri, 10 Mar 2017 14:52:18 +0100 Subject: [vtk-developers] [vtkusers] VTK 7.1 error "Shader failed to compile" with GPU Volume rendering and clipping planes In-Reply-To: References: Message-ID: Hello, I've found the error, it is located in vtkVolumeShaderComposer.h, if someone use GPU volume rendering, cropping and clipping at the same time, the variable vec4 temp gets declared twice. Renaming 'temp' to 'temp_clip' fix the crash. HTH someone ;) Simon 2017-03-08 10:35 GMT+01:00 Simon ESNEAULT : > Hello, > > After the migration to VTK 7.1, we get a crash in the shader program (it > can't be build) when trying to use clipping planes on GPU volume rendering > mapper > > The error is : > Error: ERROR: In C:\Dev\ES-Externals\superbuild\VTK\src\Rendering\OpenGL2\vtkShaderProgram.cxx, > line 395 > vtkShaderProgram (000001FEBFB646D0): 0(474) : error C1038: declaration of > "temp" conflicts with previous declaration at 0(426) > > it appears the variable Vec4 temp is declared twice... > > Here is the full log > https://paste.ee/p/FsdWx > > On Windows 10, VTK is built in 64 bits with Visual Studio 2013 along with > Qt 5.3.2 and other libraries. > > Ring a bell to anyone ? > > Thanks > Simon > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Mar 10 13:37:09 2017 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Mar 2017 13:37:09 -0500 Subject: [vtk-developers] open.cdash.org updated In-Reply-To: References: Message-ID: On Thu, Mar 9, 2017 at 1:39 PM, David Gobbi wrote: > It looks like cdash is confused by certain hexadecimal numbers. For > example, 312e67 is shown as 3.12e69 > https://open.cdash.org/index.php?project=VTK&date=2017-03-03 > Thanks, this should be fixed now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zack.galbreath at kitware.com Fri Mar 10 13:40:16 2017 From: zack.galbreath at kitware.com (Zack Galbreath) Date: Fri, 10 Mar 2017 13:40:16 -0500 Subject: [vtk-developers] open.cdash.org updated In-Reply-To: <20170309182708.766732742@mail.rogue-research.com> References: <20170309182708.766732742@mail.rogue-research.com> Message-ID: On Thu, Mar 9, 2017 at 1:27 PM, Sean McBride wrote: > On Tue, 21 Feb 2017 09:57:31 -0500, Zack Galbreath said: > > >I just upgraded open.cdash.org. The most visible change you'll notice is > >that the Update column now shows the commit that was built rather than the > >number of files that changed. > > I notice it doesn't show this for my cppcheck VTK dashboards. Is that a > cdash bug, or something about the way I submit the results? Would be nice > to have it there... > You need to call ctest_update() to generate this info for CDash. If some other process is already responsible for doing the git pull, you can tell CTest to do a "version only" update like so: set(CTEST_UPDATE_VERSION_ONLY 1) ctest_update() -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Sat Mar 11 08:44:34 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 11 Mar 2017 14:44:34 +0100 Subject: [vtk-developers] Disable vtkNetCDF module without disabling StandAlone group? Message-ID: Hi all, I'm trying to disable building of the vtkNetCDF module without disabling the entire StandAlone group. Is it possible? It looks to me like it isn't, since vtkNetCDF is part of the StandAlone group. But if I do -DVTK_Group_StandAlone=OFF (which I'm not even sure is possible?), then I think I must individually enable all the modules of that group that I want, which leads to a lot (!) of cmake arguments :/ My goal is to compile VTK without linking to the HDF5 library. Thanks in advance, Elvis From elvis.stansvik at orexplore.com Sat Mar 11 08:58:26 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Sat, 11 Mar 2017 14:58:26 +0100 Subject: [vtk-developers] Disable vtkNetCDF module without disabling StandAlone group? In-Reply-To: References: Message-ID: 2017-03-11 14:44 GMT+01:00 Elvis Stansvik : > Hi all, > > I'm trying to disable building of the vtkNetCDF module without > disabling the entire StandAlone group. Is it possible? > > It looks to me like it isn't, since vtkNetCDF is part of the StandAlone group. > > But if I do -DVTK_Group_StandAlone=OFF (which I'm not even sure is > possible?), then I think I must individually enable all the modules of > that group that I want, which leads to a lot (!) of cmake arguments :/ > > My goal is to compile VTK without linking to the HDF5 library. Actually, looking at what gets enabled if I disable the StandAlone group and enable the Imaging, Views and Qt groups, it seems pretty spot on for what I want (and it disabled the vtkNetCDF module). So I'm happy now, provided that the compile goes through :) Elvis > > Thanks in advance, > Elvis From simon.esneault at gmail.com Mon Mar 13 10:01:28 2017 From: simon.esneault at gmail.com (Simon Esneault) Date: Mon, 13 Mar 2017 15:01:28 +0100 Subject: [vtk-developers] [vtkusers] VTK 7.1 error "Shader failed to compile" with GPU Volume rendering and clipping planes In-Reply-To: References: Message-ID: Hello, I created a merge request here https://gitlab.kitware.com/vtk/vtk/merge_requests/2583 Thanks, Simon 2017-03-10 14:52 GMT+01:00 Simon ESNEAULT : > Hello, > > I've found the error, it is located in vtkVolumeShaderComposer.h, if > someone use GPU volume rendering, cropping and clipping at the same time, > the variable vec4 temp gets declared twice. > Renaming 'temp' to 'temp_clip' fix the crash. > > HTH someone ;) > > Simon > > 2017-03-08 10:35 GMT+01:00 Simon ESNEAULT : > >> Hello, >> >> After the migration to VTK 7.1, we get a crash in the shader program (it >> can't be build) when trying to use clipping planes on GPU volume rendering >> mapper >> >> The error is : >> Error: ERROR: In C:\Dev\ES-Externals\superbuild >> \VTK\src\Rendering\OpenGL2\vtkShaderProgram.cxx, line 395 >> vtkShaderProgram (000001FEBFB646D0): 0(474) : error C1038: declaration of >> "temp" conflicts with previous declaration at 0(426) >> >> it appears the variable Vec4 temp is declared twice... >> >> Here is the full log >> https://paste.ee/p/FsdWx >> >> On Windows 10, VTK is built in 64 bits with Visual Studio 2013 along with >> Qt 5.3.2 and other libraries. >> >> Ring a bell to anyone ? >> >> Thanks >> Simon >> >> -- >> ------------------------------------------------------------------ >> Simon Esneault >> Rennes, France >> ------------------------------------------------------------------ >> > > > > -- > ------------------------------------------------------------------ > Simon Esneault > Rennes, France > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ Simon Esneault Rennes, France ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From afnanahmad at live.com Tue Mar 14 08:03:34 2017 From: afnanahmad at live.com (afnanahmad) Date: Tue, 14 Mar 2017 05:03:34 -0700 (MST) Subject: [vtk-developers] VTK 7.1 vtkPoints while rendering Message-ID: <1489493014165-5742466.post@n5.nabble.com> I'm reading a PointCloud data from LAS file using libLAS library into vtkPoints collection. I've verified the points in the collection to be correct, but when it is presented on the renderer, it is messing points on y axis. As you can see points cloud is missing point between the lines. I checked these points in a 3rd party viewer and its rendering fine there. -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-vtkPoints-while-rendering-tp5742466.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Mar 14 09:04:05 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 14 Mar 2017 09:04:05 -0400 Subject: [vtk-developers] VTK 7.1 vtkPoints while rendering In-Reply-To: <1489493014165-5742466.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> Message-ID: I'm guessing your cells are incorrect. You need to let us know what mapper you are using and assuming you are putting your vtkPoints into a vtkPolyData did you setup the cells correctly? On Tue, Mar 14, 2017 at 8:03 AM, afnanahmad wrote: > I'm reading a PointCloud data from LAS file using libLAS library into > vtkPoints collection. I've verified the points in the collection to be > correct, but when it is presented on the renderer, it is messing points on > y > axis. > > > > As you can see points cloud is missing point between the lines. I checked > these points in a 3rd party viewer and its rendering fine there. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/VTK-7-1-vtkPoints-while-rendering-tp5742466.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From afnanahmad at live.com Tue Mar 14 09:11:59 2017 From: afnanahmad at live.com (afnanahmad) Date: Tue, 14 Mar 2017 06:11:59 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1489493014165-5742466.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> Message-ID: <1489497119408-5742468.post@n5.nabble.com> Here is the code I'm using, not sure which step is wrong. vtkSmartPointer points = vtkSmartPointer::New(); vtkSmartPointer cell = vtkCellArray::New(); for (size_t i = 0; i < point_cloud->points.size(); i++) { double point[3] = { point_cloud->points[i].x, point_cloud->points[i].y, point_cloud->points[i].z }; vtkIdType id = points->InsertNextPoint(point); cell->InsertNextCell(1); cell->InsertCellPoint(id); } vtkSmartPointer polyData = vtkSmartPointer::New(); polyData->SetPoints(points); polyData->SetVerts(cell); vtkSmartPointer glyphFilter = vtkSmartPointer::New(); glyphFilter->SetInputData(polyData); glyphFilter->Update(); vtkSmartPointer mapper = vtkSmartPointer::New(); mapper->SetInputConnection(glyphFilter->GetOutputPort()); vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); for some of the files this code is working fine. -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742468.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Mar 14 09:22:27 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 14 Mar 2017 09:22:27 -0400 Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1489497119408-5742468.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> Message-ID: Looks fine to me except that you can yank the vertexglyph as it is not doing anything for you. The polydata can go directly into the mapper. Maybe your points have a really large values and you are running into floating point issues. Look at the bounds on your points. Could be something else but the basic code looks OK to me. On Tue, Mar 14, 2017 at 9:11 AM, afnanahmad wrote: > Here is the code I'm using, not sure which step is wrong. > > vtkSmartPointer points = vtkSmartPointer::New(); > vtkSmartPointer cell = vtkCellArray::New(); > > for (size_t i = 0; i < point_cloud->points.size(); i++) > { > > double point[3] = { point_cloud->points[i].x, > point_cloud->points[i].y, > point_cloud->points[i].z }; > > vtkIdType id = points->InsertNextPoint(point); > > cell->InsertNextCell(1); > cell->InsertCellPoint(id); > } > > vtkSmartPointer polyData = vtkSmartPointer:: > New(); > polyData->SetPoints(points); > polyData->SetVerts(cell); > > vtkSmartPointer glyphFilter = > vtkSmartPointer::New(); > glyphFilter->SetInputData(polyData); > glyphFilter->Update(); > > vtkSmartPointer mapper = > vtkSmartPointer::New(); > mapper->SetInputConnection(glyphFilter->GetOutputPort()); > > vtkSmartPointer actor = vtkSmartPointer::New(); > actor->SetMapper(mapper); > > > for some of the files this code is working fine. > > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742468.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From afnanahmad at live.com Tue Mar 14 09:26:49 2017 From: afnanahmad at live.com (afnanahmad) Date: Tue, 14 Mar 2017 06:26:49 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> Message-ID: <1489498009588-5742470.post@n5.nabble.com> This is the info for file I extracted from a tool. Can you please point out the issue here? -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742470.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Mar 14 09:39:11 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 14 Mar 2017 09:39:11 -0400 Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1489498009588-5742470.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> Message-ID: Yeh, it is a data issue, large values but small deltas. You need to center your data using a transform filter (or in your code when creating it). -------------- next part -------------- An HTML attachment was scrubbed... URL: From afnanahmad at live.com Tue Mar 14 13:27:40 2017 From: afnanahmad at live.com (afnanahmad) Date: Tue, 14 Mar 2017 10:27:40 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> Message-ID: <1489512460565-5742478.post@n5.nabble.com> the points are being added to *vtkPoints* collection as* double*. I think *double* should hold those points? -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742478.html Sent from the VTK - Dev mailing list archive at Nabble.com. From bill.lorensen at gmail.com Thu Mar 16 11:55:21 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 16 Mar 2017 11:55:21 -0400 Subject: [vtk-developers] NULL versus nullptr Message-ID: I just reviewed a gitlab MR. The developer replaced =0 with =NULL. Since we now require c++11, should we be using nullptr? Bill -- Unpaid intern in BillsBasement at noware dot com From marcus.hanwell at kitware.com Thu Mar 16 12:00:33 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 16 Mar 2017 12:00:33 -0400 Subject: [vtk-developers] NULL versus nullptr In-Reply-To: References: Message-ID: On Thu, Mar 16, 2017 at 11:55 AM, Bill Lorensen wrote: > I just reviewed a gitlab MR. The developer replaced =0 with =NULL. > Since we now require c++11, should we be using nullptr? > I think we should in new code, but there may be a little debate on this as I am not sure our coding standards have been updated to reflect this (along with what else we expect/allow from C++11). From bill.lorensen at gmail.com Thu Mar 16 12:01:49 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 16 Mar 2017 12:01:49 -0400 Subject: [vtk-developers] NULL versus nullptr In-Reply-To: References: Message-ID: That's what I thought. I will remind the MR author to use nullptr. On Thu, Mar 16, 2017 at 12:00 PM, Marcus D. Hanwell wrote: > On Thu, Mar 16, 2017 at 11:55 AM, Bill Lorensen wrote: >> I just reviewed a gitlab MR. The developer replaced =0 with =NULL. >> Since we now require c++11, should we be using nullptr? >> > I think we should in new code, but there may be a little debate on > this as I am not sure our coding standards have been updated to > reflect this (along with what else we expect/allow from C++11). -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Thu Mar 16 12:11:33 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 16 Mar 2017 12:11:33 -0400 Subject: [vtk-developers] NULL versus nullptr In-Reply-To: References: Message-ID: <20170316161133.GA12706@megas.kitware.com> On Thu, Mar 16, 2017 at 11:55:21 -0400, Bill Lorensen wrote: > I just reviewed a gitlab MR. The developer replaced =0 with =NULL. > Since we now require c++11, should we be using nullptr? For new code, I'd say so. At some point, we might want to use this: http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html --Ben From andrew.amaclean at gmail.com Thu Mar 16 17:00:25 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 17 Mar 2017 08:00:25 +1100 Subject: [vtk-developers] NULL versus nullptr Message-ID: Hi Bill My inclination would be to use nullptr. It is fully supported by all the compilers we are now using. It has also been around for a long while as seen in this extract from: http://stackoverflow.com/questions/1282295/what-exactly-is-nullptr >From *nullptr: A Type-safe and Clear-Cut Null Pointer* : The new C++09 nullptr keyword designates an rvalue constant that serves as a universal null pointer literal, replacing the buggy and weakly-typed literal 0 and the infamous NULL macro. nullptr thus puts an end to more than 30 years of embarrassment, ambiguity, and bugs. The following sections present the nullptr facility and show how it can remedy the ailments of NULL and 0. ---------- Forwarded message ---------- > From: Bill Lorensen > To: VTK Developers > Cc: > Bcc: > Date: Thu, 16 Mar 2017 11:55:21 -0400 > Subject: [vtk-developers] NULL versus nullptr > I just reviewed a gitlab MR. The developer replaced =0 with =NULL. > Since we now require c++11, should we be using nullptr? > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Mar 16 18:24:47 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 17 Mar 2017 09:24:47 +1100 Subject: [vtk-developers] Building using Qt 5.8 and VS2017. Message-ID: At present the builds will fail. I have posted a report on the Qt forum: https://forum.qt.io/topic/77260/errors-when-building-cmake-and-vtk In the interim here is a temporary fix: The problem relates to the Qt macro: **Q_DECL_CONSTEXPR** If it is commented out in lines 593 to 714 of *qalgorithms.h* then the builds work for CMake and VTK and any other Qt build using VS2017. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Mar 17 09:36:07 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 17 Mar 2017 09:36:07 -0400 Subject: [vtk-developers] NULL versus nullptr In-Reply-To: References: Message-ID: Marcus is correct in that we have not updated our coding standards to account for C++11 I am going to make it my priority to establish an initial document on expect/allow from C++11. On Thu, Mar 16, 2017 at 12:00 PM, Marcus D. Hanwell wrote: > On Thu, Mar 16, 2017 at 11:55 AM, Bill Lorensen wrote: >> I just reviewed a gitlab MR. The developer replaced =0 with =NULL. >> Since we now require c++11, should we be using nullptr? >> > I think we should in new code, but there may be a little debate on > this as I am not sure our coding standards have been updated to > reflect this (along with what else we expect/allow from C++11). > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From dave.demarle at kitware.com Fri Mar 17 16:21:57 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 17 Mar 2017 16:21:57 -0400 Subject: [vtk-developers] next vtk hackathon - 4/19? Message-ID: Hey Devs, It's about time for the next VTK hackathon. How does April 19'th sound to you? I propose "examples" as the focus this time around. I for one would like to move the in source examples out to the wiki examples project, add more dashboard testers for the wiki examples, and shore them up with demonstrations of more of what VTK can do. cheers, David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Mar 17 16:30:13 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 17 Mar 2017 16:30:13 -0400 Subject: [vtk-developers] next vtk hackathon - 4/19? In-Reply-To: References: Message-ID: That date is great for me! On Mar 17, 2017 4:22 PM, "David E DeMarle" wrote: > Hey Devs, > > It's about time for the next VTK hackathon. How does April 19'th sound to > you? > > I propose "examples" as the focus this time around. I for one would like > to move the in source examples out to the wiki examples project, add more > dashboard testers for the wiki examples, and shore them up with > demonstrations of more of what VTK can do. > > cheers, > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Fri Mar 17 22:34:39 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Fri, 17 Mar 2017 22:34:39 -0400 Subject: [vtk-developers] next vtk hackathon - 4/19? In-Reply-To: References: Message-ID: +1 On Fri, Mar 17, 2017 at 4:21 PM, David E DeMarle wrote: > Hey Devs, > > It's about time for the next VTK hackathon. How does April 19'th sound to > you? > > I propose "examples" as the focus this time around. I for one would like to > move the in source examples out to the wiki examples project, add more > dashboard testers for the wiki examples, and shore them up with > demonstrations of more of what VTK can do. > > cheers, > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. From afnanahmad at live.com Sat Mar 18 19:20:44 2017 From: afnanahmad at live.com (afnanahmad) Date: Sat, 18 Mar 2017 16:20:44 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1489512460565-5742478.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> <1489512460565-5742478.post@n5.nabble.com> Message-ID: <1489879244494-5742514.post@n5.nabble.com> I was wondering if there is a way I can set the vtkPolyDataMappe's Precision to double? -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742514.html Sent from the VTK - Dev mailing list archive at Nabble.com. From afnanahmad at live.com Sat Mar 18 19:52:34 2017 From: afnanahmad at live.com (afnanahmad) Date: Sat, 18 Mar 2017 16:52:34 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> Message-ID: <1489881154413-5742515.post@n5.nabble.com> I've scaled my point cloud using the transform filter but output still remains the same, I just have 10 points in my Point Cloud and renderer window flickers while interacting it with mouse. Before applying transform filter /xMin = 289814.15 xMax = 289818.5 yMin = 4320978.61 yMax = 4320980.59 zMin = 170.58 zMax = 170.76/ After applying transform filter Scale(0.01, 0.01, 0.01) /xMin = 2898.1415 xMax = 2898.185 yMin = 43209.786100000005 yMax = 43209.8059 zMin = 1.7058000000000002 zMax = 1.7076/ I've also attached one of the file here for which I'm having issue while rendering the Point Cloud. points.xyz -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742515.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Sat Mar 18 20:55:29 2017 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 18 Mar 2017 20:55:29 -0400 Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1489881154413-5742515.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> <1489881154413-5742515.post@n5.nabble.com> Message-ID: The issue is the translation. Not the scale. Find the center of your data and translate by negative that amount. Give that a shot Sent from my iPhone > On Mar 18, 2017, at 7:52 PM, afnanahmad wrote: > > I've scaled my point cloud using the transform filter but output still > remains the same, I just have 10 points in my Point Cloud and renderer > window flickers while interacting it with mouse. > > Before applying transform filter > /xMin = 289814.15 > xMax = 289818.5 > > yMin = 4320978.61 > yMax = 4320980.59 > > zMin = 170.58 > zMax = 170.76/ > > After applying transform filter Scale(0.01, 0.01, 0.01) > /xMin = 2898.1415 > xMax = 2898.185 > > yMin = 43209.786100000005 > yMax = 43209.8059 > > zMin = 1.7058000000000002 > zMax = 1.7076/ > > I've also attached one of the file here for which I'm having issue while > rendering the Point Cloud. > points.xyz > > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742515.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From afnanahmad at live.com Mon Mar 20 10:29:38 2017 From: afnanahmad at live.com (afnanahmad) Date: Mon, 20 Mar 2017 07:29:38 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> <1489881154413-5742515.post@n5.nabble.com> Message-ID: <1490020178823-5742523.post@n5.nabble.com> I tried finding the center using Center Of Mass Filter, and translated as you mentioned. Doing that renderer did stop flickering on mouse events but the out is still the same. -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742523.html Sent from the VTK - Dev mailing list archive at Nabble.com. From afnanahmad at live.com Mon Mar 20 10:46:54 2017 From: afnanahmad at live.com (afnanahmad) Date: Mon, 20 Mar 2017 07:46:54 -0700 (MST) Subject: [vtk-developers] VTK 7.1 issue with vtkPoints while rendering In-Reply-To: <1490020178823-5742523.post@n5.nabble.com> References: <1489493014165-5742466.post@n5.nabble.com> <1489497119408-5742468.post@n5.nabble.com> <1489498009588-5742470.post@n5.nabble.com> <1489881154413-5742515.post@n5.nabble.com> <1490020178823-5742523.post@n5.nabble.com> Message-ID: <1490021214336-5742524.post@n5.nabble.com> This issue is fixed now. Sorry I forgot the set the data type of vtkPoints to Double. Thank you for your support! :) -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-7-1-issue-with-vtkPoints-while-rendering-tp5742466p5742524.html Sent from the VTK - Dev mailing list archive at Nabble.com. From elvis.stansvik at orexplore.com Mon Mar 20 16:55:34 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 20 Mar 2017 21:55:34 +0100 Subject: [vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5 Message-ID: > On Mon, Jul 13, 2015 at 16:51:34 -0400, Ben Boeckel wrote: >> On Mon, Jul 13, 2015 at 15:00:56 -0400, Ben Boeckel wrote: >>> https://codereview.qt-project.org/#/c/115531/ >> >> Applying this patch (with one conflicting hunk) to 5.5.0 fixes the >> problem for me. I'll poke the review to see if some movement can't be >> made. > > It looks like the patch has been merged for 5.6.0 (due at the end of > October). Just in case anyone is in the same boat like me, hitting this bug on Ubuntu 16.04 LTS (which has Qt 5.5.1), just FYI I'm trying to get an SRU (Stable Release Update) going with this fix: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173 Elvis From dave.demarle at kitware.com Mon Mar 20 17:14:06 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 20 Mar 2017 17:14:06 -0400 Subject: [vtk-developers] next vtk hackathon - 4/19? In-Reply-To: References: Message-ID: Well this is awkward. Turns out my proposed date isn't good on my own calendar. Here is a doodle poll to vote in. http://doodle.com/poll/w49hsaf42qcx9rev David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Mar 17, 2017 at 10:34 PM, Cory Quammen wrote: > +1 > > On Fri, Mar 17, 2017 at 4:21 PM, David E DeMarle > wrote: > > Hey Devs, > > > > It's about time for the next VTK hackathon. How does April 19'th sound to > > you? > > > > I propose "examples" as the focus this time around. I for one would like > to > > move the in source examples out to the wiki examples project, add more > > dashboard testers for the wiki examples, and shore them up with > > demonstrations of more of what VTK can do. > > > > cheers, > > > > David E DeMarle > > Kitware, Inc. > > R&D Engineer > > 21 Corporate Drive > > Clifton Park, NY 12065-8662 > > Phone: 518-881-4909 > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Cory Quammen > Staff R&D Engineer > Kitware, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Mar 20 17:39:45 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 20 Mar 2017 17:39:45 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? Message-ID: Hi, Does anyone have work in progress that should delay the branch point for 8.0.0? If so, please add the 8.0.0 milestone on any relevant merge requests and @mention ben.beockel, demarle, and chuck.atkins so they can be more easily tracked. We are hoping to get 8.0.0 started by April 3, 2017. Thanks, The VTK Maintenance Team David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prakeshofficial at gmail.com Mon Mar 20 23:07:56 2017 From: prakeshofficial at gmail.com (rakesh patil) Date: Tue, 21 Mar 2017 08:37:56 +0530 Subject: [vtk-developers] vtkBooleanOperationPolyDataFilter updates Message-ID: Hi, >From the users mailing list I am able to understand that there is a problem with the vtkBooleanOperationPolyDataFilter that creates holes. But the link dates back to 2012. I suppose there will be more development happening in this domain. So I am very eager to know and understand, whether in this current version, is it fixed? This filter does not produces holes anymore? Thanks in advance. Regards Rakesh Patil -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Mar 21 09:24:22 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 21 Mar 2017 09:24:22 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: Dave, VTK 8.0.0 seems like a good target for some of the bigger API change merge requests that have been put off for a while Examples include: https://gitlab.kitware.com/vtk/vtk/merge_requests/1455 https://gitlab.kitware.com/vtk/vtk/merge_requests/917 If we are aspiring toward using semantic versioning [1], now would be the time to make such API changes. And document them nicely as well, of course. Thanks, Cory [1] http://semver.org/ On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > 8.0.0? > > If so, please add the 8.0.0 milestone on any relevant merge requests > and @mention ben.beockel, demarle, and chuck.atkins so they can be more > easily tracked. > > We are hoping to get 8.0.0 started by April 3, 2017. > > Thanks, > > The VTK Maintenance Team > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. From ben.boeckel at kitware.com Tue Mar 21 10:10:47 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 21 Mar 2017 10:10:47 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: <20170321141047.GB18336@megas.kitware.com> On Tue, Mar 21, 2017 at 09:24:22 -0400, Cory Quammen wrote: > If we are aspiring toward using semantic versioning [1], now would be > the time to make such API changes. And document them nicely as well, > of course. If we really want to go with semver, it might be good to get ABI checkers to check MRs: https://lvc.github.io/abi-compliance-checker/ I suspect we'll be bumping major versions every release though unless we're really diligent about it. Though the ABI is also affected by all the flags you can set in VTK's build, so there are other issues since we can't just rely on "it looks OK", but "it looks OK under configuration X". --Ben From s-pfeifer at gmx.net Tue Mar 21 10:34:39 2017 From: s-pfeifer at gmx.net (Stefan Pfeifer) Date: Tue, 21 Mar 2017 15:34:39 +0100 Subject: [vtk-developers] vtkCamera: add an equivalent to UseHorizontalViewAngle for parallel projection? Message-ID: Hi everyone, So the vtkCamera interprets the view angle as vertical by default. This can be changed via camera->SetUseHorizontalViewAngle(true); One of the effects is that the resizing behaviour of the windows changes: The view now gets adjusted when the window's width changes, not the height as before. At least that's my use case. My problem is that this doesn't work with the parallel projection, as there is no equivalent method to change the direction of the ParallelScale. It's always vertical. So my suggestion would be to add exactly that. Maybe call it SetUseHorizontalParallelScale so it would be consistent with the Get/Set methods: Perspective: Get/SetViewAngle <-> Get/SetUseHorizontalViewAngle Parallel: Get/SetParallelScale <-> Get/SetUseHorizontalParallelScale I haven't contributed before so I wanted to get some feedback on this first. It doesn't seem very difficult to implement, so if you guys think it makes sense I could give it a try. Best regards Stefan From hahnse at ornl.gov Tue Mar 21 10:31:51 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Tue, 21 Mar 2017 14:31:51 +0000 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double? Steven min, max https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58 isinf https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98 isnan https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56 On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" wrote: Dave, VTK 8.0.0 seems like a good target for some of the bigger API change merge requests that have been put off for a while Examples include: https://gitlab.kitware.com/vtk/vtk/merge_requests/1455 https://gitlab.kitware.com/vtk/vtk/merge_requests/917 If we are aspiring toward using semantic versioning [1], now would be the time to make such API changes. And document them nicely as well, of course. Thanks, Cory [1] http://semver.org/ On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > 8.0.0? > > If so, please add the 8.0.0 milestone on any relevant merge requests > and @mention ben.beockel, demarle, and chuck.atkins so they can be more > easily tracked. > > We are hoping to get 8.0.0 started by April 3, 2017. > > Thanks, > > The VTK Maintenance Team > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From david.gobbi at gmail.com Tue Mar 21 11:03:43 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Mar 2017 09:03:43 -0600 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: Not clear what you mean here. Do you want to template the IsInf, IsNan, and IsFinite methods in vtkMath, or do you want to VTK codebase to stop using them? On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. wrote: > There are templated min, max, isinf, and isnan functions scattered around > the VTK codebase. Is this a good time to replace the (slower?) functions in > vtkMath.h that require a conversion to double? > > Steven > > min, max > https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65 > ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58 > > isinf > https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65 > ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98 > > isnan > https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65 > ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56 > > > On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" < > vtk-developers-bounces at vtk.org on behalf of cory.quammen at kitware.com> > wrote: > > Dave, > > VTK 8.0.0 seems like a good target for some of the bigger API change > merge requests that have been put off for a while Examples include: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/1455 > https://gitlab.kitware.com/vtk/vtk/merge_requests/917 > > If we are aspiring toward using semantic versioning [1], now would be > the time to make such API changes. And document them nicely as well, > of course. > > Thanks, > Cory > > [1] http://semver.org/ > > On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle > wrote: > > Hi, > > > > Does anyone have work in progress that should delay the branch point > for > > 8.0.0? > > > > If so, please add the 8.0.0 milestone on any relevant merge requests > > and @mention ben.beockel, demarle, and chuck.atkins so they can be > more > > easily tracked. > > > > We are hoping to get 8.0.0 started by April 3, 2017. > > > > Thanks, > > > > The VTK Maintenance Team > > > > David E DeMarle > > Kitware, Inc. > > R&D Engineer > > 21 Corporate Drive > > Clifton Park, NY 12065-8662 > > Phone: 518-881-4909 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Mar 21 11:04:39 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 21 Mar 2017 09:04:39 -0600 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: Typo: I meant to write "want the VTK codebase to stop using them". On Tue, Mar 21, 2017 at 9:03 AM, David Gobbi wrote: > Not clear what you mean here. Do you want to template the IsInf, IsNan, > and IsFinite methods in vtkMath, or do you want to VTK codebase to stop > using them? > > > On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. wrote: > >> There are templated min, max, isinf, and isnan functions scattered around >> the VTK codebase. Is this a good time to replace the (slower?) functions in >> vtkMath.h that require a conversion to double? >> >> Steven >> >> min, max >> https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642 >> ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58 >> >> isinf >> https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642 >> ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98 >> >> isnan >> https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642 >> ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56 >> >> >> On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" < >> vtk-developers-bounces at vtk.org on behalf of cory.quammen at kitware.com> >> wrote: >> >> Dave, >> >> VTK 8.0.0 seems like a good target for some of the bigger API change >> merge requests that have been put off for a while Examples include: >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1455 >> https://gitlab.kitware.com/vtk/vtk/merge_requests/917 >> >> If we are aspiring toward using semantic versioning [1], now would be >> the time to make such API changes. And document them nicely as well, >> of course. >> >> Thanks, >> Cory >> >> [1] http://semver.org/ >> >> On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle >> wrote: >> > Hi, >> > >> > Does anyone have work in progress that should delay the branch >> point for >> > 8.0.0? >> > >> > If so, please add the 8.0.0 milestone on any relevant merge requests >> > and @mention ben.beockel, demarle, and chuck.atkins so they can be >> more >> > easily tracked. >> > >> > We are hoping to get 8.0.0 started by April 3, 2017. >> > >> > Thanks, >> > >> > The VTK Maintenance Team >> > >> > David E DeMarle >> > Kitware, Inc. >> > R&D Engineer >> > 21 Corporate Drive >> > Clifton Park, NY 12065-8662 >> > Phone: 518-881-4909 <(518)%20881-4909> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hahnse at ornl.gov Tue Mar 21 11:41:00 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Tue, 21 Mar 2017 15:41:00 +0000 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: The former. I?d like to move these functions (and workarounds for certain data types and compilers) into a header where they can be reused. Would it make sense to either template the existing function in vtkMath or put the templated functions in a different header file? From: David Gobbi Date: Tuesday, March 21, 2017 at 11:04 AM To: "Hahn, Steven E." Cc: vtkdev Subject: Re: [vtk-developers] ready to branch for 8.0.0? Typo: I meant to write "want the VTK codebase to stop using them". On Tue, Mar 21, 2017 at 9:03 AM, David Gobbi > wrote: Not clear what you mean here. Do you want to template the IsInf, IsNan, and IsFinite methods in vtkMath, or do you want to VTK codebase to stop using them? On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. > wrote: There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double? Steven min, max https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58 isinf https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98 isnan https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56 On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" on behalf of cory.quammen at kitware.com> wrote: Dave, VTK 8.0.0 seems like a good target for some of the bigger API change merge requests that have been put off for a while Examples include: https://gitlab.kitware.com/vtk/vtk/merge_requests/1455 https://gitlab.kitware.com/vtk/vtk/merge_requests/917 If we are aspiring toward using semantic versioning [1], now would be the time to make such API changes. And document them nicely as well, of course. Thanks, Cory [1] http://semver.org/ On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle > wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > 8.0.0? > > If so, please add the 8.0.0 milestone on any relevant merge requests > and @mention ben.beockel, demarle, and chuck.atkins so they can be more > easily tracked. > > We are hoping to get 8.0.0 started by April 3, 2017. > > Thanks, > > The VTK Maintenance Team > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Mar 21 12:59:51 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 21 Mar 2017 17:59:51 +0100 Subject: [vtk-developers] vtkCamera: add an equivalent to UseHorizontalViewAngle for parallel projection? In-Reply-To: References: Message-ID: Den 21 mars 2017 3:39 em skrev "Stefan Pfeifer" : > > Hi everyone, > > So the vtkCamera interprets the view angle as vertical by default. This can be changed via > > camera->SetUseHorizontalViewAngle(true); > > One of the effects is that the resizing behaviour of the windows changes: The view now gets adjusted when the window's width changes, not the height as before. At least that's my use case. > > My problem is that this doesn't work with the parallel projection, as there is no equivalent method to change the direction of the ParallelScale. It's always vertical. So my suggestion would be to add exactly that. Maybe call it SetUseHorizontalParallelScale so it would be consistent with the Get/Set methods: > > Perspective: Get/SetViewAngle <-> Get/SetUseHorizontalViewAngle > Parallel: Get/SetParallelScale <-> Get/SetUseHorizontalParallelScale > > I haven't contributed before so I wanted to get some feedback on this first. It doesn't seem very difficult to implement, so if you guys think it makes sense I could give it a try. Just a +1 from me as a user. I have a use for such an API right now. Elvis > > Best regards > Stefan > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Mar 22 00:37:40 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 22 Mar 2017 00:37:40 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: On Tue, Mar 21, 2017 at 11:41 AM, Hahn, Steven E. wrote: > The former. I?d like to move these functions (and workarounds for certain > data types and compilers) into a header where they can be reused. Would it > make sense to either template the existing function in vtkMath or put the > templated functions in a different header file? > vtkMathUtilities.h in Common/Core would be a good place, I started it to put more modern, inline and/or templated functions in. From elvis.stansvik at orexplore.com Wed Mar 22 02:53:22 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 22 Mar 2017 07:53:22 +0100 Subject: [vtk-developers] AddObserver taking C++11 lambda? Message-ID: Hi all, With C++11 now required, would there be interest in an AddObserver version that takes a C++11 lambda? I've found myself wishing there was one a couple of times. Anyone know off the top of their head how easy/hard that would be to add? Cheers, Elvis From andrii at ebi.ac.uk Wed Mar 22 10:24:35 2017 From: andrii at ebi.ac.uk (Andrii Iudin) Date: Wed, 22 Mar 2017 14:24:35 +0000 Subject: [vtk-developers] Unpacking VTP In-Reply-To: <93919806-883d-e8bc-3111-1cc832d1b6b7@ebi.ac.uk> References: <93919806-883d-e8bc-3111-1cc832d1b6b7@ebi.ac.uk> Message-ID: <954b068d-bb87-7d82-c8b0-2ae884798293@ebi.ac.uk> Dear VTK Developers, Apologies for the obvious question, of course the data is in blocks as stated here: http://www.vtk.org/Wiki/VTK_XML_Formats#Compressed_Data To avoid any future confusion, it might be worth underlying on this page that each block is compressed separately and to get the whole data back it is necessary to parse the VTK header and use its contents to extract and combine the data from the blocks. Best regards, Andrii On 14/03/2017 13:27, Andrii Iudin wrote: > Dear VTK Developers, > > Apologies for sending this question, if this is a wrong mailing list, > but there has been no reply from the users list and the issue seems to > be more to do with the specifics of the format, rather than something > a general user is expected to know. > > We are working on a loader of VTP files into three.js to display these > files on-line. The VTP files are saved as binary and compressed with > Zlib. However, when decoding the contents of these files from base64 > and then decompressing, the result is truncated. Only 32768 bytes are > obtained. This happens in the Javascript implementations of Zlib (both > pako and zlib.js) and also when decompressing in Python. Please see > the example files attached. > > emd_2557.vtp contains the binary compressed data > emd_2557_ascii.vtp contains the ASCII data without compression > > Both files are perfectly viewable in Paraview, so the data has to be > there. > > > For example, the procedure in Python is the following: > import base64 > import zlib > > s = "eJyFnXm4V1Pbx8/eKQ1UpnN+DVSKksxJoYkSIhpUFE0nGtC..." # The whole > string of the first of the Polys except the VTK header > a = bytearray( base64.b64decode( s ) ) > d = zlib.decompress( bytes( a ) ) > d[-8:-1] > '\x83\x18\x00\x00\x00\x00\x00' > > which is 131 + 256 * 24 = 6275. That is, only first 4096 numbers from > the first of the Polys are being obtained (as can be seen from the > ASCII file). Is there a way, maybe a parameter that can be set in Zlib > to allow obtaining the rest? > > Many thanks and best regards, > Andrii From sankhesh.jhaveri at kitware.com Wed Mar 22 11:45:33 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 22 Mar 2017 15:45:33 +0000 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: +1 to using lambda functions for AddObserver. ? On Tue, Mar 21, 2017 at 11:53 PM Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > Hi all, > > With C++11 now required, would there be interest in an AddObserver > version that takes a C++11 lambda? I've found myself wishing there was > one a couple of times. > > Anyone know off the top of their head how easy/hard that would be to add? > > Cheers, > Elvis > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Mar 22 13:47:48 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 22 Mar 2017 11:47:48 -0600 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: It doesn't look hard. New AddObserver methods would be needed that take std::function<> as a parameter, and they'd have to store the "function" object and call it. Overall, it would probably be simpler than the code that currently exists in vtkObject.h for adding observers. On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > Hi all, > > With C++11 now required, would there be interest in an AddObserver > version that takes a C++11 lambda? I've found myself wishing there was > one a couple of times. > > Anyone know off the top of their head how easy/hard that would be to add? > > Cheers, > Elvis > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed Mar 22 14:00:45 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 22 Mar 2017 19:00:45 +0100 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: Den 22 mars 2017 6:48 em skrev "David Gobbi" : > > It doesn't look hard. New AddObserver methods would be needed that take std::function<> as a parameter, and they'd have to store the "function" object and call it. Overall, it would probably be simpler than the code that currently exists in vtkObject.h for adding observers. Good to hear, I might have a go at it then. Elvis > > On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: >> >> Hi all, >> >> With C++11 now required, would there be interest in an AddObserver >> version that takes a C++11 lambda? I've found myself wishing there was >> one a couple of times. >> >> Anyone know off the top of their head how easy/hard that would be to add? >> >> Cheers, >> Elvis >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milefn at rpi.edu Wed Mar 22 13:55:27 2017 From: milefn at rpi.edu (Milef, Nicholas Boris) Date: Wed, 22 Mar 2017 17:55:27 +0000 Subject: [vtk-developers] Tangents for rendering with normal maps Message-ID: Hi, I've trying to add normal mapping to an application (iMSTK). In order to get this to work, we would need tangent vertex attributes. Is this something that could be of interest in VTK? More generally, it might be useful to allow additional arbitrary vertex attributes in the future for things like GPU skinning, but I'm not sure how well that would work. Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Mar 22 17:01:45 2017 From: sean at rogue-research.com (Sean McBride) Date: Wed, 22 Mar 2017 17:01:45 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: <20170322210145.978133664@mail.rogue-research.com> On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said: >The former. I?d like to move these functions (and workarounds for >certain data types and compilers) into a header where they can be >reused. Would it make sense to either template the existing function in >vtkMath or put the templated functions in a different header file? Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf. Cheers, Sean From cory.quammen at kitware.com Wed Mar 22 21:09:45 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 22 Mar 2017 21:09:45 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: <20170321141047.GB18336@megas.kitware.com> References: <20170321141047.GB18336@megas.kitware.com> Message-ID: On Tue, Mar 21, 2017 at 10:10 AM, Ben Boeckel wrote: > On Tue, Mar 21, 2017 at 09:24:22 -0400, Cory Quammen wrote: >> If we are aspiring toward using semantic versioning [1], now would be >> the time to make such API changes. And document them nicely as well, >> of course. > > If we really want to go with semver, it might be good to get ABI > checkers to check MRs: > > https://lvc.github.io/abi-compliance-checker/ > > I suspect we'll be bumping major versions every release though unless > we're really diligent about it. > > Though the ABI is also affected by all the flags you can set in VTK's > build, so there are other issues since we can't just rely on "it looks > OK", but "it looks OK under configuration X". I think ABI-backwards compatibility is probably a little pie in the sky for VTK. An API compatibility checker for MRs would be great. Let the buildbot be the curmudgeon, I say. Cory -- Cory Quammen Staff R&D Engineer Kitware, Inc. From hahnse at ornl.gov Thu Mar 23 10:07:03 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Thu, 23 Mar 2017 14:07:03 +0000 Subject: [vtk-developers] ready to branch for 8.0.0? References: , <20170322210145.978133664@mail.rogue-research.com> Message-ID: <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> I've encountered a few complications with recent versions of MSVC and clang with integral value types. With std::isnan and std::isinf Visual Studio 2017 generates an error message. With std::isinf clang generates code that is 3-4 times slower than one would naively expect for a type that doesn?t contain infinity. I worked around both issues with tag dispatch, but don?t think we want that code copied and pasted throughout the VTK codebase. Steven ________________________________________ From: Sean McBride Sent: Wednesday, March 22, 2017 5:01 PM To: Hahn, Steven E.; David Gobbi Cc: vtkdev Subject: Re: [vtk-developers] ready to branch for 8.0.0? On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said: >The former. I?d like to move these functions (and workarounds for >certain data types and compilers) into a header where they can be >reused. Would it make sense to either template the existing function in >vtkMath or put the templated functions in a different header file? Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf. Cheers, Sean From robert.maynard at kitware.com Thu Mar 23 10:21:21 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Mar 2017 10:21:21 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> References: <20170322210145.978133664@mail.rogue-research.com> <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> Message-ID: Given these issues, and known performance problems with std::min/std::max I think it would be valuable to provide a single header that wraps all these functions and provides fast versions where needed. Personally I see no reason to not place these into a vtk namespace. On Thu, Mar 23, 2017 at 10:07 AM, Hahn, Steven E. wrote: > I've encountered a few complications with recent versions of MSVC and clang with integral value types. With std::isnan and std::isinf Visual Studio 2017 generates an error message. With std::isinf clang generates code that is 3-4 times slower than one would naively expect for a type that doesn?t contain infinity. I worked around both issues with tag dispatch, but don?t think we want that code copied and pasted throughout the VTK codebase. > > Steven > ________________________________________ > From: Sean McBride > Sent: Wednesday, March 22, 2017 5:01 PM > To: Hahn, Steven E.; David Gobbi > Cc: vtkdev > Subject: Re: [vtk-developers] ready to branch for 8.0.0? > > On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said: > >>The former. I?d like to move these functions (and workarounds for >>certain data types and compilers) into a header where they can be >>reused. Would it make sense to either template the existing function in >>vtkMath or put the templated functions in a different header file? > > Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf. > > Cheers, > > Sean > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From aashish.chaudhary at kitware.com Thu Mar 23 10:23:42 2017 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Thu, 23 Mar 2017 14:23:42 +0000 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: References: Message-ID: We have one or two volume branches which we are hoping to get merged this week is desired for 8.0. I will tag them today. Thanks, On Mon, Mar 20, 2017 at 5:40 PM David E DeMarle wrote: > Hi, > > Does anyone have work in progress that should delay the branch point for > 8.0.0? > > If so, please add the 8.0.0 milestone on any relevant merge requests > and @mention ben.beockel, demarle, and chuck.atkins so they can be more > easily tracked. > > We are hoping to get 8.0.0 started by April 3, 2017. > > Thanks, > > The VTK Maintenance Team > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Mar 23 10:31:48 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Mar 2017 10:31:48 -0400 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: While allowing lambda's to be held by std::function is really nice, it becomes very easy to mistakenly captures items whose lifetime is shorter than the Observer you are binding too. I am currently writing up the first draft of c++11 guidelines for VTK and for lambda functions and these are the guidelines I currently have: Usage of lambda expressions are allowed with the following guidelines. - Use default capture by value ([=]) only as a means of binding a few variables for a short lambda, where the set of captured variables is obvious at a glance. Prefer not to write long or complex lambdas with default capture by value. - Except for the above, all capture arguments must be explicitly captured. Using the default capture by reference ([&]) is not allowed. This is to done so that it is easier to evaluate lifespan and reference ownership. - Keep unnamed lambdas short. If a lambda body is more than maybe five lines long, prefer using a named function instead of a lambda. - Specify the return type of the lambda explicitly if that will make it more obvious to readers. On-top of these guidelines I have also stated that lambda functions should be kept to implementation files in VTK, which is fine as we go with an approach like David proposed. On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik wrote: > Den 22 mars 2017 6:48 em skrev "David Gobbi" : >> >> It doesn't look hard. New AddObserver methods would be needed that take >> std::function<> as a parameter, and they'd have to store the "function" >> object and call it. Overall, it would probably be simpler than the code >> that currently exists in vtkObject.h for adding observers. > > Good to hear, I might have a go at it then. > > Elvis > >> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik >> wrote: >>> >>> Hi all, >>> >>> With C++11 now required, would there be interest in an AddObserver >>> version that takes a C++11 lambda? I've found myself wishing there was >>> one a couple of times. >>> >>> Anyone know off the top of their head how easy/hard that would be to add? >>> >>> Cheers, >>> Elvis >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Thu Mar 23 10:55:46 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Mar 2017 08:55:46 -0600 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: Hi Robert, Our AddObserver() methods only use weak pointers when the observer is derived from vtkObjectBase, which means that currently if the observer is not a VTK object, then we have a situation where we might call a dangling pointer. I'm not aware of any uniform way around get around this issue except for using std::weak_ptr, which in turn demands that any non-vtk observer objects are wrapped with a std::shared_ptr. When people start using lambdas with AddObserver, about the only thing we can do for safety is provide rules such as the ones that you describe to ensure that the lambda doesn't capture pointers that can be left dangling. Thanks, by the way, for working on the c++11 guidelines. - David On Thu, Mar 23, 2017 at 8:31 AM, Robert Maynard wrote: > While allowing lambda's to be held by std::function is really nice, it > becomes very easy to mistakenly captures items whose lifetime is > shorter than the Observer you are binding too. > > I am currently writing up the first draft of c++11 guidelines for VTK > and for lambda functions and these are the guidelines I currently > have: > > Usage of lambda expressions are allowed with the following guidelines. > > - Use default capture by value ([=]) only as a means of binding a few > variables for a short lambda, where the set of captured variables is > obvious at a glance. Prefer not to write long or complex lambdas with > default capture by value. > - Except for the above, all capture arguments must be explicitly > captured. Using the default capture by reference ([&]) is not allowed. > This is to done so that it is easier to evaluate lifespan and > reference ownership. > - Keep unnamed lambdas short. If a lambda body is more than maybe five > lines long, prefer using a named function instead of a lambda. > - Specify the return type of the lambda explicitly if that will make > it more obvious to readers. > > On-top of these guidelines I have also stated that lambda functions > should be kept to implementation files in VTK, which is fine as we go > with an approach like David proposed. > > On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik > wrote: > > Den 22 mars 2017 6:48 em skrev "David Gobbi" : > >> > >> It doesn't look hard. New AddObserver methods would be needed that take > >> std::function<> as a parameter, and they'd have to store the "function" > >> object and call it. Overall, it would probably be simpler than the code > >> that currently exists in vtkObject.h for adding observers. > > > > Good to hear, I might have a go at it then. > > > > Elvis > > > >> > >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik > >> wrote: > >>> > >>> Hi all, > >>> > >>> With C++11 now required, would there be interest in an AddObserver > >>> version that takes a C++11 lambda? I've found myself wishing there was > >>> one a couple of times. > >>> > >>> Anyone know off the top of their head how easy/hard that would be to > add? > >>> > >>> Cheers, > >>> Elvis > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Search the list archives at: http://markmail.org/search/?q= > vtk-developers > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.harris at kitware.com Thu Mar 23 11:13:30 2017 From: chris.harris at kitware.com (Chris Harris) Date: Thu, 23 Mar 2017 11:13:30 -0400 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: Qt provides help for this situation ( in the signal world ) by allowing a "context object" to be provided on the connect, which causes the signal to be disconnected when the object is destroyed. Could something similar work here? Chris On Thu, Mar 23, 2017 at 10:55 AM, David Gobbi wrote: > Hi Robert, > > Our AddObserver() methods only use weak pointers when the observer is > derived from vtkObjectBase, which means that currently if the observer is > not a VTK object, then we have a situation where we might call a dangling > pointer. I'm not aware of any uniform way around get around this issue > except for using std::weak_ptr, which in turn demands that any non-vtk > observer objects are wrapped with a std::shared_ptr. > > When people start using lambdas with AddObserver, about the only thing we > can do for safety is provide rules such as the ones that you describe to > ensure that the lambda doesn't capture pointers that can be left dangling. > > Thanks, by the way, for working on the c++11 guidelines. > > - David > > On Thu, Mar 23, 2017 at 8:31 AM, Robert Maynard < > robert.maynard at kitware.com> wrote: > >> While allowing lambda's to be held by std::function is really nice, it >> becomes very easy to mistakenly captures items whose lifetime is >> shorter than the Observer you are binding too. >> >> I am currently writing up the first draft of c++11 guidelines for VTK >> and for lambda functions and these are the guidelines I currently >> have: >> >> Usage of lambda expressions are allowed with the following guidelines. >> >> - Use default capture by value ([=]) only as a means of binding a few >> variables for a short lambda, where the set of captured variables is >> obvious at a glance. Prefer not to write long or complex lambdas with >> default capture by value. >> - Except for the above, all capture arguments must be explicitly >> captured. Using the default capture by reference ([&]) is not allowed. >> This is to done so that it is easier to evaluate lifespan and >> reference ownership. >> - Keep unnamed lambdas short. If a lambda body is more than maybe five >> lines long, prefer using a named function instead of a lambda. >> - Specify the return type of the lambda explicitly if that will make >> it more obvious to readers. >> >> On-top of these guidelines I have also stated that lambda functions >> should be kept to implementation files in VTK, which is fine as we go >> with an approach like David proposed. >> >> On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik >> wrote: >> > Den 22 mars 2017 6:48 em skrev "David Gobbi" : >> >> >> >> It doesn't look hard. New AddObserver methods would be needed that >> take >> >> std::function<> as a parameter, and they'd have to store the "function" >> >> object and call it. Overall, it would probably be simpler than the >> code >> >> that currently exists in vtkObject.h for adding observers. >> > >> > Good to hear, I might have a go at it then. >> > >> > Elvis >> > >> >> >> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> With C++11 now required, would there be interest in an AddObserver >> >>> version that takes a C++11 lambda? I've found myself wishing there was >> >>> one a couple of times. >> >>> >> >>> Anyone know off the top of their head how easy/hard that would be to >> add? >> >>> >> >>> Cheers, >> >>> Elvis >> >>> _______________________________________________ >> >>> Powered by www.kitware.com >> >>> >> >>> Visit other Kitware open-source projects at >> >>> http://www.kitware.com/opensource/opensource.html >> >>> >> >>> Search the list archives at: http://markmail.org/search/?q= >> vtk-developers >> >>> >> >>> Follow this link to subscribe/unsubscribe: >> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >> >>> >> >> >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Search the list archives at: http://markmail.org/search/?q= >> vtk-developers >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hahnse at ornl.gov Thu Mar 23 11:14:33 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Thu, 23 Mar 2017 15:14:33 +0000 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: <4DF9F657-4052-4854-B0F7-94017B802C14@ornl.gov> Would it be more efficient to pass the lambda via a template parameter, like what is done in vtkClassMemberCallback? std::function<> adds a lot of overhead (see https://vittorioromeo.info/index/blog/passing_functions_to_functions.html ) and may be overkill. Steven On 3/23/17, 10:31 AM, "vtk-developers on behalf of Robert Maynard" wrote: While allowing lambda's to be held by std::function is really nice, it becomes very easy to mistakenly captures items whose lifetime is shorter than the Observer you are binding too. I am currently writing up the first draft of c++11 guidelines for VTK and for lambda functions and these are the guidelines I currently have: Usage of lambda expressions are allowed with the following guidelines. - Use default capture by value ([=]) only as a means of binding a few variables for a short lambda, where the set of captured variables is obvious at a glance. Prefer not to write long or complex lambdas with default capture by value. - Except for the above, all capture arguments must be explicitly captured. Using the default capture by reference ([&]) is not allowed. This is to done so that it is easier to evaluate lifespan and reference ownership. - Keep unnamed lambdas short. If a lambda body is more than maybe five lines long, prefer using a named function instead of a lambda. - Specify the return type of the lambda explicitly if that will make it more obvious to readers. On-top of these guidelines I have also stated that lambda functions should be kept to implementation files in VTK, which is fine as we go with an approach like David proposed. On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik wrote: > Den 22 mars 2017 6:48 em skrev "David Gobbi" : >> >> It doesn't look hard. New AddObserver methods would be needed that take >> std::function<> as a parameter, and they'd have to store the "function" >> object and call it. Overall, it would probably be simpler than the code >> that currently exists in vtkObject.h for adding observers. > > Good to hear, I might have a go at it then. > > Elvis > >> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik >> wrote: >>> >>> Hi all, >>> >>> With C++11 now required, would there be interest in an AddObserver >>> version that takes a C++11 lambda? I've found myself wishing there was >>> one a couple of times. >>> >>> Anyone know off the top of their head how easy/hard that would be to add? >>> >>> Cheers, >>> Elvis >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From david.gobbi at gmail.com Thu Mar 23 12:54:31 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Mar 2017 10:54:31 -0600 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: Hi Chris, If I'm reading the Qt docs correctly, then the "context" object that connect() uses is simply any Qt object. If we add an AddObserver() that takes lambdas or function pointers, then we could similarly take a "context" object that would be any vtkObjectBase-derived object. But as far as I understand, this wouldn't be generalizable to non-vtk objects. - David On Thu, Mar 23, 2017 at 9:13 AM, Chris Harris wrote: > Qt provides help for this situation ( in the signal world ) by allowing a > "context object" to be provided on the connect, which causes the signal to > be disconnected when the object is destroyed. Could something similar work > here? > > Chris > > On Thu, Mar 23, 2017 at 10:55 AM, David Gobbi > wrote: > >> Hi Robert, >> >> Our AddObserver() methods only use weak pointers when the observer is >> derived from vtkObjectBase, which means that currently if the observer is >> not a VTK object, then we have a situation where we might call a dangling >> pointer. I'm not aware of any uniform way around get around this issue >> except for using std::weak_ptr, which in turn demands that any non-vtk >> observer objects are wrapped with a std::shared_ptr. >> >> When people start using lambdas with AddObserver, about the only thing we >> can do for safety is provide rules such as the ones that you describe to >> ensure that the lambda doesn't capture pointers that can be left dangling. >> >> Thanks, by the way, for working on the c++11 guidelines. >> >> - David >> >> On Thu, Mar 23, 2017 at 8:31 AM, Robert Maynard < >> robert.maynard at kitware.com> wrote: >> >>> While allowing lambda's to be held by std::function is really nice, it >>> becomes very easy to mistakenly captures items whose lifetime is >>> shorter than the Observer you are binding too. >>> >>> I am currently writing up the first draft of c++11 guidelines for VTK >>> and for lambda functions and these are the guidelines I currently >>> have: >>> >>> Usage of lambda expressions are allowed with the following guidelines. >>> >>> - Use default capture by value ([=]) only as a means of binding a few >>> variables for a short lambda, where the set of captured variables is >>> obvious at a glance. Prefer not to write long or complex lambdas with >>> default capture by value. >>> - Except for the above, all capture arguments must be explicitly >>> captured. Using the default capture by reference ([&]) is not allowed. >>> This is to done so that it is easier to evaluate lifespan and >>> reference ownership. >>> - Keep unnamed lambdas short. If a lambda body is more than maybe five >>> lines long, prefer using a named function instead of a lambda. >>> - Specify the return type of the lambda explicitly if that will make >>> it more obvious to readers. >>> >>> On-top of these guidelines I have also stated that lambda functions >>> should be kept to implementation files in VTK, which is fine as we go >>> with an approach like David proposed. >>> >>> On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik >>> wrote: >>> > Den 22 mars 2017 6:48 em skrev "David Gobbi" : >>> >> >>> >> It doesn't look hard. New AddObserver methods would be needed that >>> take >>> >> std::function<> as a parameter, and they'd have to store the >>> "function" >>> >> object and call it. Overall, it would probably be simpler than the >>> code >>> >> that currently exists in vtkObject.h for adding observers. >>> > >>> > Good to hear, I might have a go at it then. >>> > >>> > Elvis >>> > >>> >> >>> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik >>> >> wrote: >>> >>> >>> >>> Hi all, >>> >>> >>> >>> With C++11 now required, would there be interest in an AddObserver >>> >>> version that takes a C++11 lambda? I've found myself wishing there >>> was >>> >>> one a couple of times. >>> >>> >>> >>> Anyone know off the top of their head how easy/hard that would be to >>> add? >>> >>> >>> >>> Cheers, >>> >>> Elvis >>> >>> _______________________________________________ >>> >>> Powered by www.kitware.com >>> >>> >>> >>> Visit other Kitware open-source projects at >>> >>> http://www.kitware.com/opensource/opensource.html >>> >>> >>> >>> Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> >>> >>> >>> Follow this link to subscribe/unsubscribe: >>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Powered by www.kitware.com >>> > >>> > Visit other Kitware open-source projects at >>> > http://www.kitware.com/opensource/opensource.html >>> > >>> > Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >>> > >>> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Mar 23 12:55:58 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 23 Mar 2017 10:55:58 -0600 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: <4DF9F657-4052-4854-B0F7-94017B802C14@ornl.gov> References: <4DF9F657-4052-4854-B0F7-94017B802C14@ornl.gov> Message-ID: Hi Steve, I don't think we have to worry about overhead in VTK's observers. Our main concerns should be safety and usability. The VTK observer implementation is heavy by design, it is meant to used for overall application control (e.g. for the "controller" part of the MVC pattern). It is generally not meant to be used within the VTK computational algorithms themselves. - David On Thu, Mar 23, 2017 at 9:14 AM, Hahn, Steven E. wrote: > Would it be more efficient to pass the lambda via a template parameter, > like what is done in vtkClassMemberCallback? std::function<> adds a lot of > overhead (see https://vittorioromeo.info/index/blog/passing_functions_ > to_functions.html ) and may be overkill. > > Steven > > On 3/23/17, 10:31 AM, "vtk-developers on behalf of Robert Maynard" < > vtk-developers-bounces at vtk.org on behalf of robert.maynard at kitware.com> > wrote: > > While allowing lambda's to be held by std::function is really nice, it > becomes very easy to mistakenly captures items whose lifetime is > shorter than the Observer you are binding too. > > I am currently writing up the first draft of c++11 guidelines for VTK > and for lambda functions and these are the guidelines I currently > have: > > Usage of lambda expressions are allowed with the following guidelines. > > - Use default capture by value ([=]) only as a means of binding a few > variables for a short lambda, where the set of captured variables is > obvious at a glance. Prefer not to write long or complex lambdas with > default capture by value. > - Except for the above, all capture arguments must be explicitly > captured. Using the default capture by reference ([&]) is not allowed. > This is to done so that it is easier to evaluate lifespan and > reference ownership. > - Keep unnamed lambdas short. If a lambda body is more than maybe five > lines long, prefer using a named function instead of a lambda. > - Specify the return type of the lambda explicitly if that will make > it more obvious to readers. > > On-top of these guidelines I have also stated that lambda functions > should be kept to implementation files in VTK, which is fine as we go > with an approach like David proposed. > > On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik > wrote: > > Den 22 mars 2017 6:48 em skrev "David Gobbi" >: > >> > >> It doesn't look hard. New AddObserver methods would be needed that > take > >> std::function<> as a parameter, and they'd have to store the > "function" > >> object and call it. Overall, it would probably be simpler than the > code > >> that currently exists in vtkObject.h for adding observers. > > > > Good to hear, I might have a go at it then. > > > > Elvis > > > >> > >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik > >> wrote: > >>> > >>> Hi all, > >>> > >>> With C++11 now required, would there be interest in an AddObserver > >>> version that takes a C++11 lambda? I've found myself wishing there > was > >>> one a couple of times. > >>> > >>> Anyone know off the top of their head how easy/hard that would be > to add? > >>> > >>> Cheers, > >>> Elvis > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Search the list archives at: http://markmail.org/search/?q= > vtk-developers > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > >> > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q= > vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.harris at kitware.com Fri Mar 24 10:47:43 2017 From: chris.harris at kitware.com (Chris Harris) Date: Fri, 24 Mar 2017 10:47:43 -0400 Subject: [vtk-developers] AddObserver taking C++11 lambda? In-Reply-To: References: Message-ID: David, Correct the "context" could have to be vtkObjectBase derived object, so would only help with vtkObjectBase derived objects used in the lamdba, but that would help in many cases I would think. Chris On Thu, Mar 23, 2017 at 12:54 PM, David Gobbi wrote: > Hi Chris, > > If I'm reading the Qt docs correctly, then the "context" object that > connect() uses is simply any Qt object. If we add an AddObserver() that > takes lambdas or function pointers, then we could similarly take a > "context" object that would be any vtkObjectBase-derived object. But as > far as I understand, this wouldn't be generalizable to non-vtk objects. > > - David > > > On Thu, Mar 23, 2017 at 9:13 AM, Chris Harris > wrote: > >> Qt provides help for this situation ( in the signal world ) by allowing >> a "context object" to be provided on the connect, which causes the signal >> to be disconnected when the object is destroyed. Could something similar >> work here? >> >> Chris >> >> On Thu, Mar 23, 2017 at 10:55 AM, David Gobbi >> wrote: >> >>> Hi Robert, >>> >>> Our AddObserver() methods only use weak pointers when the observer is >>> derived from vtkObjectBase, which means that currently if the observer is >>> not a VTK object, then we have a situation where we might call a dangling >>> pointer. I'm not aware of any uniform way around get around this issue >>> except for using std::weak_ptr, which in turn demands that any non-vtk >>> observer objects are wrapped with a std::shared_ptr. >>> >>> When people start using lambdas with AddObserver, about the only thing >>> we can do for safety is provide rules such as the ones that you describe to >>> ensure that the lambda doesn't capture pointers that can be left dangling. >>> >>> Thanks, by the way, for working on the c++11 guidelines. >>> >>> - David >>> >>> On Thu, Mar 23, 2017 at 8:31 AM, Robert Maynard < >>> robert.maynard at kitware.com> wrote: >>> >>>> While allowing lambda's to be held by std::function is really nice, it >>>> becomes very easy to mistakenly captures items whose lifetime is >>>> shorter than the Observer you are binding too. >>>> >>>> I am currently writing up the first draft of c++11 guidelines for VTK >>>> and for lambda functions and these are the guidelines I currently >>>> have: >>>> >>>> Usage of lambda expressions are allowed with the following guidelines. >>>> >>>> - Use default capture by value ([=]) only as a means of binding a few >>>> variables for a short lambda, where the set of captured variables is >>>> obvious at a glance. Prefer not to write long or complex lambdas with >>>> default capture by value. >>>> - Except for the above, all capture arguments must be explicitly >>>> captured. Using the default capture by reference ([&]) is not allowed. >>>> This is to done so that it is easier to evaluate lifespan and >>>> reference ownership. >>>> - Keep unnamed lambdas short. If a lambda body is more than maybe five >>>> lines long, prefer using a named function instead of a lambda. >>>> - Specify the return type of the lambda explicitly if that will make >>>> it more obvious to readers. >>>> >>>> On-top of these guidelines I have also stated that lambda functions >>>> should be kept to implementation files in VTK, which is fine as we go >>>> with an approach like David proposed. >>>> >>>> On Wed, Mar 22, 2017 at 2:00 PM, Elvis Stansvik >>>> wrote: >>>> > Den 22 mars 2017 6:48 em skrev "David Gobbi" : >>>> >> >>>> >> It doesn't look hard. New AddObserver methods would be needed that >>>> take >>>> >> std::function<> as a parameter, and they'd have to store the >>>> "function" >>>> >> object and call it. Overall, it would probably be simpler than the >>>> code >>>> >> that currently exists in vtkObject.h for adding observers. >>>> > >>>> > Good to hear, I might have a go at it then. >>>> > >>>> > Elvis >>>> > >>>> >> >>>> >> On Wed, Mar 22, 2017 at 12:53 AM, Elvis Stansvik >>>> >> wrote: >>>> >>> >>>> >>> Hi all, >>>> >>> >>>> >>> With C++11 now required, would there be interest in an AddObserver >>>> >>> version that takes a C++11 lambda? I've found myself wishing there >>>> was >>>> >>> one a couple of times. >>>> >>> >>>> >>> Anyone know off the top of their head how easy/hard that would be >>>> to add? >>>> >>> >>>> >>> Cheers, >>>> >>> Elvis >>>> >>> _______________________________________________ >>>> >>> Powered by www.kitware.com >>>> >>> >>>> >>> Visit other Kitware open-source projects at >>>> >>> http://www.kitware.com/opensource/opensource.html >>>> >>> >>>> >>> Search the list archives at: http://markmail.org/search/?q= >>>> vtk-developers >>>> >>> >>>> >>> Follow this link to subscribe/unsubscribe: >>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > Powered by www.kitware.com >>>> > >>>> > Visit other Kitware open-source projects at >>>> > http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Search the list archives at: http://markmail.org/search/?q= >>>> vtk-developers >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>> > >>>> > >>>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Sat Mar 25 14:28:47 2017 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 25 Mar 2017 14:28:47 -0400 Subject: [vtk-developers] TemporalArrayOperator Message-ID: Looks like a small typo vtkTemporalArrayOperatorFilter.cxx: 267 in vtkTemporalArrayOperatorFilter ::ProcessDataObject(vtkDataObject *, vtkDataObject *)() 261 //---------------------------------------------------------- -------------------- 262 vtkDataObject* vtkTemporalArrayOperatorFilter::ProcessDataObject( 263 vtkDataObject* inputData0, vtkDataObject* inputData1) 264 { 265 vtkDataArray* inputArray0 = this->GetInputArrayToProcess(0, inputData0); 266 vtkDataArray* inputArray1 = this->GetInputArrayToProcess(0, inputData1); >>> CID 1372958: Incorrect expression (CONSTANT_EXPRESSION_RESULT) >>> The expression "!inputArray1 || !inputArray1" does not accomplish anything because it evaluates to either of its identical operands, "!inputArray1". 267 if (!inputArray1 || !inputArray1) 268 { 269 vtkErrorMacro(<< "Unable to retrieve data arrays to process."); 270 return NULL; 271 } 272 -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Sun Mar 26 16:28:09 2017 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Sun, 26 Mar 2017 16:28:09 -0400 Subject: [vtk-developers] TemporalArrayOperator In-Reply-To: References: Message-ID: Thanks for reporting this Ken. https://gitlab.kitware.com/vtk/vtk/merge_requests/2628 Best, Joachim *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * 2017-03-25 14:28 GMT-04:00 Ken Martin : > Looks like a small typo > > vtkTemporalArrayOperatorFilter.cxx: 267 in vtkTemporalArrayOperatorFilter > ::ProcessDataObject(vtkDataObject *, vtkDataObject *)() > 261 //---------------------------------------------------------- > -------------------- > 262 vtkDataObject* vtkTemporalArrayOperatorFilter::ProcessDataObject( > 263 vtkDataObject* inputData0, vtkDataObject* inputData1) > 264 { > 265 vtkDataArray* inputArray0 = this->GetInputArrayToProcess(0, > inputData0); > 266 vtkDataArray* inputArray1 = this->GetInputArrayToProcess(0, > inputData1); > >>> CID 1372958: Incorrect expression (CONSTANT_EXPRESSION_RESULT) > >>> The expression "!inputArray1 || !inputArray1" does not accomplish > anything because it evaluates to either of its identical operands, > "!inputArray1". > 267 if (!inputArray1 || !inputArray1) > 268 { > 269 vtkErrorMacro(<< "Unable to retrieve data arrays to process."); > 270 return NULL; > 271 } > 272 > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Mar 27 14:03:16 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 27 Mar 2017 14:03:16 -0400 Subject: [vtk-developers] Allowable C++11 Features in VTK Message-ID: As everyone is aware over the past couple of months we have updated VTK to require a C++11 compiler, but have not explicitly stated what C++11 features are usable. We do not intend to incorporate all features of the language at this time because of incompatibilities with the structure of VTK and/or incomplete support for the features by all of the compilers that VTK aims to support. The current proposed C++11 features, and where they are allowed can be found at: https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing Over the next two weeks please provide feedback, either by commenting on the google document, or replying on the mailing list. Once the two weeks are over, we will integrate the result into the existing coding documentation, and then allow C++11 to be used. From baljci at hotmail.com Mon Mar 27 15:30:13 2017 From: baljci at hotmail.com (B B) Date: Mon, 27 Mar 2017 19:30:13 +0000 Subject: [vtk-developers] [vtkusers] Allowable C++11 Features in VTK In-Reply-To: References: Message-ID: I would suggest the following: - Prefer the use of alias declarations instead of typedef: they do the same but alias declarations are better because they can be templetized (see Scott Meyers, Effective Modern C++, 63-67) - Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays. - For scoped enums, I would restrict their use to global enums, especially in case of possible name conflicts. For nested enums, I would suggest to maintain the use of unscoped enums for two reasons: first, you don't need to write MyEnum::MyEnumValue each time you use them inside the class implementation; second, from my own experience, their implicit conversion to int can be useful in many cases. Boris ________________________________ De : vtkusers de la part de Robert Maynard Envoy? : lundi 27 mars 2017 20:03 ? : VTK Developers; vtk vtk Objet : [vtkusers] Allowable C++11 Features in VTK As everyone is aware over the past couple of months we have updated VTK to require a C++11 compiler, but have not explicitly stated what C++11 features are usable. We do not intend to incorporate all features of the language at this time because of incompatibilities with the structure of VTK and/or incomplete support for the features by all of the compilers that VTK aims to support. The current proposed C++11 features, and where they are allowed can be found at: https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing Over the next two weeks please provide feedback, either by commenting on the google document, or replying on the mailing list. Once the two weeks are over, we will integrate the result into the existing coding documentation, and then allow C++11 to be used. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ Search the list archives at: http://markmail.org/search/?q=vtkusers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtkusers vtkusers Info Page - Kitware public.kitware.com To see the collection of prior postings to the list, visit the vtkusers Archives. Using vtkusers: To post a message to all the list members, send ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Mar 27 16:14:43 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 27 Mar 2017 16:14:43 -0400 Subject: [vtk-developers] [vtkusers] Allowable C++11 Features in VTK In-Reply-To: References: Message-ID: Hi, Thanks for the feedback. 1. I agree that when doing template metaprogramming, the alias keyword is significantly better than typedef. I will update the document to state that we prefer alias over typedef 2. I am going to update the std::array section to clarify that is preferred over raw fixed size 'C' arrays. 3. This is good information to have. I will add a comment to the scoped enums section while I wait for more feedback On Mon, Mar 27, 2017 at 3:30 PM, B B wrote: > I would suggest the following: > > > - Prefer the use of alias declarations instead of typedef: they do the > same but alias declarations are better because they can be templetized (see > Scott Meyers, Effective Modern C++, 63-67) > > - Replace raw arrays with std::array when possible: they are > copyable, easier to manipulate and have no extra performance costs compared > to raw arrays. > > - For scoped enums, I would restrict their use to global enums, > especially in case of possible name conflicts. For nested enums, I would > suggest to maintain the use of unscoped enums for two reasons: first, you > don't need to write MyEnum::MyEnumValue each time you use them inside > the class implementation; second, from my own experience, their implicit > conversion to int can be useful in many cases. > > Boris > > ------------------------------ > *De :* vtkusers de la part de Robert Maynard < > robert.maynard at kitware.com> > *Envoy? :* lundi 27 mars 2017 20:03 > *? :* VTK Developers; vtk vtk > *Objet :* [vtkusers] Allowable C++11 Features in VTK > > As everyone is aware over the past couple of months we have updated > VTK to require a C++11 compiler, but have not explicitly stated what > C++11 features are usable. > > We do not intend to incorporate all features of the language at this > time because of incompatibilities with the structure of VTK and/or > incomplete support for the features by all of the compilers that VTK > aims to support. > > The current proposed C++11 features, and where they are allowed can be > found at: > > https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHX > KKlHM2sW2ErohfHiuCg/edit?usp=sharing > > Over the next two weeks please provide feedback, either by commenting > on the google document, or replying on the mailing list. Once the two > weeks are over, we will integrate the result into the existing coding > documentation, and then allow C++11 to be used. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Search the list archives at: http://markmail.org/search/?q=vtkusers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > vtkusers Info Page - Kitware > > public.kitware.com > To see the collection of prior postings to the list, visit the vtkusers > Archives. Using vtkusers: To post a message to all the list members, send > ... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Mar 27 16:58:41 2017 From: sean at rogue-research.com (Sean McBride) Date: Mon, 27 Mar 2017 16:58:41 -0400 Subject: [vtk-developers] TemporalArrayOperator In-Reply-To: References: Message-ID: <20170327205841.470339503@mail.rogue-research.com> On Sat, 25 Mar 2017 14:28:47 -0400, Ken Martin said: >>>> CID 1372958: Incorrect expression (CONSTANT_EXPRESSION_RESULT) >>>> The expression "!inputArray1 || !inputArray1" does not accomplish >anything because it evaluates to either of its identical operands, >"!inputArray1". >267 if (!inputArray1 || !inputArray1) A good occasion to remind everyone to look at the nightly cppcheck dashboard :), where this has also been since Wednesday: Filters/Hybrid/vtkTemporalArrayOperatorFilter.cxx:267: style: Same expression on both sides of '||'. Sean From sean at rogue-research.com Mon Mar 27 17:11:40 2017 From: sean at rogue-research.com (Sean McBride) Date: Mon, 27 Mar 2017 17:11:40 -0400 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> References: ,<20170322210145.978133664@ma il.rogue-research.com> <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> Message-ID: <20170327211140.1255596157@mail.rogue-research.com> On Thu, 23 Mar 2017 14:07:03 +0000, Hahn, Steven E. said: >With std::isinf clang generates code that is 3-4 times slower than >one would naively expect for a type that doesn?t contain infinity. Is there a bug for that? A quick search didn't reveal anything: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From hahnse at ornl.gov Mon Mar 27 17:15:10 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Mon, 27 Mar 2017 21:15:10 +0000 Subject: [vtk-developers] ready to branch for 8.0.0? In-Reply-To: <20170327211140.1255596157@mail.rogue-research.com> References: <03adb949690649ad8877f1f62a0dcf7c@EXCHCS33.ornl.gov> <20170327211140.1255596157@mail.rogue-research.com> Message-ID: I sent a message along with a short file showing the performance bug to the cfe-dev mailing list but haven?t received a response. http://lists.llvm.org/pipermail/cfe-dev/2017-March/053305.html On 3/27/17, 5:11 PM, "Sean McBride" wrote: On Thu, 23 Mar 2017 14:07:03 +0000, Hahn, Steven E. said: >With std::isinf clang generates code that is 3-4 times slower than >one would naively expect for a type that doesn?t contain infinity. Is there a bug for that? A quick search didn't reveal anything: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From david.gobbi at gmail.com Mon Mar 27 17:22:29 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 27 Mar 2017 15:22:29 -0600 Subject: [vtk-developers] [vtkusers] Allowable C++11 Features in VTK In-Reply-To: References: Message-ID: The fixed-type enums in C++11 could also be beneficial. Consider the following vtkLookupTable code, which declares a few constants in the header (shown below) and then provides the definition in the .cxx file (not shown): class vtkLookupTable { public: static const vtkIdType BELOW_RANGE_COLOR_INDEX; static const vtkIdType ABOVE_RANGE_COLOR_INDEX; static const vtkIdType NAN_COLOR_INDEX; static const vtkIdType NUMBER_OF_SPECIAL_COLORS; ... }; In C++11 these "static const" members can be defined more efficiently as a fixed-type enum: public: enum : vtkIdType { BELOW_RANGE_COLOR_INDEX = 0, ABOVE_RANGE_COLOR_INDEX = 1, NAN_COLOR_INDEX = 2, NUMBER_OF_SPECIAL_COLORS }; Of course VTK already uses enums for most constants (except for the ones that are still #define'd), so the benefit is for when you need a guarantee that the constant will be evaluated as a specific integral type. - David On Mon, Mar 27, 2017 at 2:14 PM, Robert Maynard wrote: > Hi, > > Thanks for the feedback. > > 1. I agree that when doing template metaprogramming, the alias keyword is > significantly better than typedef. I will update the document to state that > we prefer alias over typedef > > 2. I am going to update the std::array section to clarify that is > preferred over raw fixed size 'C' arrays. > > 3. This is good information to have. I will add a comment to the scoped > enums section while I wait for more feedback > > > On Mon, Mar 27, 2017 at 3:30 PM, B B wrote: > >> I would suggest the following: >> >> >> - Prefer the use of alias declarations instead of typedef: they do the >> same but alias declarations are better because they can be templetized (see >> Scott Meyers, Effective Modern C++, 63-67) >> >> - Replace raw arrays with std::array when possible: they are >> copyable, easier to manipulate and have no extra performance costs compared >> to raw arrays. >> >> - For scoped enums, I would restrict their use to global enums, >> especially in case of possible name conflicts. For nested enums, I would >> suggest to maintain the use of unscoped enums for two reasons: first, you >> don't need to write MyEnum::MyEnumValue each time you use them inside >> the class implementation; second, from my own experience, their implicit >> conversion to int can be useful in many cases. >> >> Boris >> >> ------------------------------ >> *De :* vtkusers de la part de Robert Maynard < >> robert.maynard at kitware.com> >> *Envoy? :* lundi 27 mars 2017 20:03 >> *? :* VTK Developers; vtk vtk >> *Objet :* [vtkusers] Allowable C++11 Features in VTK >> >> As everyone is aware over the past couple of months we have updated >> VTK to require a C++11 compiler, but have not explicitly stated what >> C++11 features are usable. >> >> We do not intend to incorporate all features of the language at this >> time because of incompatibilities with the structure of VTK and/or >> incomplete support for the features by all of the compilers that VTK >> aims to support. >> >> The current proposed C++11 features, and where they are allowed can be >> found at: >> >> https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHX >> KKlHM2sW2ErohfHiuCg/edit?usp=sharing >> >> Over the next two weeks please provide feedback, either by commenting >> on the google document, or replying on the mailing list. Once the two >> weeks are over, we will integrate the result into the existing coding >> documentation, and then allow C++11 to be used. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Mar 28 18:52:42 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 29 Mar 2017 09:52:42 +1100 Subject: [vtk-developers] Allowable C++11 Features in VTK Message-ID: I agree with David. I would argue for strongly typed enums to be allowed. In contrast to ordinary enums, they don't export their enumerators to the surrounding scope and they don't have implicit conversion to int. Implicit conversion to int can dangerous in that the code performs correctly but the results are unexpected. I don't think their use should be restricted to just global enumerations. I actually had the experience of converting old code to C++11 and when I converted the enums to strongly typed enums a whole lot of subtle faults were revealed where ints were used instead of enums. The important thing was that the old code ran perfectly but it was nearly impossible to account for the anomalous behaviour until strongly typed enums were used. Here is a contrived example that illustrates the problem. #include #include #include enum bg1 {r, g, b}; enum class bg2 { r, g, b }; void c0(int intensity) { std::cout << "Intensity: " << intensity << "\n"; } void c1(bg1 bg, int intensity) { std::cout << "Background: "; switch (bg) { case r: std::cout << "r\n"; break; case g: std::cout << "gr\n"; break; case b: std::cout << "b\n"; break; } std::cout << "Intensity: " << intensity << "\n"; } void c2(bg2 bg, int intensity) { std::cout << "Background: "; switch (bg) { case bg2::r: std::cout << "r\n"; break; case bg2::g: std::cout << "g\n"; break; case bg2::b: std::cout << "b\n"; break; } std::cout << "Intensity: " << intensity << "\n"; } int main() { int intensity = 7; c0(intensity); c0(bg1::r); // OK but surely an error! c1(bg1::r, intensity); // This call is Ok as bg is implicitly converted to int. // Is this what we really want? c1(bg1::r, bg1::g); // Strongly typed case. c2(bg2::r, intensity); // Because of strongly typed enums, // these will fail as bg2 is strongly typed. // c0(bg2::r); // c2(bg2::r, bg2::g); return EXIT_SUCCESS; } Regards Andrew ---------- Forwarded message ---------- > From: David Gobbi > To: Robert Maynard > Cc: VTK Developers , vtk vtk > Bcc: > Date: Mon, 27 Mar 2017 15:22:29 -0600 > Subject: Re: [vtk-developers] [vtkusers] Allowable C++11 Features in VTK > The fixed-type enums in C++11 could also be beneficial. Consider the > following vtkLookupTable code, which declares a few constants in the header > (shown below) and then provides the definition in the .cxx file (not shown): > > class vtkLookupTable > { > public: > static const vtkIdType BELOW_RANGE_COLOR_INDEX; > static const vtkIdType ABOVE_RANGE_COLOR_INDEX; > static const vtkIdType NAN_COLOR_INDEX; > static const vtkIdType NUMBER_OF_SPECIAL_COLORS; > ... > }; > > In C++11 these "static const" members can be defined more efficiently as a > fixed-type enum: > > public: > enum : vtkIdType { > BELOW_RANGE_COLOR_INDEX = 0, > ABOVE_RANGE_COLOR_INDEX = 1, > NAN_COLOR_INDEX = 2, > NUMBER_OF_SPECIAL_COLORS > }; > > Of course VTK already uses enums for most constants (except for the ones > that are still #define'd), so the benefit is for when you need a guarantee > that the constant will be evaluated as a specific integral type. > > - David > > > > On Mon, Mar 27, 2017 at 2:14 PM, Robert Maynard < > robert.maynard at kitware.com> wrote: > >> Hi, >> >> Thanks for the feedback. >> >> 1. I agree that when doing template metaprogramming, the alias keyword is >> significantly better than typedef. I will update the document to state that >> we prefer alias over typedef >> >> 2. I am going to update the std::array section to clarify that is >> preferred over raw fixed size 'C' arrays. >> >> 3. This is good information to have. I will add a comment to the scoped >> enums section while I wait for more feedback >> >> >> On Mon, Mar 27, 2017 at 3:30 PM, B B wrote: >> >>> I would suggest the following: >>> >>> >>> - Prefer the use of alias declarations instead of typedef: they do the >>> same but alias declarations are better because they can be templetized (see >>> Scott Meyers, Effective Modern C++, 63-67) >>> >>> - Replace raw arrays with std::array when possible: they are >>> copyable, easier to manipulate and have no extra performance costs compared >>> to raw arrays. >>> >>> - For scoped enums, I would restrict their use to global enums, >>> especially in case of possible name conflicts. For nested enums, I would >>> suggest to maintain the use of unscoped enums for two reasons: first, you >>> don't need to write MyEnum::MyEnumValue each time you use them inside >>> the class implementation; second, from my own experience, their implicit >>> conversion to int can be useful in many cases. >>> >>> Boris >>> >>> ------------------------------ >>> *De :* vtkusers de la part de Robert Maynard >>> >>> *Envoy? :* lundi 27 mars 2017 20:03 >>> *? :* VTK Developers; vtk vtk >>> *Objet :* [vtkusers] Allowable C++11 Features in VTK >>> >>> As everyone is aware over the past couple of months we have updated >>> VTK to require a C++11 compiler, but have not explicitly stated what >>> C++11 features are usable. >>> >>> We do not intend to incorporate all features of the language at this >>> time because of incompatibilities with the structure of VTK and/or >>> incomplete support for the features by all of the compilers that VTK >>> aims to support. >>> >>> The current proposed C++11 features, and where they are allowed can be >>> found at: >>> >>> https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHX >>> KKlHM2sW2ErohfHiuCg/edit?usp=sharing >>> >>> Over the next two weeks please provide feedback, either by commenting >>> on the google document, or replying on the mailing list. Once the two >>> weeks are over, we will integrate the result into the existing coding >>> documentation, and then allow C++11 to be used. >>> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Mar 29 12:30:50 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 29 Mar 2017 10:30:50 -0600 Subject: [vtk-developers] Image filter to remap labels to new values Message-ID: Hi All, I'm planning to add a new image filter to VTK, and will name it something like vtkImageMapThroughLUT. The operation of this filter will be as follows: - It will take, as input, any image that uses an integer scalar type - The scalars will be mapped though a lookup table to generate the output image For the "lookup table" or (LUT), I was planning to use a plain-old vtkDataArray. I cannot use vtkLookupTable as the LUT, since vtkLookupTable can only produce "unsigned char" output and is meant to be used for generating color data. My question to the list is as follows: is vtkDataArray the best object to use for storing such a LUT? Also, is there already a class in the VTK geometry pipeline that allows labels to be remapped to new label values via a LUT? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Mar 29 12:42:41 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Mar 2017 12:42:41 -0400 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: References: Message-ID: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> Hi David, > ...I'm planning to add a new image filter to VTK, and will name it something like vtkImageMapThroughLUT. The operation of this filter will be as follows: > > - It will take, as input, any image that uses an integer scalar type > - The scalars will be mapped though a lookup table to generate the output image > > For the "lookup table" or (LUT), I was planning to use a plain-old vtkDataArray. I cannot use vtkLookupTable as the LUT, since vtkLookupTable can only produce "unsigned char" output and is meant to be used for generating color data. > > My question to the list is as follows: is vtkDataArray the best object to use for storing such a LUT? You might consider vtkPiecewiseFunction (in Common/DataModel). > Also, is there already a class in the VTK geometry pipeline that allows labels to be remapped to new label values via a LUT? I don't know of any; what format are the labels in? David From david.gobbi at gmail.com Wed Mar 29 12:53:46 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 29 Mar 2017 10:53:46 -0600 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> References: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> Message-ID: On Wed, Mar 29, 2017 at 10:42 AM, David Thompson wrote: > Hi David, > > > ...I'm planning to add a new image filter to VTK, and will name it > something like vtkImageMapThroughLUT. The operation of this filter will be > as follows: > > > > - It will take, as input, any image that uses an integer scalar type > > - The scalars will be mapped though a lookup table to generate the > output image > > > > For the "lookup table" or (LUT), I was planning to use a plain-old > vtkDataArray. I cannot use vtkLookupTable as the LUT, since vtkLookupTable > can only produce "unsigned char" output and is meant to be used for > generating color data. > > > > My question to the list is as follows: is vtkDataArray the best object > to use for storing such a LUT? > > You might consider vtkPiecewiseFunction (in Common/DataModel). > > > Also, is there already a class in the VTK geometry pipeline that allows > labels to be remapped to new label values via a LUT? > > I don't know of any; what format are the labels in? > The "labels", in this case, are just scalar values. The use case is images that represent brain segmentations, where a pixel value of "0" represents nothing, a pixel value of "1" represents one particular region of the brain, a pixel value of "2" represents a different region of the brain, etc. Such images are commonly used in neuroscience imaging research, and are often called "label images" or, depending on their use, "atlas images". So we're talking about simply mapping integer scalar values through a LUT, to get a new set of integer scalar values. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Mar 29 13:01:27 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 29 Mar 2017 11:01:27 -0600 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: References: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> Message-ID: On Wed, Mar 29, 2017 at 10:53 AM, David Gobbi wrote: > On Wed, Mar 29, 2017 at 10:42 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi David, >> >> > ...I'm planning to add a new image filter to VTK, and will name it >> something like vtkImageMapThroughLUT. The operation of this filter will be >> as follows: >> > >> > - It will take, as input, any image that uses an integer scalar type >> > - The scalars will be mapped though a lookup table to generate the >> output image >> > >> > For the "lookup table" or (LUT), I was planning to use a plain-old >> vtkDataArray. I cannot use vtkLookupTable as the LUT, since vtkLookupTable >> can only produce "unsigned char" output and is meant to be used for >> generating color data. >> > >> > My question to the list is as follows: is vtkDataArray the best object >> to use for storing such a LUT? >> >> You might consider vtkPiecewiseFunction (in Common/DataModel). >> >> > Also, is there already a class in the VTK geometry pipeline that allows >> labels to be remapped to new label values via a LUT? >> >> I don't know of any; what format are the labels in? >> > > The "labels", in this case, are just scalar values. The use case is > images that represent brain segmentations, where a pixel value of "0" > represents nothing, a pixel value of "1" represents one particular region > of the brain, a pixel value of "2" represents a different region of the > brain, etc. Such images are commonly used in neuroscience imaging > research, and are often called "label images" or, depending on their use, > "atlas images". > > So we're talking about simply mapping integer scalar values through a LUT, > to get a new set of integer scalar values. > To put it another way, the labels that I'm referring to are categorical values, where all voxels with value "n" belong to "category n". - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Mar 29 13:01:53 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Mar 2017 13:01:53 -0400 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: References: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> Message-ID: <2D09359C-DA72-4C90-8695-4CD836413110@kitware.com> Hi David, > ... The "labels", in this case, are just scalar values. The use case is images that represent brain segmentations, where a pixel value of "0" represents nothing, a pixel value of "1" represents one particular region of the brain, a pixel value of "2" represents a different region of the brain, etc. Such images are commonly used in neuroscience imaging research, and are often called "label images" or, depending on their use, "atlas images". > > So we're talking about simply mapping integer scalar values through a LUT, to get a new set of integer scalar values. Then I don't see vtkPiecewiseFunction or anything else doing anything you need; a vtkDataArray is probably best, although it might be nice to have a new vtkDataObject subclass (vtkScalarMap?) that takes the table and sorts it so lookups are O(log(N)) instead of O(N). That's not a whole lot of code, though, so I can also see just making it part of vtkImageMapThroughLUT. David From david.thompson at kitware.com Wed Mar 29 13:03:10 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Mar 2017 13:03:10 -0400 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: References: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> Message-ID: <102053B5-3F55-4992-B768-7C698B92A672@kitware.com> Hi David, > ... > To put it another way, the labels that I'm referring to are categorical values, where all voxels with value "n" belong to "category n". Yup. All the categorical colormap stuff uses vtkVariant (not fast) to accommodate strings as categories. I would not use it for this. David From david.gobbi at gmail.com Wed Mar 29 13:11:29 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 29 Mar 2017 11:11:29 -0600 Subject: [vtk-developers] Image filter to remap labels to new values In-Reply-To: <2D09359C-DA72-4C90-8695-4CD836413110@kitware.com> References: <9A3EC51B-D6B3-44A0-BCA0-42ACBAB2ABA3@kitware.com> <2D09359C-DA72-4C90-8695-4CD836413110@kitware.com> Message-ID: On Wed, Mar 29, 2017 at 11:01 AM, David Thompson wrote: > > Then I don't see vtkPiecewiseFunction or anything else doing anything you > need; a vtkDataArray is probably best, although it might be nice to have a > new vtkDataObject subclass (vtkScalarMap?) that takes the table and sorts > it so lookups are O(log(N)) instead of O(N). That's not a whole lot of > code, though, so I can also see just making it part of > vtkImageMapThroughLUT. The kind of lookups I'm thinking of are O(1), i.e. output = LUT[input]. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: