Nabble - VTK

Multiple glcontext (vtkXOpenGLRenderWidow) and sharing resources.

2009-12-01T00:33:20Z

Hi all!
I have a question that may have been asked before. But I wonder if
there is something you are planing to do?

I am working on making a display containing multiple views.
I use QvtkWidget(vtkXOpenGlRenderWindow) for one view which displays 2D
images. I will have up to 9 views with images from the same volume.
I also want to have images from different volumes view together in the
views(overlay).

Will it be possible to have multiple
vtkRenderWindow to share the same data set(resources)?

I have solved this by using glCreateContext with shared list in
vtkXOpenGLRenderWidow.
Are there any potential risk in doing this?

Regards
Petter Wake
System developer @ SonoWand

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: QVTK resizing on Windows XP

2009-11-30T23:45:38Z

After some tests I can report that this problem does not occur in paraview. I did not really expect that paraview raises the same rendering issue as my application also works fine on XP when built as standalone program.
The QVTKWidget cut-off/update/rendering problems only exist when the GUI is called from the DLL interface as there are some weird event loop interferences with the client application's event loop. This may (occasionally) prevent some necessary internal events to fire.

lars

-------- Original-Nachricht --------
> Datum: Mon, 30 Nov 2009 20:47:49 +0100
> Von: "Lars Friedrich Lars" <lars-friedrich@...>
> An: Clinton Stimpson <clinton@...>, vtkusers@...
> Betreff: Re: [vtkusers] QVTK resizing on Windows XP

> Hello Clint,
>
> I will do tests with Paraview tomorrow and report the results to you. I
> did not use Paraview for a while, but I cannot remember comparable problems
> with it.
>
> lars
>
>
> -------- Original-Nachricht --------
> > Datum: Mon, 30 Nov 2009 12:13:05 -0700
> > Von: Clinton Stimpson <clinton@...>
> > An: vtkusers@...
> > Betreff: Re: [vtkusers] QVTK resizing on Windows XP
>
> >
> > Oh, then maybe the saveImageToCache() is causing an extra render that is
> > "solving" you problem. Do you see the same problem in an application
> like
> > paraview, which uses splitters too?
> >
> > Clint
> >
> > On Monday 30 November 2009 12:07:35 pm Lars Friedrich Lars wrote:
> > > No, I do not call setAutomaticImageCacheEnabled(true) in my
> application;
> > > this features is deactivated. Some cross-platform experiments in the
> > past
> > > with this flag set to TRUE showed me that it does not reliably work in
> > 100%
> > > of the cases - as you confirmed below. I just call the related methods
> > > after resizing the widget as explained in the previous mail. My
> > application
> > > is basically built as standalone application and - on demand (on
> windows
> > > systems) - with an additional shared lib interface. The described
> > > workaround works on windows Vista / XP / 2000 for the standalone
> version
> > > and the shared lib interface; it also works on Ubuntu 64 bit.
> > >
> > > lars
> > >
> > >
> > > -------- Original-Nachricht --------
> > >
> > > > Datum: Mon, 30 Nov 2009 08:21:04 -0700
> > > > Von: Clinton Stimpson <clinton@...>
> > > > An: vtkusers@...
> > > > Betreff: Re: [vtkusers] QVTK resizing on Windows XP
> > > >
> > > >
> > > > Are you calling setAutomaticImageCacheEnabled(true) to enable image
> > > > caching with it?
> > > > Maybe you should avoid doing this.
> > > > I don't know if its been found to be useful in practice as it was
> once
> > > > tried in ParaView but it didn't work too well. Whether one has
> > problems
> > > > with it is dependent on the windowing system.
> > > >
> > > > Personally, I think the problem QVTKWidget's image caching tries to
> > > > solve, is best solved by the windowing system. Mac OSX and some
> Linux
> > > > desktops already do it.
> > > >
> > > > Clint
> > > >
> > > > On 11/30/2009 08:04 AM, Lars Friedrich Lars wrote:
> > > > > Hello,
> > > > >
> > > > > I just would like to report a solution to the problem outlined in
> > the
> > > >
> > > > previous mail:
> > > > > It seems to be a pure QVTKWidget problem; after resizing the
> > QVTKWidget
> > > >
> > > > invoking the following code-cascade works to successfully render the
> > > >
> > > > complete viewport:
> > > > > qvtk->markCachedImageAsDirty();
> > > > > qvtk->saveImageToCache();
> > > > > qvtk->GetRenderWindow()->Render();
> > > > >
> > > > > However, it is really interesting that this problem occurs on
> > Windows
> > > > > XP
> > > >
> > > > only ...
> > > >
> > > > > I must admit that it is a very special situation as the Qt-based
> GUI
> > is
> > > >
> > > > implemented within a DLL and called via a Delphi-client-application.
> > You
> > > > can read more about the related signal/slot problems here:
> > > >
> >
> http://lists.trolltech.com/pipermail/qt-interest/2009-November/014826.htm
> > > >l
> > > >
> > > > > Maybe there are other people struggling around with similar
> problems
> > > > > who
> > > >
> > > > can take advantage of this 'solution'.
> > > >
> > > > > regards,
> > > > >
> > > > > lars
> > > > >
> > > > >
> > > > > -------- Original-Nachricht --------
> > > > >
> > > > >> Datum: Mon, 23 Nov 2009 20:31:22 +0100
> > > > >> Von: "Lars Friedrich Lars"<lars-friedrich@...>
> > > > >> An: vtkusers@...
> > > > >> Betreff: [vtkusers] QVTK resizing on Windows XP
> > > > >>
> > > > >>
> > > > >> Hello,
> > > > >>
> > > > >> I have an application which uses multiple QVTKWidgets to render
> > > >
> > > > different
> > > >
> > > > >> scenes (as shown on the attached screen shots). During run-time I
> > can
> > > > >> resize the widgets' size with the help of splitters. Normally a
> > > >
> > > > VTK-scene (the
> > > >
> > > > >> vtkRenderWindow ...) immediately adapts to the QVTKWidget's size.
> > But
> > > >
> > > > on
> > > >
> > > > >> windows XP I am facing serious problems: as can be seen von the
> > second
> > > >
> > > > screen
> > > >
> > > > >> shot, the vtkRenderWindow gets cut at the bottom.
> > > > >>
> > > > >> Did someone face similiar problems?
> > > > >>
> > > > >> It may the worth to annotate that the interactor (e.g. rotating
> the
> > > > >> camera) still works in the cut area at the bottom, but the scene
> is
> > > > >> not
> > > >
> > > > rendered.
> > > >
> > > > >> Furthermore, this problem solely exists on Windows XP (32 and 64
> > bit)
> > > > >> -
> > > >
> > > > it
> > > >
> > > > >> works on Windows 2000 / Vista / 7. It also works in an ordinary
> > > >
> > > > executable
> > > >
> > > > >> on Windows XP, but not when my user interface is called out of a
> > DLL.
> > > > >>
> > > > >> I guess there are some problems with some openGL buffers in the
> > > >
> > > > background
> > > >
> > > > >> and the device context. Are there possibilities to force the
> render
> > > >
> > > > window
> > > >
> > > > >> to reallocate its buffer?
> > > > >>
> > > > >> Can you help me, please? I am kind of desperate.
> > > > >>
> > > > >> regards,
> > > > >>
> > > > >> lars
> > > > >>
> > > > >> --
> > > > >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > > > >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> > > >
> > > > _______________________________________________
> > > > Powered by www.kitware.com
> > > >
> > > > Visit other Kitware open-source projects at
> > > > http://www.kitware.com/opensource/opensource.html
> > > >
> > > > Please keep messages on-topic and check the VTK FAQ at:
> > > > http://www.vtk.org/Wiki/VTK_FAQ
> > > >
> > > > Follow this link to subscribe/unsubscribe:
> > > > http://www.vtk.org/mailman/listinfo/vtkusers
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at:
> > http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.vtk.org/mailman/listinfo/vtkusers
>
> --
> Endlich! Das Debüt-Album von Pop-Diva Sarah Kreuz ist da!
>
> Jetzt bei GMX Musik Downloads. http://portal.gmx.net/de/go/musik01
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers

--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: Textures

2009-11-30T16:35:55Z

This is a good idea. But how does this work for a cube? How is it possible to add an Actor/Texture to each side of the cube? Do you have a code example?

Andy

Von: Wes Turner [mailto:wes.turner@...]
Gesendet: Dienstag, 24. November 2009 23:02
An: André Rohde
Cc: vtkusers@...
Betreff: Re: [vtkusers] Textures

I believe that there is a limit of one texture per vtkActor, which gives you two alternatives. Either you need to combine your 6 views into a single texture or you need to make each side of the cube a separate actor.

- Wes

2009/11/24 "André Rohde" <Rohy@...>

Dear Vtk Users,
i´d like to map one texture to each side of a cube (6 sides = 6 different textures) from different arrays. (Only one Array in my Code yet)
Mapping one texture to the cube works fine for me. But i don´t have an idea how this is gonna work for each side of a cube. The general idea behind my program is to take an specific amount of snapshots from a camera and generate an array/cube of this pictures in vtk.

Here´s my Code:

//First Array > Image Data should be mapped to the first side of the cube...
vtkFloatArray *vtkArray = vtkFloatArray::New();
vtkArray->SetNumberOfComponents(1);
vtkArray->SetNumberOfTuples(1392*1040);

unsigned indexInverted = 0;

for(int k = 0; k < 1040; k++)
{
for(int l = 0; l < 1392; l++)
{
//pcFrame contains the ImageData from the Camera
vtkArray->SetTuple1(indexInverted,pcFrame[((1392*1040)-(1392*(k+1)))+l]);
indexInverted++;
}
}

vtkImageData *myImage = vtkImageData::New();
myImage->SetDimensions(1392,1040,1);
myImage->SetSpacing(1,1,1);
myImage->SetOrigin(0,0,0);
myImage->SetNumberOfScalarComponents(1);
myImage->SetScalarTypeToFloat();
myImage->AllocateScalars();
myImage->GetPointData()->SetScalars(vtkArray);

int i;
//Cube Coordinates
static float x[8][3]={{0,0,0}, {1392,0,0}, {1392,1040,0}, {0,1040,0}, {0,0,700}, {1392,0,700}, {1392,1040,700}, {0,1040,700}};

static vtkIdType pts[6][4]={{0,1,2,3},{4,5,6,7}, {0,1,5,4},{1,2,6,5}, {2,3,7,6}, {3,0,4,7}};

// Color LookupTable
vtkLookupTable *table = vtkLookupTable::New();
table->SetTableRange(0,255);
table->SetValueRange(0.0,1.0);
table->SetSaturationRange(0.0,0.0);
table->SetHueRange(0.0,0.0);
table->SetAlphaRange(1.0,1.0);
table->SetNumberOfColors(256);
table->Build();

// Create texture
vtkTexture *atext = vtkTexture::New();
atext->SetInput(myImage);
atext->SetLookupTable(table);
atext->InterpolateOff();

// We'll create the building blocks of polydata including data attributes.
vtkPolyData *cube = vtkPolyData::New();
vtkPoints *points = vtkPoints::New();
vtkCellArray *polys = vtkCellArray::New();
vtkFloatArray *tCoords = vtkFloatArray::New();

tCoords->SetNumberOfComponents(2);
tCoords->InsertTuple2(0, 0, 0);
tCoords->InsertTuple2(1, 1, 0);
tCoords->InsertTuple2(2, 1, 1);
tCoords->InsertTuple2(3, 0, 1);
tCoords->InsertTuple2(4, 0, 0);
tCoords->InsertTuple2(5, 1, 0);
tCoords->InsertTuple2(6, 1, 1);
tCoords->InsertTuple2(7, 0, 1);

// Load the point, cell, and data attributes.
for (i=0; i<8; i++) points->InsertPoint(i,x[i]);
for (i=0; i<6; i++) polys->InsertNextCell(4,pts[i]);

// We now assign the pieces to the vtkPolyData.
cube->SetPoints(points);
points->Delete();
cube->SetPolys(polys);
polys->Delete();
cube->GetPointData()->SetTCoords(tCoords);
tCoords->Delete();

vtkPolyDataMapper *cubeMapper = vtkPolyDataMapper::New();
cubeMapper->SetInput(cube);
vtkActor *cubeActor = vtkActor::New();
cubeActor->SetMapper(cubeMapper);
cubeActor->SetTexture(atext);

// The usual rendering stuff.
vtkCamera *camera = vtkCamera::New();
camera->SetPosition(1,1,1);
camera->SetFocalPoint(0,0,0);

vtkRenderer *renderer = vtkRenderer::New();
vtkRenderWindow *renWin = vtkRenderWindow::New();
renWin->AddRenderer(renderer);

vtkRenderWindowInteractor *iren = vtkRenderWindowInteractor::New();
vtkWidget->SetRenderWindow(renWin);

renderer->AddActor(cubeActor);
renderer->SetActiveCamera(camera);
renderer->ResetCamera();
renderer->SetBackground(0.4,0.5,0.6);

//interact with data
renWin->Render();
iren->Start();

with kind regards
Andy
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

--
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T14:41:43Z

thanks and till tomorrow !!!

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> It hardly makes any difference. If you use one reslice, then it has
> to output several slices. If you use multiple reslices, then each one
> only produces a single slice. Overall, the amount of data in memory
> is the same.
>
> David
>
>
> On Mon, Nov 30, 2009 at 3:30 PM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> last question for today, how memory hungry is that setup (one anything
>> per slice)?
>>
>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>> On Mon, Nov 30, 2009 at 2:49 PM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> reader.GetOutput().Update() is not the same that reader.Update()?
>>>
>>> When VTK 5.0 was released, data.Update() did a little bit extra that
>>> algorithm.Update() did not do, i.e. in VTK 5.0 the pipeline was newly
>>> designed and had some bugs. Now the pipeline bugs are fixed, but I
>>> still always call update on data out of habit.
>>>
>>>
>>>> if U have a renderer per slice, why to have a reslice for every render
>>>> and not just one?
>>>
>>> Because I find that the easiest way to use vtkImageReslice is to make
>>> it output just one slice. It is just my preference, in other words.
>>>
>>>
>>>> How do I achieve that if I change the window/level in a renderer, all
>>>> images in the 4x4 configuration get updated with the same
>>>> window/level?
>>>
>>> Easy. Use the same vtkLookupTable for all images. In your data
>>> pipeline, use vtkImageMapToColors() to color the data. I cannot help
>>> you with vtkImageColorViewer because I never use that class.
>>>
>>> David
>>>
>>>
>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>> Usually I use a separate renderer for each slice. This also means a
>>>>> separate reslice, image actor, etc.
>>>>>
>>>>> For this to work efficiently, you must force the reader to read all
>>>>> the whole dicom series, like this:
>>>>>
>>>>> reader.GetOutput().Update()
>>>>>
>>>>> If you don't do this, then the reader will only read one slice at a
>>>>> time, so if you are displaying 4x4 then it will go to the disk 16
>>>>> times on every render. By calling update on the the reader, you force
>>>>> the whole series into memory.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
>>>>> <jmrbcu@...> wrote:
>>>>>> thanks, and another question:
>>>>>>
>>>>>> I need to display the images in a dicom serie in several
>>>>>> configurations: just one image, 2 images side by side, 2x2 images and
>>>>>> so on. Which is the recommended way to display those configurations in
>>>>>> a render window, with several renderers or with several image actors?
>>>>>>
>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>>>>>>> <jmrbcu@...> wrote:
>>>>>>>> yes, thanks, in fact this is my pattern example but, in this example
>>>>>>>> the sagital view is flipped, why is that?
>>>>>>>
>>>>>>> You are complaining because the head is facing right instead of
>>>>>>> facing
>>>>>>> left?? It is still sagittal.
>>>>>>>
>>>>>>>> PS: So, to use ImageReslice for an dicom image viewer is not a
>>>>>>>> problem?
>>>>>>>
>>>>>>> No problem at all. Plenty of people use it for dicom. The only
>>>>>>> restrictions are the following:
>>>>>>>
>>>>>>> 1) the spacing must be constant
>>>>>>>
>>>>>>> 2) the gantry must not be tilted
>>>>>>>
>>>>>>> These restrictions are true for all vtkImageData. Fortunately, CT
>>>>>>> and
>>>>>>> MRI almost always use constant slice spacing, so that is never a
>>>>>>> problem. CT gantry tilt can be fairly common, though, so any dicom
>>>>>>> image viewer should check for it. MR images never have gantry tilt.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>>> I didn't give the full path for the example in my last email. Here
>>>>>>>>> it
>>>>>>>>> is:
>>>>>>>>>
>>>>>>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi
>>>>>>>>> <david.gobbi@...>
>>>>>>>>> wrote:
>>>>>>>>>> Because no-one has contributed a reslicng image viewer to VTK yet.
>>>>>>>>>> I
>>>>>>>>>> would like to do so myself, but I don't know when I will have the
>>>>>>>>>> time.
>>>>>>>>>>
>>>>>>>>>> I did submit a python reslicing example to VTK that you might find
>>>>>>>>>> useful:
>>>>>>>>>>
>>>>>>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>>> why is that?
>>>>>>>>>>>
>>>>>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for
>>>>>>>>>>>> your
>>>>>>>>>>>> application. That is the closest thing to a generic reslicing
>>>>>>>>>>>> image
>>>>>>>>>>>> viewer that VTK has.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too)
>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>> use
>>>>>>>>>>>>> vtkImageReslice for changing the slice orientation (axial,
>>>>>>>>>>>>> sagital
>>>>>>>>>>>>> and
>>>>>>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos
>>>>>>>>>>>>> ignoramos
>>>>>>>>>>>>> lo
>>>>>>>>>>>>> mismo.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el
>>>>>>>>>>>>> titanic
>>>>>>>>>>>>> por profesionales
>>>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>>>>
>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos
>>>>>>>>>>> ignoramos
>>>>>>>>>>> lo
>>>>>>>>>>> mismo.
>>>>>>>>>>>
>>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el
>>>>>>>>>>> titanic
>>>>>>>>>>> por profesionales
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>> Centro de Biofisica Medica
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>> lo
>>>>>>>> mismo.
>>>>>>>>
>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>> por profesionales
>>>>>>>> -----------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>> Centro de Biofisica Medica
>>>>>> -----------------------------------------------------------------
>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>>> mismo.
>>>>>>
>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>> por profesionales
>>>>>> -----------------------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>>
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

--
Lic. José M. Rodriguez Bacallao
Centro de Biofisica Medica
-----------------------------------------------------------------
Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.

Recuerda: El arca de Noe fue construida por aficionados, el titanic
por profesionales
-----------------------------------------------------------------
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T14:37:01Z

It hardly makes any difference. If you use one reslice, then it has
to output several slices. If you use multiple reslices, then each one
only produces a single slice. Overall, the amount of data in memory
is the same.

David

On Mon, Nov 30, 2009 at 3:30 PM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:

> last question for today, how memory hungry is that setup (one anything
> per slice)?
>
> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> On Mon, Nov 30, 2009 at 2:49 PM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> reader.GetOutput().Update() is not the same that reader.Update()?
>>
>> When VTK 5.0 was released, data.Update() did a little bit extra that
>> algorithm.Update() did not do, i.e. in VTK 5.0 the pipeline was newly
>> designed and had some bugs. Now the pipeline bugs are fixed, but I
>> still always call update on data out of habit.
>>
>>
>>> if U have a renderer per slice, why to have a reslice for every render
>>> and not just one?
>>
>> Because I find that the easiest way to use vtkImageReslice is to make
>> it output just one slice. It is just my preference, in other words.
>>
>>
>>> How do I achieve that if I change the window/level in a renderer, all
>>> images in the 4x4 configuration get updated with the same
>>> window/level?
>>
>> Easy. Use the same vtkLookupTable for all images. In your data
>> pipeline, use vtkImageMapToColors() to color the data. I cannot help
>> you with vtkImageColorViewer because I never use that class.
>>
>> David
>>
>>
>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>> Usually I use a separate renderer for each slice. This also means a
>>>> separate reslice, image actor, etc.
>>>>
>>>> For this to work efficiently, you must force the reader to read all
>>>> the whole dicom series, like this:
>>>>
>>>> reader.GetOutput().Update()
>>>>
>>>> If you don't do this, then the reader will only read one slice at a
>>>> time, so if you are displaying 4x4 then it will go to the disk 16
>>>> times on every render. By calling update on the the reader, you force
>>>> the whole series into memory.
>>>>
>>>> David
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
>>>> <jmrbcu@...> wrote:
>>>>> thanks, and another question:
>>>>>
>>>>> I need to display the images in a dicom serie in several
>>>>> configurations: just one image, 2 images side by side, 2x2 images and
>>>>> so on. Which is the recommended way to display those configurations in
>>>>> a render window, with several renderers or with several image actors?
>>>>>
>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>>>>>> <jmrbcu@...> wrote:
>>>>>>> yes, thanks, in fact this is my pattern example but, in this example
>>>>>>> the sagital view is flipped, why is that?
>>>>>>
>>>>>> You are complaining because the head is facing right instead of facing
>>>>>> left?? It is still sagittal.
>>>>>>
>>>>>>> PS: So, to use ImageReslice for an dicom image viewer is not a
>>>>>>> problem?
>>>>>>
>>>>>> No problem at all. Plenty of people use it for dicom. The only
>>>>>> restrictions are the following:
>>>>>>
>>>>>> 1) the spacing must be constant
>>>>>>
>>>>>> 2) the gantry must not be tilted
>>>>>>
>>>>>> These restrictions are true for all vtkImageData. Fortunately, CT and
>>>>>> MRI almost always use constant slice spacing, so that is never a
>>>>>> problem. CT gantry tilt can be fairly common, though, so any dicom
>>>>>> image viewer should check for it. MR images never have gantry tilt.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>> I didn't give the full path for the example in my last email. Here
>>>>>>>> it
>>>>>>>> is:
>>>>>>>>
>>>>>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>>>>>>> wrote:
>>>>>>>>> Because no-one has contributed a reslicng image viewer to VTK yet.
>>>>>>>>> I
>>>>>>>>> would like to do so myself, but I don't know when I will have the
>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>> I did submit a python reslicing example to VTK that you might find
>>>>>>>>> useful:
>>>>>>>>>
>>>>>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>> why is that?
>>>>>>>>>>
>>>>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for
>>>>>>>>>>> your
>>>>>>>>>>> application. That is the closest thing to a generic reslicing
>>>>>>>>>>> image
>>>>>>>>>>> viewer that VTK has.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't
>>>>>>>>>>>> use
>>>>>>>>>>>> vtkImageReslice for changing the slice orientation (axial,
>>>>>>>>>>>> sagital
>>>>>>>>>>>> and
>>>>>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos
>>>>>>>>>>>> ignoramos
>>>>>>>>>>>> lo
>>>>>>>>>>>> mismo.
>>>>>>>>>>>>
>>>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el
>>>>>>>>>>>> titanic
>>>>>>>>>>>> por profesionales
>>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>>
>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>>
>>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>>>
>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>>>> lo
>>>>>>>>>> mismo.
>>>>>>>>>>
>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>>>> por profesionales
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>> Centro de Biofisica Medica
>>>>>>> -----------------------------------------------------------------
>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>>>> mismo.
>>>>>>>
>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>> por profesionales
>>>>>>> -----------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lic. José M. Rodriguez Bacallao
>>>>> Centro de Biofisica Medica
>>>>> -----------------------------------------------------------------
>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>> mismo.
>>>>>
>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>> por profesionales
>>>>> -----------------------------------------------------------------
>>>>>
>>>>
>>>
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>>
>>
>
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T14:30:31Z

last question for today, how memory hungry is that setup (one anything
per slice)?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> On Mon, Nov 30, 2009 at 2:49 PM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> reader.GetOutput().Update() is not the same that reader.Update()?
>
> When VTK 5.0 was released, data.Update() did a little bit extra that
> algorithm.Update() did not do, i.e. in VTK 5.0 the pipeline was newly
> designed and had some bugs. Now the pipeline bugs are fixed, but I
> still always call update on data out of habit.
>
>
>> if U have a renderer per slice, why to have a reslice for every render
>> and not just one?
>
> Because I find that the easiest way to use vtkImageReslice is to make
> it output just one slice. It is just my preference, in other words.
>
>
>> How do I achieve that if I change the window/level in a renderer, all
>> images in the 4x4 configuration get updated with the same
>> window/level?
>
> Easy. Use the same vtkLookupTable for all images. In your data
> pipeline, use vtkImageMapToColors() to color the data. I cannot help
> you with vtkImageColorViewer because I never use that class.
>
> David
>
>
>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>> Usually I use a separate renderer for each slice. This also means a
>>> separate reslice, image actor, etc.
>>>
>>> For this to work efficiently, you must force the reader to read all
>>> the whole dicom series, like this:
>>>
>>> reader.GetOutput().Update()
>>>
>>> If you don't do this, then the reader will only read one slice at a
>>> time, so if you are displaying 4x4 then it will go to the disk 16
>>> times on every render. By calling update on the the reader, you force
>>> the whole series into memory.
>>>
>>> David
>>>
>>>
>>> On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> thanks, and another question:
>>>>
>>>> I need to display the images in a dicom serie in several
>>>> configurations: just one image, 2 images side by side, 2x2 images and
>>>> so on. Which is the recommended way to display those configurations in
>>>> a render window, with several renderers or with several image actors?
>>>>
>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>>>>> <jmrbcu@...> wrote:
>>>>>> yes, thanks, in fact this is my pattern example but, in this example
>>>>>> the sagital view is flipped, why is that?
>>>>>
>>>>> You are complaining because the head is facing right instead of facing
>>>>> left?? It is still sagittal.
>>>>>
>>>>>> PS: So, to use ImageReslice for an dicom image viewer is not a
>>>>>> problem?
>>>>>
>>>>> No problem at all. Plenty of people use it for dicom. The only
>>>>> restrictions are the following:
>>>>>
>>>>> 1) the spacing must be constant
>>>>>
>>>>> 2) the gantry must not be tilted
>>>>>
>>>>> These restrictions are true for all vtkImageData. Fortunately, CT and
>>>>> MRI almost always use constant slice spacing, so that is never a
>>>>> problem. CT gantry tilt can be fairly common, though, so any dicom
>>>>> image viewer should check for it. MR images never have gantry tilt.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>>
>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>> I didn't give the full path for the example in my last email. Here
>>>>>>> it
>>>>>>> is:
>>>>>>>
>>>>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>>>>>> wrote:
>>>>>>>> Because no-one has contributed a reslicng image viewer to VTK yet.
>>>>>>>> I
>>>>>>>> would like to do so myself, but I don't know when I will have the
>>>>>>>> time.
>>>>>>>>
>>>>>>>> I did submit a python reslicing example to VTK that you might find
>>>>>>>> useful:
>>>>>>>>
>>>>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>> why is that?
>>>>>>>>>
>>>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for
>>>>>>>>>> your
>>>>>>>>>> application. That is the closest thing to a generic reslicing
>>>>>>>>>> image
>>>>>>>>>> viewer that VTK has.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't
>>>>>>>>>>> use
>>>>>>>>>>> vtkImageReslice for changing the slice orientation (axial,
>>>>>>>>>>> sagital
>>>>>>>>>>> and
>>>>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos
>>>>>>>>>>> ignoramos
>>>>>>>>>>> lo
>>>>>>>>>>> mismo.
>>>>>>>>>>>
>>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el
>>>>>>>>>>> titanic
>>>>>>>>>>> por profesionales
>>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>>
>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>>
>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>>
>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>>> lo
>>>>>>>>> mismo.
>>>>>>>>>
>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>>> por profesionales
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>> Centro de Biofisica Medica
>>>>>> -----------------------------------------------------------------
>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>>> mismo.
>>>>>>
>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>> por profesionales
>>>>>> -----------------------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>>
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

From forum: VTK - Users

Re: how to get Cell ID?

2009-11-30T14:26:28Z

On Thu, Nov 12, 2009 at 8:35 AM, Grzegorz Pytel <bioinfguy@...> wrote:

> I want to get cell id while traversing vtkCellArray. How can I get it?
> Regards,
> Gregory
> This is my code:
> vtkCellArray * CA = this->data->GetPolys();
> CA->InitTraversal();
> vtkIdType npts;
> vtkIdType *pts;
>
> int i=0;
> while(CA->GetNextCell(npts,pts))
> {
> glBegin(GL_TRIANGLES);
> for (int j = 0; j < npts; ++j)
> {
> if (i == 0)
> {
> //double * p = points->GetPoint(pts[j]);
> double * p = this->data->GetPoint(pts[j]);
> points->SetPoint(pts[j], p[0] - 0.3, p[1], p[2]);
> }
> double *p = points->GetPoint(pts[j]);
> double x = p[0];
> double y = p[1];
> double z = p[2];
> glVertex3f((float)x,(float)y,(float)z);
> //cout << endl;
> //cout << "X: " << x << " " << "Y: " << y << " " << "Z: " << z << endl;
> //cout << endl;
> }
> glEnd();
> i++;
> }
> cout << i << endl;

Did you ever get this resolved? Why are you calling OpenGL functions
if you are using VTK?

Thanks,

David
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T14:17:24Z

On Mon, Nov 30, 2009 at 2:49 PM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:
> reader.GetOutput().Update() is not the same that reader.Update()?

When VTK 5.0 was released, data.Update() did a little bit extra that
algorithm.Update() did not do, i.e. in VTK 5.0 the pipeline was newly
designed and had some bugs. Now the pipeline bugs are fixed, but I
still always call update on data out of habit.

> if U have a renderer per slice, why to have a reslice for every render
> and not just one?

Because I find that the easiest way to use vtkImageReslice is to make
it output just one slice. It is just my preference, in other words.

> How do I achieve that if I change the window/level in a renderer, all
> images in the 4x4 configuration get updated with the same
> window/level?

Easy. Use the same vtkLookupTable for all images. In your data
pipeline, use vtkImageMapToColors() to color the data. I cannot help
you with vtkImageColorViewer because I never use that class.

David

> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> Usually I use a separate renderer for each slice. This also means a
>> separate reslice, image actor, etc.
>>
>> For this to work efficiently, you must force the reader to read all
>> the whole dicom series, like this:
>>
>> reader.GetOutput().Update()
>>
>> If you don't do this, then the reader will only read one slice at a
>> time, so if you are displaying 4x4 then it will go to the disk 16
>> times on every render. By calling update on the the reader, you force
>> the whole series into memory.
>>
>> David
>>
>>
>> On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> thanks, and another question:
>>>
>>> I need to display the images in a dicom serie in several
>>> configurations: just one image, 2 images side by side, 2x2 images and
>>> so on. Which is the recommended way to display those configurations in
>>> a render window, with several renderers or with several image actors?
>>>
>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>>>> <jmrbcu@...> wrote:
>>>>> yes, thanks, in fact this is my pattern example but, in this example
>>>>> the sagital view is flipped, why is that?
>>>>
>>>> You are complaining because the head is facing right instead of facing
>>>> left?? It is still sagittal.
>>>>
>>>>> PS: So, to use ImageReslice for an dicom image viewer is not a problem?
>>>>
>>>> No problem at all. Plenty of people use it for dicom. The only
>>>> restrictions are the following:
>>>>
>>>> 1) the spacing must be constant
>>>>
>>>> 2) the gantry must not be tilted
>>>>
>>>> These restrictions are true for all vtkImageData. Fortunately, CT and
>>>> MRI almost always use constant slice spacing, so that is never a
>>>> problem. CT gantry tilt can be fairly common, though, so any dicom
>>>> image viewer should check for it. MR images never have gantry tilt.
>>>>
>>>> David
>>>>
>>>>
>>>>>
>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>> I didn't give the full path for the example in my last email. Here it
>>>>>> is:
>>>>>>
>>>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>>>>> wrote:
>>>>>>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>>>>>>> would like to do so myself, but I don't know when I will have the
>>>>>>> time.
>>>>>>>
>>>>>>> I did submit a python reslicing example to VTK that you might find
>>>>>>> useful:
>>>>>>>
>>>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>>>> <jmrbcu@...> wrote:
>>>>>>>> why is that?
>>>>>>>>
>>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for
>>>>>>>>> your
>>>>>>>>> application. That is the closest thing to a generic reslicing image
>>>>>>>>> viewer that VTK has.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't
>>>>>>>>>> use
>>>>>>>>>> vtkImageReslice for changing the slice orientation (axial, sagital
>>>>>>>>>> and
>>>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>>>> lo
>>>>>>>>>> mismo.
>>>>>>>>>>
>>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>>>> por profesionales
>>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>
>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>
>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>
>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>> Centro de Biofisica Medica
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>> lo
>>>>>>>> mismo.
>>>>>>>>
>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>> por profesionales
>>>>>>>> -----------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lic. José M. Rodriguez Bacallao
>>>>> Centro de Biofisica Medica
>>>>> -----------------------------------------------------------------
>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>> mismo.
>>>>>
>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>> por profesionales
>>>>> -----------------------------------------------------------------
>>>>>
>>>>
>>>
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>>
>>
>
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T13:51:28Z

reader.GetOutput().Update() is not the same that reader.Update()?

if U have a renderer per slice, why to have a reslice for every
renderer and not just one?
How do I achieve that if I change the window/level in a renderer, all
images in the 4x4 configuration get updated with the same
window/level?
having a renderer, reslicer and image actor per slice is not memory
very memory hungry setup?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> Usually I use a separate renderer for each slice. This also means a
> separate reslice, image actor, etc.
>
> For this to work efficiently, you must force the reader to read all
> the whole dicom series, like this:
>
> reader.GetOutput().Update()
>
> If you don't do this, then the reader will only read one slice at a
> time, so if you are displaying 4x4 then it will go to the disk 16
> times on every render. By calling update on the the reader, you force
> the whole series into memory.
>
> David
>
>
> On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> thanks, and another question:
>>
>> I need to display the images in a dicom serie in several
>> configurations: just one image, 2 images side by side, 2x2 images and
>> so on. Which is the recommended way to display those configurations in
>> a render window, with several renderers or with several image actors?
>>
>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> yes, thanks, in fact this is my pattern example but, in this example
>>>> the sagital view is flipped, why is that?
>>>
>>> You are complaining because the head is facing right instead of facing
>>> left?? It is still sagittal.
>>>
>>>> PS: So, to use ImageReslice for an dicom image viewer is not a problem?
>>>
>>> No problem at all. Plenty of people use it for dicom. The only
>>> restrictions are the following:
>>>
>>> 1) the spacing must be constant
>>>
>>> 2) the gantry must not be tilted
>>>
>>> These restrictions are true for all vtkImageData. Fortunately, CT and
>>> MRI almost always use constant slice spacing, so that is never a
>>> problem. CT gantry tilt can be fairly common, though, so any dicom
>>> image viewer should check for it. MR images never have gantry tilt.
>>>
>>> David
>>>
>>>
>>>>
>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>> I didn't give the full path for the example in my last email. Here it
>>>>> is:
>>>>>
>>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>>>> wrote:
>>>>>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>>>>>> would like to do so myself, but I don't know when I will have the
>>>>>> time.
>>>>>>
>>>>>> I did submit a python reslicing example to VTK that you might find
>>>>>> useful:
>>>>>>
>>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>>> <jmrbcu@...> wrote:
>>>>>>> why is that?
>>>>>>>
>>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for
>>>>>>>> your
>>>>>>>> application. That is the closest thing to a generic reslicing image
>>>>>>>> viewer that VTK has.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>>> <jmrbcu@...> wrote:
>>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't
>>>>>>>>> use
>>>>>>>>> vtkImageReslice for changing the slice orientation (axial, sagital
>>>>>>>>> and
>>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>>> Centro de Biofisica Medica
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>>> lo
>>>>>>>>> mismo.
>>>>>>>>>
>>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>>> por profesionales
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>> Centro de Biofisica Medica
>>>>>>> -----------------------------------------------------------------
>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>> lo
>>>>>>> mismo.
>>>>>>>
>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>> por profesionales
>>>>>>> -----------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>>
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T13:49:24Z

reader.GetOutput().Update() is not the same that reader.Update()?

if U have a renderer per slice, why to have a reslice for every render
and not just one?
How do I achieve that if I change the window/level in a renderer, all
images in the 4x4 configuration get updated with the same
window/level?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

From forum: VTK - Users

Re: Source derived from vtkAlgorithm

2009-11-30T13:45:24Z

RequestDataObject (RDO) is an earlier pipeline pass.
During RDO, each filter is supposed to produce an empty data object of
the proper type

Later on RequestData (RD) happens.
During RD each filter examines any inputs it has, then fills in that
empty data object with real data.

The VTK User's guide goes into more detail. Issue 1 of the Kitware
source also describes the pipeline execution model.

David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109

On Mon, Nov 30, 2009 at 4:34 PM, David Doria <daviddoria+vtk@...> wrote:

> On Mon, Nov 30, 2009 at 9:24 AM, Jeff Baumes <jeff.baumes@...> wrote:
>>> I spent quite a while paring some of those down and combining them trying to
>>> get the desired functionality. However, I'm still having some issues. The
>>> pipeline code gets pretty complex in a big hurry.
>>
>> You may want to look at this special-purpose data object. Note that
>> your new type must inherit from vtkDataObject or subclass.
>>
>> Rendering/vtkLabelHierarchy (new data object subclass)
>> Rendering/vtkLabelHierarchyAlgorithm (new superclass for algorithms)
>> Rendering/vtkPointSetToLabelHierarchy (algorithm that produces
>> vtkLabelHierarchy)
>>
>> Jeff
>>
>
> Great - I got them working:
> http://www.vtk.org/Wiki/VTK_Examples_vtkAlgorithm_Source
> http://www.vtk.org/Wiki/VTK_Examples_vtkAlgorithm_Filter
>
> What is the difference between RequestDataObject() and RequestData()?
>
> Thanks,
>
> David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: Source derived from vtkAlgorithm

2009-11-30T13:44:09Z

RequestDataObject is where the algorithm creates the (empty) output
data object. RequestData is where it fills it.

-berk

On Mon, Nov 30, 2009 at 4:34 PM, David Doria <daviddoria+vtk@...> wrote:

From forum: VTK - Users

Re: Source derived from vtkAlgorithm

2009-11-30T13:34:30Z

On Mon, Nov 30, 2009 at 9:24 AM, Jeff Baumes <jeff.baumes@...> wrote:

>> I spent quite a while paring some of those down and combining them trying to
>> get the desired functionality. However, I'm still having some issues. The
>> pipeline code gets pretty complex in a big hurry.
>
> You may want to look at this special-purpose data object. Note that
> your new type must inherit from vtkDataObject or subclass.
>
> Rendering/vtkLabelHierarchy (new data object subclass)
> Rendering/vtkLabelHierarchyAlgorithm (new superclass for algorithms)
> Rendering/vtkPointSetToLabelHierarchy (algorithm that produces
> vtkLabelHierarchy)
>
> Jeff
>

Great - I got them working:
http://www.vtk.org/Wiki/VTK_Examples_vtkAlgorithm_Source
http://www.vtk.org/Wiki/VTK_Examples_vtkAlgorithm_Filter

What is the difference between RequestDataObject() and RequestData()?

Thanks,

David
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T13:21:57Z

It is because most of tests are not C++ tests.

Look at the experimental section, my machine is xanth (Ubuntu 9.10
x86_64). There are 3 submissions.
http://www.cdash.org/CDash/index.php?project=VTK#Experimental

1. force locale on C++ tests with French locale:

82 tests failed 1088 passes

2. Fixed event recorder, use French locale:
56 tests failed (-26) 1114 passed

3. Use English locale after event recorder fix:
10 test failed (-46) 1161 passed

On Mon, Nov 30, 2009 at 4:15 PM, Bill Lorensen <bill.lorensen@...> wrote:

> Excellent. That's what I have been doing in itk classes that use streams.
>
> I'm surprised that more tests did not fail in vtk.
>
> Bill
>
> On Mon, Nov 30, 2009 at 4:02 PM, Francois Bertel
> <francois.bertel@...> wrote:
>> VTK/Common/vtkTimePointUtility.cxx
>>
>> I added a imbue(vtkstd::locale::classic()); on the relevant C++ stream.
>>
>> ref: http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkTimePointUtility.cxx?r1=1.2&r2=1.3
>>
>> On Mon, Nov 30, 2009 at 3:53 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>> Can you share what you changed? Which class?
>>>
>>> Bill
>>>
>>> On Mon, Nov 30, 2009 at 3:42 PM, Francois Bertel
>>> <francois.bertel@...> wrote:
>>>> Not only locale for language like French are different for thousand
>>>> separator but also English is different from C|POSIX !!
>>>>
>>>> An integer of value 2000 will generate the string "2000" in POSIX|C
>>>> locale but will generate the string "2,000" in "en_US.UTF-8" locale.
>>>>
>>>> Example of test that was failing with "en_US.UTF-8":
>>>>
>>>> http://www.cdash.org/CDash/testDetails.php?test=37688960&build=483148
>>>>
>>>> This test is now fixed by forcing C|POSIX in the C++ stream.
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 1:04 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>>>> Tom,
>>>>>
>>>>> I don't think we need to be concerned with the per-thread issue. My
>>>>> changes are all local to the methods that need c-locale's. For
>>>>> example, surrounding the ReadImageInformation calls with save/restore
>>>>> locales in many readers fixes the readers.
>>>>>
>>>>> Maybe you can try my simple itkLocale class. I'll send it in a separate mail.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>>>>> Tom,
>>>>>>
>>>>>> What I have done is create an itk class, itkLocale, that in its
>>>>>> constructor saves the current c-locale and creates a new one. The
>>>>>> destructor restores the original locale.
>>>>>>
>>>>>> C++-locales are handled explicitly with imbue.
>>>>>>
>>>>>> I'll try your approach in the itkLocale class.
>>>>>>
>>>>>> BTW, I have not checked in any code yet.
>>>>>>
>>>>>> I think it is time to start an ITK Policy and Procedure page for
>>>>>> internationalization on the itk wiki.
>>>>>>
>>>>>> It can include the work you are doing with unicode.
>>>>>>
>>>>>> I'll give it a stab today. Then we can start a new thread on itk developers.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
>>>>>> <tom.vercauteren@...> wrote:
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> I would just like to mention that in our group we have been facing
>>>>>>> several issues with locale support on mac.
>>>>>>>
>>>>>>> Looking at the documentation of xlocale:
>>>>>>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>>>>>>> you will see that setlocale will have absolutely no effect (on mac,
>>>>>>> maybe on windows also
>>>>>>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>>>>>>> per-thread locale had been specified.
>>>>>>>
>>>>>>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>>>>>>
>>>>>>>
>>>>>>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>>>>>>> chose to proceed:
>>>>>>>
>>>>>>> // Create a new locale based on a copy of the current one (which need
>>>>>>> not be explicitly set)
>>>>>>> // but where LC_NUMERIC has been modified to match the C locale
>>>>>>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>>>>>>> // Use this new locale and store the current one to reset it aftwards
>>>>>>> locale_t previousLocale = uselocale(templocale);
>>>>>>>
>>>>>>> [Actual useful code]
>>>>>>>
>>>>>>> // Reset the locale to the previous one
>>>>>>> uselocale(previousLocale)
>>>>>>> // More house keeing
>>>>>>> freelocale(tempLocale)
>>>>>>>
>>>>>>>
>>>>>>> Actually, on mac we also had to do explicitly create thread-specific
>>>>>>> locale to avoid some random crash in heavily threaded code. But that
>>>>>>> is a slightly different topic
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>>>>>>> I've already made a pass through the itk readers. Several were broken
>>>>>>>> wrt locale.
>>>>>>>>
>>>>>>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>>>>>>> locale in and itk::Locale class.
>>>>>>>>
>>>>>>>> I have not checked in any changes yet, but I went from over 40 failing
>>>>>>>> I/O tests down to 0.
>>>>>>>>
>>>>>>>> Bill
>>>>>>>>
>>>>>>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>>>>>>> <marcus.hanwell@...> wrote:
>>>>>>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>>>>>>> Luis,
>>>>>>>>>>
>>>>>>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>>>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>>>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>>>>>>> any changes yet. Still more investigation is needed as to the best
>>>>>>>>>> portable solution.
>>>>>>>>>>
>>>>>>>>>> I do this:
>>>>>>>>>> const char *originalLocale;
>>>>>>>>>> char *currentLocale;
>>>>>>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>>>>>> setlocale(LC_NUMERIC, "C");
>>>>>>>>>>
>>>>>>>>>> ......
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>>>>>> free(currentLocale);
>>>>>>>>>
>>>>>>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>>>>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>>>>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>>>>>>
>>>>>>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>>>>>>
>>>>>>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>>>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>>>>>>> snippets.
>>>>>>>>>>
>>>>>>>>>> There are other readers/writers that use C++ streams, and there we
>>>>>>>>>> will have to imbue.
>>>>>>>>>
>>>>>>>>> I think that using the C locale is probably the easiest short term solution,
>>>>>>>>> but to support GUIs using different locales we should be using the C++ locale
>>>>>>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>>>>>>> subtle bugs if reading and writing files in separate threads that are all
>>>>>>>>> using C locales.
>>>>>>>>>>
>>>>>>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>>>>>>> etc. In the long run we probably should address these cases with
>>>>>>>>>> stream replacements.
>>>>>>>>>
>>>>>>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>>>>>>> existing code with C++ streams. As you say this should probably be part of a
>>>>>>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>>>>>>> to our libraries.
>>>>>>>>>
>>>>>>>>> Marcus
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>>>>> http://kitware.com/products/protraining.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> François Bertel, PhD | Kitware Inc. Suite 204
>>>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>>>> | Clifton Park NY 12065, USA
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>
>>>
>>
>>
>>
>> --
>> François Bertel, PhD | Kitware Inc. Suite 204
>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>> | Clifton Park NY 12065, USA
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>

--
François Bertel, PhD | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
| Clifton Park NY 12065, USA
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T13:20:55Z

Usually I use a separate renderer for each slice. This also means a
separate reslice, image actor, etc.

For this to work efficiently, you must force the reader to read all
the whole dicom series, like this:

reader.GetOutput().Update()

If you don't do this, then the reader will only read one slice at a
time, so if you are displaying 4x4 then it will go to the disk 16
times on every render. By calling update on the the reader, you force
the whole series into memory.

David

On Mon, Nov 30, 2009 at 1:58 PM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:

> thanks, and another question:
>
> I need to display the images in a dicom serie in several
> configurations: just one image, 2 images side by side, 2x2 images and
> so on. Which is the recommended way to display those configurations in
> a render window, with several renderers or with several image actors?
>
> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> yes, thanks, in fact this is my pattern example but, in this example
>>> the sagital view is flipped, why is that?
>>
>> You are complaining because the head is facing right instead of facing
>> left?? It is still sagittal.
>>
>>> PS: So, to use ImageReslice for an dicom image viewer is not a problem?
>>
>> No problem at all. Plenty of people use it for dicom. The only
>> restrictions are the following:
>>
>> 1) the spacing must be constant
>>
>> 2) the gantry must not be tilted
>>
>> These restrictions are true for all vtkImageData. Fortunately, CT and
>> MRI almost always use constant slice spacing, so that is never a
>> problem. CT gantry tilt can be fairly common, though, so any dicom
>> image viewer should check for it. MR images never have gantry tilt.
>>
>> David
>>
>>
>>>
>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>> I didn't give the full path for the example in my last email. Here it
>>>> is:
>>>>
>>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>>
>>>> David
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>>> wrote:
>>>>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>>>>> would like to do so myself, but I don't know when I will have the
>>>>> time.
>>>>>
>>>>> I did submit a python reslicing example to VTK that you might find
>>>>> useful:
>>>>>
>>>>> VTK/Examples/Python/ImageSlicing.py
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>>> <jmrbcu@...> wrote:
>>>>>> why is that?
>>>>>>
>>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>>>>>>> application. That is the closest thing to a generic reslicing image
>>>>>>> viewer that VTK has.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>>> <jmrbcu@...> wrote:
>>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>>>>>>> vtkImageReslice for changing the slice orientation (axial, sagital
>>>>>>>> and
>>>>>>>> coronal)? I am just curious!!!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>>> Centro de Biofisica Medica
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>>> lo
>>>>>>>> mismo.
>>>>>>>>
>>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>>> por profesionales
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>> Centro de Biofisica Medica
>>>>>> -----------------------------------------------------------------
>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>>> mismo.
>>>>>>
>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>> por profesionales
>>>>>> -----------------------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>>
>>
>
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T13:15:00Z

Excellent. That's what I have been doing in itk classes that use streams.

I'm surprised that more tests did not fail in vtk.

Bill

On Mon, Nov 30, 2009 at 4:02 PM, Francois Bertel
<francois.bertel@...> wrote:

> VTK/Common/vtkTimePointUtility.cxx
>
> I added a imbue(vtkstd::locale::classic()); on the relevant C++ stream.
>
> ref: http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkTimePointUtility.cxx?r1=1.2&r2=1.3
>
> On Mon, Nov 30, 2009 at 3:53 PM, Bill Lorensen <bill.lorensen@...> wrote:
>> Can you share what you changed? Which class?
>>
>> Bill
>>
>> On Mon, Nov 30, 2009 at 3:42 PM, Francois Bertel
>> <francois.bertel@...> wrote:
>>> Not only locale for language like French are different for thousand
>>> separator but also English is different from C|POSIX !!
>>>
>>> An integer of value 2000 will generate the string "2000" in POSIX|C
>>> locale but will generate the string "2,000" in "en_US.UTF-8" locale.
>>>
>>> Example of test that was failing with "en_US.UTF-8":
>>>
>>> http://www.cdash.org/CDash/testDetails.php?test=37688960&build=483148
>>>
>>> This test is now fixed by forcing C|POSIX in the C++ stream.
>>>
>>>
>>> On Mon, Nov 30, 2009 at 1:04 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>>> Tom,
>>>>
>>>> I don't think we need to be concerned with the per-thread issue. My
>>>> changes are all local to the methods that need c-locale's. For
>>>> example, surrounding the ReadImageInformation calls with save/restore
>>>> locales in many readers fixes the readers.
>>>>
>>>> Maybe you can try my simple itkLocale class. I'll send it in a separate mail.
>>>>
>>>> Bill
>>>>
>>>> On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>>>> Tom,
>>>>>
>>>>> What I have done is create an itk class, itkLocale, that in its
>>>>> constructor saves the current c-locale and creates a new one. The
>>>>> destructor restores the original locale.
>>>>>
>>>>> C++-locales are handled explicitly with imbue.
>>>>>
>>>>> I'll try your approach in the itkLocale class.
>>>>>
>>>>> BTW, I have not checked in any code yet.
>>>>>
>>>>> I think it is time to start an ITK Policy and Procedure page for
>>>>> internationalization on the itk wiki.
>>>>>
>>>>> It can include the work you are doing with unicode.
>>>>>
>>>>> I'll give it a stab today. Then we can start a new thread on itk developers.
>>>>>
>>>>> Bill
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
>>>>> <tom.vercauteren@...> wrote:
>>>>>> Hi Bill,
>>>>>>
>>>>>> I would just like to mention that in our group we have been facing
>>>>>> several issues with locale support on mac.
>>>>>>
>>>>>> Looking at the documentation of xlocale:
>>>>>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>>>>>> you will see that setlocale will have absolutely no effect (on mac,
>>>>>> maybe on windows also
>>>>>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>>>>>> per-thread locale had been specified.
>>>>>>
>>>>>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>>>>>
>>>>>>
>>>>>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>>>>>> chose to proceed:
>>>>>>
>>>>>> // Create a new locale based on a copy of the current one (which need
>>>>>> not be explicitly set)
>>>>>> // but where LC_NUMERIC has been modified to match the C locale
>>>>>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>>>>>> // Use this new locale and store the current one to reset it aftwards
>>>>>> locale_t previousLocale = uselocale(templocale);
>>>>>>
>>>>>> [Actual useful code]
>>>>>>
>>>>>> // Reset the locale to the previous one
>>>>>> uselocale(previousLocale)
>>>>>> // More house keeing
>>>>>> freelocale(tempLocale)
>>>>>>
>>>>>>
>>>>>> Actually, on mac we also had to do explicitly create thread-specific
>>>>>> locale to avoid some random crash in heavily threaded code. But that
>>>>>> is a slightly different topic
>>>>>>
>>>>>> Cheers,
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>>>>>> I've already made a pass through the itk readers. Several were broken
>>>>>>> wrt locale.
>>>>>>>
>>>>>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>>>>>> locale in and itk::Locale class.
>>>>>>>
>>>>>>> I have not checked in any changes yet, but I went from over 40 failing
>>>>>>> I/O tests down to 0.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>>>>>> <marcus.hanwell@...> wrote:
>>>>>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>>>>>> Luis,
>>>>>>>>>
>>>>>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>>>>>> any changes yet. Still more investigation is needed as to the best
>>>>>>>>> portable solution.
>>>>>>>>>
>>>>>>>>> I do this:
>>>>>>>>> const char *originalLocale;
>>>>>>>>> char *currentLocale;
>>>>>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>>>>> setlocale(LC_NUMERIC, "C");
>>>>>>>>>
>>>>>>>>> ......
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>>>>> free(currentLocale);
>>>>>>>>
>>>>>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>>>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>>>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>>>>>
>>>>>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>>>>>
>>>>>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>>>>>> snippets.
>>>>>>>>>
>>>>>>>>> There are other readers/writers that use C++ streams, and there we
>>>>>>>>> will have to imbue.
>>>>>>>>
>>>>>>>> I think that using the C locale is probably the easiest short term solution,
>>>>>>>> but to support GUIs using different locales we should be using the C++ locale
>>>>>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>>>>>> subtle bugs if reading and writing files in separate threads that are all
>>>>>>>> using C locales.
>>>>>>>>>
>>>>>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>>>>>> etc. In the long run we probably should address these cases with
>>>>>>>>> stream replacements.
>>>>>>>>
>>>>>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>>>>>> existing code with C++ streams. As you say this should probably be part of a
>>>>>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>>>>>> to our libraries.
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>>>> http://kitware.com/products/protraining.html
>>>>>>>
>>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>
>>>
>>>
>>>
>>> --
>>> François Bertel, PhD | Kitware Inc. Suite 204
>>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>>> | Clifton Park NY 12065, USA
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>
>
>
>
> --
> François Bertel, PhD | Kitware Inc. Suite 204
> 1 (518) 371 3971 x113 | 28 Corporate Drive
> | Clifton Park NY 12065, USA
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T13:02:43Z

VTK/Common/vtkTimePointUtility.cxx

I added a imbue(vtkstd::locale::classic()); on the relevant C++ stream.

ref: http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkTimePointUtility.cxx?r1=1.2&r2=1.3

On Mon, Nov 30, 2009 at 3:53 PM, Bill Lorensen <bill.lorensen@...> wrote:

> Can you share what you changed? Which class?
>
> Bill
>
> On Mon, Nov 30, 2009 at 3:42 PM, Francois Bertel
> <francois.bertel@...> wrote:
>> Not only locale for language like French are different for thousand
>> separator but also English is different from C|POSIX !!
>>
>> An integer of value 2000 will generate the string "2000" in POSIX|C
>> locale but will generate the string "2,000" in "en_US.UTF-8" locale.
>>
>> Example of test that was failing with "en_US.UTF-8":
>>
>> http://www.cdash.org/CDash/testDetails.php?test=37688960&build=483148
>>
>> This test is now fixed by forcing C|POSIX in the C++ stream.
>>
>>
>> On Mon, Nov 30, 2009 at 1:04 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>> Tom,
>>>
>>> I don't think we need to be concerned with the per-thread issue. My
>>> changes are all local to the methods that need c-locale's. For
>>> example, surrounding the ReadImageInformation calls with save/restore
>>> locales in many readers fixes the readers.
>>>
>>> Maybe you can try my simple itkLocale class. I'll send it in a separate mail.
>>>
>>> Bill
>>>
>>> On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>>> Tom,
>>>>
>>>> What I have done is create an itk class, itkLocale, that in its
>>>> constructor saves the current c-locale and creates a new one. The
>>>> destructor restores the original locale.
>>>>
>>>> C++-locales are handled explicitly with imbue.
>>>>
>>>> I'll try your approach in the itkLocale class.
>>>>
>>>> BTW, I have not checked in any code yet.
>>>>
>>>> I think it is time to start an ITK Policy and Procedure page for
>>>> internationalization on the itk wiki.
>>>>
>>>> It can include the work you are doing with unicode.
>>>>
>>>> I'll give it a stab today. Then we can start a new thread on itk developers.
>>>>
>>>> Bill
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
>>>> <tom.vercauteren@...> wrote:
>>>>> Hi Bill,
>>>>>
>>>>> I would just like to mention that in our group we have been facing
>>>>> several issues with locale support on mac.
>>>>>
>>>>> Looking at the documentation of xlocale:
>>>>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>>>>> you will see that setlocale will have absolutely no effect (on mac,
>>>>> maybe on windows also
>>>>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>>>>> per-thread locale had been specified.
>>>>>
>>>>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>>>>
>>>>>
>>>>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>>>>> chose to proceed:
>>>>>
>>>>> // Create a new locale based on a copy of the current one (which need
>>>>> not be explicitly set)
>>>>> // but where LC_NUMERIC has been modified to match the C locale
>>>>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>>>>> // Use this new locale and store the current one to reset it aftwards
>>>>> locale_t previousLocale = uselocale(templocale);
>>>>>
>>>>> [Actual useful code]
>>>>>
>>>>> // Reset the locale to the previous one
>>>>> uselocale(previousLocale)
>>>>> // More house keeing
>>>>> freelocale(tempLocale)
>>>>>
>>>>>
>>>>> Actually, on mac we also had to do explicitly create thread-specific
>>>>> locale to avoid some random crash in heavily threaded code. But that
>>>>> is a slightly different topic
>>>>>
>>>>> Cheers,
>>>>> Tom
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>>>>> I've already made a pass through the itk readers. Several were broken
>>>>>> wrt locale.
>>>>>>
>>>>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>>>>> locale in and itk::Locale class.
>>>>>>
>>>>>> I have not checked in any changes yet, but I went from over 40 failing
>>>>>> I/O tests down to 0.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>>>>> <marcus.hanwell@...> wrote:
>>>>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>>>>> Luis,
>>>>>>>>
>>>>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>>>>> any changes yet. Still more investigation is needed as to the best
>>>>>>>> portable solution.
>>>>>>>>
>>>>>>>> I do this:
>>>>>>>> const char *originalLocale;
>>>>>>>> char *currentLocale;
>>>>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>>>> setlocale(LC_NUMERIC, "C");
>>>>>>>>
>>>>>>>> ......
>>>>>>>>
>>>>>>>>
>>>>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>>>> free(currentLocale);
>>>>>>>
>>>>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>>>>
>>>>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>>>>
>>>>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>>>>> snippets.
>>>>>>>>
>>>>>>>> There are other readers/writers that use C++ streams, and there we
>>>>>>>> will have to imbue.
>>>>>>>
>>>>>>> I think that using the C locale is probably the easiest short term solution,
>>>>>>> but to support GUIs using different locales we should be using the C++ locale
>>>>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>>>>> subtle bugs if reading and writing files in separate threads that are all
>>>>>>> using C locales.
>>>>>>>>
>>>>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>>>>> etc. In the long run we probably should address these cases with
>>>>>>>> stream replacements.
>>>>>>>
>>>>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>>>>> existing code with C++ streams. As you say this should probably be part of a
>>>>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>>>>> to our libraries.
>>>>>>>
>>>>>>> Marcus
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>>> http://kitware.com/products/protraining.html
>>>>>>
>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>
>>
>>
>> --
>> François Bertel, PhD | Kitware Inc. Suite 204
>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>> | Clifton Park NY 12065, USA
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T12:58:26Z

thanks, and another question:

I need to display the images in a dicom serie in several
configurations: just one image, 2 images side by side, 2x2 images and
so on. Which is the recommended way to display those configurations in
a render window, with several renderers or with several image actors?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> yes, thanks, in fact this is my pattern example but, in this example
>> the sagital view is flipped, why is that?
>
> You are complaining because the head is facing right instead of facing
> left?? It is still sagittal.
>
>> PS: So, to use ImageReslice for an dicom image viewer is not a problem?
>
> No problem at all. Plenty of people use it for dicom. The only
> restrictions are the following:
>
> 1) the spacing must be constant
>
> 2) the gantry must not be tilted
>
> These restrictions are true for all vtkImageData. Fortunately, CT and
> MRI almost always use constant slice spacing, so that is never a
> problem. CT gantry tilt can be fairly common, though, so any dicom
> image viewer should check for it. MR images never have gantry tilt.
>
> David
>
>
>>
>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>> I didn't give the full path for the example in my last email. Here it
>>> is:
>>>
>>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>>
>>> David
>>>
>>>
>>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...>
>>> wrote:
>>>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>>>> would like to do so myself, but I don't know when I will have the
>>>> time.
>>>>
>>>> I did submit a python reslicing example to VTK that you might find
>>>> useful:
>>>>
>>>> VTK/Examples/Python/ImageSlicing.py
>>>>
>>>> David
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>>> <jmrbcu@...> wrote:
>>>>> why is that?
>>>>>
>>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>>>>>> application. That is the closest thing to a generic reslicing image
>>>>>> viewer that VTK has.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>>> <jmrbcu@...> wrote:
>>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>>>>>> vtkImageReslice for changing the slice orientation (axial, sagital
>>>>>>> and
>>>>>>> coronal)? I am just curious!!!
>>>>>>>
>>>>>>> --
>>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>>> Centro de Biofisica Medica
>>>>>>> -----------------------------------------------------------------
>>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos
>>>>>>> lo
>>>>>>> mismo.
>>>>>>>
>>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>>> por profesionales
>>>>>>> -----------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lic. José M. Rodriguez Bacallao
>>>>> Centro de Biofisica Medica
>>>>> -----------------------------------------------------------------
>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>> mismo.
>>>>>
>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>> por profesionales
>>>>> -----------------------------------------------------------------
>>>>>
>>>>
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T12:53:19Z

Can you share what you changed? Which class?

Bill

On Mon, Nov 30, 2009 at 3:42 PM, Francois Bertel
<francois.bertel@...> wrote:

> Not only locale for language like French are different for thousand
> separator but also English is different from C|POSIX !!
>
> An integer of value 2000 will generate the string "2000" in POSIX|C
> locale but will generate the string "2,000" in "en_US.UTF-8" locale.
>
> Example of test that was failing with "en_US.UTF-8":
>
> http://www.cdash.org/CDash/testDetails.php?test=37688960&build=483148
>
> This test is now fixed by forcing C|POSIX in the C++ stream.
>
>
> On Mon, Nov 30, 2009 at 1:04 PM, Bill Lorensen <bill.lorensen@...> wrote:
>> Tom,
>>
>> I don't think we need to be concerned with the per-thread issue. My
>> changes are all local to the methods that need c-locale's. For
>> example, surrounding the ReadImageInformation calls with save/restore
>> locales in many readers fixes the readers.
>>
>> Maybe you can try my simple itkLocale class. I'll send it in a separate mail.
>>
>> Bill
>>
>> On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:
>>> Tom,
>>>
>>> What I have done is create an itk class, itkLocale, that in its
>>> constructor saves the current c-locale and creates a new one. The
>>> destructor restores the original locale.
>>>
>>> C++-locales are handled explicitly with imbue.
>>>
>>> I'll try your approach in the itkLocale class.
>>>
>>> BTW, I have not checked in any code yet.
>>>
>>> I think it is time to start an ITK Policy and Procedure page for
>>> internationalization on the itk wiki.
>>>
>>> It can include the work you are doing with unicode.
>>>
>>> I'll give it a stab today. Then we can start a new thread on itk developers.
>>>
>>> Bill
>>>
>>>
>>> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
>>> <tom.vercauteren@...> wrote:
>>>> Hi Bill,
>>>>
>>>> I would just like to mention that in our group we have been facing
>>>> several issues with locale support on mac.
>>>>
>>>> Looking at the documentation of xlocale:
>>>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>>>> you will see that setlocale will have absolutely no effect (on mac,
>>>> maybe on windows also
>>>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>>>> per-thread locale had been specified.
>>>>
>>>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>>>
>>>>
>>>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>>>> chose to proceed:
>>>>
>>>> // Create a new locale based on a copy of the current one (which need
>>>> not be explicitly set)
>>>> // but where LC_NUMERIC has been modified to match the C locale
>>>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>>>> // Use this new locale and store the current one to reset it aftwards
>>>> locale_t previousLocale = uselocale(templocale);
>>>>
>>>> [Actual useful code]
>>>>
>>>> // Reset the locale to the previous one
>>>> uselocale(previousLocale)
>>>> // More house keeing
>>>> freelocale(tempLocale)
>>>>
>>>>
>>>> Actually, on mac we also had to do explicitly create thread-specific
>>>> locale to avoid some random crash in heavily threaded code. But that
>>>> is a slightly different topic
>>>>
>>>> Cheers,
>>>> Tom
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>>>> I've already made a pass through the itk readers. Several were broken
>>>>> wrt locale.
>>>>>
>>>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>>>> locale in and itk::Locale class.
>>>>>
>>>>> I have not checked in any changes yet, but I went from over 40 failing
>>>>> I/O tests down to 0.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>>>> <marcus.hanwell@...> wrote:
>>>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>>>> Luis,
>>>>>>>
>>>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>>>> any changes yet. Still more investigation is needed as to the best
>>>>>>> portable solution.
>>>>>>>
>>>>>>> I do this:
>>>>>>> const char *originalLocale;
>>>>>>> char *currentLocale;
>>>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>>> setlocale(LC_NUMERIC, "C");
>>>>>>>
>>>>>>> ......
>>>>>>>
>>>>>>>
>>>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>>> free(currentLocale);
>>>>>>
>>>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>>>
>>>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>>>
>>>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>>>> snippets.
>>>>>>>
>>>>>>> There are other readers/writers that use C++ streams, and there we
>>>>>>> will have to imbue.
>>>>>>
>>>>>> I think that using the C locale is probably the easiest short term solution,
>>>>>> but to support GUIs using different locales we should be using the C++ locale
>>>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>>>> subtle bugs if reading and writing files in separate threads that are all
>>>>>> using C locales.
>>>>>>>
>>>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>>>> etc. In the long run we probably should address these cases with
>>>>>>> stream replacements.
>>>>>>
>>>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>>>> existing code with C++ streams. As you say this should probably be part of a
>>>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>>>> to our libraries.
>>>>>>
>>>>>> Marcus
>>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://kitware.com/products/protraining.html
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>
>>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>
>
>
> --
> François Bertel, PhD | Kitware Inc. Suite 204
> 1 (518) 371 3971 x113 | 28 Corporate Drive
> | Clifton Park NY 12065, USA
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T12:42:48Z

Not only locale for language like French are different for thousand
separator but also English is different from C|POSIX !!

An integer of value 2000 will generate the string "2000" in POSIX|C
locale but will generate the string "2,000" in "en_US.UTF-8" locale.

Example of test that was failing with "en_US.UTF-8":

http://www.cdash.org/CDash/testDetails.php?test=37688960&build=483148

This test is now fixed by forcing C|POSIX in the C++ stream.

On Mon, Nov 30, 2009 at 1:04 PM, Bill Lorensen <bill.lorensen@...> wrote:

> Tom,
>
> I don't think we need to be concerned with the per-thread issue. My
> changes are all local to the methods that need c-locale's. For
> example, surrounding the ReadImageInformation calls with save/restore
> locales in many readers fixes the readers.
>
> Maybe you can try my simple itkLocale class. I'll send it in a separate mail.
>
> Bill
>
> On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:
>> Tom,
>>
>> What I have done is create an itk class, itkLocale, that in its
>> constructor saves the current c-locale and creates a new one. The
>> destructor restores the original locale.
>>
>> C++-locales are handled explicitly with imbue.
>>
>> I'll try your approach in the itkLocale class.
>>
>> BTW, I have not checked in any code yet.
>>
>> I think it is time to start an ITK Policy and Procedure page for
>> internationalization on the itk wiki.
>>
>> It can include the work you are doing with unicode.
>>
>> I'll give it a stab today. Then we can start a new thread on itk developers.
>>
>> Bill
>>
>>
>> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
>> <tom.vercauteren@...> wrote:
>>> Hi Bill,
>>>
>>> I would just like to mention that in our group we have been facing
>>> several issues with locale support on mac.
>>>
>>> Looking at the documentation of xlocale:
>>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>>> you will see that setlocale will have absolutely no effect (on mac,
>>> maybe on windows also
>>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>>> per-thread locale had been specified.
>>>
>>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>>
>>>
>>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>>> chose to proceed:
>>>
>>> // Create a new locale based on a copy of the current one (which need
>>> not be explicitly set)
>>> // but where LC_NUMERIC has been modified to match the C locale
>>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>>> // Use this new locale and store the current one to reset it aftwards
>>> locale_t previousLocale = uselocale(templocale);
>>>
>>> [Actual useful code]
>>>
>>> // Reset the locale to the previous one
>>> uselocale(previousLocale)
>>> // More house keeing
>>> freelocale(tempLocale)
>>>
>>>
>>> Actually, on mac we also had to do explicitly create thread-specific
>>> locale to avoid some random crash in heavily threaded code. But that
>>> is a slightly different topic
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>>> I've already made a pass through the itk readers. Several were broken
>>>> wrt locale.
>>>>
>>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>>> locale in and itk::Locale class.
>>>>
>>>> I have not checked in any changes yet, but I went from over 40 failing
>>>> I/O tests down to 0.
>>>>
>>>> Bill
>>>>
>>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>>> <marcus.hanwell@...> wrote:
>>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>>> Luis,
>>>>>>
>>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>>> any changes yet. Still more investigation is needed as to the best
>>>>>> portable solution.
>>>>>>
>>>>>> I do this:
>>>>>> const char *originalLocale;
>>>>>> char *currentLocale;
>>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>>> setlocale(LC_NUMERIC, "C");
>>>>>>
>>>>>> ......
>>>>>>
>>>>>>
>>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>>> free(currentLocale);
>>>>>
>>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>>
>>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>>
>>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>>> snippets.
>>>>>>
>>>>>> There are other readers/writers that use C++ streams, and there we
>>>>>> will have to imbue.
>>>>>
>>>>> I think that using the C locale is probably the easiest short term solution,
>>>>> but to support GUIs using different locales we should be using the C++ locale
>>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>>> subtle bugs if reading and writing files in separate threads that are all
>>>>> using C locales.
>>>>>>
>>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>>> etc. In the long run we probably should address these cases with
>>>>>> stream replacements.
>>>>>
>>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>>> existing code with C++ streams. As you say this should probably be part of a
>>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>>> to our libraries.
>>>>>
>>>>> Marcus
>>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.html
>>>>
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>
>>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T12:36:48Z

On Mon, Nov 30, 2009 at 1:11 PM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:
> yes, thanks, in fact this is my pattern example but, in this example
> the sagital view is flipped, why is that?

You are complaining because the head is facing right instead of facing
left?? It is still sagittal.

> PS: So, to use ImageReslice for an dicom image viewer is not a problem?

No problem at all. Plenty of people use it for dicom. The only
restrictions are the following:

1) the spacing must be constant

2) the gantry must not be tilted

These restrictions are true for all vtkImageData. Fortunately, CT and
MRI almost always use constant slice spacing, so that is never a
problem. CT gantry tilt can be fairly common, though, so any dicom
image viewer should check for it. MR images never have gantry tilt.

David

>
> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> I didn't give the full path for the example in my last email. Here it is:
>>
>> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>>
>> David
>>
>>
>> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...> wrote:
>>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>>> would like to do so myself, but I don't know when I will have the
>>> time.
>>>
>>> I did submit a python reslicing example to VTK that you might find useful:
>>>
>>> VTK/Examples/Python/ImageSlicing.py
>>>
>>> David
>>>
>>>
>>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> why is that?
>>>>
>>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>>> The only class that uses vtkImageReslice for image viewing is
>>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>>>>> application. That is the closest thing to a generic reslicing image
>>>>> viewer that VTK has.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>>> <jmrbcu@...> wrote:
>>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>>>>> vtkImageReslice for changing the slice orientation (axial, sagital and
>>>>>> coronal)? I am just curious!!!
>>>>>>
>>>>>> --
>>>>>> Lic. José M. Rodriguez Bacallao
>>>>>> Centro de Biofisica Medica
>>>>>> -----------------------------------------------------------------
>>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>>> mismo.
>>>>>>
>>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>>> por profesionales
>>>>>> -----------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>>
>>>
>>
>
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T12:11:13Z

yes, thanks, in fact this is my pattern example but, in this example
the sagital view is flipped, why is that?

PS: So, to use ImageReslice for an dicom image viewer is not a problem?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> I didn't give the full path for the example in my last email. Here it is:
>
> VTK/Examples/ImageProcessing/Python/ImageSlicing.py
>
> David
>
>
> On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...> wrote:
>> Because no-one has contributed a reslicng image viewer to VTK yet. I
>> would like to do so myself, but I don't know when I will have the
>> time.
>>
>> I did submit a python reslicing example to VTK that you might find useful:
>>
>> VTK/Examples/Python/ImageSlicing.py
>>
>> David
>>
>>
>> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> why is that?
>>>
>>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>>> The only class that uses vtkImageReslice for image viewing is
>>>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>>>> application. That is the closest thing to a generic reslicing image
>>>> viewer that VTK has.
>>>>
>>>> David
>>>>
>>>>
>>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>>> <jmrbcu@...> wrote:
>>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>>>> vtkImageReslice for changing the slice orientation (axial, sagital and
>>>>> coronal)? I am just curious!!!
>>>>>
>>>>> --
>>>>> Lic. José M. Rodriguez Bacallao
>>>>> Centro de Biofisica Medica
>>>>> -----------------------------------------------------------------
>>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>>> mismo.
>>>>>
>>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>>> por profesionales
>>>>> -----------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>>
>>>>
>>>
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>>
>>
>

From forum: VTK - Users

Re: QVTK resizing on Windows XP

2009-11-30T11:47:49Z

Hello Clint,

I will do tests with Paraview tomorrow and report the results to you. I did not use Paraview for a while, but I cannot remember comparable problems with it.

lars

-------- Original-Nachricht --------
> Datum: Mon, 30 Nov 2009 12:13:05 -0700
> Von: Clinton Stimpson <clinton@...>
> An: vtkusers@...
> Betreff: Re: [vtkusers] QVTK resizing on Windows XP

>
> Oh, then maybe the saveImageToCache() is causing an extra render that is
> "solving" you problem. Do you see the same problem in an application like
> paraview, which uses splitters too?
>
> Clint
>
> On Monday 30 November 2009 12:07:35 pm Lars Friedrich Lars wrote:
> > No, I do not call setAutomaticImageCacheEnabled(true) in my application;
> > this features is deactivated. Some cross-platform experiments in the
> past
> > with this flag set to TRUE showed me that it does not reliably work in
> 100%
> > of the cases - as you confirmed below. I just call the related methods
> > after resizing the widget as explained in the previous mail. My
> application
> > is basically built as standalone application and - on demand (on windows
> > systems) - with an additional shared lib interface. The described
> > workaround works on windows Vista / XP / 2000 for the standalone version
> > and the shared lib interface; it also works on Ubuntu 64 bit.
> >
> > lars
> >
> >
> > -------- Original-Nachricht --------
> >
> > > Datum: Mon, 30 Nov 2009 08:21:04 -0700
> > > Von: Clinton Stimpson <clinton@...>
> > > An: vtkusers@...
> > > Betreff: Re: [vtkusers] QVTK resizing on Windows XP
> > >
> > >
> > > Are you calling setAutomaticImageCacheEnabled(true) to enable image
> > > caching with it?
> > > Maybe you should avoid doing this.
> > > I don't know if its been found to be useful in practice as it was once
> > > tried in ParaView but it didn't work too well. Whether one has
> problems
> > > with it is dependent on the windowing system.
> > >
> > > Personally, I think the problem QVTKWidget's image caching tries to
> > > solve, is best solved by the windowing system. Mac OSX and some Linux
> > > desktops already do it.
> > >
> > > Clint
> > >
> > > On 11/30/2009 08:04 AM, Lars Friedrich Lars wrote:
> > > > Hello,
> > > >
> > > > I just would like to report a solution to the problem outlined in
> the
> > >
> > > previous mail:
> > > > It seems to be a pure QVTKWidget problem; after resizing the
> QVTKWidget
> > >
> > > invoking the following code-cascade works to successfully render the
> > >
> > > complete viewport:
> > > > qvtk->markCachedImageAsDirty();
> > > > qvtk->saveImageToCache();
> > > > qvtk->GetRenderWindow()->Render();
> > > >
> > > > However, it is really interesting that this problem occurs on
> Windows
> > > > XP
> > >
> > > only ...
> > >
> > > > I must admit that it is a very special situation as the Qt-based GUI
> is
> > >
> > > implemented within a DLL and called via a Delphi-client-application.
> You
> > > can read more about the related signal/slot problems here:
> > >
> http://lists.trolltech.com/pipermail/qt-interest/2009-November/014826.htm
> > >l
> > >
> > > > Maybe there are other people struggling around with similar problems
> > > > who
> > >
> > > can take advantage of this 'solution'.
> > >
> > > > regards,
> > > >
> > > > lars
> > > >
> > > >
> > > > -------- Original-Nachricht --------
> > > >
> > > >> Datum: Mon, 23 Nov 2009 20:31:22 +0100
> > > >> Von: "Lars Friedrich Lars"<lars-friedrich@...>
> > > >> An: vtkusers@...
> > > >> Betreff: [vtkusers] QVTK resizing on Windows XP
> > > >>
> > > >>
> > > >> Hello,
> > > >>
> > > >> I have an application which uses multiple QVTKWidgets to render
> > >
> > > different
> > >
> > > >> scenes (as shown on the attached screen shots). During run-time I
> can
> > > >> resize the widgets' size with the help of splitters. Normally a
> > >
> > > VTK-scene (the
> > >
> > > >> vtkRenderWindow ...) immediately adapts to the QVTKWidget's size.
> But
> > >
> > > on
> > >
> > > >> windows XP I am facing serious problems: as can be seen von the
> second
> > >
> > > screen
> > >
> > > >> shot, the vtkRenderWindow gets cut at the bottom.
> > > >>
> > > >> Did someone face similiar problems?
> > > >>
> > > >> It may the worth to annotate that the interactor (e.g. rotating the
> > > >> camera) still works in the cut area at the bottom, but the scene is
> > > >> not
> > >
> > > rendered.
> > >
> > > >> Furthermore, this problem solely exists on Windows XP (32 and 64
> bit)
> > > >> -
> > >
> > > it
> > >
> > > >> works on Windows 2000 / Vista / 7. It also works in an ordinary
> > >
> > > executable
> > >
> > > >> on Windows XP, but not when my user interface is called out of a
> DLL.
> > > >>
> > > >> I guess there are some problems with some openGL buffers in the
> > >
> > > background
> > >
> > > >> and the device context. Are there possibilities to force the render
> > >
> > > window
> > >
> > > >> to reallocate its buffer?
> > > >>
> > > >> Can you help me, please? I am kind of desperate.
> > > >>
> > > >> regards,
> > > >>
> > > >> lars
> > > >>
> > > >> --
> > > >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > > >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> > >
> > > _______________________________________________
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at
> > > http://www.kitware.com/opensource/opensource.html
> > >
> > > Please keep messages on-topic and check the VTK FAQ at:
> > > http://www.vtk.org/Wiki/VTK_FAQ
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > http://www.vtk.org/mailman/listinfo/vtkusers
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers

--
Endlich! Das Debüt-Album von Pop-Diva Sarah Kreuz ist da!
Jetzt bei GMX Musik Downloads. http://portal.gmx.net/de/go/musik01
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T11:27:31Z

I didn't give the full path for the example in my last email. Here it is:

VTK/Examples/ImageProcessing/Python/ImageSlicing.py

David

On Mon, Nov 30, 2009 at 12:25 PM, David Gobbi <david.gobbi@...> wrote:

> Because no-one has contributed a reslicng image viewer to VTK yet. I
> would like to do so myself, but I don't know when I will have the
> time.
>
> I did submit a python reslicing example to VTK that you might find useful:
>
> VTK/Examples/Python/ImageSlicing.py
>
> David
>
>
> On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> why is that?
>>
>> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>>> The only class that uses vtkImageReslice for image viewing is
>>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>>> application. That is the closest thing to a generic reslicing image
>>> viewer that VTK has.
>>>
>>> David
>>>
>>>
>>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>>> vtkImageReslice for changing the slice orientation (axial, sagital and
>>>> coronal)? I am just curious!!!
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>>
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T11:25:54Z

Because no-one has contributed a reslicng image viewer to VTK yet. I
would like to do so myself, but I don't know when I will have the
time.

I did submit a python reslicing example to VTK that you might find useful:

VTK/Examples/Python/ImageSlicing.py

David

On Mon, Nov 30, 2009 at 11:45 AM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:

> why is that?
>
> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> The only class that uses vtkImageReslice for image viewing is
>> vtkImagePlaneWidget, you can try it to see if it is suitable for your
>> application. That is the closest thing to a generic reslicing image
>> viewer that VTK has.
>>
>> David
>>
>>
>> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>>> vtkImageReslice for changing the slice orientation (axial, sagital and
>>> coronal)? I am just curious!!!
>>>
>>> --
>>> Lic. José M. Rodriguez Bacallao
>>> Centro de Biofisica Medica
>>> -----------------------------------------------------------------
>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>> mismo.
>>>
>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>> por profesionales
>>> -----------------------------------------------------------------
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>
>
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
>

From forum: VTK - Users

Re: QVTK resizing on Windows XP

2009-11-30T11:12:45Z

Oh, then maybe the saveImageToCache() is causing an extra render that is
"solving" you problem. Do you see the same problem in an application like
paraview, which uses splitters too?

Clint

On Monday 30 November 2009 12:07:35 pm Lars Friedrich Lars wrote:

> No, I do not call setAutomaticImageCacheEnabled(true) in my application;
> this features is deactivated. Some cross-platform experiments in the past
> with this flag set to TRUE showed me that it does not reliably work in 100%
> of the cases - as you confirmed below. I just call the related methods
> after resizing the widget as explained in the previous mail. My application
> is basically built as standalone application and - on demand (on windows
> systems) - with an additional shared lib interface. The described
> workaround works on windows Vista / XP / 2000 for the standalone version
> and the shared lib interface; it also works on Ubuntu 64 bit.
>
> lars
>
>
> -------- Original-Nachricht --------
>
> > Datum: Mon, 30 Nov 2009 08:21:04 -0700
> > Von: Clinton Stimpson <clinton@...>
> > An: vtkusers@...
> > Betreff: Re: [vtkusers] QVTK resizing on Windows XP
> >
> >
> > Are you calling setAutomaticImageCacheEnabled(true) to enable image
> > caching with it?
> > Maybe you should avoid doing this.
> > I don't know if its been found to be useful in practice as it was once
> > tried in ParaView but it didn't work too well. Whether one has problems
> > with it is dependent on the windowing system.
> >
> > Personally, I think the problem QVTKWidget's image caching tries to
> > solve, is best solved by the windowing system. Mac OSX and some Linux
> > desktops already do it.
> >
> > Clint
> >
> > On 11/30/2009 08:04 AM, Lars Friedrich Lars wrote:
> > > Hello,
> > >
> > > I just would like to report a solution to the problem outlined in the
> >
> > previous mail:
> > > It seems to be a pure QVTKWidget problem; after resizing the QVTKWidget
> >
> > invoking the following code-cascade works to successfully render the
> >
> > complete viewport:
> > > qvtk->markCachedImageAsDirty();
> > > qvtk->saveImageToCache();
> > > qvtk->GetRenderWindow()->Render();
> > >
> > > However, it is really interesting that this problem occurs on Windows
> > > XP
> >
> > only ...
> >
> > > I must admit that it is a very special situation as the Qt-based GUI is
> >
> > implemented within a DLL and called via a Delphi-client-application. You
> > can read more about the related signal/slot problems here:
> > http://lists.trolltech.com/pipermail/qt-interest/2009-November/014826.htm
> >l
> >
> > > Maybe there are other people struggling around with similar problems
> > > who
> >
> > can take advantage of this 'solution'.
> >
> > > regards,
> > >
> > > lars
> > >
> > >
> > > -------- Original-Nachricht --------
> > >
> > >> Datum: Mon, 23 Nov 2009 20:31:22 +0100
> > >> Von: "Lars Friedrich Lars"<lars-friedrich@...>
> > >> An: vtkusers@...
> > >> Betreff: [vtkusers] QVTK resizing on Windows XP
> > >>
> > >>
> > >> Hello,
> > >>
> > >> I have an application which uses multiple QVTKWidgets to render
> >
> > different
> >
> > >> scenes (as shown on the attached screen shots). During run-time I can
> > >> resize the widgets' size with the help of splitters. Normally a
> >
> > VTK-scene (the
> >
> > >> vtkRenderWindow ...) immediately adapts to the QVTKWidget's size. But
> >
> > on
> >
> > >> windows XP I am facing serious problems: as can be seen von the second
> >
> > screen
> >
> > >> shot, the vtkRenderWindow gets cut at the bottom.
> > >>
> > >> Did someone face similiar problems?
> > >>
> > >> It may the worth to annotate that the interactor (e.g. rotating the
> > >> camera) still works in the cut area at the bottom, but the scene is
> > >> not
> >
> > rendered.
> >
> > >> Furthermore, this problem solely exists on Windows XP (32 and 64 bit)
> > >> -
> >
> > it
> >
> > >> works on Windows 2000 / Vista / 7. It also works in an ordinary
> >
> > executable
> >
> > >> on Windows XP, but not when my user interface is called out of a DLL.
> > >>
> > >> I guess there are some problems with some openGL buffers in the
> >
> > background
> >
> > >> and the device context. Are there possibilities to force the render
> >
> > window
> >
> > >> to reallocate its buffer?
> > >>
> > >> Can you help me, please? I am kind of desperate.
> > >>
> > >> regards,
> > >>
> > >> lars
> > >>
> > >> --
> > >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> > >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at:
> > http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: QVTK resizing on Windows XP

2009-11-30T11:07:35Z

No, I do not call setAutomaticImageCacheEnabled(true) in my application; this features is deactivated. Some cross-platform experiments in the past with this flag set to TRUE showed me that it does not reliably work in 100% of the cases - as you confirmed below.
I just call the related methods after resizing the widget as explained in the previous mail.
My application is basically built as standalone application and - on demand (on windows systems) - with an additional shared lib interface. The described workaround works on windows Vista / XP / 2000 for the standalone version and the shared lib interface; it also works on Ubuntu 64 bit.

lars

-------- Original-Nachricht --------
> Datum: Mon, 30 Nov 2009 08:21:04 -0700
> Von: Clinton Stimpson <clinton@...>
> An: vtkusers@...
> Betreff: Re: [vtkusers] QVTK resizing on Windows XP

>
> Are you calling setAutomaticImageCacheEnabled(true) to enable image
> caching with it?
> Maybe you should avoid doing this.
> I don't know if its been found to be useful in practice as it was once
> tried in ParaView but it didn't work too well. Whether one has problems
> with it is dependent on the windowing system.
>
> Personally, I think the problem QVTKWidget's image caching tries to
> solve, is best solved by the windowing system. Mac OSX and some Linux
> desktops already do it.
>
> Clint
>
> On 11/30/2009 08:04 AM, Lars Friedrich Lars wrote:
> > Hello,
> >
> > I just would like to report a solution to the problem outlined in the
> previous mail:
> >
> > It seems to be a pure QVTKWidget problem; after resizing the QVTKWidget
> invoking the following code-cascade works to successfully render the
> complete viewport:
> > qvtk->markCachedImageAsDirty();
> > qvtk->saveImageToCache();
> > qvtk->GetRenderWindow()->Render();
> >
> > However, it is really interesting that this problem occurs on Windows XP
> only ...
> > I must admit that it is a very special situation as the Qt-based GUI is
> implemented within a DLL and called via a Delphi-client-application. You
> can read more about the related signal/slot problems here:
> http://lists.trolltech.com/pipermail/qt-interest/2009-November/014826.html
> >
> > Maybe there are other people struggling around with similar problems who
> can take advantage of this 'solution'.
> >
> > regards,
> >
> > lars
> >
> >
> > -------- Original-Nachricht --------
> >
> >> Datum: Mon, 23 Nov 2009 20:31:22 +0100
> >> Von: "Lars Friedrich Lars"<lars-friedrich@...>
> >> An: vtkusers@...
> >> Betreff: [vtkusers] QVTK resizing on Windows XP
> >>
> >
> >> Hello,
> >>
> >> I have an application which uses multiple QVTKWidgets to render
> different
> >> scenes (as shown on the attached screen shots). During run-time I can
> >> resize the widgets' size with the help of splitters. Normally a
> VTK-scene (the
> >> vtkRenderWindow ...) immediately adapts to the QVTKWidget's size. But
> on
> >> windows XP I am facing serious problems: as can be seen von the second
> screen
> >> shot, the vtkRenderWindow gets cut at the bottom.
> >>
> >> Did someone face similiar problems?
> >>
> >> It may the worth to annotate that the interactor (e.g. rotating the
> >> camera) still works in the cut area at the bottom, but the scene is not
> rendered.
> >> Furthermore, this problem solely exists on Windows XP (32 and 64 bit) -
> it
> >> works on Windows 2000 / Vista / 7. It also works in an ordinary
> executable
> >> on Windows XP, but not when my user interface is called out of a DLL.
> >>
> >> I guess there are some problems with some openGL buffers in the
> background
> >> and the device context. Are there possibilities to force the render
> window
> >> to reallocate its buffer?
> >>
> >> Can you help me, please? I am kind of desperate.
> >>
> >> regards,
> >>
> >> lars
> >>
> >> --
> >> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >>
> >
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers

--
Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen
Debütalbum "One Moment in Time". http://portal.gmx.net/de/go/musik
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T10:45:53Z

why is that?

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> The only class that uses vtkImageReslice for image viewing is
> vtkImagePlaneWidget, you can try it to see if it is suitable for your
> application. That is the closest thing to a generic reslicing image
> viewer that VTK has.
>
> David
>
>
> On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
>> vtkImageReslice for changing the slice orientation (axial, sagital and
>> coronal)? I am just curious!!!
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T10:04:44Z

Tom,

I don't think we need to be concerned with the per-thread issue. My
changes are all local to the methods that need c-locale's. For
example, surrounding the ReadImageInformation calls with save/restore
locales in many readers fixes the readers.

Maybe you can try my simple itkLocale class. I'll send it in a separate mail.

Bill

On Mon, Nov 30, 2009 at 12:57 PM, Bill Lorensen <bill.lorensen@...> wrote:

> Tom,
>
> What I have done is create an itk class, itkLocale, that in its
> constructor saves the current c-locale and creates a new one. The
> destructor restores the original locale.
>
> C++-locales are handled explicitly with imbue.
>
> I'll try your approach in the itkLocale class.
>
> BTW, I have not checked in any code yet.
>
> I think it is time to start an ITK Policy and Procedure page for
> internationalization on the itk wiki.
>
> It can include the work you are doing with unicode.
>
> I'll give it a stab today. Then we can start a new thread on itk developers.
>
> Bill
>
>
> On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
> <tom.vercauteren@...> wrote:
>> Hi Bill,
>>
>> I would just like to mention that in our group we have been facing
>> several issues with locale support on mac.
>>
>> Looking at the documentation of xlocale:
>> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
>> you will see that setlocale will have absolutely no effect (on mac,
>> maybe on windows also
>> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
>> per-thread locale had been specified.
>>
>> Using newlocale, duplocale, uselocale and freelocale seems a better option:
>> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
>> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
>> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>>
>>
>> For example, to put only the LC_NUMERIC parameter to C, here is how we
>> chose to proceed:
>>
>> // Create a new locale based on a copy of the current one (which need
>> not be explicitly set)
>> // but where LC_NUMERIC has been modified to match the C locale
>> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
>> // Use this new locale and store the current one to reset it aftwards
>> locale_t previousLocale = uselocale(templocale);
>>
>> [Actual useful code]
>>
>> // Reset the locale to the previous one
>> uselocale(previousLocale)
>> // More house keeing
>> freelocale(tempLocale)
>>
>>
>> Actually, on mac we also had to do explicitly create thread-specific
>> locale to avoid some random crash in heavily threaded code. But that
>> is a slightly different topic
>>
>> Cheers,
>> Tom
>>
>>
>> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>>> I've already made a pass through the itk readers. Several were broken
>>> wrt locale.
>>>
>>> I used a combination of C++ and C locale api's. I encapsulated the C
>>> locale in and itk::Locale class.
>>>
>>> I have not checked in any changes yet, but I went from over 40 failing
>>> I/O tests down to 0.
>>>
>>> Bill
>>>
>>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>>> <marcus.hanwell@...> wrote:
>>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>>> Luis,
>>>>>
>>>>> Actually, we can surround certain functions with c-style setlocale and
>>>>> it solves the problems. I already fixed StimulateImageIO,
>>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>>> any changes yet. Still more investigation is needed as to the best
>>>>> portable solution.
>>>>>
>>>>> I do this:
>>>>> const char *originalLocale;
>>>>> char *currentLocale;
>>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>>> setlocale(LC_NUMERIC, "C");
>>>>>
>>>>> ......
>>>>>
>>>>>
>>>>> setlocale(LC_NUMERIC, currentLocale);
>>>>> free(currentLocale);
>>>>
>>>> A page from the Apache C++ resource site gives some good explanations of why
>>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>>
>>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>>
>>>>> For example in StimulateImageIO I surrounded the calls in
>>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>>> snippets.
>>>>>
>>>>> There are other readers/writers that use C++ streams, and there we
>>>>> will have to imbue.
>>>>
>>>> I think that using the C locale is probably the easiest short term solution,
>>>> but to support GUIs using different locales we should be using the C++ locale
>>>> class and associated API. Otherwise users of our libraries may suffer from
>>>> subtle bugs if reading and writing files in separate threads that are all
>>>> using C locales.
>>>>>
>>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>>> etc. In the long run we probably should address these cases with
>>>>> stream replacements.
>>>>
>>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>>> existing code with C++ streams. As you say this should probably be part of a
>>>> larger i18n effort which would involve using Unicode strings and other changes
>>>> to our libraries.
>>>>
>>>> Marcus
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T09:57:16Z

Tom,

What I have done is create an itk class, itkLocale, that in its
constructor saves the current c-locale and creates a new one. The
destructor restores the original locale.

C++-locales are handled explicitly with imbue.

I'll try your approach in the itkLocale class.

BTW, I have not checked in any code yet.

I think it is time to start an ITK Policy and Procedure page for
internationalization on the itk wiki.

It can include the work you are doing with unicode.

I'll give it a stab today. Then we can start a new thread on itk developers.

Bill

On Mon, Nov 30, 2009 at 12:50 PM, Tom Vercauteren
<tom.vercauteren@...> wrote:

> Hi Bill,
>
> I would just like to mention that in our group we have been facing
> several issues with locale support on mac.
>
> Looking at the documentation of xlocale:
> http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html
> you will see that setlocale will have absolutely no effect (on mac,
> maybe on windows also
> http://msdn.microsoft.com/en-us/library/26c0tb7x.aspx ) if a
> per-thread locale had been specified.
>
> Using newlocale, duplocale, uselocale and freelocale seems a better option:
> http://www.opengroup.org/onlinepubs/9699919799/functions/uselocale.html
> http://www.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
> http://www.opengroup.org/onlinepubs/9699919799/functions/duplocale.html
> http://www.opengroup.org/onlinepubs/9699919799/functions/freelocale.html
>
>
> For example, to put only the LC_NUMERIC parameter to C, here is how we
> chose to proceed:
>
> // Create a new locale based on a copy of the current one (which need
> not be explicitly set)
> // but where LC_NUMERIC has been modified to match the C locale
> locale_t tempLocale = newlocale(LC_NUMERIC_MASK, NULL, NULL);
> // Use this new locale and store the current one to reset it aftwards
> locale_t previousLocale = uselocale(templocale);
>
> [Actual useful code]
>
> // Reset the locale to the previous one
> uselocale(previousLocale)
> // More house keeing
> freelocale(tempLocale)
>
>
> Actually, on mac we also had to do explicitly create thread-specific
> locale to avoid some random crash in heavily threaded code. But that
> is a slightly different topic
>
> Cheers,
> Tom
>
>
> On Mon, Nov 30, 2009 at 17:08, Bill Lorensen <bill.lorensen@...> wrote:
>> I've already made a pass through the itk readers. Several were broken
>> wrt locale.
>>
>> I used a combination of C++ and C locale api's. I encapsulated the C
>> locale in and itk::Locale class.
>>
>> I have not checked in any changes yet, but I went from over 40 failing
>> I/O tests down to 0.
>>
>> Bill
>>
>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>> <marcus.hanwell@...> wrote:
>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>> Luis,
>>>>
>>>> Actually, we can surround certain functions with c-style setlocale and
>>>> it solves the problems. I already fixed StimulateImageIO,
>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>> any changes yet. Still more investigation is needed as to the best
>>>> portable solution.
>>>>
>>>> I do this:
>>>> const char *originalLocale;
>>>> char *currentLocale;
>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>> setlocale(LC_NUMERIC, "C");
>>>>
>>>> ......
>>>>
>>>>
>>>> setlocale(LC_NUMERIC, currentLocale);
>>>> free(currentLocale);
>>>
>>> A page from the Apache C++ resource site gives some good explanations of why
>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>
>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>
>>>> For example in StimulateImageIO I surrounded the calls in
>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>> snippets.
>>>>
>>>> There are other readers/writers that use C++ streams, and there we
>>>> will have to imbue.
>>>
>>> I think that using the C locale is probably the easiest short term solution,
>>> but to support GUIs using different locales we should be using the C++ locale
>>> class and associated API. Otherwise users of our libraries may suffer from
>>> subtle bugs if reading and writing files in separate threads that are all
>>> using C locales.
>>>>
>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>> etc. In the long run we probably should address these cases with
>>>> stream replacements.
>>>
>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>> existing code with C++ streams. As you say this should probably be part of a
>>> larger i18n effort which would involve using Unicode strings and other changes
>>> to our libraries.
>>>
>>> Marcus
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T09:24:44Z

Nice.

I'll look at doing the same in itk's test driver. I did it manually
for my initial pass.

One caveat. Tests may pass but if they use atof() to parse argv, the
resultant floating point number may be wrong.

itk has lots of tests that use atof().

Bill

On Mon, Nov 30, 2009 at 11:48 AM, Francois Bertel
<francois.bertel@...> wrote:

> Hello,
>
> I just changed VTK/CMakeLists.txt and
> VTK/Common/Testing/Cxx/vtkTestDriver.h to be able to run the C++ tests
> under locale conditions.
>
> An advanced flag VTK_TESTING_USE_LOCALE (initial value to OFF) allows
> to test the C++ tests with locale.
> VTK_TESTING_LOCALE is an advanced string variable (initial value to an
> empty string) storing the name of the locale (example: fr_FR.utf8). If
> the string is empty it looks at the current environment variables
> LC_*, if the string is specified, it
> takes it into account, overwriting whatever is in the environment variables.
>
> If VTK_TESTING_USE_LOCALE is ON, the c++ tests start with a call to
> the C function setlocale() and with a call to the C++ funtion
> std::locale::global().
>
>
>
> On Mon, Nov 30, 2009 at 11:08 AM, Bill Lorensen <bill.lorensen@...> wrote:
>> I've already made a pass through the itk readers. Several were broken
>> wrt locale.
>>
>> I used a combination of C++ and C locale api's. I encapsulated the C
>> locale in and itk::Locale class.
>>
>> I have not checked in any changes yet, but I went from over 40 failing
>> I/O tests down to 0.
>>
>> Bill
>>
>> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
>> <marcus.hanwell@...> wrote:
>>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>>> Luis,
>>>>
>>>> Actually, we can surround certain functions with c-style setlocale and
>>>> it solves the problems. I already fixed StimulateImageIO,
>>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>>> any changes yet. Still more investigation is needed as to the best
>>>> portable solution.
>>>>
>>>> I do this:
>>>> const char *originalLocale;
>>>> char *currentLocale;
>>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>>> setlocale(LC_NUMERIC, "C");
>>>>
>>>> ......
>>>>
>>>>
>>>> setlocale(LC_NUMERIC, currentLocale);
>>>> free(currentLocale);
>>>
>>> A page from the Apache C++ resource site gives some good explanations of why
>>> the C++ locale should be preferred. Mainly because the C locale is a global
>>> resource, whereas in the C++ locale instances of the locale can be created.
>>>
>>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>>
>>>> For example in StimulateImageIO I surrounded the calls in
>>>> StimulateImageIO::InternalReadImageInformation with the above
>>>> snippets.
>>>>
>>>> There are other readers/writers that use C++ streams, and there we
>>>> will have to imbue.
>>>
>>> I think that using the C locale is probably the easiest short term solution,
>>> but to support GUIs using different locales we should be using the C++ locale
>>> class and associated API. Otherwise users of our libraries may suffer from
>>> subtle bugs if reading and writing files in separate threads that are all
>>> using C locales.
>>>>
>>>> Even in some code that uses streams, people still use sscanf, atof,
>>>> etc. In the long run we probably should address these cases with
>>>> stream replacements.
>>>
>>> We should aim to ensure new code uses C++ streams and imbue, and replace
>>> existing code with C++ streams. As you say this should probably be part of a
>>> larger i18n effort which would involve using Unicode strings and other changes
>>> to our libraries.
>>>
>>> Marcus
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>
>
>
> --
> François Bertel, PhD | Kitware Inc. Suite 204
> 1 (518) 371 3971 x113 | 28 Corporate Drive
> | Clifton Park NY 12065, USA
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: vtkImageColorViewer and slice orientation

2009-11-30T09:07:46Z

The only class that uses vtkImageReslice for image viewing is
vtkImagePlaneWidget, you can try it to see if it is suitable for your
application. That is the closest thing to a generic reslicing image
viewer that VTK has.

David

On Mon, Nov 30, 2009 at 9:20 AM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:

> why vtkImageColorViewer(I think that vtkImageViewer2 too) doesn't use
> vtkImageReslice for changing the slice orientation (axial, sagital and
> coronal)? I am just curious!!!
>
> --
> Lic. José M. Rodriguez Bacallao
> Centro de Biofisica Medica
> -----------------------------------------------------------------
> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo mismo.
>
> Recuerda: El arca de Noe fue construida por aficionados, el titanic
> por profesionales
> -----------------------------------------------------------------
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: vtkImageColorViewer

2009-11-30T09:02:36Z

You can verify what objects aren't deleted by compiling VTK with
VTK_DEBUG_LEAKS set in your CMakeCache.txt file. There might be some
other objects that are connected to the viewer that cause VTK not to
delete it.

David

On Mon, Nov 30, 2009 at 9:31 AM, Lic. José M. Rodriguez Bacallao
<jmrbcu@...> wrote:

> sorry, I forgot to put it in the example, but, I already do what U
> said and nothing happened
>
> r = vtkgdcm.vtkGDCMImageReader()
> r.SetFileName('/path/to/image.dcm')
> r.Update()
>
> v = vtkgdcm.vtkImageColorViewer()
> v.SetInputConnection(r.GetOutputPort())
> v.SetupInteractor(QT Interactor)
> v.SetRenderWindow(Qt Interactor.GetRenderWindow())
> v.Render()
>
> this is what I am doing in the close event of my widget in the tab:
>
> v.SetupInteractor(None)
> v.SetInputConnection(None)
> v = None
> del v
>
> r = None
> del r
>
>
> On 11/30/09, David Gobbi <david.gobbi@...> wrote:
>> Hi José,
>>
>> Please keep the discussion on the list.
>>
>> In the example code in your email, you aren't disconnecting the viewer
>> from the pipeline. In my email, I specifically said you should remove
>> the input from the viewer. Why didn't you do it? Don't you like my
>> advice?
>>
>> I will repeat myself. Before you delete the viewer, do this:
>>
>> v.SetInputConnection(None)
>>
>> Email me back and tell me if that works.
>>
>> David
>>
>>
>> On Mon, Nov 30, 2009 at 9:02 AM, Lic. José M. Rodriguez Bacallao
>> <jmrbcu@...> wrote:
>>> this is how I setup my pipeline:
>>>
>>> r = vtkgdcm.vtkGDCMImageReader()
>>> r.SetFileName('/path/to/image.dcm')
>>> r.Update()
>>>
>>> v = vtkgdcm.vtkImageColorViewer()
>>> v.SetInputConnection(r.GetOutputPort())
>>> v.SetupInteractor(QT Interactor)
>>> v.SetRenderWindow(Qt Interactor.GetRenderWindow())
>>> v.Render()
>>>
>>> this is what I am doing in the close event of my widget in the tab:
>>>
>>> v.SetupInteractor(None)
>>> v = None
>>> del v
>>>
>>> r = None
>>> del r
>>>
>>> but it doesn't release its memory, just a few Mb, not all.
>>>
>>> On 11/28/09, David Gobbi <david.gobbi@...> wrote:
>>>> Hi José,
>>>>
>>>> Before calling "del" you should remove it from the pipeline. This is
>>>> done with any one of these three calls:
>>>>
>>>> object.RemoveAllInputs(), if the object is a vtkAlgorithm
>>>>
>>>> object.SetInputConnection(None), if the object is faking a vtkAlgorithm
>>>>
>>>> object.SetInput(None), if the object still uses the old pipeline API
>>>>
>>>> After that, the "del" should release the memory immediately. If it
>>>> doesn't, you can always force the garbage collection:
>>>>
>>>> # force python garbage collection
>>>> import gc
>>>> gc.collect()
>>>>
>>>> # force VTK garbage collection
>>>> import vtk
>>>> vtk.vtkGarbageCollector.Collect()
>>>>
>>>> Forcing the garbage collector usually isn't necessary if you have
>>>> disconnected the object from the pipeline.
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Nov 28, 2009 at 3:50 PM, Lic. José M. Rodriguez Bacallao
>>>> <jmrbcu@...> wrote:
>>>>> hi folks, how do I release the memory occupied by an
>>>>> vtkImageColorViewer used from python?
>>>>> I think it is not properly garbage collected, even when I try remove
>>>>> it with "del"

From forum: VTK - Users

Re: [Insight-developers] wx/vtk weirdness

2009-11-30T08:48:56Z

Hello,

I just changed VTK/CMakeLists.txt and
VTK/Common/Testing/Cxx/vtkTestDriver.h to be able to run the C++ tests
under locale conditions.

An advanced flag VTK_TESTING_USE_LOCALE (initial value to OFF) allows
to test the C++ tests with locale.
VTK_TESTING_LOCALE is an advanced string variable (initial value to an
empty string) storing the name of the locale (example: fr_FR.utf8). If
the string is empty it looks at the current environment variables
LC_*, if the string is specified, it
takes it into account, overwriting whatever is in the environment variables.

If VTK_TESTING_USE_LOCALE is ON, the c++ tests start with a call to
the C function setlocale() and with a call to the C++ funtion
std::locale::global().

On Mon, Nov 30, 2009 at 11:08 AM, Bill Lorensen <bill.lorensen@...> wrote:

> I've already made a pass through the itk readers. Several were broken
> wrt locale.
>
> I used a combination of C++ and C locale api's. I encapsulated the C
> locale in and itk::Locale class.
>
> I have not checked in any changes yet, but I went from over 40 failing
> I/O tests down to 0.
>
> Bill
>
> On Mon, Nov 30, 2009 at 10:58 AM, Marcus D. Hanwell
> <marcus.hanwell@...> wrote:
>> On Saturday 28 November 2009 13:19:58 Bill Lorensen wrote:
>>> Luis,
>>>
>>> Actually, we can surround certain functions with c-style setlocale and
>>> it solves the problems. I already fixed StimulateImageIO,
>>> PolygonGroupSpatialObjectXMLFile and VTKImageIO. I have not checked in
>>> any changes yet. Still more investigation is needed as to the best
>>> portable solution.
>>>
>>> I do this:
>>> const char *originalLocale;
>>> char *currentLocale;
>>> originalLocale = setlocale(LC_NUMERIC, NULL);
>>> currentLocale = strdup(originalLocale ? originalLocale : "C");
>>> setlocale(LC_NUMERIC, "C");
>>>
>>> ......
>>>
>>>
>>> setlocale(LC_NUMERIC, currentLocale);
>>> free(currentLocale);
>>
>> A page from the Apache C++ resource site gives some good explanations of why
>> the C++ locale should be preferred. Mainly because the C locale is a global
>> resource, whereas in the C++ locale instances of the locale can be created.
>>
>> http://stdcxx.apache.org/doc/stdlibug/24-3.html
>>>
>>> For example in StimulateImageIO I surrounded the calls in
>>> StimulateImageIO::InternalReadImageInformation with the above
>>> snippets.
>>>
>>> There are other readers/writers that use C++ streams, and there we
>>> will have to imbue.
>>
>> I think that using the C locale is probably the easiest short term solution,
>> but to support GUIs using different locales we should be using the C++ locale
>> class and associated API. Otherwise users of our libraries may suffer from
>> subtle bugs if reading and writing files in separate threads that are all
>> using C locales.
>>>
>>> Even in some code that uses streams, people still use sscanf, atof,
>>> etc. In the long run we probably should address these cases with
>>> stream replacements.
>>
>> We should aim to ensure new code uses C++ streams and imbue, and replace
>> existing code with C++ streams. As you say this should probably be part of a
>> larger i18n effort which would involve using Unicode strings and other changes
>> to our libraries.
>>
>> Marcus
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>

From forum: VTK - Users

Re: vtkImageColorViewer

2009-11-30T08:31:15Z

sorry, I forgot to put it in the example, but, I already do what U
said and nothing happened

r = vtkgdcm.vtkGDCMImageReader()
r.SetFileName('/path/to/image.dcm')
r.Update()

v = vtkgdcm.vtkImageColorViewer()
v.SetInputConnection(r.GetOutputPort())
v.SetupInteractor(QT Interactor)
v.SetRenderWindow(Qt Interactor.GetRenderWindow())
v.Render()

this is what I am doing in the close event of my widget in the tab:

v.SetupInteractor(None)
v.SetInputConnection(None)
v = None
del v

r = None
del r

On 11/30/09, David Gobbi <david.gobbi@...> wrote:

> Hi José,
>
> Please keep the discussion on the list.
>
> In the example code in your email, you aren't disconnecting the viewer
> from the pipeline. In my email, I specifically said you should remove
> the input from the viewer. Why didn't you do it? Don't you like my
> advice?
>
> I will repeat myself. Before you delete the viewer, do this:
>
> v.SetInputConnection(None)
>
> Email me back and tell me if that works.
>
> David
>
>
> On Mon, Nov 30, 2009 at 9:02 AM, Lic. José M. Rodriguez Bacallao
> <jmrbcu@...> wrote:
>> this is how I setup my pipeline:
>>
>> r = vtkgdcm.vtkGDCMImageReader()
>> r.SetFileName('/path/to/image.dcm')
>> r.Update()
>>
>> v = vtkgdcm.vtkImageColorViewer()
>> v.SetInputConnection(r.GetOutputPort())
>> v.SetupInteractor(QT Interactor)
>> v.SetRenderWindow(Qt Interactor.GetRenderWindow())
>> v.Render()
>>
>> this is what I am doing in the close event of my widget in the tab:
>>
>> v.SetupInteractor(None)
>> v = None
>> del v
>>
>> r = None
>> del r
>>
>> but it doesn't release its memory, just a few Mb, not all.
>>
>> On 11/28/09, David Gobbi <david.gobbi@...> wrote:
>>> Hi José,
>>>
>>> Before calling "del" you should remove it from the pipeline. This is
>>> done with any one of these three calls:
>>>
>>> object.RemoveAllInputs(), if the object is a vtkAlgorithm
>>>
>>> object.SetInputConnection(None), if the object is faking a vtkAlgorithm
>>>
>>> object.SetInput(None), if the object still uses the old pipeline API
>>>
>>> After that, the "del" should release the memory immediately. If it
>>> doesn't, you can always force the garbage collection:
>>>
>>> # force python garbage collection
>>> import gc
>>> gc.collect()
>>>
>>> # force VTK garbage collection
>>> import vtk
>>> vtk.vtkGarbageCollector.Collect()
>>>
>>> Forcing the garbage collector usually isn't necessary if you have
>>> disconnected the object from the pipeline.
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>>
>>>
>>> On Sat, Nov 28, 2009 at 3:50 PM, Lic. José M. Rodriguez Bacallao
>>> <jmrbcu@...> wrote:
>>>> hi folks, how do I release the memory occupied by an
>>>> vtkImageColorViewer used from python?
>>>> I think it is not properly garbage collected, even when I try remove
>>>> it with "del"
>>>>
>>>> --
>>>> Lic. José M. Rodriguez Bacallao
>>>> Centro de Biofisica Medica
>>>> -----------------------------------------------------------------
>>>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>>>> mismo.
>>>>
>>>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>>>> por profesionales
>>>> -----------------------------------------------------------------
>>>
>>
>>
>> --
>> Lic. José M. Rodriguez Bacallao
>> Centro de Biofisica Medica
>> -----------------------------------------------------------------
>> Todos somos muy ignorantes, lo que ocurre es que no todos ignoramos lo
>> mismo.
>>
>> Recuerda: El arca de Noe fue construida por aficionados, el titanic
>> por profesionales
>> -----------------------------------------------------------------
>>
>

From forum: VTK - Users