[vtkusers] Problem with lookup table, mapper, and number of colors in 5.8

Andy Bauer andy.bauer at kitware.com
Mon Jun 27 15:15:14 EDT 2011


Hi Riku,

This problem cropts up because essentially the mesa version that you and I
are using wants to have a power of 2 (2^N) colors in it so it expands from
10 colors to 16.  It's not an easy fix and so it's been put in my backlog.
The behavior before was incorrect too but the problem was that it wasn't
noticeable as you'd be trying to divide 256, 512 or 1024 colors evenly into
10 colors (e.g. for 256 there would be 6 colors that would have 26 texels in
the texture and 4 colors that would have 25 texels in the texture).

If you really wanted only 10 colors (or some non-power of 2 colors), I'd
suggest trying vtkDiscretizableTransferFunction instead.

Andy

On Mon, Jun 27, 2011 at 11:01 AM, Riku <subs at collab.se> wrote:

> Hi Andy,
>
> A quick look into this again gives me the impression that two separate
> concepts were mixed here: 1) The requested number of colors (that the users
> wants), and 2) the capability that was before hard-coded to 1024. I changed
> my code to always set the numberOfColors variable to the texture size
> capacity, as that seemed to closer reflect the logic from before. That "fix"
> works out nicely as well.
>
> The lookup table seems to work nicely even if that numberOfColors inside
> that function is set to the texture size, which in my case is 4096, and thus
> larger than the prior 1024. I fail to understand the details of the
> function, but whatever magic is at work here, it works better like this...
>
> I am still a bit confused about what causes the different results between
> different usage modes (software rendering/offscreen and not), but I'm
> guessing it has to do with which class is used by the graphics factory?
>
> Thanks for looking into this (although I solved it for myself already)!
>
> Kind regards,
>
> Riku
>
>
>
>
> On 22 June 2011 20:57, Andy Bauer <andy.bauer at kitware.com> wrote:
>
>> Hi Riku,
>>
>> I'm looking into fixing this.  I'm able to replicate this behavior on my
>> machine using mesa and the problem arises from having the textures be a
>> power of 2.  So in your case with mesa the 10 texture colors are getting
>> forced to 16 colors.  Unfortunately I'm not sure of the proper fix for this
>> yet though.
>>
>> Andy
>>
>>
>> On Wed, Jun 22, 2011 at 10:23 AM, Riku <subs at collab.se> wrote:
>>
>>> 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/20110627/af623a63/attachment.htm>


More information about the vtkusers mailing list