RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Bill Lorensen
Folks,

Interesting.

When an image is passed through vtkWindowToImageFilter, the size of
the output image is reduced by 1 in each dimension.

So if you SetSize on a render window,
renderWindow->SetSize(n, m), the saved size will be n-1, m-1.

This has to do with the setting in vtkWindowTiImageFilter:
#define BORDER_PIXEL 2

I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0,
the saved size matches the SetSize.

We can't change vtkWindowToImageFilter since it would break every
regression test.

I can fix the odd baseline issue by setting sizes in the failing tests
that take into account the logic in window to image filter.

Bill


On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen <[hidden email]> wrote:

> There are only 23 tests that have odd sizes and they are all python
> tests, oddly enough.
>
> I'll change them to have even sizes and I'll update the baselines. For
> those tests, I'll delete all baseline versions before I add the new
> one.
>
> Bill
>
>
> On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride <[hidden email]> wrote:
>> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said:
>>
>>>Ping?  Is anyone still working on this?
>>
>> I'm not.  I don't believe we agreed on a plan either.
>>
>> I've asked on the cocoa-dev list and am pretty sure we are stuck with NSWindow's behaviour, which is: round sizes *up* to even integral sizes.
>>
>> David's suggestion of changing the testing system so that it tolerates a 1-pixel difference in the size in the images I agree is probably best, in the short term at least.  Still, if we were starting from scratch, it seems to me that having test output and baselines of identical sizes would be preferable.  Perhaps as tests are maintained, they should be updated to not use odd sizes?
>>
>> I wonder too if we ought to add a log/warning to SetSize() implementations when users of the API provide odd sizes?
>>
>> Sean
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



--
Unpaid intern in BillsBasement at noware dot com
_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Utkarsh Ayachit
Bill,

I would be surprised if it has anything to do with BORDER_PIXEL. BORDER_PIXEL comes into play only when `FixBoundary` is ON, and it's OFF by default and tiling is used -- which is rarely, if at all used for VTK test baselines. It should be deprecated as it's no longer needed. It was needed in OpenGL1 days for certain OpenGL drivers where when rendering wireframe, the wireframe for a cell would get artificially closed if it intersected the viewport boundary. That doesn't happen with OpenGL2.

Utkarsh

On Wed, Jul 5, 2017 at 10:59 AM, Bill Lorensen <[hidden email]> wrote:
Folks,

Interesting.

When an image is passed through vtkWindowToImageFilter, the size of
the output image is reduced by 1 in each dimension.

So if you SetSize on a render window,
renderWindow->SetSize(n, m), the saved size will be n-1, m-1.

This has to do with the setting in vtkWindowTiImageFilter:
#define BORDER_PIXEL 2

I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0,
the saved size matches the SetSize.

We can't change vtkWindowToImageFilter since it would break every
regression test.

I can fix the odd baseline issue by setting sizes in the failing tests
that take into account the logic in window to image filter.

Bill


On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen <[hidden email]> wrote:
> There are only 23 tests that have odd sizes and they are all python
> tests, oddly enough.
>
> I'll change them to have even sizes and I'll update the baselines. For
> those tests, I'll delete all baseline versions before I add the new
> one.
>
> Bill
>
>
> On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride <[hidden email]> wrote:
>> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said:
>>
>>>Ping?  Is anyone still working on this?
>>
>> I'm not.  I don't believe we agreed on a plan either.
>>
>> I've asked on the cocoa-dev list and am pretty sure we are stuck with NSWindow's behaviour, which is: round sizes *up* to even integral sizes.
>>
>> David's suggestion of changing the testing system so that it tolerates a 1-pixel difference in the size in the images I agree is probably best, in the short term at least.  Still, if we were starting from scratch, it seems to me that having test output and baselines of identical sizes would be preferable.  Perhaps as tests are maintained, they should be updated to not use odd sizes?
>>
>> I wonder too if we ought to add a log/warning to SetSize() implementations when users of the API provide odd sizes?
>>
>> Sean
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



--
Unpaid intern in BillsBasement at noware dot com
_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers



_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Bill Lorensen
Utkarsh,

You can verify this by setting the size on an exiting test to some
value. Ypu will see the test image size is opff ob 1. If you rebuild
with BORDER_SIZE 0, the size will match what you set.

Unless I'm smoking something...


On Wed, Jul 5, 2017 at 11:08 AM, Utkarsh Ayachit
<[hidden email]> wrote:

> Bill,
>
> I would be surprised if it has anything to do with BORDER_PIXEL.
> BORDER_PIXEL comes into play only when `FixBoundary` is ON, and it's OFF by
> default and tiling is used -- which is rarely, if at all used for VTK test
> baselines. It should be deprecated as it's no longer needed. It was needed
> in OpenGL1 days for certain OpenGL drivers where when rendering wireframe,
> the wireframe for a cell would get artificially closed if it intersected the
> viewport boundary. That doesn't happen with OpenGL2.
>
> Utkarsh
>
> On Wed, Jul 5, 2017 at 10:59 AM, Bill Lorensen <[hidden email]>
> wrote:
>>
>> Folks,
>>
>> Interesting.
>>
>> When an image is passed through vtkWindowToImageFilter, the size of
>> the output image is reduced by 1 in each dimension.
>>
>> So if you SetSize on a render window,
>> renderWindow->SetSize(n, m), the saved size will be n-1, m-1.
>>
>> This has to do with the setting in vtkWindowTiImageFilter:
>> #define BORDER_PIXEL 2
>>
>> I'm not sure of the logic using BORDER_PIXEL, but if I define it as 0,
>> the saved size matches the SetSize.
>>
>> We can't change vtkWindowToImageFilter since it would break every
>> regression test.
>>
>> I can fix the odd baseline issue by setting sizes in the failing tests
>> that take into account the logic in window to image filter.
>>
>> Bill
>>
>>
>> On Mon, Jul 3, 2017 at 2:52 PM, Bill Lorensen <[hidden email]>
>> wrote:
>> > There are only 23 tests that have odd sizes and they are all python
>> > tests, oddly enough.
>> >
>> > I'll change them to have even sizes and I'll update the baselines. For
>> > those tests, I'll delete all baseline versions before I add the new
>> > one.
>> >
>> > Bill
>> >
>> >
>> > On Mon, Jul 3, 2017 at 12:54 PM, Sean McBride <[hidden email]>
>> > wrote:
>> >> On Fri, 30 Jun 2017 09:56:41 -0400, Shawn Waldon said:
>> >>
>> >>>Ping?  Is anyone still working on this?
>> >>
>> >> I'm not.  I don't believe we agreed on a plan either.
>> >>
>> >> I've asked on the cocoa-dev list and am pretty sure we are stuck with
>> >> NSWindow's behaviour, which is: round sizes *up* to even integral sizes.
>> >>
>> >> David's suggestion of changing the testing system so that it tolerates
>> >> a 1-pixel difference in the size in the images I agree is probably best, in
>> >> the short term at least.  Still, if we were starting from scratch, it seems
>> >> to me that having test output and baselines of identical sizes would be
>> >> preferable.  Perhaps as tests are maintained, they should be updated to not
>> >> use odd sizes?
>> >>
>> >> I wonder too if we ought to add a log/warning to SetSize()
>> >> implementations when users of the API provide odd sizes?
>> >>
>> >> Sean
>> >>
>> >>
>> >> _______________________________________________
>> >> Powered by www.kitware.com
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Search the list archives at:
>> >> http://markmail.org/search/?q=vtk-developers
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://public.kitware.com/mailman/listinfo/vtk-developers
>> >>
>> >
>> >
>> >
>> > --
>> > Unpaid intern in BillsBasement at noware dot com
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>



--
Unpaid intern in BillsBasement at noware dot com
_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Utkarsh Ayachit
Unless I'm smoking something...


I want what you have ;)! Attached is a modified test. It works with vtkpython no matter the value of  BORDER_SIZE. What am I missing? Also, I get exactly the size I request (300, 300) and not 1 pixel less.

Utkarsh

_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


test.py (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Bill Lorensen
Yes.That works for me.

But please try this:

Take an existing test, like:
Imaging/Core/Testing/Python/TestHSIToRGB.py
add
viewer.SetSize(320,320)

ctest -V -R TestHSVToRGB.py
you should see this error:
1989: Image differencing failed to produce an image because images are
different size:
1989: Valid image: 320, 320, 0
1989: Test image: 319, 319, 0


On Wed, Jul 5, 2017 at 11:48 AM, Utkarsh Ayachit
<[hidden email]> wrote:
>> Unless I'm smoking something...
>>
>
> I want what you have ;)! Attached is a modified test. It works with
> vtkpython no matter the value of  BORDER_SIZE. What am I missing? Also, I
> get exactly the size I request (300, 300) and not 1 pixel less.
>
> Utkarsh



--
Unpaid intern in BillsBasement at noware dot com
_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RenderWindow sizes for testing (was: is someone working on the bigmac failures?)

Bill Lorensen
I think I see the problem. The vtkTesting.cxx code is producing the
wrong output. It is reporting (extent[11] - extent[0]) as a size but
the size is really (extent[1] - extent[0] + 1).

I've submitted an MR:
https://gitlab.kitware.com/vtk/vtk/merge_requests/2998


On Wed, Jul 5, 2017 at 12:20 PM, Bill Lorensen <[hidden email]> wrote:

> Yes.That works for me.
>
> But please try this:
>
> Take an existing test, like:
> Imaging/Core/Testing/Python/TestHSIToRGB.py
> add
> viewer.SetSize(320,320)
>
> ctest -V -R TestHSVToRGB.py
> you should see this error:
> 1989: Image differencing failed to produce an image because images are
> different size:
> 1989: Valid image: 320, 320, 0
> 1989: Test image: 319, 319, 0
>
>
> On Wed, Jul 5, 2017 at 11:48 AM, Utkarsh Ayachit
> <[hidden email]> wrote:
>>> Unless I'm smoking something...
>>>
>>
>> I want what you have ;)! Attached is a modified test. It works with
>> vtkpython no matter the value of  BORDER_SIZE. What am I missing? Also, I
>> get exactly the size I request (300, 300) and not 1 pixel less.
>>
>> Utkarsh
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



--
Unpaid intern in BillsBasement at noware dot com
_______________________________________________
Powered by www.kitware.com

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

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Loading...