[vtkusers] Problem with lookup table, mapper, and number of colors in 5.8
Riku
subs at collab.se
Wed Jun 22 10:23:44 EDT 2011
Hello all,
Presently it is not possible to report new issues in the VTK bugtracker
(???), so I post a follow-up to you:
Number of painted colors is sometimes wrong
In some circumstances the actual painted number of colors is wrong. The
number of colors set to the lookup table used by the user is not honoured.
Instead another (higher) number of colours is used. Testing shows that
version 5.6.1 did not have this problem.
I have found that the regression starts with the commit 46e01f5 (Changing
the amount of colors shown for lookup tables). The issue was reported on the
vtk users mailing list (link to thread below), and some suggestions were
offered.
I finally found time for a thorough git bisect session and can confirm that
the regression starts at the suggested commit.
Testing has been performed and the behaviour confirmed with the test code
below on several different platforms.
Detailed problem description (and testing code) here:
http://vtk.1045678.n5.nabble.com/Problem-with-lookup-table-mapper-and-number-of-colors-in-5-8-td3389336.html
Partial analysis:
Instead of using the hard-coded COLOR_TEXTURE_MAP_SIZE=1024 for the number
of available colors in vtkScalarsToColorsPainter.cxx, the function
GetNumberOfAvailableColors() was introduced in other classes for this
purpose. In doing so, something with the logic went astray (maybe in child
classes?), and the problem appeared.
A temporary solution for me has been to restore the hard-coded color texture
map size in vtkScalarsToColorsPainter.cxx, but the full problem seems more
intricate and I cannot provide a secure solution.
Note:
The problem appears (as far as I can see) when offscreen rendering is used
with OSMesa on Linux, and when software rendering is used on Windows. (The
last case can be provoked by running the test in a Remote Desktop session.)
Best regards,
Riku
On 5 April 2011 17:00, David E DeMarle <dave.demarle at kitware.com> wrote:
> My guess is that it has to do with the changes centering on this one,
> we're we removed the 256 color hard coded limit in the painters.
>
> 46e01f50d2d48dea54f630e383e37f91fb39b1bf
>
> Changing the amount of colors shown for lookup tables.
>
> There was a number of colors limit (256 in v3.8, and currently 1024)
> set in vtkScalarsToColorsPainter which is now changed to be
> limited by the nubmer of opengl texture colors. The changes to the
> other files are for specifying the amount of available colors
> in those lookup tables.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
>
>
>
> On Tue, Apr 5, 2011 at 10:33 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > Hmm... yes, if things are like you say, then it is not a bug in OSMesa.
> > Something must have changed in the Mapper code. Hopefully someone
> > on the list knows why InterpolateScalarsBeforeMappingOn() would behave
> > differently than it used to.
> >
> > - David
> >
> >
> > On Tue, Apr 5, 2011 at 8:11 AM, Riku <subs at collab.se> wrote:
> >> Hi David,
> >>
> >> Thank you for the suggestion. I just tested it, and attached the
> >> result here. Although it seems that the number of colors are more
> >> "correct", the image itself is not of much use in that state.
> >>
> >> But the main thing is: this behaviour appeared _after_ VTK 5.6.1. I
> >> have tried the exact same code compiled with (1) VTK 5.6.1 and with
> >> (2) the VTK release head, both linking to the same libOSMesa library
> >> (on the same machine). It seems unlikely the OpenGL implementation is
> >> changing here.
> >>
> >> This issue is one of very few remaining in a current task, and I'd
> >> love to get it resolved.
> >>
> >> Thanks for any further help,
> >>
> >> Riku
> >>
> >>
> >> On 5 April 2011 15:35, David Gobbi <david.gobbi at gmail.com> wrote:
> >>> Hi Riku,
> >>>
> >>> The discrepancy probably has something to do with this:
> >>>
> >>> mapper->InterpolateScalarsBeforeMappingOn();
> >>>
> >>> This method defers the color mapping to OpenGL, so it
> >>> might vary in behavior between OpenGL implementations.
> >>>
> >>> - David
> >>>
> >>>
> >>> On Tue, Apr 5, 2011 at 5:08 AM, Riku <subs at collab.se> wrote:
> >>>> Hello,
> >>>>
> >>>> I am going to annoyingly bump this topic again, as I still have found
> >>>> no solution to the problem. Has anyone been able to reproduce the
> >>>> deviant behaviour I described? At present I would categorize it a big
> >>>> problem to the code, unless I made a blatantly obvious mistake.
> >>>>
> >>>> To summarize: plots rendered with the release head of VTK and osmesa
> >>>> do not honour the number of colours set in the lookup table.
> >>>>
> >>>> (The VTK file referenced in the test code below is from the VTK data
> directory.)
> >>>>
> >>>> Thank you,
> >>>>
> >>>> Riku
> >>>>
> >>>>
> >>>> On 21 February 2011 13:34, Riku <subs at collab.se> wrote:
> >>>>> Hello,
> >>>>>
> >>>>> So far no new input regarding my problem (see below), so I thought
> I'd
> >>>>> report some more on the problem and my recent findings. (Hoping
> >>>>> someone might have a lead on this.)
> >>>>>
> >>>>> I have attached two PNG images that highlight my present problem.
> >>>>>
> >>>>> It seems that the problem is in some way related to OSMesa and/or
> what
> >>>>> happens in VTK when that implementation is used. For my testing, I
> >>>>> have created four different builds for shared objects:
> >>>>>
> >>>>> vtk-5.6.1
> >>>>> vtk-5.6.1-osmesa
> >>>>> vtk-5.8
> >>>>> vtk-5.8-osmesa <-- problem is here
> >>>>>
> >>>>> The CMake settings are the same for the four build, except for the
> >>>>> OSMesa settings. (VTK_OPENGL_HAS_OSMESA is true, VTK_USE_X
> >>>>> is false, OPENGL_gl_LIBRARY is set to the empty string.) For the
> >>>>> OSMesa builds, the resulting libraries have no dependencies on X
> >>>>> libraries or on libGL, only on libOSMesa.
> >>>>>
> >>>>> With the testing program (below), all is fine for the three first
> >>>>> cases. For vtk-5.8-osmesa the colors go "wild". Is this a bug in the
> >>>>> VTK code? I have started to review the code changes that I think are
> >>>>> involved, but have so far not found anything obviously useful.
> >>>>>
> >>>>> Still hoping for some leads! I am very thankful for any help, as I
> >>>>> need precisely my last case to work.
> >>>>>
> >>>>> Riku
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 17 February 2011 12:49, Riku <subs at collab.se> wrote:
> >>>>>> Hello all,
> >>>>>>
> >>>>>> I have a weird problem using the VTK source code from the release
> head
> >>>>>> in git. The results differ consistently between VS2008 (Windows 7
> >>>>>> 64-bit) and gcc (Ubuntu 10.10).
> >>>>>>
> >>>>>> In the test program I set the number of table values (colors) in the
> >>>>>> lookup table to 10. In the rendered image this is reflected
> correctly
> >>>>>> by the scalar bar actor, but NOT by the sliced structured grid, but
> >>>>>> only when running the program on Linux. I get a higher number of
> >>>>>> colors than requested, but it seems different inputs give different
> >>>>>> results. I have not been able to understand the logic of the
> problem.
> >>>>>> The Windows compiled program behaves "well".
> >>>>>>
> >>>>>> My test program below reproduces the problem. Am I missing anything
> >>>>>> obvious? Can someone else reproduce the problem? (Is this an issue
> for
> >>>>>> the developers?)
> >>>>>>
> >>>>>> I have compiled the release head in different varieties, all with
> the
> >>>>>> same result.
> >>>>>>
> >>>>>> Thanks for any help!
> >>>>>>
> >>>>>> Riku
> >>>>>>
> >>>>>> --- Test code below ---
> >>>>>>
> >>>>>> #include "vtkSmartPointer.h"
> >>>>>> #include "vtkDataSetReader.h"
> >>>>>> #include "vtkPlane.h"
> >>>>>> #include "vtkCutter.h"
> >>>>>> #include "vtkLookupTable.h"
> >>>>>> #include "vtkDataSetMapper.h"
> >>>>>> #include "vtkActor.h"
> >>>>>> #include "vtkScalarBarActor.h"
> >>>>>> #include "vtkRenderer.h"
> >>>>>> #include "vtkRenderWindow.h"
> >>>>>> #include "vtkWindowToImageFilter.h"
> >>>>>> #include "vtkPNGWriter.h"
> >>>>>>
> >>>>>> #define VTK_CREATE(type, var) vtkSmartPointer<type> var =
> >>>>>> vtkSmartPointer<type>::New()
> >>>>>>
> >>>>>> int main(int argc, char* argv[])
> >>>>>> {
> >>>>>> VTK_CREATE(vtkDataSetReader, reader);
> >>>>>> reader->SetFileName("SampleStructGrid.vtk");
> >>>>>> reader->Update();
> >>>>>>
> >>>>>> VTK_CREATE(vtkPlane, plane);
> >>>>>> plane->SetOrigin(0.5, 0.5, 0.26);
> >>>>>> plane->SetNormal(0, 0, 1);
> >>>>>>
> >>>>>> VTK_CREATE(vtkCutter, cutter);
> >>>>>> cutter->SetCutFunction(plane);
> >>>>>> cutter->SetInputConnection(reader->GetOutputPort());
> >>>>>>
> >>>>>> VTK_CREATE(vtkLookupTable, lut);
> >>>>>> lut->SetNumberOfTableValues(10);
> >>>>>> lut->SetHueRange(0.66667, 0);
> >>>>>> lut->Build();
> >>>>>>
> >>>>>> VTK_CREATE(vtkDataSetMapper, mapper);
> >>>>>> mapper->SetInputConnection(cutter->GetOutputPort());
> >>>>>> mapper->SetLookupTable(lut);
> >>>>>> mapper->InterpolateScalarsBeforeMappingOn();
> >>>>>> mapper->SetScalarRange(0.3, 1.1);
> >>>>>>
> >>>>>> VTK_CREATE(vtkActor, actor);
> >>>>>> actor->SetMapper(mapper);
> >>>>>>
> >>>>>> VTK_CREATE(vtkScalarBarActor, bar);
> >>>>>> bar->SetLookupTable(lut);
> >>>>>>
> bar->GetPositionCoordinate()->SetCoordinateSystemToNormalizedViewport();
> >>>>>> bar->GetPositionCoordinate()->SetValue(0.25, 0.01);
> >>>>>> bar->SetOrientationToHorizontal();
> >>>>>> bar->SetWidth(0.5);
> >>>>>> bar->SetHeight(0.11);
> >>>>>>
> >>>>>> VTK_CREATE(vtkRenderer, renderer);
> >>>>>> renderer->AddViewProp(actor);
> >>>>>> renderer->AddViewProp(bar);
> >>>>>> renderer->SetBackground(1, 1, 1);
> >>>>>> renderer->ResetCamera();
> >>>>>>
> >>>>>> VTK_CREATE(vtkRenderWindow, window);
> >>>>>> window->OffScreenRenderingOn();
> >>>>>> window->AddRenderer(renderer);
> >>>>>> window->SetSize(600, 600);
> >>>>>>
> >>>>>> VTK_CREATE(vtkWindowToImageFilter, wti);
> >>>>>> wti->SetInput(window);
> >>>>>>
> >>>>>> VTK_CREATE(vtkPNGWriter, writer);
> >>>>>> writer->SetInputConnection(wti->GetOutputPort());
> >>>>>> writer->SetFileName("test-color.png");
> >>>>>> writer->Write();
> >>>>>>
> >>>>>> return 0;
> >>>>>> }
> >>>>>>
> >>>>>> --- End test code ---
> >>>>>>
> >>>
> >>
> > _______________________________________________
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110622/85929b76/attachment.htm>
More information about the vtkusers
mailing list