Inconsistency with returned ScalarType in vtkPointData (from vtk 9.0.3 onwards)?

Hello everyone,

Does anyone know if by chance something changed in vtkPointData with respect to retrieving its scalars. I’m not quite sure of what I’m observing in my application and would like to get to the bottom of it, I’m currently reading PLY files using vtkPLYReader and at first I noticed that there could be some PLY files (ie: like mine) that have the colours saved in the Cell-Data whereas others could be saved in Point-Data (in either RGBA or RGB) depending on how the PLY file was exported (at least as far as I understand).

Now, since my application is setup in a way that we only process points during rendering (and not faces), my approach was to use vtkCellDataToPointData to first convert the cell-datas colour information to point-data colour format. This seems to work as I can visually test this in my application.

The issue arises when I’m running unit-tests at my end to test the scalars I’m actually getting back from the PLY read and converted by the vtkCellDataToPointData and there I noticed that when I call GetScalars(...)->GetDataType() prior to vtk9.0.3 the results return VTK_UNSIGNED_CHAR whereas from vtk 9.0.3 onwards it returns VTK_FLOAT for the same test PLY file(s) I have.

I had a look at VTK/Documentation/release and nothing jumps at me that may have caused it. Does anyone have any idea what could have happened? it’s a bit daunting to search git log for all possible changes in ie: vtkDataAttributes, vtkPointData, vtkCellData and vtkCellDataToPointData if I don’t know exactly where the change occurred if any at all.

Thanks in advance

Okay, I was able to investigate a bit further on why this issue is occurring. I noticed that for example with v9.0.2 the PLY files of concern I’m testing were returning the ScalarType as VTK_UNSIGNED_CHAR and as I previously mentioned vtk_master returns VTK_FLOAT
On bisecting this two (v9.0.2 and master) it revealed there was a change to vtkCellDataToPointData see hash: d24724da089debda086fb2210ed831692bde915c that now causes the change in scalar type to occur. @will.schroeder by any chance do you know why this is the case? Is the change deliberate?

I suspect the data is being type-promoted while setting up the threading process. I don’t remember, did you send some sample data? It would be helpful…

Hello Will,
Would you like me to provide the ply files? I didn’t send any sample data (if you mean the files).