loading and stroring large transfer function (vp file)

Hello,

I’m working on a project to automatically create transfer functions (TF) and use Slicer as a reference and also to render the results. The approach is as follows,

  1. I generate a transfer function.
  2. I sample it and put the values in VP format.
  3. I load the VP file in Slicer and see the results.
    However, the problem is as I get more samples from the generated TF (say 50 or 100) slicer discards values at the end of the range.
    Is there a way to increase the Slicer’s threshold when dealing with vp files?

Thanks

Currently, line length in .vp files is (quite arbitrarily) limited to 1024 characters. This is certainly not nice and it should not be hard to change this (probably we could just use the C++ verison of getline that does not require preallocation of a buffer).

Transfer functions are expected to contain only a limited number of control points to make sure they are conveniently editable; and usually there is a limit in how many different structures can be distinguished by varying the colors. Could you tell a bit more about your use case? Where do these large number of control points come from? Are you considering using volume rendering for displaying labelmap volumes with many labels?

1 Like

In my experiment, I’m using machine learning to produce a customized transfer function (TF) for a given volume, mapping the scalar field to RGBA. The TF is continuous (regression) and can be a bit spiky in some cases. I sample the TF and store it in VP format. It would be amazing if I could feed this kinda big VP file to Slicer.

Yes, the .vp files are pretty ad hoc - at the time I recall that we looked around for some standard way to store them but couldn’t find anything so we came up with something simple. It would be great to remove the 1024 character limitation.

As a side note I’l mention that there is now a dicom standard for volume rendering. It covers a lot of territory in addition to transfer functions and I’ve never looked seriously at whether we could support this in Slicer (I’m not sure any other software supports it since it is so broad).

https://dicom.nema.org/medical/dicom/current/output/html/part03.html#sect_A.80