From bill.lorensen at gmail.com Sun Jul 2 08:57:00 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 2 Jul 2017 08:57:00 -0400 Subject: [vtk-developers] What is vtkRenderLargeImage? In-Reply-To: References: Message-ID: SetMagnification is deprecated. Use SetScale instead. Sent from my iPad On Jun 29, 2017, at 10:40 AM, Utkarsh Ayachit wrote: >> I believe vtkWindowToImageFilter cannot render in something larger >> than the current window on the screen... well things may have changed >> since. > > vtkWindowToImageFilter indeed supports `Magnification` (similar to > vtkRenderLargeImage) which allows for rendering an image larger than > the current render window size. > > Utkarsh > _______________________________________________ > 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 bill.lorensen at gmail.com Sun Jul 2 11:18:17 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 2 Jul 2017 11:18:17 -0400 Subject: [vtk-developers] What is vtkRenderLargeImage? In-Reply-To: References: Message-ID: I'm wrong about that. Sorry for the noise. On Sun, Jul 2, 2017 at 8:57 AM, Bill Lorensen wrote: > SetMagnification is deprecated. Use SetScale instead. > > Sent from my iPad > > On Jun 29, 2017, at 10:40 AM, Utkarsh Ayachit wrote: > >>> I believe vtkWindowToImageFilter cannot render in something larger >>> than the current window on the screen... well things may have changed >>> since. >> >> vtkWindowToImageFilter indeed supports `Magnification` (similar to >> vtkRenderLargeImage) which allows for rendering an image larger than >> the current render window size. >> >> Utkarsh >> _______________________________________________ >> 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 >> -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Mon Jul 3 12:54:51 2017 From: sean at rogue-research.com (Sean McBride) Date: Mon, 3 Jul 2017 12:54:51 -0400 Subject: [vtk-developers] Is someone working on the bigmac failures? In-Reply-To: References: <20170602155435.646162128@mail.rogue-research.com> Message-ID: <20170703165451.1678652112@mail.rogue-research.com> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said: >Ping? Is anyone still working on this? I'm not. I don't believe we agreed on a plan either. I've asked on the cocoa-dev list and am pretty sure we are stuck with NSWindow's behaviour, which is: round sizes *up* to even integral sizes. David's suggestion of changing the testing system so that it tolerates a 1-pixel difference in the size in the images I agree is probably best, in the short term at least. Still, if we were starting from scratch, it seems to me that having test output and baselines of identical sizes would be preferable. Perhaps as tests are maintained, they should be updated to not use odd sizes? I wonder too if we ought to add a log/warning to SetSize() implementations when users of the API provide odd sizes? Sean From sean at rogue-research.com Mon Jul 3 12:56:41 2017 From: sean at rogue-research.com (Sean McBride) Date: Mon, 3 Jul 2017 12:56:41 -0400 Subject: [vtk-developers] No Windows 'nightly expected' builds? Message-ID: <20170703165641.1789695961@mail.rogue-research.com> Hi all, I just noticed there are no Windows builds in the 'nightly expected' section of the dashboard. Pretty sure there used to be... Cheers, Sean From bill.lorensen at gmail.com Mon Jul 3 14:52:46 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 3 Jul 2017 14:52:46 -0400 Subject: [vtk-developers] Is someone working on the bigmac failures? In-Reply-To: <20170703165451.1678652112@mail.rogue-research.com> References: <20170602155435.646162128@mail.rogue-research.com> <20170703165451.1678652112@mail.rogue-research.com> Message-ID: There are only 23 tests that have odd sizes and they are all python tests, oddly enough. I'll change them to have even sizes and I'll update the baselines. For those tests, I'll delete all baseline versions before I add the new one. Bill On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride wrote: > On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said: > >>Ping? Is anyone still working on this? > > I'm not. I don't believe we agreed on a plan either. > > I've asked on the cocoa-dev list and am pretty sure we are stuck with NSWindow's behaviour, which is: round sizes *up* to even integral sizes. > > David's suggestion of changing the testing system so that it tolerates a 1-pixel difference in the size in the images I agree is probably best, in the short term at least. Still, if we were starting from scratch, it seems to me that having test output and baselines of identical sizes would be preferable. Perhaps as tests are maintained, they should be updated to not use odd sizes? > > I wonder too if we ought to add a log/warning to SetSize() implementations when users of the API provide odd sizes? > > 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 > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Wed Jul 5 09:41:00 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 5 Jul 2017 09:41:00 -0400 Subject: [vtk-developers] No Windows 'nightly expected' builds? In-Reply-To: <20170703165641.1789695961@mail.rogue-research.com> References: <20170703165641.1789695961@mail.rogue-research.com> Message-ID: mun fills the role of checking vtk on windows better. It is in the latest-master section, with the other machines that run after every merge to master. I will eventually promote kargad and dash1win7 to nightly expected once I've sorted out the remaining noise on them. I intend those specifically to validate ospray and xdmf3 on windows but they will run most of the other tests as well. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Jul 3, 2017 at 12:56 PM, Sean McBride wrote: > Hi all, > > I just noticed there are no Windows builds in the 'nightly expected' > section of the dashboard. Pretty sure there used to be... > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Jul 5 10:59:13 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 5 Jul 2017 10:59:13 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) Message-ID: Folks, Interesting. When an image is passed through vtkWindowToImageFilter, the size of the output image is reduced by 1 in each dimension. So if you SetSize on a render window, renderWindow->SetSize(n, m), the saved size will be n-1, m-1. This has to do with the setting in vtkWindowTiImageFilter: #define BORDER_PIXEL 2 I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0, the saved size matches the SetSize. We can't change vtkWindowToImageFilter since it would break every regression test. I can fix the odd baseline issue by setting sizes in the failing tests that take into account the logic in window to image filter. Bill On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen wrote: > There are only 23 tests that have odd sizes and they are all python > tests, oddly enough. > > I'll change them to have even sizes and I'll update the baselines. For > those tests, I'll delete all baseline versions before I add the new > one. > > Bill > > > On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride wrote: >> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said: >> >>>Ping? Is anyone still working on this? >> >> I'm not. I don't believe we agreed on a plan either. >> >> I've asked on the cocoa-dev list and am pretty sure we are stuck with NSWindow's behaviour, which is: round sizes *up* to even integral sizes. >> >> David's suggestion of changing the testing system so that it tolerates a 1-pixel difference in the size in the images I agree is probably best, in the short term at least. Still, if we were starting from scratch, it seems to me that having test output and baselines of identical sizes would be preferable. Perhaps as tests are maintained, they should be updated to not use odd sizes? >> >> I wonder too if we ought to add a log/warning to SetSize() implementations when users of the API provide odd sizes? >> >> 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 >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Wed Jul 5 11:08:43 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 5 Jul 2017 11:08:43 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) In-Reply-To: References: Message-ID: Bill, I would be surprised if it has anything to do with BORDER_PIXEL. BORDER_PIXEL comes into play only when `FixBoundary` is ON, and it's OFF by default and tiling is used -- which is rarely, if at all used for VTK test baselines. It should be deprecated as it's no longer needed. It was needed in OpenGL1 days for certain OpenGL drivers where when rendering wireframe, the wireframe for a cell would get artificially closed if it intersected the viewport boundary. That doesn't happen with OpenGL2. Utkarsh On Wed, Jul 5, 2017 at 10:59 AM, Bill Lorensen wrote: > Folks, > > Interesting. > > When an image is passed through vtkWindowToImageFilter, the size of > the output image is reduced by 1 in each dimension. > > So if you SetSize on a render window, > renderWindow->SetSize(n, m), the saved size will be n-1, m-1. > > This has to do with the setting in vtkWindowTiImageFilter: > #define BORDER_PIXEL 2 > > I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0, > the saved size matches the SetSize. > > We can't change vtkWindowToImageFilter since it would break every > regression test. > > I can fix the odd baseline issue by setting sizes in the failing tests > that take into account the logic in window to image filter. > > Bill > > > On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen > wrote: > > There are only 23 tests that have odd sizes and they are all python > > tests, oddly enough. > > > > I'll change them to have even sizes and I'll update the baselines. For > > those tests, I'll delete all baseline versions before I add the new > > one. > > > > Bill > > > > > > On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride > wrote: > >> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said: > >> > >>>Ping? Is anyone still working on this? > >> > >> I'm not. I don't believe we agreed on a plan either. > >> > >> I've asked on the cocoa-dev list and am pretty sure we are stuck with > NSWindow's behaviour, which is: round sizes *up* to even integral sizes. > >> > >> David's suggestion of changing the testing system so that it tolerates > a 1-pixel difference in the size in the images I agree is probably best, in > the short term at least. Still, if we were starting from scratch, it seems > to me that having test output and baselines of identical sizes would be > preferable. Perhaps as tests are maintained, they should be updated to not > use odd sizes? > >> > >> I wonder too if we ought to add a log/warning to SetSize() > implementations when users of the API provide odd sizes? > >> > >> 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 > >> > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > > > > -- > Unpaid intern in BillsBasement at noware dot 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Jul 5 11:12:31 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 5 Jul 2017 11:12:31 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) In-Reply-To: References: Message-ID: Utkarsh, You can verify this by setting the size on an exiting test to some value. Ypu will see the test image size is opff ob 1. If you rebuild with BORDER_SIZE 0, the size will match what you set. Unless I'm smoking something... On Wed, Jul 5, 2017 at 11:08 AM, Utkarsh Ayachit wrote: > Bill, > > I would be surprised if it has anything to do with BORDER_PIXEL. > BORDER_PIXEL comes into play only when `FixBoundary` is ON, and it's OFF by > default and tiling is used -- which is rarely, if at all used for VTK test > baselines. It should be deprecated as it's no longer needed. It was needed > in OpenGL1 days for certain OpenGL drivers where when rendering wireframe, > the wireframe for a cell would get artificially closed if it intersected the > viewport boundary. That doesn't happen with OpenGL2. > > Utkarsh > > On Wed, Jul 5, 2017 at 10:59 AM, Bill Lorensen > wrote: >> >> Folks, >> >> Interesting. >> >> When an image is passed through vtkWindowToImageFilter, the size of >> the output image is reduced by 1 in each dimension. >> >> So if you SetSize on a render window, >> renderWindow->SetSize(n, m), the saved size will be n-1, m-1. >> >> This has to do with the setting in vtkWindowTiImageFilter: >> #define BORDER_PIXEL 2 >> >> I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0, >> the saved size matches the SetSize. >> >> We can't change vtkWindowToImageFilter since it would break every >> regression test. >> >> I can fix the odd baseline issue by setting sizes in the failing tests >> that take into account the logic in window to image filter. >> >> Bill >> >> >> On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen >> wrote: >> > There are only 23 tests that have odd sizes and they are all python >> > tests, oddly enough. >> > >> > I'll change them to have even sizes and I'll update the baselines. For >> > those tests, I'll delete all baseline versions before I add the new >> > one. >> > >> > Bill >> > >> > >> > On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride >> > wrote: >> >> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said: >> >> >> >>>Ping? Is anyone still working on this? >> >> >> >> I'm not. I don't believe we agreed on a plan either. >> >> >> >> I've asked on the cocoa-dev list and am pretty sure we are stuck with >> >> NSWindow's behaviour, which is: round sizes *up* to even integral sizes. >> >> >> >> David's suggestion of changing the testing system so that it tolerates >> >> a 1-pixel difference in the size in the images I agree is probably best, in >> >> the short term at least. Still, if we were starting from scratch, it seems >> >> to me that having test output and baselines of identical sizes would be >> >> preferable. Perhaps as tests are maintained, they should be updated to not >> >> use odd sizes? >> >> >> >> I wonder too if we ought to add a log/warning to SetSize() >> >> implementations when users of the API provide odd sizes? >> >> >> >> 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 >> >> >> > >> > >> > >> > -- >> > Unpaid intern in BillsBasement at noware dot com >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot 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 >> > -- Unpaid intern in BillsBasement at noware dot com From utkarsh.ayachit at kitware.com Wed Jul 5 11:48:22 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 5 Jul 2017 11:48:22 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) In-Reply-To: References: Message-ID: > > Unless I'm smoking something... > > I want what you have ;)! Attached is a modified test. It works with vtkpython no matter the value of BORDER_SIZE. What am I missing? Also, I get exactly the size I request (300, 300) and not 1 pixel less. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.py Type: text/x-python Size: 1754 bytes Desc: not available URL: From bill.lorensen at gmail.com Wed Jul 5 12:20:38 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 5 Jul 2017 12:20:38 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) In-Reply-To: References: Message-ID: Yes.That works for me. But please try this: Take an existing test, like: Imaging/Core/Testing/Python/TestHSIToRGB.py add viewer.SetSize(320,320) ctest -V -R TestHSVToRGB.py you should see this error: 1989: Image differencing failed to produce an image because images are different size: 1989: Valid image: 320, 320, 0 1989: Test image: 319, 319, 0 On Wed, Jul 5, 2017 at 11:48 AM, Utkarsh Ayachit wrote: >> Unless I'm smoking something... >> > > I want what you have ;)! Attached is a modified test. It works with > vtkpython no matter the value of BORDER_SIZE. What am I missing? Also, I > get exactly the size I request (300, 300) and not 1 pixel less. > > Utkarsh -- Unpaid intern in BillsBasement at noware dot com From huangwhwow at gmail.com Wed Jul 5 14:05:20 2017 From: huangwhwow at gmail.com (Wenhan Huang) Date: Wed, 5 Jul 2017 14:05:20 -0400 Subject: [vtk-developers] vtkSmartVolumeMapper RGB image raycast support. Message-ID: I recently upgraded vtk lib from 6.2 to VTK 8.0.0 and found out that the Initialize function has changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huangwhwow at gmail.com Wed Jul 5 14:09:27 2017 From: huangwhwow at gmail.com (Wenhan Huang) Date: Wed, 5 Jul 2017 14:09:27 -0400 Subject: [vtk-developers] vtkSmartVolumeMapper RGB image raycast support Message-ID: Hi, I apologize for the previous post. I hit send by accident. I recently upgraded vtk lib from 6.2 to VTK 8.0.0 and found out that the Initialize function has changed. Right now the way we determine whether raycastmapper is support is this->RayCastSupported = (usingCellColors || numComp > 1) ? 0 : 1; So If the number of component is larger than 1 then Fixedpoint raycastmapper is not support? Is this intended? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Jul 5 14:30:46 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 5 Jul 2017 14:30:46 -0400 Subject: [vtk-developers] RenderWindow sizes for testing (was: is someone working on the bigmac failures?) In-Reply-To: References: Message-ID: I think I see the problem. The vtkTesting.cxx code is producing the wrong output. It is reporting (extent[11] - extent[0]) as a size but the size is really (extent[1] - extent[0] + 1). I've submitted an MR: https://gitlab.kitware.com/vtk/vtk/merge_requests/2998 On Wed, Jul 5, 2017 at 12:20 PM, Bill Lorensen wrote: > Yes.That works for me. > > But please try this: > > Take an existing test, like: > Imaging/Core/Testing/Python/TestHSIToRGB.py > add > viewer.SetSize(320,320) > > ctest -V -R TestHSVToRGB.py > you should see this error: > 1989: Image differencing failed to produce an image because images are > different size: > 1989: Valid image: 320, 320, 0 > 1989: Test image: 319, 319, 0 > > > On Wed, Jul 5, 2017 at 11:48 AM, Utkarsh Ayachit > wrote: >>> Unless I'm smoking something... >>> >> >> I want what you have ;)! Attached is a modified test. It works with >> vtkpython no matter the value of BORDER_SIZE. What am I missing? Also, I >> get exactly the size I request (300, 300) and not 1 pixel less. >> >> Utkarsh > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Mon Jul 10 11:15:50 2017 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Jul 2017 11:15:50 -0400 Subject: [vtk-developers] Some Event handling ideas Message-ID: Lucas and I have been working on VTK's VR support and one issue we bumped into was event handing. VTK's event handling tends to be data light where most events follow this approach 1) event happens 2) we set properties on the interactor such as alt/shift/control key state, mouse position, etc 3) fire the event (with little or no calldata) 4) event handlers query needed properties from the interactor The challenge here is that as more event types are supported, the interactor's state and structure is required to grow to match them. For example with multitouch events, the interactor now has to support multiple mouse positions and pointer indexes. Now add in multi controller VR and we have to also store arrays of world coordinate positions and orientations and what controller the current event corresponds to. Many systems use a different approach where they define an event data structure or class that get passed with the event (or associated with the event). Then whatever is handling the event receives that data structure which contains most of the key properties of the event. Such an event structure can also be used for filtering. For example currently in VTK you can map keyboard events on a widget using the vtkWidgetCallbackMapper method void SetCallbackMethod(unsigned long VTKEvent, int modifiers, char keyCode, int repeatCount, const char* keySym, unsigned long widgetEvent, vtkAbstractWidget *w, CallbackType f); Note that this signature is designed for keyboard events as it contains keyboard event specific parameters. To add a mapping for multitouch, or VR controller events would require more event specific signatures. In contrast if we had a formal vtkEventData structure then the method could use a vtkEventData as a filter and handle many different event types as long as the EventData has an equality operator on it (or maybe a filtering specific equality). Lucas and I have tried this out for VR and it has made event handling reasonable and fairly clean and I would like to get some feedback on the idea/approach/etc. Right now our vtkEventData is included below. It uses the approach of a union of event type structs and what has been fleshed out is targeted at VR but it should be easy to see how keyboard or mouse devices/events could get added as well. Thanks! Ken enum class vtkEventDataDevice { Unknown = -1, HeadMountedDisplay, RightController, LeftController, NumberOfDevices }; const int vtkEventDataNumberOfDevices = static_cast(vtkEventDataDevice::NumberOfDevices); enum class vtkEventDataDeviceInput { Unknown = -1, Trigger, TrackPad, Grip, ApplicationMenu, NumberOfInputs }; const int vtkEventDataNumberOfInputs = static_cast(vtkEventDataDeviceInput::NumberOfInputs); enum class vtkEventDataAction { Unknown = -1, Press, Release, NumberOfActions }; struct vtkEventDataButton3D { vtkEventDataDevice Device; vtkEventDataDeviceInput Input; vtkEventDataAction Action; double WorldPosition[3]; double WorldOrientation[4]; bool operator==(const vtkEventDataButton3D& rh) { return (Device == rh.Device && Input == rh.Input && Action == rh.Action); } void SetWorldPosition(const double p[3]) { WorldPosition[0] = p[0]; WorldPosition[1] = p[1]; WorldPosition[2] = p[2]; } void SetWorldOrientation(const double p[4]) { WorldOrientation[0] = p[0]; WorldOrientation[1] = p[1]; WorldOrientation[2] = p[2]; WorldOrientation[3] = p[3]; } }; struct vtkEventDataMove3D { vtkEventDataDevice Device; double WorldPosition[3]; double WorldOrientation[4]; bool operator==(const vtkEventDataMove3D& rh) { return (Device == rh.Device); } void SetWorldPosition(const double p[3]) { WorldPosition[0] = p[0]; WorldPosition[1] = p[1]; WorldPosition[2] = p[2]; } void SetWorldOrientation(const double p[4]) { WorldOrientation[0] = p[0]; WorldOrientation[1] = p[1]; WorldOrientation[2] = p[2]; WorldOrientation[3] = p[3]; } }; typedef union { vtkEventDataButton3D Button; vtkEventDataMove3D Move; } vtkEventDataUnion; struct vtkEventData { int Type; // see vtkCommand.h vtkEventDataUnion Data; bool operator==(const vtkEventData& rh) { if (Type != rh.Type) { return false; } switch (Type) { case vtkCommand::ButtonEvent3D: return Data.Button == rh.Data.Button; case vtkCommand::MoveEvent3D: return Data.Move == rh.Data.Move; } return false; } bool GetDevice(vtkEventDataDevice &val) { switch (Type) { case vtkCommand::ButtonEvent3D: val = Data.Button.Device; return true; case vtkCommand::MoveEvent3D: val = Data.Move.Device; return true; } return false; } bool GetWorldPosition(double *&pos) { switch (Type) { case vtkCommand::ButtonEvent3D: pos = Data.Button.WorldPosition; return true; case vtkCommand::MoveEvent3D: pos = Data.Move.WorldPosition; return true; } return false; } bool GetWorldOrientation(double *&val) { switch (Type) { case vtkCommand::ButtonEvent3D: val = Data.Button.WorldOrientation; return true; case vtkCommand::MoveEvent3D: val = Data.Move.WorldOrientation; return true; } return false; } }; -- 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 david.gobbi at gmail.com Mon Jul 10 14:59:07 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 10 Jul 2017 12:59:07 -0600 Subject: [vtk-developers] Some Event handling ideas In-Reply-To: References: Message-ID: Hi Ken, Why not use polymorphism here? I use an event hierarchy like so: Event <- InputEvent <- PointEvent, KeyEvent I've never used a union; the code that generates the event knows what type of event object to instantiate, and the observer methods just get a pointer to the event object. Qt does things similarly. - David On Mon, Jul 10, 2017 at 9:15 AM, Ken Martin wrote: > > Lucas and I have been working on VTK's VR support and one issue we bumped > into was event handing. VTK's event handling tends to be data light where > most events follow this approach > > 1) event happens > > 2) we set properties on the interactor such as alt/shift/control key > state, mouse position, etc > > 3) fire the event (with little or no calldata) > > 4) event handlers query needed properties from the interactor > > The challenge here is that as more event types are supported, the > interactor's state and structure is required to grow to match them. For > example with multitouch events, the interactor now has to support multiple > mouse positions and pointer indexes. Now add in multi controller VR and we > have to also store arrays of world coordinate positions and orientations > and what controller the current event corresponds to. > > Many systems use a different approach where they define an event data > structure or class that get passed with the event (or associated with the > event). Then whatever is handling the event receives that data structure > which contains most of the key properties of the event. Such an event > structure can also be used for filtering. For example currently in VTK you > can map keyboard events on a widget using the vtkWidgetCallbackMapper method > > void SetCallbackMethod(unsigned long VTKEvent, int modifiers, char keyCode, > int repeatCount, const char* keySym, > unsigned long widgetEvent, > vtkAbstractWidget *w, CallbackType f); > > Note that this signature is designed for keyboard events as it contains > keyboard event specific parameters. To add a mapping for multitouch, or VR > controller events would require more event specific signatures. In contrast > if we had a formal vtkEventData structure then the method could use a > vtkEventData as a filter and handle many different event types as long as > the EventData has an equality operator on it (or maybe a filtering specific > equality). > > Lucas and I have tried this out for VR and it has made event handling > reasonable and fairly clean and I would like to get some feedback on the > idea/approach/etc. Right now our vtkEventData is included below. It uses > the approach of a union of event type structs and what has been fleshed out > is targeted at VR but it should be easy to see how keyboard or mouse > devices/events could get added as well. > > Thanks! > Ken > > > > enum class vtkEventDataDevice { > Unknown = -1, > HeadMountedDisplay, > RightController, > LeftController, > NumberOfDevices > }; > > const int vtkEventDataNumberOfDevices = > static_cast(vtkEventDataDevice::NumberOfDevices); > > enum class vtkEventDataDeviceInput { > Unknown = -1, > Trigger, > TrackPad, > Grip, > ApplicationMenu, > NumberOfInputs > }; > > const int vtkEventDataNumberOfInputs = > static_cast(vtkEventDataDeviceInput::NumberOfInputs); > > enum class vtkEventDataAction { > Unknown = -1, > Press, > Release, > NumberOfActions > }; > > struct vtkEventDataButton3D > { > vtkEventDataDevice Device; > vtkEventDataDeviceInput Input; > vtkEventDataAction Action; > double WorldPosition[3]; > double WorldOrientation[4]; > > bool operator==(const vtkEventDataButton3D& rh) > { > return (Device == rh.Device && Input == rh.Input && Action == > rh.Action); > } > void SetWorldPosition(const double p[3]) > { > WorldPosition[0] = p[0]; > WorldPosition[1] = p[1]; > WorldPosition[2] = p[2]; > } > void SetWorldOrientation(const double p[4]) > { > WorldOrientation[0] = p[0]; > WorldOrientation[1] = p[1]; > WorldOrientation[2] = p[2]; > WorldOrientation[3] = p[3]; > } > }; > > struct vtkEventDataMove3D > { > vtkEventDataDevice Device; > double WorldPosition[3]; > double WorldOrientation[4]; > > bool operator==(const vtkEventDataMove3D& rh) > { > return (Device == rh.Device); > } > void SetWorldPosition(const double p[3]) > { > WorldPosition[0] = p[0]; > WorldPosition[1] = p[1]; > WorldPosition[2] = p[2]; > } > void SetWorldOrientation(const double p[4]) > { > WorldOrientation[0] = p[0]; > WorldOrientation[1] = p[1]; > WorldOrientation[2] = p[2]; > WorldOrientation[3] = p[3]; > } > }; > > typedef union > { > vtkEventDataButton3D Button; > vtkEventDataMove3D Move; > } vtkEventDataUnion; > > struct vtkEventData > { > int Type; // see vtkCommand.h > vtkEventDataUnion Data; > > bool operator==(const vtkEventData& rh) > { > if (Type != rh.Type) > { > return false; > } > switch (Type) > { > case vtkCommand::ButtonEvent3D: > return Data.Button == rh.Data.Button; > case vtkCommand::MoveEvent3D: > return Data.Move == rh.Data.Move; > } > return false; > } > > bool GetDevice(vtkEventDataDevice &val) > { > switch (Type) > { > case vtkCommand::ButtonEvent3D: > val = Data.Button.Device; > return true; > case vtkCommand::MoveEvent3D: > val = Data.Move.Device; > return true; > } > return false; > } > > bool GetWorldPosition(double *&pos) > { > switch (Type) > { > case vtkCommand::ButtonEvent3D: > pos = Data.Button.WorldPosition; > return true; > case vtkCommand::MoveEvent3D: > pos = Data.Move.WorldPosition; > return true; > } > return false; > } > > bool GetWorldOrientation(double *&val) > { > switch (Type) > { > case vtkCommand::ButtonEvent3D: > val = Data.Button.WorldOrientation; > return true; > case vtkCommand::MoveEvent3D: > val = Data.Move.WorldOrientation; > return true; > } > return false; > } > }; > > > > -- > 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 ken.martin at kitware.com Mon Jul 10 16:00:23 2017 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Jul 2017 16:00:23 -0400 Subject: [vtk-developers] Some Event handling ideas In-Reply-To: References: Message-ID: I like that too :-) So what are your thoughts on down casting to access the properties? e.g. void handleEvent(vtkEventData *event) { if (event->GetType() == Button) { vtkButtonEvent *be = static_cast(event); be->GetButtonId() } or something else? On Mon, Jul 10, 2017 at 2:59 PM, David Gobbi wrote: > Hi Ken, > > Why not use polymorphism here? I use an event hierarchy like so: > > Event <- InputEvent <- PointEvent, KeyEvent > > I've never used a union; the code that generates the event knows what type > of event object to instantiate, and the observer methods just get a pointer > to the event object. Qt does things similarly. > > - David > > > On Mon, Jul 10, 2017 at 9:15 AM, Ken Martin > wrote: > >> >> Lucas and I have been working on VTK's VR support and one issue we bumped >> into was event handing. VTK's event handling tends to be data light where >> most events follow this approach >> >> 1) event happens >> >> 2) we set properties on the interactor such as alt/shift/control key >> state, mouse position, etc >> >> 3) fire the event (with little or no calldata) >> >> 4) event handlers query needed properties from the interactor >> >> The challenge here is that as more event types are supported, the >> interactor's state and structure is required to grow to match them. For >> example with multitouch events, the interactor now has to support multiple >> mouse positions and pointer indexes. Now add in multi controller VR and we >> have to also store arrays of world coordinate positions and orientations >> and what controller the current event corresponds to. >> >> Many systems use a different approach where they define an event data >> structure or class that get passed with the event (or associated with the >> event). Then whatever is handling the event receives that data structure >> which contains most of the key properties of the event. Such an event >> structure can also be used for filtering. For example currently in VTK you >> can map keyboard events on a widget using the vtkWidgetCallbackMapper method >> >> void SetCallbackMethod(unsigned long VTKEvent, int modifiers, char >> keyCode, >> int repeatCount, const char* keySym, >> unsigned long widgetEvent, >> vtkAbstractWidget *w, CallbackType f); >> >> Note that this signature is designed for keyboard events as it contains >> keyboard event specific parameters. To add a mapping for multitouch, or VR >> controller events would require more event specific signatures. In contrast >> if we had a formal vtkEventData structure then the method could use a >> vtkEventData as a filter and handle many different event types as long as >> the EventData has an equality operator on it (or maybe a filtering specific >> equality). >> >> Lucas and I have tried this out for VR and it has made event handling >> reasonable and fairly clean and I would like to get some feedback on the >> idea/approach/etc. Right now our vtkEventData is included below. It uses >> the approach of a union of event type structs and what has been fleshed out >> is targeted at VR but it should be easy to see how keyboard or mouse >> devices/events could get added as well. >> >> Thanks! >> Ken >> >> >> >> enum class vtkEventDataDevice { >> Unknown = -1, >> HeadMountedDisplay, >> RightController, >> LeftController, >> NumberOfDevices >> }; >> >> const int vtkEventDataNumberOfDevices = >> static_cast(vtkEventDataDevice::NumberOfDevices); >> >> enum class vtkEventDataDeviceInput { >> Unknown = -1, >> Trigger, >> TrackPad, >> Grip, >> ApplicationMenu, >> NumberOfInputs >> }; >> >> const int vtkEventDataNumberOfInputs = >> static_cast(vtkEventDataDeviceInput::NumberOfInputs); >> >> enum class vtkEventDataAction { >> Unknown = -1, >> Press, >> Release, >> NumberOfActions >> }; >> >> struct vtkEventDataButton3D >> { >> vtkEventDataDevice Device; >> vtkEventDataDeviceInput Input; >> vtkEventDataAction Action; >> double WorldPosition[3]; >> double WorldOrientation[4]; >> >> bool operator==(const vtkEventDataButton3D& rh) >> { >> return (Device == rh.Device && Input == rh.Input && Action == >> rh.Action); >> } >> void SetWorldPosition(const double p[3]) >> { >> WorldPosition[0] = p[0]; >> WorldPosition[1] = p[1]; >> WorldPosition[2] = p[2]; >> } >> void SetWorldOrientation(const double p[4]) >> { >> WorldOrientation[0] = p[0]; >> WorldOrientation[1] = p[1]; >> WorldOrientation[2] = p[2]; >> WorldOrientation[3] = p[3]; >> } >> }; >> >> struct vtkEventDataMove3D >> { >> vtkEventDataDevice Device; >> double WorldPosition[3]; >> double WorldOrientation[4]; >> >> bool operator==(const vtkEventDataMove3D& rh) >> { >> return (Device == rh.Device); >> } >> void SetWorldPosition(const double p[3]) >> { >> WorldPosition[0] = p[0]; >> WorldPosition[1] = p[1]; >> WorldPosition[2] = p[2]; >> } >> void SetWorldOrientation(const double p[4]) >> { >> WorldOrientation[0] = p[0]; >> WorldOrientation[1] = p[1]; >> WorldOrientation[2] = p[2]; >> WorldOrientation[3] = p[3]; >> } >> }; >> >> typedef union >> { >> vtkEventDataButton3D Button; >> vtkEventDataMove3D Move; >> } vtkEventDataUnion; >> >> struct vtkEventData >> { >> int Type; // see vtkCommand.h >> vtkEventDataUnion Data; >> >> bool operator==(const vtkEventData& rh) >> { >> if (Type != rh.Type) >> { >> return false; >> } >> switch (Type) >> { >> case vtkCommand::ButtonEvent3D: >> return Data.Button == rh.Data.Button; >> case vtkCommand::MoveEvent3D: >> return Data.Move == rh.Data.Move; >> } >> return false; >> } >> >> bool GetDevice(vtkEventDataDevice &val) >> { >> switch (Type) >> { >> case vtkCommand::ButtonEvent3D: >> val = Data.Button.Device; >> return true; >> case vtkCommand::MoveEvent3D: >> val = Data.Move.Device; >> return true; >> } >> return false; >> } >> >> bool GetWorldPosition(double *&pos) >> { >> switch (Type) >> { >> case vtkCommand::ButtonEvent3D: >> pos = Data.Button.WorldPosition; >> return true; >> case vtkCommand::MoveEvent3D: >> pos = Data.Move.WorldPosition; >> return true; >> } >> return false; >> } >> >> bool GetWorldOrientation(double *&val) >> { >> switch (Type) >> { >> case vtkCommand::ButtonEvent3D: >> val = Data.Button.WorldOrientation; >> return true; >> case vtkCommand::MoveEvent3D: >> val = Data.Move.WorldOrientation; >> return true; >> } >> return false; >> } >> }; >> >> >> >> -- >> 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. >> > > -- 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 david.gobbi at gmail.com Mon Jul 10 17:23:53 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 10 Jul 2017 15:23:53 -0600 Subject: [vtk-developers] Some Event handling ideas In-Reply-To: References: Message-ID: Something else. Ideally handleEvent() should be a generic dispatcher that simply forwards the events to other methods that handle the specific event types. E.g. handleEvent(vtkEventData *) would forward button events to handleButtonEvent(vtkButtonEventData *) So the question is, how to do this dispatching generically without using an "if" for each event type? I use a method like the following to add callbacks: template void EventDispatcher::Bind(int type, T* observer, void (T::*callback)(E *e)); Each event class E has a static member E::TypeBase that can be used to check that class "E" is allowed to handle "type". The job of the this Bind() method is to build a binding table, which is basically a map of (type, callback) pairs. The trick here is that the "callback" stored in the table is polymorphic: class EventCallback { public: virtual void operator()(Event *event) const = 0; }; And the Bind() creates subclasses on the fly, thanks to the magic of templates. The operator() method is responsible for performing the downcast: template class EventCallbackTE : public EventCallback { public: EventCallbackTE(T *object, void (T::*method)(E *event)) : Object(object), Method(method) {} void operator()(Event *event) const override { (this->Object->*(this->Method))(static_cast(event)); } private: T *Object; void (T::*Method)(E *event); }; So, basically, the "if" statements are replaced by a lookup table that can grow as needed. At least some of the ideas are from the book "Modern C++ Design" (unfortunately I don't have my own copy, so I can't locate pages or chapters right now). My own implementation adds things like weak pointers and dispatching based on more than just the event type, e.g. dispatching also considers which button is held down, what modifiers are held down, and other relevant state. - David On Mon, Jul 10, 2017 at 2:00 PM, Ken Martin wrote: > I like that too :-) So what are your thoughts on down casting to access > the properties? e.g. > > void handleEvent(vtkEventData *event) > { > if (event->GetType() == Button) > { > vtkButtonEvent *be = static_cast(event); > be->GetButtonId() > } > > or something else? > > > > > On Mon, Jul 10, 2017 at 2:59 PM, David Gobbi > wrote: > >> Hi Ken, >> >> Why not use polymorphism here? I use an event hierarchy like so: >> >> Event <- InputEvent <- PointEvent, KeyEvent >> >> I've never used a union; the code that generates the event knows what >> type of event object to instantiate, and the observer methods just get a >> pointer to the event object. Qt does things similarly. >> >> - David >> >> >> On Mon, Jul 10, 2017 at 9:15 AM, Ken Martin >> wrote: >> >>> >>> Lucas and I have been working on VTK's VR support and one issue we >>> bumped into was event handing. VTK's event handling tends to be data light >>> where most events follow this approach >>> >>> 1) event happens >>> >>> 2) we set properties on the interactor such as alt/shift/control key >>> state, mouse position, etc >>> >>> 3) fire the event (with little or no calldata) >>> >>> 4) event handlers query needed properties from the interactor >>> >>> The challenge here is that as more event types are supported, the >>> interactor's state and structure is required to grow to match them. For >>> example with multitouch events, the interactor now has to support multiple >>> mouse positions and pointer indexes. Now add in multi controller VR and we >>> have to also store arrays of world coordinate positions and orientations >>> and what controller the current event corresponds to. >>> >>> Many systems use a different approach where they define an event data >>> structure or class that get passed with the event (or associated with the >>> event). Then whatever is handling the event receives that data structure >>> which contains most of the key properties of the event. Such an event >>> structure can also be used for filtering. For example currently in VTK you >>> can map keyboard events on a widget using the vtkWidgetCallbackMapper method >>> >>> void SetCallbackMethod(unsigned long VTKEvent, int modifiers, char >>> keyCode, >>> int repeatCount, const char* keySym, >>> unsigned long widgetEvent, >>> vtkAbstractWidget *w, CallbackType f); >>> >>> Note that this signature is designed for keyboard events as it contains >>> keyboard event specific parameters. To add a mapping for multitouch, or VR >>> controller events would require more event specific signatures. In contrast >>> if we had a formal vtkEventData structure then the method could use a >>> vtkEventData as a filter and handle many different event types as long as >>> the EventData has an equality operator on it (or maybe a filtering specific >>> equality). >>> >>> Lucas and I have tried this out for VR and it has made event handling >>> reasonable and fairly clean and I would like to get some feedback on the >>> idea/approach/etc. Right now our vtkEventData is included below. It uses >>> the approach of a union of event type structs and what has been fleshed out >>> is targeted at VR but it should be easy to see how keyboard or mouse >>> devices/events could get added as well. >>> >>> Thanks! >>> Ken >>> >>> >>> >>> enum class vtkEventDataDevice { >>> Unknown = -1, >>> HeadMountedDisplay, >>> RightController, >>> LeftController, >>> NumberOfDevices >>> }; >>> >>> const int vtkEventDataNumberOfDevices = >>> static_cast(vtkEventDataDevice::NumberOfDevices); >>> >>> enum class vtkEventDataDeviceInput { >>> Unknown = -1, >>> Trigger, >>> TrackPad, >>> Grip, >>> ApplicationMenu, >>> NumberOfInputs >>> }; >>> >>> const int vtkEventDataNumberOfInputs = >>> static_cast(vtkEventDataDeviceInput::NumberOfInputs); >>> >>> enum class vtkEventDataAction { >>> Unknown = -1, >>> Press, >>> Release, >>> NumberOfActions >>> }; >>> >>> struct vtkEventDataButton3D >>> { >>> vtkEventDataDevice Device; >>> vtkEventDataDeviceInput Input; >>> vtkEventDataAction Action; >>> double WorldPosition[3]; >>> double WorldOrientation[4]; >>> >>> bool operator==(const vtkEventDataButton3D& rh) >>> { >>> return (Device == rh.Device && Input == rh.Input && Action == >>> rh.Action); >>> } >>> void SetWorldPosition(const double p[3]) >>> { >>> WorldPosition[0] = p[0]; >>> WorldPosition[1] = p[1]; >>> WorldPosition[2] = p[2]; >>> } >>> void SetWorldOrientation(const double p[4]) >>> { >>> WorldOrientation[0] = p[0]; >>> WorldOrientation[1] = p[1]; >>> WorldOrientation[2] = p[2]; >>> WorldOrientation[3] = p[3]; >>> } >>> }; >>> >>> struct vtkEventDataMove3D >>> { >>> vtkEventDataDevice Device; >>> double WorldPosition[3]; >>> double WorldOrientation[4]; >>> >>> bool operator==(const vtkEventDataMove3D& rh) >>> { >>> return (Device == rh.Device); >>> } >>> void SetWorldPosition(const double p[3]) >>> { >>> WorldPosition[0] = p[0]; >>> WorldPosition[1] = p[1]; >>> WorldPosition[2] = p[2]; >>> } >>> void SetWorldOrientation(const double p[4]) >>> { >>> WorldOrientation[0] = p[0]; >>> WorldOrientation[1] = p[1]; >>> WorldOrientation[2] = p[2]; >>> WorldOrientation[3] = p[3]; >>> } >>> }; >>> >>> typedef union >>> { >>> vtkEventDataButton3D Button; >>> vtkEventDataMove3D Move; >>> } vtkEventDataUnion; >>> >>> struct vtkEventData >>> { >>> int Type; // see vtkCommand.h >>> vtkEventDataUnion Data; >>> >>> bool operator==(const vtkEventData& rh) >>> { >>> if (Type != rh.Type) >>> { >>> return false; >>> } >>> switch (Type) >>> { >>> case vtkCommand::ButtonEvent3D: >>> return Data.Button == rh.Data.Button; >>> case vtkCommand::MoveEvent3D: >>> return Data.Move == rh.Data.Move; >>> } >>> return false; >>> } >>> >>> bool GetDevice(vtkEventDataDevice &val) >>> { >>> switch (Type) >>> { >>> case vtkCommand::ButtonEvent3D: >>> val = Data.Button.Device; >>> return true; >>> case vtkCommand::MoveEvent3D: >>> val = Data.Move.Device; >>> return true; >>> } >>> return false; >>> } >>> >>> bool GetWorldPosition(double *&pos) >>> { >>> switch (Type) >>> { >>> case vtkCommand::ButtonEvent3D: >>> pos = Data.Button.WorldPosition; >>> return true; >>> case vtkCommand::MoveEvent3D: >>> pos = Data.Move.WorldPosition; >>> return true; >>> } >>> return false; >>> } >>> >>> bool GetWorldOrientation(double *&val) >>> { >>> switch (Type) >>> { >>> case vtkCommand::ButtonEvent3D: >>> val = Data.Button.WorldOrientation; >>> return true; >>> case vtkCommand::MoveEvent3D: >>> val = Data.Move.WorldOrientation; >>> return true; >>> } >>> return false; >>> } >>> }; >>> >>> >>> >>> -- >>> 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. >>> >> >> > > > -- > 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 prabhu at aero.iitb.ac.in Wed Jul 12 00:22:38 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Tue, 11 Jul 2017 23:22:38 -0500 Subject: [vtk-developers] VTK Python wheels? Message-ID: Hi folks, I was wondering if there is any support for easily building Python wheels of VTK. Three years ago David Gobbi had posted this: http://public.kitware.com/pipermail/vtkusers/2014-August/084731.html I was wondering if there has been any progress on this front as this would be very useful to have. Are any of you folks going to be at SciPy 2017? If you are maybe we can work on this together and make it happen? Thanks! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Wed Jul 12 08:15:58 2017 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 12 Jul 2017 08:15:58 -0400 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: Hi Prabhu, Matt, Fran?ois, Marcus ans I are at SciPy. We would be happy to meet you. Re: wheels Now we have wheels for ITK, we should be able to apply the same approach for ITK. See https://blog.kitware.com/itk-python-wheels/ and https://github.com/InsightSoftwareConsortium/ITKPythonPackage Jc On Jul 11, 2017 11:28 PM, "Prabhu Ramachandran" wrote: > Hi folks, > > I was wondering if there is any support for easily building Python wheels > of VTK. Three years ago David Gobbi had posted this: > http://public.kitware.com/pipermail/vtkusers/2014-August/084731.html > > I was wondering if there has been any progress on this front as this would > be very useful to have. > > Are any of you folks going to be at SciPy 2017? If you are maybe we can > work on this together and make it happen? > > > Thanks! > > cheers, > > Prabhu > > _______________________________________________ > 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 prabhu at aero.iitb.ac.in Wed Jul 12 12:04:41 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 12 Jul 2017 11:04:41 -0500 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On 7/12/17 7:15 AM, Jean-Christophe Fillion-Robin wrote: > Hi Prabhu, > > Matt, Fran?ois, Marcus ans I are at SciPy. > > We would be happy to meet you. > > Re: wheels > > Now we have wheels for ITK, we should be able to apply the same approach for > ITK. See https://blog.kitware.com/itk-python-wheels/ and > https://github.com/InsightSoftwareConsortium/ITKPythonPackage That sounds awesome! Will catch up with you. Stefan van der Walt and I will come by and meet with you sometime. Thank you! cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Jul 12 12:26:51 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 12 Jul 2017 17:26:51 +0100 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On Wed, Jul 12, 2017 at 5:04 PM, Prabhu Ramachandran wrote: > On 7/12/17 7:15 AM, Jean-Christophe Fillion-Robin wrote: > > Hi Prabhu, > > Matt, Fran?ois, Marcus ans I are at SciPy. > > We would be happy to meet you. > > Re: wheels > > Now we have wheels for ITK, we should be able to apply the same approach for > ITK. See https://blog.kitware.com/itk-python-wheels/ and > https://github.com/InsightSoftwareConsortium/ITKPythonPackage > > > That sounds awesome! Will catch up with you. Stefan van der Walt and I > will come by and meet with you sometime. Thank you! If I can help - let me know - I'm in the UK, but I will be online, Cheers, Matthew From matt.mccormick at kitware.com Wed Jul 12 15:00:05 2017 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 12 Jul 2017 15:00:05 -0400 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On Wed, Jul 12, 2017 at 12:26 PM, Matthew Brett wrote: > On Wed, Jul 12, 2017 at 5:04 PM, Prabhu Ramachandran > wrote: >> On 7/12/17 7:15 AM, Jean-Christophe Fillion-Robin wrote: >> >> Hi Prabhu, >> >> Matt, Fran?ois, Marcus ans I are at SciPy. >> >> We would be happy to meet you. >> >> Re: wheels >> >> Now we have wheels for ITK, we should be able to apply the same approach for >> ITK. See https://blog.kitware.com/itk-python-wheels/ and >> https://github.com/InsightSoftwareConsortium/ITKPythonPackage >> >> >> That sounds awesome! Will catch up with you. Stefan van der Walt and I >> will come by and meet with you sometime. Thank you! > > If I can help - let me know - I'm in the UK, but I will be online, Excellent! Here is a publically editable Google Doc: https://docs.google.com/document/d/1WFN_1oqyxDn0crCKlSs7nn5qQ-Ppqexv8tlMN2NG5sk/edit?usp=sharing We could meet on Friday at the evening BoF session, 5:30 PM Central Time in the Grand Ballroom. Matthew and others could join via video chat. Here is a link: https://meet.google.com/cry-ucqr-jer Thanks, Matt From david.gobbi at gmail.com Fri Jul 14 09:51:25 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 14 Jul 2017 07:51:25 -0600 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: I'll be able to join remotely. - David On Wed, Jul 12, 2017 at 1:00 PM, Matt McCormick wrote: > On Wed, Jul 12, 2017 at 12:26 PM, Matthew Brett > wrote: > > On Wed, Jul 12, 2017 at 5:04 PM, Prabhu Ramachandran > > wrote: > >> On 7/12/17 7:15 AM, Jean-Christophe Fillion-Robin wrote: > >> > >> Hi Prabhu, > >> > >> Matt, Fran?ois, Marcus ans I are at SciPy. > >> > >> We would be happy to meet you. > >> > >> Re: wheels > >> > >> Now we have wheels for ITK, we should be able to apply the same > approach for > >> ITK. See https://blog.kitware.com/itk-python-wheels/ and > >> https://github.com/InsightSoftwareConsortium/ITKPythonPackage > >> > >> > >> That sounds awesome! Will catch up with you. Stefan van der Walt and I > >> will come by and meet with you sometime. Thank you! > > > > If I can help - let me know - I'm in the UK, but I will be online, > > > Excellent! > > Here is a publically editable Google Doc: > > https://docs.google.com/document/d/1WFN_1oqyxDn0crCKlSs7nn5qQ- > Ppqexv8tlMN2NG5sk/edit?usp=sharing > > We could meet on Friday at the evening BoF session, 5:30 PM Central > Time in the Grand Ballroom. Matthew and others could join via video > chat. Here is a link: > > https://meet.google.com/cry-ucqr-jer > > Thanks, > Matt > _______________________________________________ > 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 prabhu at aero.iitb.ac.in Sat Jul 15 01:37:35 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sat, 15 Jul 2017 00:37:35 -0500 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On 7/14/17 8:51 AM, David Gobbi wrote: > I'll be able to join remotely. > Thank you for organizing this, Matt. My sincere apologies for missing this meeting! I had to lead a BOF on SciPy 2018 and that ended up going on until 7:15 and had another appointment at 7:30. I will be at the sprints all day tomorrow though so would love to chat with Matt and JC. cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Sat Jul 15 09:31:34 2017 From: matt.mccormick at kitware.com (Matt McCormick) Date: Sat, 15 Jul 2017 09:31:34 -0400 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On Sat, Jul 15, 2017 at 1:37 AM, Prabhu Ramachandran wrote: > On 7/14/17 8:51 AM, David Gobbi wrote: > > I'll be able to join remotely. > > > Thank you for organizing this, Matt. My sincere apologies for missing this > meeting! I had to lead a BOF on SciPy 2018 and that ended up going on until > 7:15 and had another appointment at 7:30. I will be at the sprints all day > tomorrow though so would love to chat with Matt and JC. Thank you for organizing the conference, Prabhu, and helping to facilitate SciPy 2018 :-). Despite inconvenient timing, David Gobbi, Dave DeMarle, and Matthew Brett were all able to join remotely. The discussion was helpful and productive. A summary can be found here: https://docs.google.com/document/d/1WFN_1oqyxDn0crCKlSs7nn5qQ-Ppqexv8tlMN2NG5sk/edit# Unfortunately, I am flying back this morning, but Jc indicated he was going to hack on it during the sprints. Thanks, Matt From ken.martin at kitware.com Mon Jul 17 10:25:23 2017 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 17 Jul 2017 10:25:23 -0400 Subject: [vtk-developers] A few nightly warnings and test failures introduced last Thursday Message-ID: If you have committed to VTK between Thursday and now please take a look. The expected nightlies have a some warnings and test failures introduced since last Thursday. https://open.cdash.org/index.php?project=VTK -- 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 dave.demarle at kitware.com Mon Jul 17 10:31:54 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 17 Jul 2017 10:31:54 -0400 Subject: [vtk-developers] A few nightly warnings and test failures introduced last Thursday In-Reply-To: References: Message-ID: Looks like ArrayCalculator and MultiBlockPlot3DReader are responsible for the bulk of the warnings. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Jul 17, 2017 at 10:25 AM, Ken Martin wrote: > > If you have committed to VTK between Thursday and now please take a look. > The expected nightlies have a some warnings and test failures introduced > since last Thursday. > > https://open.cdash.org/index.php?project=VTK > > > -- > 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 shawn.waldon at kitware.com Mon Jul 17 10:33:25 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 17 Jul 2017 10:33:25 -0400 Subject: [vtk-developers] A few nightly warnings and test failures introduced last Thursday In-Reply-To: References: Message-ID: I've already merged a branch that fixes the inconsistent override warnings in vtkArrayCalculator.h after Cory pointed them out to me this morning. My branch changed vtkArrayCalculator to be a subclass of vtkPassInputTypeAlgorithm so that it can be applied to vtkTables and vtkGraphs (for molecules). So I don't think it is related to the other failures. Shawn On Mon, Jul 17, 2017 at 10:25 AM, Ken Martin wrote: > > If you have committed to VTK between Thursday and now please take a look. > The expected nightlies have a some warnings and test failures introduced > since last Thursday. > > https://open.cdash.org/index.php?project=VTK > > > -- > 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 DLRdave at aol.com Mon Jul 17 11:17:12 2017 From: DLRdave at aol.com (David Cole) Date: Mon, 17 Jul 2017 11:17:12 -0400 Subject: [vtk-developers] A few nightly warnings and test failures introduced last Thursday In-Reply-To: References: Message-ID: These Windows/VS2013 warnings are also related to vtkArrayCalculator: https://open.cdash.org/viewBuildError.php?type=1&buildid=4980673 On Mon, Jul 17, 2017 at 10:33 AM, Shawn Waldon wrote: > I've already merged a branch that fixes the inconsistent override warnings > in vtkArrayCalculator.h after Cory pointed them out to me this morning. My > branch changed vtkArrayCalculator to be a subclass of > vtkPassInputTypeAlgorithm so that it can be applied to vtkTables and > vtkGraphs (for molecules). So I don't think it is related to the other > failures. > > Shawn > > On Mon, Jul 17, 2017 at 10:25 AM, Ken Martin wrote: >> >> >> If you have committed to VTK between Thursday and now please take a look. >> The expected nightlies have a some warnings and test failures introduced >> since last Thursday. >> >> https://open.cdash.org/index.php?project=VTK >> >> >> -- >> 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 >> >> > > > _______________________________________________ > 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 shawn.waldon at kitware.com Mon Jul 17 11:42:07 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 17 Jul 2017 11:42:07 -0400 Subject: [vtk-developers] A few nightly warnings and test failures introduced last Thursday In-Reply-To: References: Message-ID: Thanks for pointing those out David. I thought I'd gotten all those when I compiled with VTK_LEGACY_REMOVE, but it missed deprecated functions called from other deprecated functions. That is what is happening there. The vtkArrayCalculator::SetAttributeModeToXXX() functions are calling vtkArrayCalculator::SetAttributeMode(), which I deprecated in favor of vtkArrayCalculator::SetAttributeType() which has its own variants (vtkArrayCalculator::SetAttributeTypeToXXX(). How do we handle deprecated functions called from deprecated functions? Shawn For the curious: the difference is that the old deprecated functions use custom constants declared in vtkArrayCalculator.h and the new functions take vtkDataObject::AttributeTypes constants (plus one custom constant for "default" (-1)) This let me refactor the calculator to use the vtkDataObject::GetAttributes()/GetNumberOfElements() API instead of down-casting each data type to get its data/data length. On Mon, Jul 17, 2017 at 11:17 AM, David Cole wrote: > These Windows/VS2013 warnings are also related to vtkArrayCalculator: > > https://open.cdash.org/viewBuildError.php?type=1&buildid=4980673 > > > On Mon, Jul 17, 2017 at 10:33 AM, Shawn Waldon > wrote: > > I've already merged a branch that fixes the inconsistent override > warnings > > in vtkArrayCalculator.h after Cory pointed them out to me this morning. > My > > branch changed vtkArrayCalculator to be a subclass of > > vtkPassInputTypeAlgorithm so that it can be applied to vtkTables and > > vtkGraphs (for molecules). So I don't think it is related to the other > > failures. > > > > Shawn > > > > On Mon, Jul 17, 2017 at 10:25 AM, Ken Martin > wrote: > >> > >> > >> If you have committed to VTK between Thursday and now please take a > look. > >> The expected nightlies have a some warnings and test failures introduced > >> since last Thursday. > >> > >> https://open.cdash.org/index.php?project=VTK > >> > >> > >> -- > >> 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 > >> > >> > > > > > > _______________________________________________ > > 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 Jul 19 11:58:54 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 19 Jul 2017 11:58:54 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering Message-ID: We work on Tomviz, and one of its primary goals is to work with volumes in an intuitive way making heavy use of the volume rendering code. It also needs to interact with several libraries that operate on volumes, ideally using our Python NumPy integration and zero copy approaches to process data in place. One of the challenges has been preserving the Fortran ordering of the single component scalar data. We will also be adding support for multi-component data soon. What are people's thoughts on potentially adding some API to vtkImageData to mark it as C ordered? That would largely just geometrically transform how the volume is rendered, but ensure a contour is correctly extracted and aligned. It would then let us use the default C ordering, simplifying our application code, and the current order could remain the default. I would suggest considering the same for the vtk.js work too. It is feasible to make these changes in the application logic too, but this feels like a fairly common problem that others would also hit from time to time. Maybe I am missing more corner cases, so I am posting this in hopes of feedback before writing any code (or asking someone else to). -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Jul 19 12:35:42 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 19 Jul 2017 12:35:42 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: Hi Marcus, > We work on Tomviz, and one of its primary goals is to work with volumes in an intuitive way making heavy use of the volume rendering code. It also needs to interact with several libraries that operate on volumes, ideally using our Python NumPy integration and zero copy approaches to process data in place. > > One of the challenges has been preserving the Fortran ordering of the single component scalar data. We will also be adding support for multi-component data soon. What are people's thoughts on potentially adding some API to vtkImageData to mark it as C ordered? > > That would largely just geometrically transform how the volume is rendered, but ensure a contour is correctly extracted and aligned. It would then let us use the default C ordering, simplifying our application code, and the current order could remain the default. I would suggest considering the same for the vtk.js work too. > > It is feasible to make these changes in the application logic too, but this feels like a fairly common problem that others would also hit from time to time. Maybe I am missing more corner cases, so I am posting this in hopes of feedback before writing any code (or asking someone else to). I think a common problem would be that many image filters choose a particular order to process data because access is much faster in one plane than others. Are you thinking that those filters would also adjust their algorithms/traverse order to accommodate FORTRAN ordering when it is present on the input (and presumably output)? David From marcus.hanwell at kitware.com Wed Jul 19 12:55:52 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 19 Jul 2017 12:55:52 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 12:35 PM, David Thompson wrote: > Hi Marcus, > > > We work on Tomviz, and one of its primary goals is to work with volumes > in an intuitive way making heavy use of the volume rendering code. It also > needs to interact with several libraries that operate on volumes, ideally > using our Python NumPy integration and zero copy approaches to process data > in place. > > > > One of the challenges has been preserving the Fortran ordering of the > single component scalar data. We will also be adding support for > multi-component data soon. What are people's thoughts on potentially adding > some API to vtkImageData to mark it as C ordered? > > > > That would largely just geometrically transform how the volume is > rendered, but ensure a contour is correctly extracted and aligned. It would > then let us use the default C ordering, simplifying our application code, > and the current order could remain the default. I would suggest considering > the same for the vtk.js work too. > > > > It is feasible to make these changes in the application logic too, but > this feels like a fairly common problem that others would also hit from > time to time. Maybe I am missing more corner cases, so I am posting this in > hopes of feedback before writing any code (or asking someone else to). > > I think a common problem would be that many image filters choose a > particular order to process data because access is much faster in one plane > than others. Are you thinking that those filters would also adjust their > algorithms/traverse order to accommodate FORTRAN ordering when it is > present on the input (and presumably output)? My ideal scenario is to mark a vtkImageData as C ordered (default it to Fortran/what it is now). It may be easier to manage more of that at an application level though too, I was more thinking out loud and wondering if other people had explored this or solved it in other ways. I get the historical perspective, and possibly that what I want may not be needed by the wider VTK community. I would like to leave as much of VTK alone as possible, and so let most VTK stuff continue as it always has, but be able to pass a vtkImageData to a 3D NumPy array as C ordered, operate on it, and then render the result. We currently go to great pains to ensure if comes back as Fortran ordered, and there is no way to set a default. I also find that most stuff assumes the C ordering, so it can require some reshuffling of the data which can involve large volumes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jul 19 13:11:27 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 19 Jul 2017 11:11:27 -0600 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Jul 19, 2017 at 12:35 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Marcus, >> >> > We work on Tomviz, and one of its primary goals is to work with volumes >> in an intuitive way making heavy use of the volume rendering code. It also >> needs to interact with several libraries that operate on volumes, ideally >> using our Python NumPy integration and zero copy approaches to process data >> in place. >> > >> > One of the challenges has been preserving the Fortran ordering of the >> single component scalar data. We will also be adding support for >> multi-component data soon. What are people's thoughts on potentially adding >> some API to vtkImageData to mark it as C ordered? >> > >> > That would largely just geometrically transform how the volume is >> rendered, but ensure a contour is correctly extracted and aligned. It would >> then let us use the default C ordering, simplifying our application code, >> and the current order could remain the default. I would suggest considering >> the same for the vtk.js work too. >> > >> > It is feasible to make these changes in the application logic too, but >> this feels like a fairly common problem that others would also hit from >> time to time. Maybe I am missing more corner cases, so I am posting this in >> hopes of feedback before writing any code (or asking someone else to). >> >> I think a common problem would be that many image filters choose a >> particular order to process data because access is much faster in one plane >> than others. Are you thinking that those filters would also adjust their >> algorithms/traverse order to accommodate FORTRAN ordering when it is >> present on the input (and presumably output)? > > > My ideal scenario is to mark a vtkImageData as C ordered (default it to > Fortran/what it is now). It may be easier to manage more of that at an > application level though too, I was more thinking out loud and wondering if > other people had explored this or solved it in other ways. I get the > historical perspective, and possibly that what I want may not be needed by > the wider VTK community. > > I would like to leave as much of VTK alone as possible, and so let most > VTK stuff continue as it always has, but be able to pass a vtkImageData to > a 3D NumPy array as C ordered, operate on it, and then render the result. > We currently go to great pains to ensure if comes back as Fortran ordered, > and there is no way to set a default. I also find that most stuff assumes > the C ordering, so it can require some reshuffling of the data which can > involve large volumes. > It's already possible to add extra flags to any VTK data set, without making any changes to VTK itself. The simplest way is to add an array to the vtkFieldData of the data set. You could add a field data array called "ImageOrdering" that would hold the flag. Another way (a little trickier) is to add your own information key. For example, for my VTK DICOM pipelines I've defined a key called PATIENT_MATRIX that stores a 4x4 matrix to define the image orientation. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Wed Jul 19 13:28:19 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 19 Jul 2017 13:28:19 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: Couldn't you do things in the same way that the VTK SOA zero-copy array was done? That way it's transparent to whatever is using the data array how the memory is stored. Also, on a side note I'm not a big fan of calling these C vs. Fortran ordering as it's more how we traverse the data most efficiently. It looks like your most efficient way would be to go through Z fastest, then Y and finally X (opposite for current vtkImageData arrays). How about something like ZYX vs. XYZ ordering for identifying the difference? On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi wrote: > On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> On Wed, Jul 19, 2017 at 12:35 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Marcus, >>> >>> > We work on Tomviz, and one of its primary goals is to work with >>> volumes in an intuitive way making heavy use of the volume rendering code. >>> It also needs to interact with several libraries that operate on volumes, >>> ideally using our Python NumPy integration and zero copy approaches to >>> process data in place. >>> > >>> > One of the challenges has been preserving the Fortran ordering of the >>> single component scalar data. We will also be adding support for >>> multi-component data soon. What are people's thoughts on potentially adding >>> some API to vtkImageData to mark it as C ordered? >>> > >>> > That would largely just geometrically transform how the volume is >>> rendered, but ensure a contour is correctly extracted and aligned. It would >>> then let us use the default C ordering, simplifying our application code, >>> and the current order could remain the default. I would suggest considering >>> the same for the vtk.js work too. >>> > >>> > It is feasible to make these changes in the application logic too, but >>> this feels like a fairly common problem that others would also hit from >>> time to time. Maybe I am missing more corner cases, so I am posting this in >>> hopes of feedback before writing any code (or asking someone else to). >>> >>> I think a common problem would be that many image filters choose a >>> particular order to process data because access is much faster in one plane >>> than others. Are you thinking that those filters would also adjust their >>> algorithms/traverse order to accommodate FORTRAN ordering when it is >>> present on the input (and presumably output)? >> >> >> My ideal scenario is to mark a vtkImageData as C ordered (default it to >> Fortran/what it is now). It may be easier to manage more of that at an >> application level though too, I was more thinking out loud and wondering if >> other people had explored this or solved it in other ways. I get the >> historical perspective, and possibly that what I want may not be needed by >> the wider VTK community. >> >> I would like to leave as much of VTK alone as possible, and so let most >> VTK stuff continue as it always has, but be able to pass a vtkImageData to >> a 3D NumPy array as C ordered, operate on it, and then render the result. >> We currently go to great pains to ensure if comes back as Fortran ordered, >> and there is no way to set a default. I also find that most stuff assumes >> the C ordering, so it can require some reshuffling of the data which can >> involve large volumes. >> > > It's already possible to add extra flags to any VTK data set, without > making any changes to VTK itself. > > The simplest way is to add an array to the vtkFieldData of the data set. > You could add a field data array called "ImageOrdering" that would hold the > flag. > > Another way (a little trickier) is to add your own information key. For > example, for my VTK DICOM pipelines I've defined a key > called PATIENT_MATRIX that stores a 4x4 matrix to define the image > orientation. > > - David > > > > > > > _______________________________________________ > 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 Jul 19 13:34:16 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 19 Jul 2017 13:34:16 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi wrote: > On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> On Wed, Jul 19, 2017 at 12:35 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Marcus, >>> >>> > We work on Tomviz, and one of its primary goals is to work with >>> volumes in an intuitive way making heavy use of the volume rendering code. >>> It also needs to interact with several libraries that operate on volumes, >>> ideally using our Python NumPy integration and zero copy approaches to >>> process data in place. >>> > >>> > One of the challenges has been preserving the Fortran ordering of the >>> single component scalar data. We will also be adding support for >>> multi-component data soon. What are people's thoughts on potentially adding >>> some API to vtkImageData to mark it as C ordered? >>> > >>> > That would largely just geometrically transform how the volume is >>> rendered, but ensure a contour is correctly extracted and aligned. It would >>> then let us use the default C ordering, simplifying our application code, >>> and the current order could remain the default. I would suggest considering >>> the same for the vtk.js work too. >>> > >>> > It is feasible to make these changes in the application logic too, but >>> this feels like a fairly common problem that others would also hit from >>> time to time. Maybe I am missing more corner cases, so I am posting this in >>> hopes of feedback before writing any code (or asking someone else to). >>> >>> I think a common problem would be that many image filters choose a >>> particular order to process data because access is much faster in one plane >>> than others. Are you thinking that those filters would also adjust their >>> algorithms/traverse order to accommodate FORTRAN ordering when it is >>> present on the input (and presumably output)? >> >> >> My ideal scenario is to mark a vtkImageData as C ordered (default it to >> Fortran/what it is now). It may be easier to manage more of that at an >> application level though too, I was more thinking out loud and wondering if >> other people had explored this or solved it in other ways. I get the >> historical perspective, and possibly that what I want may not be needed by >> the wider VTK community. >> >> I would like to leave as much of VTK alone as possible, and so let most >> VTK stuff continue as it always has, but be able to pass a vtkImageData to >> a 3D NumPy array as C ordered, operate on it, and then render the result. >> We currently go to great pains to ensure if comes back as Fortran ordered, >> and there is no way to set a default. I also find that most stuff assumes >> the C ordering, so it can require some reshuffling of the data which can >> involve large volumes. >> > > It's already possible to add extra flags to any VTK data set, without > making any changes to VTK itself. > > The simplest way is to add an array to the vtkFieldData of the data set. > You could add a field data array called "ImageOrdering" that would hold the > flag. > > Another way (a little trickier) is to add your own information key. For > example, for my VTK DICOM pipelines I've defined a key > called PATIENT_MATRIX that stores a 4x4 matrix to define the image > orientation. > Totally, I knew about that, but VTK wouldn't particularly use that information in rendering, but we could then use it at an application level. Thanks for the pointers on how you are using it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Jul 19 13:38:39 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 19 Jul 2017 13:38:39 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Wed, Jul 19, 2017 at 1:28 PM, Andy Bauer wrote: > Couldn't you do things in the same way that the VTK SOA zero-copy array > was done? That way it's transparent to whatever is using the data array how > the memory is stored. > That felt like it would be way more invasive, and possibly not worth it. We can just keep doing what we are doing too. > > Also, on a side note I'm not a big fan of calling these C vs. Fortran > ordering as it's more how we traverse the data most efficiently. It looks > like your most efficient way would be to go through Z fastest, then Y and > finally X (opposite for current vtkImageData arrays). How about something > like ZYX vs. XYZ ordering for identifying the difference? > It is a commonly used term, and works well when searching. It is the terminology used by the Python community, Eigen, VisIt even, and so I would say it is reasonable. I am mainly looking at a mismatch between different toolkits, but I would say using the same terminology as most other communities seems reasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jul 19 14:10:51 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 19 Jul 2017 12:10:51 -0600 Subject: [vtk-developers] Kits and Python wrapping Message-ID: Hi All, I'm trying to get a better understanding of how the VTK_ENABLE_KITS build works, but when I tried the build myself, I saw link errors. This is with yesterday's master (4c17357). == VTK_ENABLE_KITS:BOOL=ON VTK_WRAP_PYTHON:BOOL=ON make vtkWrapping Undefined symbols for architecture x86_64: "_PyBytes_AsString", referenced from: vtkPythonAlgorithm::PrintSelf etc. == In order to make it compile, I had to explicitly enable the vtkPythonInterpreter module: == Module_vtkPythonInterpreter:BOOL=ON VTK_ENABLE_KITS:BOOL=ON VTK_WRAP_PYTHON:BOOL=ON make vtkWrapping success! == Is there any reason why vtkPythonInterpreter must be enabled for the build to work? Also, I'm wondering about the name "vtkWrapping" for the kit. It seems that this kit isn't actually for "Wrapping" but rather is meant to include Python-related modules like vtkFiltersPython. Maybe the kit should be called something like "vtkPython" or "vtkPythonSupport"? Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.smolens at kitware.com Wed Jul 19 14:39:49 2017 From: max.smolens at kitware.com (Max Smolens) Date: Wed, 19 Jul 2017 14:39:49 -0400 Subject: [vtk-developers] Kits and Python wrapping In-Reply-To: References: Message-ID: Hi David, I also recently ran into a link error with VTK_ENABLE_KITS and VTK_WRAP_PYTHON enabled. I have an open merge request with a possible solution: https://gitlab.kitware.com/vtk/vtk/merge_requests/3014 Thanks, Max On Wed, Jul 19, 2017 at 2:10 PM, David Gobbi wrote: > Hi All, > > I'm trying to get a better understanding of how the VTK_ENABLE_KITS build > works, but when I tried the build myself, I saw link errors. This is with > yesterday's master (4c17357). > > == > VTK_ENABLE_KITS:BOOL=ON > VTK_WRAP_PYTHON:BOOL=ON > > make vtkWrapping > > Undefined symbols for architecture x86_64: > "_PyBytes_AsString", referenced from: vtkPythonAlgorithm::PrintSelf > etc. > == > > In order to make it compile, I had to explicitly enable the > vtkPythonInterpreter module: > > == > Module_vtkPythonInterpreter:BOOL=ON > VTK_ENABLE_KITS:BOOL=ON > VTK_WRAP_PYTHON:BOOL=ON > > make vtkWrapping > success! > == > > Is there any reason why vtkPythonInterpreter must be enabled for the build > to work? > > Also, I'm wondering about the name "vtkWrapping" for the kit. It seems > that this kit isn't actually for "Wrapping" but rather is meant to include > Python-related modules like vtkFiltersPython. Maybe the kit should be > called something like "vtkPython" or "vtkPythonSupport"? > > Cheers, > - David > > > > _______________________________________________ > 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 Wed Jul 19 15:17:51 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 19 Jul 2017 15:17:51 -0400 Subject: [vtk-developers] OpenVR with DICOM series In-Reply-To: <1498246425075-5743763.post@n5.nabble.com> References: <1498246425075-5743763.post@n5.nabble.com> Message-ID: You may want to reduce the scale. In the current VTK I believe if you call SetDistance( ) on the camera that will also adjust the scale. Specifically I think the distance you set will be mapped into 1 meter in the real world. Maybe give that a shot. There are a lot of VR related changes coming in the next few weeks hopefully. I have made them but they need to be tested and merged into VTK master which will take a while. On Fri, Jun 23, 2017 at 3:33 PM, Ricardo wrote: > I've been using VTK with OpenVR for some time now, and I'd like to know how > to reduce a volume size, given a reconstructed series of DICOM. When using > VTK without openvr, the volume seems pretty normal, but when seen through > the glasses, the image gets much bigger. > Thanks! > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/OpenVR-with-DICOM-series-tp5743763.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 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 lucas.gandel at kitware.com Thu Jul 20 02:47:08 2017 From: lucas.gandel at kitware.com (Lucas Gandel) Date: Thu, 20 Jul 2017 08:47:08 +0200 Subject: [vtk-developers] OpenVR with DICOM series In-Reply-To: References: <1498246425075-5743763.post@n5.nabble.com> Message-ID: Ricardo, Volume data are usually expressed in millimeters but the world scale is in meters. Multiplying the origin and spacing of your input data by a 1/1000 factor might also help. Thanks, Lucas On Wed, Jul 19, 2017 at 9:17 PM, Ken Martin wrote: > You may want to reduce the scale. In the current VTK I believe if you call > SetDistance( ) on the camera that will also adjust the scale. Specifically > I think the distance you set will be mapped into 1 meter in the real world. > Maybe give that a shot. > > There are a lot of VR related changes coming in the next few weeks > hopefully. I have made them but they need to be tested and merged into VTK > master which will take a while. > > > On Fri, Jun 23, 2017 at 3:33 PM, Ricardo > wrote: > >> I've been using VTK with OpenVR for some time now, and I'd like to know >> how >> to reduce a volume size, given a reconstructed series of DICOM. When using >> VTK without openvr, the volume seems pretty normal, but when seen through >> the glasses, the image gets much bigger. >> Thanks! >> >> >> >> -- >> View this message in context: http://vtk.1045678.n5.nabble.c >> om/OpenVR-with-DICOM-series-tp5743763.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 > 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 ben.boeckel at kitware.com Thu Jul 20 08:28:56 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 20 Jul 2017 08:28:56 -0400 Subject: [vtk-developers] Kits and Python wrapping In-Reply-To: References: Message-ID: <20170720122856.GA7986@megas.kitware.com> On Wed, Jul 19, 2017 at 12:10:51 -0600, David Gobbi wrote: > I'm trying to get a better understanding of how the VTK_ENABLE_KITS build > works, but when I tried the build myself, I saw link errors. This is with > yesterday's master (4c17357). > > == > VTK_ENABLE_KITS:BOOL=ON > VTK_WRAP_PYTHON:BOOL=ON > > make vtkWrapping We have a +kits+python build on mun. Why isn't it failing? Windows-ism? > Also, I'm wondering about the name "vtkWrapping" for the kit. It seems > that this kit isn't actually for "Wrapping" but rather is meant to include > Python-related modules like vtkFiltersPython. Maybe the kit should be > called something like "vtkPython" or "vtkPythonSupport"? That sounds good. I was mainly using the parent directory when naming kits; was probably on auto-pilot here :) . --Ben From david.gobbi at gmail.com Thu Jul 20 08:37:29 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 20 Jul 2017 06:37:29 -0600 Subject: [vtk-developers] Kits and Python wrapping In-Reply-To: <20170720122856.GA7986@megas.kitware.com> References: <20170720122856.GA7986@megas.kitware.com> Message-ID: On Thu, Jul 20, 2017 at 6:28 AM, Ben Boeckel wrote: > On Wed, Jul 19, 2017 at 12:10:51 -0600, David Gobbi wrote: > > I'm trying to get a better understanding of how the VTK_ENABLE_KITS build > > works, but when I tried the build myself, I saw link errors. This is > with > > yesterday's master (4c17357). > > > > == > > VTK_ENABLE_KITS:BOOL=ON > > VTK_WRAP_PYTHON:BOOL=ON > > > > make vtkWrapping > > We have a +kits+python build on mun. Why isn't it failing? Windows-ism? > The mun build enables "Module_vtkPythonInterpreter:BOOL=ON". If it didn't, then it would probably suffer the same link errors as my own build. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Jul 20 10:17:44 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 20 Jul 2017 10:17:44 -0400 Subject: [vtk-developers] Dropping support for Qt 4 Message-ID: Folks, In light of cleaning things up, can we drop support for Qt 4 in VTK. Qt 4.8, the last major release, was released in 2011. Qt 5 has been out since 2012. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jul 20 10:18:35 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 20 Jul 2017 10:18:35 -0400 Subject: [vtk-developers] Kits and Python wrapping In-Reply-To: References: <20170720122856.GA7986@megas.kitware.com> Message-ID: <20170720141835.GA17210@megas.kitware.com> On Thu, Jul 20, 2017 at 06:37:29 -0600, David Gobbi wrote: > The mun build enables "Module_vtkPythonInterpreter:BOOL=ON". If it didn't, > then it would probably suffer the same link errors as my own build. Ah, that comes with the +python bit automatically. --Ben From dave.demarle at kitware.com Thu Jul 20 10:26:10 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 20 Jul 2017 10:26:10 -0400 Subject: [vtk-developers] Dropping support for Qt 4 In-Reply-To: References: Message-ID: +1 David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Jul 20, 2017 at 10:17 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Folks, > > In light of cleaning things up, can we drop support for Qt 4 in VTK. Qt > 4.8, the last major release, was released in 2011. Qt 5 has been out since > 2012. > > > Utkarsh > > _______________________________________________ > 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 jhlegarreta at vicomtech.org Thu Jul 20 12:10:08 2017 From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta) Date: Thu, 20 Jul 2017 18:10:08 +0200 Subject: [vtk-developers] Dropping support for Qt 4 In-Reply-To: References: Message-ID: +1 JON HAITZ -- On 20 July 2017 at 16:26, David E DeMarle wrote: > +1 > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Thu, Jul 20, 2017 at 10:17 AM, Utkarsh Ayachit < > utkarsh.ayachit at kitware.com> wrote: > >> Folks, >> >> In light of cleaning things up, can we drop support for Qt 4 in VTK. Qt >> 4.8, the last major release, was released in 2011. Qt 5 has been out since >> 2012. >> >> >> Utkarsh >> >> _______________________________________________ >> 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/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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Jul 20 12:14:19 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 20 Jul 2017 12:14:19 -0400 Subject: [vtk-developers] Dropping support for Qt 4 In-Reply-To: References: Message-ID: > > In light of cleaning things up, can we drop support for Qt 4 in VTK. Qt > 4.8, the last major release, was released in 2011. Qt 5 has been out since > 2012. > > I think it is time, can we nominate dropping Tcl support next? -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Jul 20 12:43:53 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 20 Jul 2017 12:43:53 -0400 Subject: [vtk-developers] Dropping support for Qt 4 In-Reply-To: References: Message-ID: > > I think it is time, can we nominate dropping Tcl support next? > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Jul 20 12:45:28 2017 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 20 Jul 2017 12:45:28 -0400 Subject: [vtk-developers] Dropping support for Qt 4 In-Reply-To: References: Message-ID: +1 (to both Qt & Tcl/Tk) On Thu, Jul 20, 2017 at 12:43 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > I think it is time, can we nominate dropping Tcl support next? >> > > +1 > > > _______________________________________________ > 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 wascott at sandia.gov Thu Jul 20 12:49:38 2017 From: wascott at sandia.gov (Scott, W Alan) Date: Thu, 20 Jul 2017 16:49:38 +0000 Subject: [vtk-developers] [EXTERNAL] Re: Dropping support for Qt 4 In-Reply-To: References: Message-ID: <119c04bebd1740cb83d4aaf1515ecbb2@ES01AMSNLNT.srn.sandia.gov> +1 From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Thursday, July 20, 2017 10:45 AM To: Ayachit, Utkarsh (External Contacts) Cc: vtk-developers at vtk.org Subject: [EXTERNAL] Re: [vtk-developers] Dropping support for Qt 4 +1 (to both Qt & Tcl/Tk) On Thu, Jul 20, 2017 at 12:43 PM, Utkarsh Ayachit > wrote: I think it is time, can we nominate dropping Tcl support next? +1 _______________________________________________ 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 berk.geveci at kitware.com Thu Jul 20 12:57:07 2017 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 20 Jul 2017 12:57:07 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. You could potentially do something at the executive layer that can automatically transform this new dataset to vtkImageData when using vtkImageData algorithms. It should be trivial to add support to the volume rendering code after that. Given that we are looking at VTK-m for much of the future algorithm, I would suggest that VTK-m natively supports both ordering. Then if we replace any VTK algorithms with VTK-m implementations, it would work out of box. On Wed, Jul 19, 2017 at 1:34 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi > wrote: > >> On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell < >> marcus.hanwell at kitware.com> wrote: >> >>> On Wed, Jul 19, 2017 at 12:35 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> >>>> Hi Marcus, >>>> >>>> > We work on Tomviz, and one of its primary goals is to work with >>>> volumes in an intuitive way making heavy use of the volume rendering code. >>>> It also needs to interact with several libraries that operate on volumes, >>>> ideally using our Python NumPy integration and zero copy approaches to >>>> process data in place. >>>> > >>>> > One of the challenges has been preserving the Fortran ordering of the >>>> single component scalar data. We will also be adding support for >>>> multi-component data soon. What are people's thoughts on potentially adding >>>> some API to vtkImageData to mark it as C ordered? >>>> > >>>> > That would largely just geometrically transform how the volume is >>>> rendered, but ensure a contour is correctly extracted and aligned. It would >>>> then let us use the default C ordering, simplifying our application code, >>>> and the current order could remain the default. I would suggest considering >>>> the same for the vtk.js work too. >>>> > >>>> > It is feasible to make these changes in the application logic too, >>>> but this feels like a fairly common problem that others would also hit from >>>> time to time. Maybe I am missing more corner cases, so I am posting this in >>>> hopes of feedback before writing any code (or asking someone else to). >>>> >>>> I think a common problem would be that many image filters choose a >>>> particular order to process data because access is much faster in one plane >>>> than others. Are you thinking that those filters would also adjust their >>>> algorithms/traverse order to accommodate FORTRAN ordering when it is >>>> present on the input (and presumably output)? >>> >>> >>> My ideal scenario is to mark a vtkImageData as C ordered (default it to >>> Fortran/what it is now). It may be easier to manage more of that at an >>> application level though too, I was more thinking out loud and wondering if >>> other people had explored this or solved it in other ways. I get the >>> historical perspective, and possibly that what I want may not be needed by >>> the wider VTK community. >>> >>> I would like to leave as much of VTK alone as possible, and so let most >>> VTK stuff continue as it always has, but be able to pass a vtkImageData to >>> a 3D NumPy array as C ordered, operate on it, and then render the result. >>> We currently go to great pains to ensure if comes back as Fortran ordered, >>> and there is no way to set a default. I also find that most stuff assumes >>> the C ordering, so it can require some reshuffling of the data which can >>> involve large volumes. >>> >> >> It's already possible to add extra flags to any VTK data set, without >> making any changes to VTK itself. >> >> The simplest way is to add an array to the vtkFieldData of the data set. >> You could add a field data array called "ImageOrdering" that would hold the >> flag. >> >> Another way (a little trickier) is to add your own information key. For >> example, for my VTK DICOM pipelines I've defined a key >> called PATIENT_MATRIX that stores a 4x4 matrix to define the image >> orientation. >> > > Totally, I knew about that, but VTK wouldn't particularly use that > information in rendering, but we could then use it at an application level. > Thanks for the pointers on how you are using it. > > _______________________________________________ > 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 matthew.brett at gmail.com Thu Jul 20 13:05:03 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 20 Jul 2017 18:05:03 +0100 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: Hi, On Wed, Jul 19, 2017 at 6:38 PM, Marcus D. Hanwell wrote: > On Wed, Jul 19, 2017 at 1:28 PM, Andy Bauer wrote: >> >> Couldn't you do things in the same way that the VTK SOA zero-copy array >> was done? That way it's transparent to whatever is using the data array how >> the memory is stored. > > > That felt like it would be way more invasive, and possibly not worth it. We > can just keep doing what we are doing too. >> >> >> Also, on a side note I'm not a big fan of calling these C vs. Fortran >> ordering as it's more how we traverse the data most efficiently. It looks >> like your most efficient way would be to go through Z fastest, then Y and >> finally X (opposite for current vtkImageData arrays). How about something >> like ZYX vs. XYZ ordering for identifying the difference? > > > It is a commonly used term, and works well when searching. It is the > terminology used by the Python community, Eigen, VisIt even, and so I would > say it is reasonable. I am mainly looking at a mismatch between different > toolkits, but I would say using the same terminology as most other > communities seems reasonable. Point taken, although we had a big-ish argument over on the Numpy mailing list about the kinds of confusion that can arise in conflating the memory layout with the index ordering - thread starting at: https://mail.python.org/pipermail/numpy-discussion/2013-March/065949.html Cheers, Matthew From utkarsh.ayachit at kitware.com Thu Jul 20 13:37:49 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 20 Jul 2017 13:37:49 -0400 Subject: [vtk-developers] Guidance with dropping Qt 4 Message-ID: Folks. As I work on dropping Qt 4 support in VTK, I am trying to figure out how best to deprecate old classes. With Qt 5, classes like QVTKWidget, QVTKWidget2, QVTKPaintEngine etc don't really make much sense. While they can compile with Qt 5, they won't work well (if at all). I wonder if I should just remove them, rather than mark them as deprecated since they really are not meant to be used with Qt 5. Thoughts? Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From inglis.dl at gmail.com Thu Jul 20 13:56:51 2017 From: inglis.dl at gmail.com (Dean Inglis) Date: Thu, 20 Jul 2017 13:56:51 -0400 Subject: [vtk-developers] Guidance with dropping Qt 4 In-Reply-To: References: Message-ID: I use Qt5 and those vtk classes successfully in all of my desktop app projects. If you remove those classes, what are the substitutes? - Dean On Thu, Jul 20, 2017 at 1:37 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Folks. > > As I work on dropping Qt 4 support in VTK, I am trying to figure out how > best to deprecate old classes. > > With Qt 5, classes like QVTKWidget, QVTKWidget2, QVTKPaintEngine etc don't > really make much sense. While they can compile with Qt 5, they won't work > well (if at all). I wonder if I should just remove them, rather than mark > them as deprecated since they really are not meant to be used with Qt 5. > > Thoughts? > > Utkarsh > > _______________________________________________ > 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 Thu Jul 20 13:59:18 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 20 Jul 2017 19:59:18 +0200 Subject: [vtk-developers] Guidance with dropping Qt 4 In-Reply-To: References: Message-ID: 2017-07-20 19:37 GMT+02:00 Utkarsh Ayachit : > Folks. > > As I work on dropping Qt 4 support in VTK, I am trying to figure out how > best to deprecate old classes. > > With Qt 5, classes like QVTKWidget, QVTKWidget2, QVTKPaintEngine etc don't > really make much sense. While they can compile with Qt 5, they won't work > well (if at all). I wonder if I should just remove them, rather than mark > them as deprecated since they really are not meant to be used with Qt 5. While I'm all for you guys dropping Qt 4, I think there should be a deprecation period for at least QVTKWidget. It's only recently that we ported our app to the new QVTKOpenGLWidget, before that we used QVTKWidget with Qt 5 without any big problems. The only real reason for the porting is that we wanted HiDPI working properly (and well, it made sense anyway), so I can imagine a lot of others are still using QVTKWidget. Elvis > > Thoughts? > > Utkarsh > > _______________________________________________ > 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 haocheng.liu at kitware.com Thu Jul 20 14:36:42 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 20 Jul 2017 14:36:42 -0400 Subject: [vtk-developers] Guidance with dropping Qt 4 In-Reply-To: References: Message-ID: On Thu, Jul 20, 2017 at 1:59 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-07-20 19:37 GMT+02:00 Utkarsh Ayachit : > > Folks. > > > > As I work on dropping Qt 4 support in VTK, I am trying to figure out how > > best to deprecate old classes. > > > > With Qt 5, classes like QVTKWidget, QVTKWidget2, QVTKPaintEngine etc > don't > > really make much sense. While they can compile with Qt 5, they won't work > > well (if at all). I wonder if I should just remove them, rather than mark > > them as deprecated since they really are not meant to be used with Qt 5. > > While I'm all for you guys dropping Qt 4, I think there should be a > deprecation period for at least QVTKWidget. > > It's only recently that we ported our app to the new QVTKOpenGLWidget, > before that we used QVTKWidget with Qt 5 without any big problems. The > only real reason for the porting is that we wanted HiDPI working > properly (and well, it made sense anyway), so I can imagine a lot of > others are still using QVTKWidget. > > +1 Image feature extractor and GrabCut in SMTK&CMB use QVTKWidget. If these classes are removed, a proper substitution is needed. > Elvis > > > > > Thoughts? > > > > Utkarsh > > > > _______________________________________________ > > 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 > > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Jul 20 15:29:42 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 20 Jul 2017 15:29:42 -0400 Subject: [vtk-developers] Guidance with dropping Qt 4 In-Reply-To: References: Message-ID: Okay, for now I'll just deprecate these classes since they still "work" for some. QVTKOpenGLWidget is the replacement for QVTKWidget. It's designed to work more well integrated with Qt's OpenGL management. On Thu, Jul 20, 2017 at 2:36 PM, Haocheng Liu wrote: > > > On Thu, Jul 20, 2017 at 1:59 PM, Elvis Stansvik < > elvis.stansvik at orexplore.com> wrote: > >> 2017-07-20 19:37 GMT+02:00 Utkarsh Ayachit : >> > Folks. >> > >> > As I work on dropping Qt 4 support in VTK, I am trying to figure out how >> > best to deprecate old classes. >> > >> > With Qt 5, classes like QVTKWidget, QVTKWidget2, QVTKPaintEngine etc >> don't >> > really make much sense. While they can compile with Qt 5, they won't >> work >> > well (if at all). I wonder if I should just remove them, rather than >> mark >> > them as deprecated since they really are not meant to be used with Qt 5. >> >> While I'm all for you guys dropping Qt 4, I think there should be a >> deprecation period for at least QVTKWidget. >> >> It's only recently that we ported our app to the new QVTKOpenGLWidget, >> before that we used QVTKWidget with Qt 5 without any big problems. The >> only real reason for the porting is that we wanted HiDPI working >> properly (and well, it made sense anyway), so I can imagine a lot of >> others are still using QVTKWidget. >> >> +1 > Image feature extractor and GrabCut in SMTK&CMB use QVTKWidget. If these > classes are removed, a proper substitution is needed. > >> Elvis >> >> > >> > Thoughts? >> > >> > Utkarsh >> > >> > _______________________________________________ >> > 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 >> >> > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 <(518)%20881-4421> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Jul 20 20:36:40 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 20 Jul 2017 20:36:40 -0400 Subject: [vtk-developers] [EXTERNAL] Re: Dropping support for Qt 4 In-Reply-To: <119c04bebd1740cb83d4aaf1515ecbb2@ES01AMSNLNT.srn.sandia.gov> References: <119c04bebd1740cb83d4aaf1515ecbb2@ES01AMSNLNT.srn.sandia.gov> Message-ID: +1 for tcl/to Sent from my iPad > On Jul 20, 2017, at 12:49 PM, Scott, W Alan wrote: > > +1 > > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci > Sent: Thursday, July 20, 2017 10:45 AM > To: Ayachit, Utkarsh (External Contacts) > Cc: vtk-developers at vtk.org > Subject: [EXTERNAL] Re: [vtk-developers] Dropping support for Qt 4 > > +1 (to both Qt & Tcl/Tk) > > > > On Thu, Jul 20, 2017 at 12:43 PM, Utkarsh Ayachit wrote: > I think it is time, can we nominate dropping Tcl support next? > > +1 > > > _______________________________________________ > 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 lasso at queensu.ca Thu Jul 20 23:49:51 2017 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 21 Jul 2017 03:49:51 +0000 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: > My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. We?ve been working on this for several years, as a background task. Adding support in VTK for reading, processing, and displaying arbitrarily oriented images would simplify many VTK-based medical image computing applications. Some information about this effort is available here: https://docs.google.com/document/d/e/2PACX-1vQiHT2IpeCtfpphJ9vFtq_dQ3dJHsayZTcvJZUMWM9lhJdItd1qQed0449pOpYIfE3Bqgd2uZaXN4iR/pub I know that it is a sensitive topic and a large number of files are involved (around 400 core classes + test/examples), but in many cases the changes are trivial (changing a few lines in a class to indicate that it can accept oriented image) and it is not necessary to update all classes at once, but gradually, as the need emerges. I would love to hear from anyone who would be interested in having orientation support, have any comments or suggestions, or might be willing to contribute. Andras From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Thursday, July 20, 2017 12:57 PM To: Marcus D. Hanwell Cc: VTK Developers ; David Gobbi Subject: Re: [vtk-developers] vtkImageData, C versus Fortran ordering My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. You could potentially do something at the executive layer that can automatically transform this new dataset to vtkImageData when using vtkImageData algorithms. It should be trivial to add support to the volume rendering code after that. Given that we are looking at VTK-m for much of the future algorithm, I would suggest that VTK-m natively supports both ordering. Then if we replace any VTK algorithms with VTK-m implementations, it would work out of box. On Wed, Jul 19, 2017 at 1:34 PM, Marcus D. Hanwell > wrote: On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi > wrote: On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell > wrote: On Wed, Jul 19, 2017 at 12:35 PM, David Thompson > wrote: Hi Marcus, > We work on Tomviz, and one of its primary goals is to work with volumes in an intuitive way making heavy use of the volume rendering code. It also needs to interact with several libraries that operate on volumes, ideally using our Python NumPy integration and zero copy approaches to process data in place. > > One of the challenges has been preserving the Fortran ordering of the single component scalar data. We will also be adding support for multi-component data soon. What are people's thoughts on potentially adding some API to vtkImageData to mark it as C ordered? > > That would largely just geometrically transform how the volume is rendered, but ensure a contour is correctly extracted and aligned. It would then let us use the default C ordering, simplifying our application code, and the current order could remain the default. I would suggest considering the same for the vtk.js work too. > > It is feasible to make these changes in the application logic too, but this feels like a fairly common problem that others would also hit from time to time. Maybe I am missing more corner cases, so I am posting this in hopes of feedback before writing any code (or asking someone else to). I think a common problem would be that many image filters choose a particular order to process data because access is much faster in one plane than others. Are you thinking that those filters would also adjust their algorithms/traverse order to accommodate FORTRAN ordering when it is present on the input (and presumably output)? My ideal scenario is to mark a vtkImageData as C ordered (default it to Fortran/what it is now). It may be easier to manage more of that at an application level though too, I was more thinking out loud and wondering if other people had explored this or solved it in other ways. I get the historical perspective, and possibly that what I want may not be needed by the wider VTK community. I would like to leave as much of VTK alone as possible, and so let most VTK stuff continue as it always has, but be able to pass a vtkImageData to a 3D NumPy array as C ordered, operate on it, and then render the result. We currently go to great pains to ensure if comes back as Fortran ordered, and there is no way to set a default. I also find that most stuff assumes the C ordering, so it can require some reshuffling of the data which can involve large volumes. It's already possible to add extra flags to any VTK data set, without making any changes to VTK itself. The simplest way is to add an array to the vtkFieldData of the data set. You could add a field data array called "ImageOrdering" that would hold the flag. Another way (a little trickier) is to add your own information key. For example, for my VTK DICOM pipelines I've defined a key called PATIENT_MATRIX that stores a 4x4 matrix to define the image orientation. Totally, I knew about that, but VTK wouldn't particularly use that information in rendering, but we could then use it at an application level. Thanks for the pointers on how you are using it. _______________________________________________ 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 aashish.chaudhary at kitware.com Thu Jul 20 23:55:23 2017 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Fri, 21 Jul 2017 03:55:23 +0000 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Thu, Jul 20, 2017 at 12:57 PM Berk Geveci wrote: > My approach with this kind of change has been to create a new subclass of > vtkDataSet. If you add some meta-data to vtkImageData that is then ignored > by all or most of algorithms, you will end up with confused users. You > could potentially do something at the executive layer that can > automatically transform this new dataset to vtkImageData when using > vtkImageData algorithms. It should be trivial to add support to the volume > rendering code after that. > > Given that we are looking at VTK-m for much of the future algorithm, I > would suggest that VTK-m natively supports both ordering. Then if we > replace any VTK algorithms with VTK-m implementations, it would work out of > box. > +1, I think this is important because depending on what system you are working with you need one or the other or go between these two. We have had few of these in geospatial and remote sensing domain. > > On Wed, Jul 19, 2017 at 1:34 PM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> On Wed, Jul 19, 2017 at 1:11 PM, David Gobbi >> wrote: >> >>> On Wed, Jul 19, 2017 at 10:55 AM, Marcus D. Hanwell < >>> marcus.hanwell at kitware.com> wrote: >>> >>>> On Wed, Jul 19, 2017 at 12:35 PM, David Thompson < >>>> david.thompson at kitware.com> wrote: >>>> >>>>> Hi Marcus, >>>>> >>>>> > We work on Tomviz, and one of its primary goals is to work with >>>>> volumes in an intuitive way making heavy use of the volume rendering code. >>>>> It also needs to interact with several libraries that operate on volumes, >>>>> ideally using our Python NumPy integration and zero copy approaches to >>>>> process data in place. >>>>> > >>>>> > One of the challenges has been preserving the Fortran ordering of >>>>> the single component scalar data. We will also be adding support for >>>>> multi-component data soon. What are people's thoughts on potentially adding >>>>> some API to vtkImageData to mark it as C ordered? >>>>> > >>>>> > That would largely just geometrically transform how the volume is >>>>> rendered, but ensure a contour is correctly extracted and aligned. It would >>>>> then let us use the default C ordering, simplifying our application code, >>>>> and the current order could remain the default. I would suggest considering >>>>> the same for the vtk.js work too. >>>>> > >>>>> > It is feasible to make these changes in the application logic too, >>>>> but this feels like a fairly common problem that others would also hit from >>>>> time to time. Maybe I am missing more corner cases, so I am posting this in >>>>> hopes of feedback before writing any code (or asking someone else to). >>>>> >>>>> I think a common problem would be that many image filters choose a >>>>> particular order to process data because access is much faster in one plane >>>>> than others. Are you thinking that those filters would also adjust their >>>>> algorithms/traverse order to accommodate FORTRAN ordering when it is >>>>> present on the input (and presumably output)? >>>> >>>> >>>> My ideal scenario is to mark a vtkImageData as C ordered (default it to >>>> Fortran/what it is now). It may be easier to manage more of that at an >>>> application level though too, I was more thinking out loud and wondering if >>>> other people had explored this or solved it in other ways. I get the >>>> historical perspective, and possibly that what I want may not be needed by >>>> the wider VTK community. >>>> >>>> I would like to leave as much of VTK alone as possible, and so let most >>>> VTK stuff continue as it always has, but be able to pass a vtkImageData to >>>> a 3D NumPy array as C ordered, operate on it, and then render the result. >>>> We currently go to great pains to ensure if comes back as Fortran ordered, >>>> and there is no way to set a default. I also find that most stuff assumes >>>> the C ordering, so it can require some reshuffling of the data which can >>>> involve large volumes. >>>> >>> >>> It's already possible to add extra flags to any VTK data set, without >>> making any changes to VTK itself. >>> >>> The simplest way is to add an array to the vtkFieldData of the data >>> set. You could add a field data array called "ImageOrdering" that would >>> hold the flag. >>> >>> Another way (a little trickier) is to add your own information key. For >>> example, for my VTK DICOM pipelines I've defined a key >>> called PATIENT_MATRIX that stores a 4x4 matrix to define the image >>> orientation. >>> >> >> Totally, I knew about that, but VTK wouldn't particularly use that >> information in rendering, but we could then use it at an application level. >> Thanks for the pointers on how you are using it. >> >> _______________________________________________ >> 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 dan.lipsa at kitware.com Fri Jul 21 09:21:06 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 21 Jul 2017 09:21:06 -0400 Subject: [vtk-developers] VTKWeb support for multiple windows on the client Message-ID: Hi all, We are using VTKWeb + ParaViewWebClient in the browser. We open several VTK windows on the server and put them inside different panels (divs) in the browser. Looking at VtkWebMouseListener/index.js it seems that there is no support for this configuration. It seems that client has not concept of active view, so it always sends mouse events to the server, regardless of the active view on the server. The resulting behavior is that you can move your mouse over a different panel, but the active panel moves. Am I missing something? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Jul 21 10:42:51 2017 From: sean at rogue-research.com (Sean McBride) Date: Fri, 21 Jul 2017 10:42:51 -0400 Subject: [vtk-developers] Add missing override warnings to gitlab builds...? Message-ID: <20170721144251.1999813403@mail.rogue-research.com> Hi all, Could we add -Winconsistent-missing-destructor-override to one of the clang bots that builds on gitlab? (Maybe bigmac, if its clang supports that flag.) It would hopefully prevent warnings from making it to nightly bots, ex: Cheers, Sean From scott.wittenburg at kitware.com Fri Jul 21 11:40:43 2017 From: scott.wittenburg at kitware.com (Scott Wittenburg) Date: Fri, 21 Jul 2017 09:40:43 -0600 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: Hi Dan, In VtkWebMouseListener, it is the "view" key in the vtk event structure that indicates what view to send the event to on the server, and it does seem that there is no way to change it from -1, which indicates to send the event to the active view. However, both the paraviewweb and vtkweb server protocols have mouse handlers which take the id of the target view as an option, so what you want to do seems to be supported on the server side at least. But I agree with you that the VtkWebMouseListener does not seem to provide a mechanism to change that view id. One thing we could do is have the VtkWebMouseListener take a view id as an optional 4th argument which defaults to -1, then use that in the zoom and drag listeners. If that makes sense to you, you can put together a PR on paraviewweb, and I'll be happy to review it. Otherwise, get in touch with me offline and we can chat about it. Hope this helps. Cheers, Scott On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa wrote: > Hi all, > We are using VTKWeb + ParaViewWebClient in the browser. We open several > VTK windows on the server and put them inside different panels (divs) in > the browser. > > Looking at VtkWebMouseListener/index.js it seems that there is no support > for this configuration. > > It seems that client has not concept of active view, so it always sends > mouse events to the server, regardless of the active view on the server. > > The resulting behavior is that you can move your mouse over a different > panel, but the active panel moves. Am I missing something? > > Thanks, > Dan > > > _______________________________________________ > 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 dan.lipsa at kitware.com Fri Jul 21 12:17:17 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Fri, 21 Jul 2017 12:17:17 -0400 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: Thanks Scott, I was thinking to go one step further: - Pass a map between the client elements(divs) and the server window ids. I already have both the element ids and the server window ids. - When a mouse event is received in vtkWebMouseListener we can use that map and send the server window id the event applies too. Dan On Fri, Jul 21, 2017 at 11:40 AM, Scott Wittenburg < scott.wittenburg at kitware.com> wrote: > Hi Dan, > > In VtkWebMouseListener, it is the "view" key in the vtk event structure > that indicates what view to send the event to on the server, and it does > seem that there is no way to change it from -1, which indicates to send the > event to the active view. However, both the paraviewweb and vtkweb server > protocols have mouse handlers which take the id of the target view as an > option, so what you want to do seems to be supported on the server side at > least. But I agree with you that the VtkWebMouseListener does not seem to > provide a mechanism to change that view id. One thing we could do is have > the VtkWebMouseListener take a view id as an optional 4th argument which > defaults to -1, then use that in the zoom and drag listeners. > > If that makes sense to you, you can put together a PR on paraviewweb, and > I'll be happy to review it. Otherwise, get in touch with me offline and we > can chat about it. Hope this helps. > > Cheers, > Scott > > > > On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa wrote: > >> Hi all, >> We are using VTKWeb + ParaViewWebClient in the browser. We open several >> VTK windows on the server and put them inside different panels (divs) in >> the browser. >> >> Looking at VtkWebMouseListener/index.js it seems that there is no support >> for this configuration. >> >> It seems that client has not concept of active view, so it always sends >> mouse events to the server, regardless of the active view on the server. >> >> The resulting behavior is that you can move your mouse over a different >> panel, but the active panel moves. Am I missing something? >> >> Thanks, >> Dan >> >> >> _______________________________________________ >> 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 shawn.waldon at kitware.com Fri Jul 21 13:09:37 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Fri, 21 Jul 2017 13:09:37 -0400 Subject: [vtk-developers] Add missing override warnings to gitlab builds...? In-Reply-To: <20170721144251.1999813403@mail.rogue-research.com> References: <20170721144251.1999813403@mail.rogue-research.com> Message-ID: Hi Sean, I've added -Winconsistent-missing-override to the build flags for bigmac's VTK builds. Clang didn't recognize -Winconsistent-missing-destructor-override but suggested I might mean this one. Hopefully that will help with this. Shawn On Fri, Jul 21, 2017 at 10:42 AM, Sean McBride wrote: > Hi all, > > Could we add -Winconsistent-missing-destructor-override to one of the > clang bots that builds on gitlab? (Maybe bigmac, if its clang supports > that flag.) It would hopefully prevent warnings from making it to nightly > bots, ex: > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Fri Jul 21 16:29:55 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Fri, 21 Jul 2017 14:29:55 -0600 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: I would rather have one vtkWebMouseListener per div so each listener has its own view id. On Fri, Jul 21, 2017 at 10:17 AM, Dan Lipsa wrote: > Thanks Scott, > I was thinking to go one step further: > - Pass a map between the client elements(divs) and the server window ids. > I already have both the element ids and the server window ids. > - When a mouse event is received in vtkWebMouseListener we can use that > map and send the server window id the event applies too. > > Dan > > > > On Fri, Jul 21, 2017 at 11:40 AM, Scott Wittenburg < > scott.wittenburg at kitware.com> wrote: > >> Hi Dan, >> >> In VtkWebMouseListener, it is the "view" key in the vtk event structure >> that indicates what view to send the event to on the server, and it does >> seem that there is no way to change it from -1, which indicates to send the >> event to the active view. However, both the paraviewweb and vtkweb server >> protocols have mouse handlers which take the id of the target view as an >> option, so what you want to do seems to be supported on the server side at >> least. But I agree with you that the VtkWebMouseListener does not seem to >> provide a mechanism to change that view id. One thing we could do is have >> the VtkWebMouseListener take a view id as an optional 4th argument which >> defaults to -1, then use that in the zoom and drag listeners. >> >> If that makes sense to you, you can put together a PR on paraviewweb, and >> I'll be happy to review it. Otherwise, get in touch with me offline and we >> can chat about it. Hope this helps. >> >> Cheers, >> Scott >> >> >> >> On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa wrote: >> >>> Hi all, >>> We are using VTKWeb + ParaViewWebClient in the browser. We open several >>> VTK windows on the server and put them inside different panels (divs) in >>> the browser. >>> >>> Looking at VtkWebMouseListener/index.js it seems that there is no >>> support for this configuration. >>> >>> It seems that client has not concept of active view, so it always sends >>> mouse events to the server, regardless of the active view on the server. >>> >>> The resulting behavior is that you can move your mouse over a different >>> panel, but the active panel moves. Am I missing something? >>> >>> Thanks, >>> Dan >>> >>> >>> _______________________________________________ >>> 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 sean at rogue-research.com Fri Jul 21 16:34:57 2017 From: sean at rogue-research.com (Sean McBride) Date: Fri, 21 Jul 2017 16:34:57 -0400 Subject: [vtk-developers] Add missing override warnings to gitlab builds...? In-Reply-To: References: <20170721144251.1999813403@mail.rogue-research.com> Message-ID: <20170721203457.1828118345@mail.rogue-research.com> On Fri, 21 Jul 2017 13:09:37 -0400, Shawn Waldon said: >I've added -Winconsistent-missing-override to the build flags for bigmac's >VTK builds. Clang didn't recognize >-Winconsistent-missing-destructor-override but suggested I might mean this >one. Hopefully that will help with this. Ah, I guess -Winconsistent-missing-destructor-override is too new for bigmac's clang... darn. I think -Winconsistent-missing-override is in -Wall, but your adding it won't hurt. Thanks! Sean From lasso at queensu.ca Sun Jul 23 16:29:21 2017 From: lasso at queensu.ca (Andras Lasso) Date: Sun, 23 Jul 2017 20:29:21 +0000 Subject: [vtk-developers] CSV file reader/writer improvement plans Message-ID: Hi all, What do people usually use for reading/writing CSV files? vtkDelimitedTextReader and vtkDelimitedTextWriter work for very specific cases, but have many important limitations: Reading: * No way to specify column types. There is some heuristics that can sometimes guess numeric column types but it is not usable in general (for example, a numeric column may be empty or a double column may happen to contain only integer values in a specific file). * All rows must contain exactly the same number of columns. * Columns that don't have names cannot be read. * If a field value contains field separator or string separator character then the file is parsed incorrectly. Writing: * Cannot specify number of digits for writing floating-point numbers (currently something like 6 digits is hardcoded). * Cannot write field values that contain string separator characters (no escaping of " by "" is performed) * If field value may contain field separator character then all values must be enforced to written with string separators, which makes the file very hard to read and edit (normally string separators are only added when needed) Questions to these answers would help us in planning/deciding if we implement solution for these by improving existing VTK classes, or just in our application: * Is there any plan (or work in progress) to address these limitations? * If we implemented these features, would they be welcome in VTK? * Would storing metadata (column type, format specifier, default value, etc.) in a schema .csv file next to the data file (such as this: https://github.com/Slicer/Slicer/blob/master/Libs/MRML/Core/Testing/TestData/table.schema.csv) would be considered a good solution? Are there any other standards/best practices for storing csv schema? * Would anyone else need these features and could contribute some time for development or writing tests? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron.helser at kitware.com Mon Jul 24 11:18:00 2017 From: aron.helser at kitware.com (Aron Helser) Date: Mon, 24 Jul 2017 11:18:00 -0400 Subject: [vtk-developers] CSV file reader/writer improvement plans In-Reply-To: References: Message-ID: We have used the vtkDelimitedTextReader as the first stage for a CSV data import tool for a government customer, and they are open to moving the tool into an open-source repository. Unfortunately, the project is stalled right now as funding is considered. Some thoughts inlne: - The tool is a 'cleaner', so it's designed to take poorly-formed CSV files and let the user make decisions about fixing the data, although there is a non-interactive path that simply drops rows that have problem data. The final result is a VTK table written to an HDF5 file, so this project doesn't use the vtkDelimitedTextWriter. It has pretty good testing written already. On Sun, Jul 23, 2017 at 4:29 PM, Andras Lasso wrote: > Hi all, > > > > What do people usually use for reading/writing CSV files? > > > > vtkDelimitedTextReader and vtkDelimitedTextWriter work for very specific > cases, but have many important limitations: > > > > Reading: > > - No way to specify column types. There is some heuristics that can > sometimes guess numeric column types but it is not usable in general (for > example, a numeric column may be empty or a double column may happen to > contain only integer values in a specific file). > > - We read everything as strings and then use vtkVariant to test if it can be converted to int/double. We do use a heuristic to choose column data types. > > - > - All rows must contain exactly the same number of columns. > > If a row has too few entries, it is filled with empty values, at least for string input. > > - > - Columns that don?t have names cannot be read. > > - I believe vtkDelimitedTextReader will read columns without a name, but they can't be used in calculations or exported until they have a name - assigning a default name in your code might be enough. > > - > - If a field value contains field separator or string separator > character then the file is parsed incorrectly. > > - The purpose of the string separator is to allow the field separator to appear inside a field. If you've found this not to work, it's a bug that can be submitted to VTK! > > - > > > > Writing: > > - Cannot specify number of digits for writing floating-point numbers > (currently something like 6 digits is hardcoded). > - Cannot write field values that contain string separator characters > (no escaping of ? by ?? is performed) > - If field value may contain field separator character then all values > must be enforced to written with string separators, which makes the file > very hard to read and edit (normally string separators are only added when > needed) > > > > Questions to these answers would help us in planning/deciding if we > implement solution for these by improving existing VTK classes, or just in > our application: > > - Is there any plan (or work in progress) to address these limitations? > - If we implemented these features, would they be welcome in VTK? > > - Yes, I think so! > > - > - Would storing metadata (column type, format specifier, default > value, etc.) in a schema .csv file next to the data file (such as this: > https://github.com/Slicer/Slicer/blob/master/Libs/MRML/ > Core/Testing/TestData/table.schema.csv > ) > would be considered a good solution? Are there any other standards/best > practices for storing csv schema? > - Would anyone else need these features and could contribute some time > for development or writing tests? > > > > Andras > > > > _______________________________________________ > 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 Tue Jul 25 14:08:25 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 25 Jul 2017 14:08:25 -0400 Subject: [vtk-developers] 0, NULL -> nullptr Message-ID: Here is a topic for updating VTK/Common to use nullptr based on fixes from clang-tidy https://gitlab.kitware.com/vtk/vtk/merge_requests/3055 I just did common as I figured that would impact fewer people. My plan is to do other directories in chunks over time but I can go whole hog and do it all at once if you all think that is better. The change is from Rob's script ala... #!/bin/bash # The vtk build must have CMAKE_EXPORT_COMPILE_COMMANDS=ON path=$(pwd) build_path="/home/ken/Documents/vtk/vtkbin" clang_tidy="/usr/bin/clang-tidy" args="-checks=-*,modernize-use-nullptr --header-filter=$path -p $build_path -fix" for file in $1/*.cxx; do $clang_tidy $args $file done -- 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 cory.quammen at kitware.com Tue Jul 25 14:28:32 2017 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 25 Jul 2017 14:28:32 -0400 Subject: [vtk-developers] 0, NULL -> nullptr In-Reply-To: References: Message-ID: +1 for doing it all at once. A sequence of changes that touch a lot of files slows down testing builds for projects that closely track VTK master. On Tue, Jul 25, 2017 at 2:08 PM, Ken Martin wrote: > > Here is a topic for updating VTK/Common to use nullptr based on fixes from > clang-tidy > > https://gitlab.kitware.com/vtk/vtk/merge_requests/3055 > > I just did common as I figured that would impact fewer people. My plan is to > do other directories in chunks over time but I can go whole hog and do it > all at once if you all think that is better. The change is from Rob's > script ala... > > #!/bin/bash > > # The vtk build must have CMAKE_EXPORT_COMPILE_COMMANDS=ON > > path=$(pwd) > build_path="/home/ken/Documents/vtk/vtkbin" > clang_tidy="/usr/bin/clang-tidy" > args="-checks=-*,modernize-use-nullptr --header-filter=$path -p $build_path > -fix" > for file in $1/*.cxx; do > $clang_tidy $args $file > done > > > > -- > 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 > > -- Cory Quammen Staff R&D Engineer Kitware, Inc. From ben.boeckel at kitware.com Tue Jul 25 15:59:38 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 25 Jul 2017 15:59:38 -0400 Subject: [vtk-developers] 0, NULL -> nullptr In-Reply-To: References: Message-ID: <20170725195938.GB8987@megas.kitware.com> On Tue, Jul 25, 2017 at 14:08:25 -0400, Ken Martin wrote: > Here is a topic for updating VTK/Common to use nullptr based on fixes from > clang-tidy > > https://gitlab.kitware.com/vtk/vtk/merge_requests/3055 > > I just did common as I figured that would impact fewer people. My plan is > to do other directories in chunks over time but I can go whole hog and do > it all at once if you all think that is better. The change is from Rob's > script ala... +1 for an all-at-once change. Please commit the change using: --author="Kitware Robot " to make it easier to skip it when blaming across the commit though. --Ben From david.gobbi at gmail.com Tue Jul 25 16:30:41 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Jul 2017 14:30:41 -0600 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: As a quick follow-up, I took J-C's new wheel builder for a spin today ( https://github.com/jcfr/VTKPythonPackage), and very quickly got a wheel that I could install on my Mac. I had to set DYLD_LIBRARY_PATH for "import vtk" to work. I'm guessing the @loader_path magic (via delocate or other means) isn't implemented yet? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jul 25 16:50:24 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Jul 2017 14:50:24 -0600 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: On Tue, Jul 25, 2017 at 2:30 PM, David Gobbi wrote: > As a quick follow-up, I took J-C's new wheel builder for a spin today ( > https://github.com/jcfr/VTKPythonPackage), and very quickly got a wheel > that I could install on my Mac. I had to set DYLD_LIBRARY_PATH for "import > vtk" to work. I'm guessing the @loader_path magic (via delocate or other > means) isn't implemented yet? > I ran delocate-wheel, and the resulting wheel worked fine. However, the wheel contained two copies of all the dylibs: one copy inside the vtk/ module, and another copy inside a .dylibs subdir. The loader_path was set for the latter. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Wed Jul 26 04:21:37 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 26 Jul 2017 13:51:37 +0530 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: <823531e4-a4fb-a975-5f85-a69667cca902@aero.iitb.ac.in> Hi David, It was nice to see you on the hangout at SciPy. Sorry I had to rush as I was supposed to be leading another BOF at the same time. On 7/26/17 2:00 AM, David Gobbi wrote: > As a quick follow-up, I took J-C's new wheel builder for a spin today > (https://github.com/jcfr/VTKPythonPackage), and very quickly got a wheel that > I could install on my Mac. I had to set DYLD_LIBRARY_PATH for "import vtk" to > work. I'm guessing the @loader_path magic (via delocate or other means) isn't > implemented yet? > The docs seem to suggest that OS X is not yet supported. Do you know if the built wheels are put up anywhere so we can test on the other platforms? cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jul 26 09:20:23 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 26 Jul 2017 09:20:23 -0400 Subject: [vtk-developers] VTK Python wheels? In-Reply-To: References: Message-ID: <20170726132023.GA4903@megas.kitware.com> On Tue, Jul 25, 2017 at 14:30:41 -0600, David Gobbi wrote: > As a quick follow-up, I took J-C's new wheel builder for a spin today ( > https://github.com/jcfr/VTKPythonPackage), and very quickly got a wheel > that I could install on my Mac. Cool. I'll try and take a look at it in the coming weeks. I'll probably have an example ParaView wheel before VTK since it already uses the new superbuild infrastructure, but I want to move VTK's superbuild over to it as well. > I had to set DYLD_LIBRARY_PATH for "import > vtk" to work. I'm guessing the @loader_path magic (via delocate or other > means) isn't implemented yet? When the superbuild supports wheels, that will work (the packging rewrites all IDs and links to use @executable_path or @loader_path depending on the library type). --Ben From dan.lipsa at kitware.com Wed Jul 26 09:59:20 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 26 Jul 2017 09:59:20 -0400 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: Thanks Seb, I'll have more questions when I get to implementing this. Dan On Fri, Jul 21, 2017 at 4:29 PM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > I would rather have one vtkWebMouseListener per div so each listener has > its own view id. > > On Fri, Jul 21, 2017 at 10:17 AM, Dan Lipsa wrote: > >> Thanks Scott, >> I was thinking to go one step further: >> - Pass a map between the client elements(divs) and the server window ids. >> I already have both the element ids and the server window ids. >> - When a mouse event is received in vtkWebMouseListener we can use that >> map and send the server window id the event applies too. >> >> Dan >> >> >> >> On Fri, Jul 21, 2017 at 11:40 AM, Scott Wittenburg < >> scott.wittenburg at kitware.com> wrote: >> >>> Hi Dan, >>> >>> In VtkWebMouseListener, it is the "view" key in the vtk event structure >>> that indicates what view to send the event to on the server, and it does >>> seem that there is no way to change it from -1, which indicates to send the >>> event to the active view. However, both the paraviewweb and vtkweb server >>> protocols have mouse handlers which take the id of the target view as an >>> option, so what you want to do seems to be supported on the server side at >>> least. But I agree with you that the VtkWebMouseListener does not seem to >>> provide a mechanism to change that view id. One thing we could do is have >>> the VtkWebMouseListener take a view id as an optional 4th argument which >>> defaults to -1, then use that in the zoom and drag listeners. >>> >>> If that makes sense to you, you can put together a PR on paraviewweb, >>> and I'll be happy to review it. Otherwise, get in touch with me offline >>> and we can chat about it. Hope this helps. >>> >>> Cheers, >>> Scott >>> >>> >>> >>> On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa >>> wrote: >>> >>>> Hi all, >>>> We are using VTKWeb + ParaViewWebClient in the browser. We open several >>>> VTK windows on the server and put them inside different panels (divs) in >>>> the browser. >>>> >>>> Looking at VtkWebMouseListener/index.js it seems that there is no >>>> support for this configuration. >>>> >>>> It seems that client has not concept of active view, so it always sends >>>> mouse events to the server, regardless of the active view on the server. >>>> >>>> The resulting behavior is that you can move your mouse over a different >>>> panel, but the active panel moves. Am I missing something? >>>> >>>> Thanks, >>>> Dan >>>> >>>> >>>> _______________________________________________ >>>> 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 sebastien.jourdain at kitware.com Wed Jul 26 10:04:23 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Wed, 26 Jul 2017 08:04:23 -0600 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: Hi Dan, I'll be in KHQ next week. If you want we can talk about it in person. Seb On Wed, Jul 26, 2017 at 7:59 AM, Dan Lipsa wrote: > Thanks Seb, > I'll have more questions when I get to implementing this. > > Dan > > > On Fri, Jul 21, 2017 at 4:29 PM, Sebastien Jourdain < > sebastien.jourdain at kitware.com> wrote: > >> I would rather have one vtkWebMouseListener per div so each listener has >> its own view id. >> >> On Fri, Jul 21, 2017 at 10:17 AM, Dan Lipsa >> wrote: >> >>> Thanks Scott, >>> I was thinking to go one step further: >>> - Pass a map between the client elements(divs) and the server window >>> ids. I already have both the element ids and the server window ids. >>> - When a mouse event is received in vtkWebMouseListener we can use that >>> map and send the server window id the event applies too. >>> >>> Dan >>> >>> >>> >>> On Fri, Jul 21, 2017 at 11:40 AM, Scott Wittenburg < >>> scott.wittenburg at kitware.com> wrote: >>> >>>> Hi Dan, >>>> >>>> In VtkWebMouseListener, it is the "view" key in the vtk event structure >>>> that indicates what view to send the event to on the server, and it does >>>> seem that there is no way to change it from -1, which indicates to send the >>>> event to the active view. However, both the paraviewweb and vtkweb server >>>> protocols have mouse handlers which take the id of the target view as an >>>> option, so what you want to do seems to be supported on the server side at >>>> least. But I agree with you that the VtkWebMouseListener does not seem to >>>> provide a mechanism to change that view id. One thing we could do is have >>>> the VtkWebMouseListener take a view id as an optional 4th argument which >>>> defaults to -1, then use that in the zoom and drag listeners. >>>> >>>> If that makes sense to you, you can put together a PR on paraviewweb, >>>> and I'll be happy to review it. Otherwise, get in touch with me offline >>>> and we can chat about it. Hope this helps. >>>> >>>> Cheers, >>>> Scott >>>> >>>> >>>> >>>> On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa >>>> wrote: >>>> >>>>> Hi all, >>>>> We are using VTKWeb + ParaViewWebClient in the browser. We open >>>>> several VTK windows on the server and put them inside different panels >>>>> (divs) in the browser. >>>>> >>>>> Looking at VtkWebMouseListener/index.js it seems that there is no >>>>> support for this configuration. >>>>> >>>>> It seems that client has not concept of active view, so it always >>>>> sends mouse events to the server, regardless of the active view on the >>>>> server. >>>>> >>>>> The resulting behavior is that you can move your mouse over a >>>>> different panel, but the active panel moves. Am I missing something? >>>>> >>>>> Thanks, >>>>> Dan >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 dan.lipsa at kitware.com Wed Jul 26 10:19:33 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 26 Jul 2017 10:19:33 -0400 Subject: [vtk-developers] VTKWeb support for multiple windows on the client In-Reply-To: References: Message-ID: Great. Just about the time when I think I'll get to this. See you then. On Wed, Jul 26, 2017 at 10:04 AM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > Hi Dan, > > I'll be in KHQ next week. If you want we can talk about it in person. > > Seb > > On Wed, Jul 26, 2017 at 7:59 AM, Dan Lipsa wrote: > >> Thanks Seb, >> I'll have more questions when I get to implementing this. >> >> Dan >> >> >> On Fri, Jul 21, 2017 at 4:29 PM, Sebastien Jourdain < >> sebastien.jourdain at kitware.com> wrote: >> >>> I would rather have one vtkWebMouseListener per div so each listener >>> has its own view id. >>> >>> On Fri, Jul 21, 2017 at 10:17 AM, Dan Lipsa >>> wrote: >>> >>>> Thanks Scott, >>>> I was thinking to go one step further: >>>> - Pass a map between the client elements(divs) and the server window >>>> ids. I already have both the element ids and the server window ids. >>>> - When a mouse event is received in vtkWebMouseListener we can use that >>>> map and send the server window id the event applies too. >>>> >>>> Dan >>>> >>>> >>>> >>>> On Fri, Jul 21, 2017 at 11:40 AM, Scott Wittenburg < >>>> scott.wittenburg at kitware.com> wrote: >>>> >>>>> Hi Dan, >>>>> >>>>> In VtkWebMouseListener, it is the "view" key in the vtk event >>>>> structure that indicates what view to send the event to on the server, and >>>>> it does seem that there is no way to change it from -1, which indicates to >>>>> send the event to the active view. However, both the paraviewweb and >>>>> vtkweb server protocols have mouse handlers which take the id of the target >>>>> view as an option, so what you want to do seems to be supported on the >>>>> server side at least. But I agree with you that the VtkWebMouseListener >>>>> does not seem to provide a mechanism to change that view id. One thing we >>>>> could do is have the VtkWebMouseListener take a view id as an optional 4th >>>>> argument which defaults to -1, then use that in the zoom and drag listeners. >>>>> >>>>> If that makes sense to you, you can put together a PR on paraviewweb, >>>>> and I'll be happy to review it. Otherwise, get in touch with me offline >>>>> and we can chat about it. Hope this helps. >>>>> >>>>> Cheers, >>>>> Scott >>>>> >>>>> >>>>> >>>>> On Fri, Jul 21, 2017 at 7:21 AM, Dan Lipsa >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> We are using VTKWeb + ParaViewWebClient in the browser. We open >>>>>> several VTK windows on the server and put them inside different panels >>>>>> (divs) in the browser. >>>>>> >>>>>> Looking at VtkWebMouseListener/index.js it seems that there is no >>>>>> support for this configuration. >>>>>> >>>>>> It seems that client has not concept of active view, so it always >>>>>> sends mouse events to the server, regardless of the active view on the >>>>>> server. >>>>>> >>>>>> The resulting behavior is that you can move your mouse over a >>>>>> different panel, but the active panel moves. Am I missing something? >>>>>> >>>>>> Thanks, >>>>>> Dan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Wed Jul 26 14:19:34 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 26 Jul 2017 14:19:34 -0400 Subject: [vtk-developers] 0, NULL -> nullptr In-Reply-To: References: Message-ID: I have merged this as a new large commit. I'll try fixing any issues that crop up on the nightlies tomorrow. There are still many uses of NULL in comments and classes that did not build on my linux system (such as Win32 and OSX specific classes) If you see uses of NULL or 0 in code you are editing that should be nullptr, please update them. I did go beyond just clang-tidy so if you see issues/regressions with the change let me know. Going forward in C++ code please use nullptr as it has better type safety and overload resolution than NULL or 0. In comments I tried to use "nullptr" or "null" depending on the context as opposed to NULL. Topics in flight may have merge conflicts (probably :-( ). On Tue, Jul 25, 2017 at 2:08 PM, Ken Martin wrote: > > Here is a topic for updating VTK/Common to use nullptr based on fixes from > clang-tidy > > https://gitlab.kitware.com/vtk/vtk/merge_requests/3055 > > I just did common as I figured that would impact fewer people. My plan is > to do other directories in chunks over time but I can go whole hog and do > it all at once if you all think that is better. The change is from Rob's > script ala... > > #!/bin/bash > > # The vtk build must have CMAKE_EXPORT_COMPILE_COMMANDS=ON > > path=$(pwd) > build_path="/home/ken/Documents/vtk/vtkbin" > clang_tidy="/usr/bin/clang-tidy" > args="-checks=-*,modernize-use-nullptr --header-filter=$path -p > $build_path -fix" > for file in $1/*.cxx; do > $clang_tidy $args $file > done > > > > -- > 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. > -- 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 marcus.hanwell at kitware.com Wed Jul 26 15:43:22 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 26 Jul 2017 15:43:22 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Thu, Jul 20, 2017 at 1:05 PM, Matthew Brett wrote: > > Hi, > > On Wed, Jul 19, 2017 at 6:38 PM, Marcus D. Hanwell > wrote: > > On Wed, Jul 19, 2017 at 1:28 PM, Andy Bauer wrote: > >> > >> Couldn't you do things in the same way that the VTK SOA zero-copy array > >> was done? That way it's transparent to whatever is using the data array how > >> the memory is stored. > > > > > > That felt like it would be way more invasive, and possibly not worth it. We > > can just keep doing what we are doing too. > >> > >> > >> Also, on a side note I'm not a big fan of calling these C vs. Fortran > >> ordering as it's more how we traverse the data most efficiently. It looks > >> like your most efficient way would be to go through Z fastest, then Y and > >> finally X (opposite for current vtkImageData arrays). How about something > >> like ZYX vs. XYZ ordering for identifying the difference? > > > > > > It is a commonly used term, and works well when searching. It is the > > terminology used by the Python community, Eigen, VisIt even, and so I would > > say it is reasonable. I am mainly looking at a mismatch between different > > toolkits, but I would say using the same terminology as most other > > communities seems reasonable. > > Point taken, although we had a big-ish argument over on the Numpy > mailing list about the kinds of confusion that can arise in conflating > the memory layout with the index ordering - thread starting at: > > https://mail.python.org/pipermail/numpy-discussion/2013-March/065949.html > That is quite a thread! I wasn't trying to oversimplify, but didn't really want to get into a terminology debate. Like it or not many toolkits use this terminology, I first encountered it in Eigen, I am totally open to additional descriptions too. If others make sense people should use them, but please map them to this terminology. I don't want to relearn it, and the NumPy docs on this subject have confused me several times in the past! These are big volumes in many cases, so I am eager to avoid copies of the mismatched orders whatever we call them. The bridges to NumPy, ITK, and potentially other toolkits would be smoother if we could present a C ordered array to them as most default to that ordering anyway. I found the idea of a geometric transformation appealing, but raised it here in case there were better approaches. From marcus.hanwell at kitware.com Wed Jul 26 15:51:39 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 26 Jul 2017 15:51:39 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Thu, Jul 20, 2017 at 11:49 PM, Andras Lasso wrote: > > > My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. > > We?ve been working on this for several years, as a background task. Adding support in VTK for reading, processing, and displaying arbitrarily oriented images would simplify many VTK-based medical image computing applications. Some information about this effort is available here: > > https://docs.google.com/document/d/e/2PACX-1vQiHT2IpeCtfpphJ9vFtq_dQ3dJHsayZTcvJZUMWM9lhJdItd1qQed0449pOpYIfE3Bqgd2uZaXN4iR/pub > > I know that it is a sensitive topic and a large number of files are involved (around 400 core classes + test/examples), but in many cases the changes are trivial (changing a few lines in a class to indicate that it can accept oriented image) and it is not necessary to update all classes at once, but gradually, as the need emerges. > > I would love to hear from anyone who would be interested in having orientation support, have any comments or suggestions, or might be willing to contribute. > Thanks for the link, there is certainly some overlap (although this goes a little further) with what I was thinking of. I think it would be good to investigate the feasibility of this approach, do you think there are any major performance issues with supporting arbitrary orientations? Marcus From marcus.hanwell at kitware.com Wed Jul 26 15:57:34 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 26 Jul 2017 15:57:34 -0400 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: On Thu, Jul 20, 2017 at 12:57 PM, Berk Geveci wrote: > My approach with this kind of change has been to create a new subclass of > vtkDataSet. If you add some meta-data to vtkImageData that is then ignored > by all or most of algorithms, you will end up with confused users. You could > potentially do something at the executive layer that can automatically > transform this new dataset to vtkImageData when using vtkImageData > algorithms. It should be trivial to add support to the volume rendering code > after that. Yes, that was my concern about doing it little by little and potentially confusing many when it is ignored by filters not aware of ordering/orientation. There is also the question of how much time is involved and whether it is worth it - we have a working solution but it can be a pain, and from some of the responses it seems there are others feeling the pain. For our application we only need a limited set of classes to support it, and then it would hopefully act as a good starting point for other contributors to extend it as they feel the need. > > Given that we are looking at VTK-m for much of the future algorithm, I would > suggest that VTK-m natively supports both ordering. Then if we replace any > VTK algorithms with VTK-m implementations, it would work out of box. > Certainly, and integration between VTK and VTK-m should be able to adapt to the different layouts fairly seamlessly. Most of the toolkits I work with outside of VTK use the C ordering, offering Fortran ordering by passing in an extra parameter usually. VTK-m and vtk.js seem like good opportunities to support both out of the box as they are newer, I will see if we can pursue an additional type so that we can ensure it either works right or complains upfront. Thanks, Marcus From lasso at queensu.ca Wed Jul 26 18:45:01 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 26 Jul 2017 22:45:01 +0000 Subject: [vtk-developers] vtkImageData, C versus Fortran ordering In-Reply-To: References: Message-ID: > do you think there are any major performance issues with supporting arbitrary orientations? So far it seems that most of the cases there is no performance impact at all. Most of the cases at the lowest level a 4x4 homogeneous transformation matrix converts between voxel and physical coordinates already, so the difference is just where you can have non-zero elements in the rotation component of the matrix (in the diagonal only or everywhere). Andras -----Original Message----- From: Marcus D. Hanwell [mailto:marcus.hanwell at kitware.com] Sent: Wednesday, July 26, 2017 3:52 PM To: Andras Lasso Cc: Berk Geveci ; VTK Developers ; David Gobbi Subject: Re: [vtk-developers] vtkImageData, C versus Fortran ordering On Thu, Jul 20, 2017 at 11:49 PM, Andras Lasso wrote: > > > My approach with this kind of change has been to create a new subclass of vtkDataSet. If you add some meta-data to vtkImageData that is then ignored by all or most of algorithms, you will end up with confused users. > > We?ve been working on this for several years, as a background task. Adding support in VTK for reading, processing, and displaying arbitrarily oriented images would simplify many VTK-based medical image computing applications. Some information about this effort is available here: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs. > google.com%2Fdocument%2Fd%2Fe%2F2PACX-1vQiHT2IpeCtfpphJ9vFtq_dQ3dJHsay > ZTcvJZUMWM9lhJdItd1qQed0449pOpYIfE3Bqgd2uZaXN4iR%2Fpub&data=02%7C01%7C > lasso%40queensu.ca%7C8d0890b2989445d73f0f08d4d45fbc59%7Cd61ecb3b38b142 > d582c4efb2838b925c%7C1%7C0%7C636366955023304566&sdata=6jLorpDvFzq6aciZ > QnLJRaooJSrGsircXqrC1rCZTk4%3D&reserved=0 > > I know that it is a sensitive topic and a large number of files are involved (around 400 core classes + test/examples), but in many cases the changes are trivial (changing a few lines in a class to indicate that it can accept oriented image) and it is not necessary to update all classes at once, but gradually, as the need emerges. > > I would love to hear from anyone who would be interested in having orientation support, have any comments or suggestions, or might be willing to contribute. > Thanks for the link, there is certainly some overlap (although this goes a little further) with what I was thinking of. I think it would be good to investigate the feasibility of this approach, do you think there are any major performance issues with supporting arbitrary orientations? Marcus From andrew.amaclean at gmail.com Wed Jul 26 19:08:23 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 27 Jul 2017 09:08:23 +1000 Subject: [vtk-developers] =?utf-8?b?4oCLUmU6IDAsIE5VTEwgLT4gbnVsbHB0ciAo?= =?utf-8?q?Ken_Martin=29?= Message-ID: Ken, I just did a windows (Win 64, VS2017) release/debug build. All seems Ok Regards Andrew ---------- Forwarded message ---------- > From: Ken Martin > To: VTK Developers > Cc: > Bcc: > Date: Wed, 26 Jul 2017 14:19:34 -0400 > Subject: Re: [vtk-developers] 0, NULL -> nullptr > I have merged this as a new large commit. I'll try fixing any issues that > crop up on the nightlies tomorrow. There are still many uses of NULL in > comments and classes that did not build on my linux system (such as Win32 > and OSX specific classes) If you see uses of NULL or 0 in code you are > editing that should be nullptr, please update them. > > I did go beyond just clang-tidy so if you see issues/regressions with the > change let me know. > > Going forward in C++ code please use nullptr as it has better type safety > and overload resolution than NULL or 0. > > In comments I tried to use "nullptr" or "null" depending on the context as > opposed to NULL. > > Topics in flight may have merge conflicts (probably :-( ). > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Jul 27 10:27:50 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 27 Jul 2017 10:27:50 -0400 Subject: [vtk-developers] =?utf-8?b?4oCLUmU6IDAsIE5VTEwgLT4gbnVsbHB0ciAo?= =?utf-8?q?Ken_Martin=29?= In-Reply-To: References: Message-ID: Thanks! There were a few issues that I introduced that I believe there are now topics in flight to fix. Additionally I ran all the tests through ctidy (and only ctidy for those) so the tests should be a bit better about using nullptr now as well. That topic has merged. On Wed, Jul 26, 2017 at 7:08 PM, Andrew Maclean wrote: > Ken, > I just did a windows (Win 64, VS2017) release/debug build. All seems Ok > > > Regards > Andrew > > ---------- Forwarded message ---------- >> From: Ken Martin >> To: VTK Developers >> Cc: >> Bcc: >> Date: Wed, 26 Jul 2017 14:19:34 -0400 >> Subject: Re: [vtk-developers] 0, NULL -> nullptr >> I have merged this as a new large commit. I'll try fixing any issues that >> crop up on the nightlies tomorrow. There are still many uses of NULL in >> comments and classes that did not build on my linux system (such as Win32 >> and OSX specific classes) If you see uses of NULL or 0 in code you are >> editing that should be nullptr, please update them. >> >> I did go beyond just clang-tidy so if you see issues/regressions with the >> change let me know. >> >> Going forward in C++ code please use nullptr as it has better type safety >> and overload resolution than NULL or 0. >> >> In comments I tried to use "nullptr" or "null" depending on the context >> as opposed to NULL. >> >> Topics in flight may have merge conflicts (probably :-( ). >> >> >> > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- 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 robert.maynard at kitware.com Fri Jul 28 09:24:59 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 28 Jul 2017 09:24:59 -0400 Subject: [vtk-developers] VTK Development Survey Message-ID: Hi Everybody, The VTK team is always looking to attract new developers and improve the experience of developing VTK. As existing VTK developers it would be great to hear you feedback. To further that, we are putting out an anonymous survey to collect data on people's thoughts about the current software development process for VTK. https://goo.gl/forms/WlqyiF0sBTZT7klJ3 We will gather the results after August 1'st. Sorry for the delay on sending this to the VTK Developers mailing list. From david.gobbi at gmail.com Sun Jul 30 23:13:59 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Sun, 30 Jul 2017 21:13:59 -0600 Subject: [vtk-developers] Remove "PythonD" libs to simplify building and packaging. Message-ID: Hi All, I've put together patch that removes the intermediate wrapper libs (the PythonD libs). So instead of vtkCommonCorePythonD and vtkCommonCorePython, now there is only vtkCommonCorePython etc. https://gitlab.kitware.com/vtk/vtk/merge_requests/3075 Some tweaking is still needed, e.g. currently it assumes the modules are directly in the python path, and it won't work if the modules are put inside the vtk package directory. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.bauinger at essteyr.com Mon Jul 31 03:04:43 2017 From: christoph.bauinger at essteyr.com (Christoph Bauinger) Date: Mon, 31 Jul 2017 09:04:43 +0200 Subject: [vtk-developers] SPH Particles an shaders Message-ID: <01c785d8-39ce-5371-279f-7360b9fe9b8e@essteyr.com> Hello, I am looking for a renderer which can interactively display hundreds of millions or even billions of SPH particles. I tried with Paraview and saw that it is quite limited. So I want to use VTK in my own implementation and maybe adjust the shaders. Does anybody know if this is possible? Are there already solutions implemeneted in VTK to do that? Best regards, Christoph From abezotosniy at amcbridge.com Mon Jul 31 06:55:07 2017 From: abezotosniy at amcbridge.com (Oleksandr Bezotosniy) Date: Mon, 31 Jul 2017 03:55:07 -0700 (MST) Subject: [vtk-developers] ANGLE backend Message-ID: <1501498507045-5744216.post@n5.nabble.com> Hi, Our application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. And we have requirement that it must to run over RDP. Since OpenGL has limited support over Microsoft's Remote Desktop we patched VTK to use ANGLE instead OpenGL. As baseline version we took VTK v8.0.0.rc2. Please see attachment: vtk8.diff I think that such option of switching between different backend will be useful and for other customers. Does it make sense to include it in official VTK? Thanks, Alex -- View this message in context: http://vtk.1045678.n5.nabble.com/ANGLE-backend-tp5744216.html Sent from the VTK - Dev mailing list archive at Nabble.com. From spir.robert at gmail.com Mon Jul 31 08:21:26 2017 From: spir.robert at gmail.com (=?iso-8859-2?B?UvNiZXJ0IKlwaXI=?=) Date: Mon, 31 Jul 2017 14:21:26 +0200 Subject: [vtk-developers] ANGLE backend In-Reply-To: <1501498507045-5744216.post@n5.nabble.com> References: <1501498507045-5744216.post@n5.nabble.com> Message-ID: <002301d309f7$888c3b20$99a4b160$@gmail.com> Hi Alex, this looks very interesting. We are also using vtk through remote desktop, but we are using only machines with AMD graphics, where opengl through remote desktop works. (NVIDIA is blocking it on all cards except quadro) I tried building VTK with your patch, but I'm getting multiple errors with opengl i.e. Rendering\ContextOpenGL2\vtkOpenGLContextDevice3D.cxx(488): error C2065: 'GL_LINE': undeclared identifier Rendering\ContextOpenGL2\vtkOpenGLContextDevice3D.cxx(509): error C3861: 'glPointSize': identifier not found Rendering\ContextOpenGL2\vtkOpenGLContextBufferId.cxx(143): error C2065: 'GL_DRAW_BUFFER': undeclared identifier Rendering\ContextOpenGL2\vtkOpenGLContextBufferId.cxx(145): error C2065: 'GL_ALPHA_TEST': undeclared identifier During CMake configuration I added variable VTK_USE_QTANGLE set to true and otherwise used standard configuration with qt5 enabled. do you have any idea, what went wrong? Thanks, Robert -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Oleksandr Bezotosniy Sent: Monday, July 31, 2017 12:55 PM To: vtk-developers at vtk.org Subject: [vtk-developers] ANGLE backend Hi, Our application uses VTK 7.0 (OpenGL 2 module) for rendering on Windows platform. And we have requirement that it must to run over RDP. Since OpenGL has limited support over Microsoft's Remote Desktop we patched VTK to use ANGLE instead OpenGL. As baseline version we took VTK v8.0.0.rc2. Please see attachment: vtk8.diff I think that such option of switching between different backend will be useful and for other customers. Does it make sense to include it in official VTK? Thanks, Alex -- View this message in context: http://vtk.1045678.n5.nabble.com/ANGLE-backend-tp5744216.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 abezotosniy at amcbridge.com Mon Jul 31 09:11:34 2017 From: abezotosniy at amcbridge.com (Oleksandr Bezotosniy) Date: Mon, 31 Jul 2017 06:11:34 -0700 (MST) Subject: [vtk-developers] ANGLE backend In-Reply-To: <002301d309f7$888c3b20$99a4b160$@gmail.com> References: <1501498507045-5744216.post@n5.nabble.com> <002301d309f7$888c3b20$99a4b160$@gmail.com> Message-ID: <1501506694920-5744219.post@n5.nabble.com> Hi Robert, We don't need vtkRenderingContextOpenGL2 so we excluded it from build and patched only required modules. We use the following command to build VTK: cmake -G"Visual Studio 14 2015 Win64" ../ -DCMAKE_INSTALL_PREFIX="%CD%/install" -DCMAKE_PREFIX_PATH="%QT_DIR%" -DCMAKE_CXX_MP_FLAG=ON -DCMAKE_DEBUG_POSTFIX="d" -DVTK_QT_VERSION=5 -DVTK_BUILD_QT_DESIGNER_PLUGIN=OFF -DVTK_CUSTOM_LIBRARY_SUFFIX="" -DVTK_RENDERING_BACKEND="OpenGL2" -DModule_vtkGUISupportQt=ON -DModule_vtkGUISupportQtOpenGL=ON -DModule_vtkRenderingQt=ON -DBUILD_DOCUMENTATION=OFF -DBUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=OFF -DVTK_USE_QTANGLE=ON -DOPENGL_ES_VERSION="3.0" -DModule_vtkRenderingOpenGL2=ON -DModule_vtkRenderingAnnotation=ON -DModule_vtkInteractionWidgets=ON -DVTK_Group_Rendering:BOOL=OFF -DVTK_Group_StandAlone:BOOL=OFF -DVTK_Group_Imaging:BOOL=OFF -DVTK_Group_MPI:BOOL=OFF -DVTK_Group_Views:BOOL=OFF -DVTK_Group_Qt:BOOL=OFF -DVTK_Group_Tk:BOOL=OFF -DVTK_Group_Web:BOOL=OFF ANGLE doesn't have some OpenGL function and definitions. So if you need this module you just need to wrap these error like the following: #if GL_ES_VERSION_3_0 != 1 glPointSize() #endif Thanks, Alex -- View this message in context: http://vtk.1045678.n5.nabble.com/ANGLE-backend-tp5744216p5744219.html Sent from the VTK - Dev mailing list archive at Nabble.com. From utkarsh.ayachit at kitware.com Mon Jul 31 11:07:47 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 31 Jul 2017 11:07:47 -0400 Subject: [vtk-developers] Remove "PythonD" libs to simplify building and packaging. In-Reply-To: References: Message-ID: That is very cool! Thanks for doing this, David! On Sun, Jul 30, 2017 at 11:13 PM, David Gobbi wrote: > Hi All, > > I've put together patch that removes the intermediate wrapper libs (the > PythonD libs). So instead of vtkCommonCorePythonD and vtkCommonCorePython, > now there is only vtkCommonCorePython etc. > > https://gitlab.kitware.com/vtk/vtk/merge_requests/3075 > > Some tweaking is still needed, e.g. currently it assumes the modules are > directly in the python path, and it won't work if the modules are put inside > the vtk package directory. > > - David > > _______________________________________________ > 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 sur.chiranjib at gmail.com Mon Jul 31 13:35:16 2017 From: sur.chiranjib at gmail.com (Chiranjib Sur) Date: Mon, 31 Jul 2017 23:05:16 +0530 Subject: [vtk-developers] SPH Particles an shaders In-Reply-To: <01c785d8-39ce-5371-279f-7360b9fe9b8e@essteyr.com> References: <01c785d8-39ce-5371-279f-7360b9fe9b8e@essteyr.com> Message-ID: Hi Christoph, I use ParaView and VTK extensively mostly for building models for SPH and convert them to discrete particles. I have scaled upto 100 million particles (never tested beyond that) using in built VTK libraries and also using interactive ParaView. >From your post, I am not so sure, what you intend to do. Could you please explain a bit more of your problem? Probably, you are aware that current VTK (and PV) has some specialised classes to handle interpolation for SPH. May be that's worth looking. HTH, Thanks, Chiranjib On Mon, Jul 31, 2017 at 12:34 PM, Christoph Bauinger < christoph.bauinger at essteyr.com> wrote: > Hello, > > I am looking for a renderer which can interactively display hundreds of > millions or even billions of SPH particles. I tried with Paraview and saw > that it is quite limited. So I want to use VTK in my own implementation and > maybe adjust the shaders. > > Does anybody know if this is possible? Are there already solutions > implemeneted in VTK to do that? > > Best regards, > Christoph > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Jul 31 14:25:10 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 31 Jul 2017 14:25:10 -0400 Subject: [vtk-developers] VTK Development Survey In-Reply-To: References: Message-ID: I would like to remind everyone that the survey closes tomorrow. On Fri, Jul 28, 2017 at 9:24 AM, Robert Maynard wrote: > Hi Everybody, > > The VTK team is always looking to attract new developers and improve > the experience of developing VTK. As existing VTK developers it would > be great to hear you feedback. > > To further that, we are putting out an anonymous survey to collect > data on people's thoughts about the current software development > process for VTK. > > https://goo.gl/forms/WlqyiF0sBTZT7klJ3 > > We will gather the results after August 1'st. Sorry for the delay on > sending this to the VTK Developers mailing list.