Proposed fix for vtkOpenGLTexture

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed fix for vtkOpenGLTexture

drjustice

Hello. I sent a recent email stating I needed to pass arbitrary data to a shader, encoded in a texture of float format.


Unfortunately, my shader only received texels with values clamped between 0-1.  As you can imagine, this is a problem. 


I have traced the problem down to vtkOpenGLTexture::Load() function.


What Load() does is : 

- Checks number of inputs. If 1, normal texture. If 6, cubemap texture.  (OK)

- Gets the image scalars (aka pixels) and number of components (aka: channels)   (OK)


- Calls MapScalarsToColor if not depth map, or if colormpde is Map_Scalars, or if datatype is NOT unsigned char.  (UGH!)


- Resizes the input of the source exceeds GL's internal dimension capacity. (OK)

- Resamples the image if needed. (OK)


- Creates a 1-channel floating point depth image, if it's a depth texture, by calling CreateDepthFromRaw(). (OK)

  (or, if not a depth map)

- Creates a 3 or 4-channel cube map, or normal texturemap, by specifying the new converted data type of VTK_UNSIGNED_CHAR.  



There is actually very little to do to support arbitrary float data: Simply avoid remapping to unsigned char if the data is float (unless there's intentional remapping by using such ColorMode), and pass the actual format down to CreateXXXFromRaw()



My proposed change is to not convert incoming float data to unsigned char, but rather, to leave float color data alone.


Edit:


Change this (eg: remove red line)


        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS ||
           inscalars->GetDataType() != VTK_UNSIGNED_CHAR ))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }

to this:

        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }


and these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, vtmp);

          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, resultData[0]);


to these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, dataType, vtmp);


          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, dataType, resultData[0]);



And that's all there is to it.

Does anyone have any objection?  The only side effect I can imagine is that more texture memory is consumed iff the source image data is float and no remapping is desired. With recent GPU hardware, I'd be surprised if this was a problem. 

In any case, with this change, we can effectively pass unclamped arbitrary floating-point data buffers to shaders to be used for advanced viz techniques.

Thanks
Patrick Bergeron






_______________________________________________
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:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Proposed fix for vtkOpenGLTexture

VTK - Dev mailing list
You can do this in VTK as is using vtkTextureObject->Create2DFromRaw and then vtkTexture->SetTextureObject.

But I don't have an issue with your suggested change provided it passes testing.



On Tue, Feb 19, 2019 at 11:48 AM Patrick Bergeron <[hidden email]> wrote:

Hello. I sent a recent email stating I needed to pass arbitrary data to a shader, encoded in a texture of float format.


Unfortunately, my shader only received texels with values clamped between 0-1.  As you can imagine, this is a problem. 


I have traced the problem down to vtkOpenGLTexture::Load() function.


What Load() does is : 

- Checks number of inputs. If 1, normal texture. If 6, cubemap texture.  (OK)

- Gets the image scalars (aka pixels) and number of components (aka: channels)   (OK)


- Calls MapScalarsToColor if not depth map, or if colormpde is Map_Scalars, or if datatype is NOT unsigned char.  (UGH!)


- Resizes the input of the source exceeds GL's internal dimension capacity. (OK)

- Resamples the image if needed. (OK)


- Creates a 1-channel floating point depth image, if it's a depth texture, by calling CreateDepthFromRaw(). (OK)

  (or, if not a depth map)

- Creates a 3 or 4-channel cube map, or normal texturemap, by specifying the new converted data type of VTK_UNSIGNED_CHAR.  



There is actually very little to do to support arbitrary float data: Simply avoid remapping to unsigned char if the data is float (unless there's intentional remapping by using such ColorMode), and pass the actual format down to CreateXXXFromRaw()



My proposed change is to not convert incoming float data to unsigned char, but rather, to leave float color data alone.


Edit:


Change this (eg: remove red line)


        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS ||
           inscalars->GetDataType() != VTK_UNSIGNED_CHAR ))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }

to this:

        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }


and these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, vtmp);

          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, resultData[0]);


to these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, dataType, vtmp);


          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, dataType, resultData[0]);



And that's all there is to it.

Does anyone have any objection?  The only side effect I can imagine is that more texture memory is consumed iff the source image data is float and no remapping is desired. With recent GPU hardware, I'd be surprised if this was a problem. 

In any case, with this change, we can effectively pass unclamped arbitrary floating-point data buffers to shaders to be used for advanced viz techniques.

Thanks
Patrick Bergeron





_______________________________________________
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:
https://vtk.org/mailman/listinfo/vtk-developers



--
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.

_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Proposed fix for vtkOpenGLTexture

drjustice

Interesting for the workaround. Thanks!


I'm soooooo not set-up for running the test suites. Any volunteer?




From: Ken Martin <[hidden email]>
Sent: February 19, 2019 11:59:26 AM
To: Patrick Bergeron
Cc: [hidden email]
Subject: Re: [vtk-developers] Proposed fix for vtkOpenGLTexture
 
You can do this in VTK as is using vtkTextureObject->Create2DFromRaw and then vtkTexture->SetTextureObject.

But I don't have an issue with your suggested change provided it passes testing.



On Tue, Feb 19, 2019 at 11:48 AM Patrick Bergeron <[hidden email]> wrote:

Hello. I sent a recent email stating I needed to pass arbitrary data to a shader, encoded in a texture of float format.


Unfortunately, my shader only received texels with values clamped between 0-1.  As you can imagine, this is a problem. 


I have traced the problem down to vtkOpenGLTexture::Load() function.


What Load() does is : 

- Checks number of inputs. If 1, normal texture. If 6, cubemap texture.  (OK)

- Gets the image scalars (aka pixels) and number of components (aka: channels)   (OK)


- Calls MapScalarsToColor if not depth map, or if colormpde is Map_Scalars, or if datatype is NOT unsigned char.  (UGH!)


- Resizes the input of the source exceeds GL's internal dimension capacity. (OK)

- Resamples the image if needed. (OK)


- Creates a 1-channel floating point depth image, if it's a depth texture, by calling CreateDepthFromRaw(). (OK)

  (or, if not a depth map)

- Creates a 3 or 4-channel cube map, or normal texturemap, by specifying the new converted data type of VTK_UNSIGNED_CHAR.  



There is actually very little to do to support arbitrary float data: Simply avoid remapping to unsigned char if the data is float (unless there's intentional remapping by using such ColorMode), and pass the actual format down to CreateXXXFromRaw()



My proposed change is to not convert incoming float data to unsigned char, but rather, to leave float color data alone.


Edit:


Change this (eg: remove red line)


        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS ||
           inscalars->GetDataType() != VTK_UNSIGNED_CHAR ))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }

to this:

        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }


and these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, vtmp);

          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, resultData[0]);


to these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, dataType, vtmp);


          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, dataType, resultData[0]);



And that's all there is to it.

Does anyone have any objection?  The only side effect I can imagine is that more texture memory is consumed iff the source image data is float and no remapping is desired. With recent GPU hardware, I'd be surprised if this was a problem. 

In any case, with this change, we can effectively pass unclamped arbitrary floating-point data buffers to shaders to be used for advanced viz techniques.

Thanks
Patrick Bergeron





_______________________________________________
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:
https://vtk.org/mailman/listinfo/vtk-developers



--
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.

_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
https://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: Proposed fix for vtkOpenGLTexture

VTK - Dev mailing list
If you submit it as a pull-request, then you can add a comment with the single line:

Do: test

and the bot will run tests for you.

On Tue, Feb 19, 2019 at 1:45 PM Patrick Bergeron <[hidden email]> wrote:

Interesting for the workaround. Thanks!


I'm soooooo not set-up for running the test suites. Any volunteer?




From: Ken Martin <[hidden email]>
Sent: February 19, 2019 11:59:26 AM
To: Patrick Bergeron
Cc: [hidden email]
Subject: Re: [vtk-developers] Proposed fix for vtkOpenGLTexture
 
You can do this in VTK as is using vtkTextureObject->Create2DFromRaw and then vtkTexture->SetTextureObject.

But I don't have an issue with your suggested change provided it passes testing.



On Tue, Feb 19, 2019 at 11:48 AM Patrick Bergeron <[hidden email]> wrote:

Hello. I sent a recent email stating I needed to pass arbitrary data to a shader, encoded in a texture of float format.


Unfortunately, my shader only received texels with values clamped between 0-1.  As you can imagine, this is a problem. 


I have traced the problem down to vtkOpenGLTexture::Load() function.


What Load() does is : 

- Checks number of inputs. If 1, normal texture. If 6, cubemap texture.  (OK)

- Gets the image scalars (aka pixels) and number of components (aka: channels)   (OK)


- Calls MapScalarsToColor if not depth map, or if colormpde is Map_Scalars, or if datatype is NOT unsigned char.  (UGH!)


- Resizes the input of the source exceeds GL's internal dimension capacity. (OK)

- Resamples the image if needed. (OK)


- Creates a 1-channel floating point depth image, if it's a depth texture, by calling CreateDepthFromRaw(). (OK)

  (or, if not a depth map)

- Creates a 3 or 4-channel cube map, or normal texturemap, by specifying the new converted data type of VTK_UNSIGNED_CHAR.  



There is actually very little to do to support arbitrary float data: Simply avoid remapping to unsigned char if the data is float (unless there's intentional remapping by using such ColorMode), and pass the actual format down to CreateXXXFromRaw()



My proposed change is to not convert incoming float data to unsigned char, but rather, to leave float color data alone.


Edit:


Change this (eg: remove red line)


        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS ||
           inscalars->GetDataType() != VTK_UNSIGNED_CHAR ))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }

to this:

        if (this->IsDepthTexture != 1 &&
          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS))
        {
          dataPtr[i] = this->MapScalarsToColors (inscalars);
          bytesPerPixel = 4;
        }


and these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, vtmp);

          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, resultData[0]);


to these:

          this->TextureObject->CreateCubeFromRaw(
            xsize, ysize, bytesPerPixel, dataType, vtmp);


          this->TextureObject->Create2DFromRaw(
            xsize, ysize, bytesPerPixel, dataType, resultData[0]);



And that's all there is to it.

Does anyone have any objection?  The only side effect I can imagine is that more texture memory is consumed iff the source image data is float and no remapping is desired. With recent GPU hardware, I'd be surprised if this was a problem. 

In any case, with this change, we can effectively pass unclamped arbitrary floating-point data buffers to shaders to be used for advanced viz techniques.

Thanks
Patrick Bergeron





_______________________________________________
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:
https://vtk.org/mailman/listinfo/vtk-developers



--
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.
_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
https://vtk.org/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:
https://vtk.org/mailman/listinfo/vtk-developers