Inquiry regarding the discrepancy in ToF Depth calculation (Eq. 1 from F-TöRF) between Real and Synthetic datasets

[roslein]

Hello,

I am currently conducting research to validate and extend the performance of G-TöRF. As part of our efforts, we have been closely analyzing the F-TöRF framework to generate a customized dataset for our study.

While experimenting with your provided dataset, we encountered a discrepancy regarding Equation 1 that we hope you could clarify.

[Problems]

When we apply Equation 1 from your paper ($d_{ToF} = \frac{c}{4\pi f} \psi$) to calculate depth from the raw quartet frames ($L_0, L_{\pi/2}, L_\pi, L_{3\pi/2}$):

1. Real Datasets (e.g., Baseball, Pillow): The calculated depth values align perfectly with the "ToF Depth" provided in your results.

2. Synthetic Datasets (e.g., Arcing Cube, Axial Speed Test): The depth calculated using Eq. 1(former one) does not match the provided depth maps(the last one).
   And the latter one doesn't make sense in itself because the foreground object and the background appear with almost the same color (value) in our calculated result, failing to show any depth separation despite their physical distance difference. (Note: While the boundaries created by motion artifacts appear as expected, the static regions lack the necessary depth contrast.)

[Question]

1. Could you provide a reasonable answer for the discrepancy?

2. And also, as I said above, we are currently trying to create our own custom dynamic synthetic scenes (following the F-TöRF format). So, if you don't mind, could you provide any scripts or tips used to generate the raw quartet captures? I already read the F-TöRF paper regarding how you made the F-TöRF dataset, but we want to ensure our custom data generation pipeline is consistent with your methodology to avoid any technical errors.

Thank you for your time and for sharing your work.

[roslein]

I just noticed in Issue #1, which already dealt with this problem.

According to the paper, Equation 1 assumes the basis function order is $[\sin, \cos, -\sin, -\cos]$ (corresponding to $L_0, L_{\pi/2}, L_\pi, L_{3\pi/2}$). However, I found that the synthetic dataset follows a different order: $[\cos, -\cos, \sin, -\sin]$. (Real ($[-cos, sin, cos, -sin]$)

It seems that this order discrepancy is the reason why my calculation fails on synthetic data. When I apply Eq. 1 directly to the synthetic indexes $(0, 1, 2, 3)$, the numerator $(L_0 - L_\pi)$ becomes $(\cos - \sin)$, and the denominator $(L_{\pi/2} - L_{3\pi/2})$ becomes $(-\cos + \sin)$, which leads to a constant value and the flat depth map shown in my observation.

As I suspected, the issue was indeed the basis function order. While Equation 1 in the paper assumes an order of $[\sin, \cos, -\sin, -\cos]$, the synthetic dataset is stored in the order of $[\cos, -\cos, \sin, -\sin]$.

By rearranging the indices to match the synthetic data's order (specifically using index 2 and 3 for the numerator and index 0 and 1 for the denominator in the arctan2 function), I was able to achieve a perfect match with your provided depth maps (MAE: $\approx 10^{-15}$). I’ve attached a comparison figure below to share this finding with other researchers who might face similar confusion.

Now that the depth calculation is clear, I would like to focus on our primary goal: creating a custom dynamic synthetic dataset following your F-TöRF format. I have two questions regarding the technical details.

1. Discrepancy in Data Types (float64 vs. float32)

My analysis shows that synthetic scenes, such as arcing_cube and occlusion, are stored as float64, while real-world scenes, like baseball and pillo,w are stored as float32. Since most hardware ToF sensors typically output uint12 raw data, could you clarify the reason for using high-precision float64 for synthetic scenes? I am uncertain which data type would be more appropriate for a customized synthetic dataset.

2. Confusion regarding DC Offset and Value Ranges

The supplementary material (Page 19) states that a fixed DC offset of C = 0.5 is used for synthetic scenes. However, my inspection shows that synthetic scenes have strictly positive values with very small ranges; for instance, arcing_cube ranges from 0.0006 to 0.0102. These values do not seem to center around the 0.5 offset as described. In contrast, real-world scenes frequently contain negative values, with pillow reaching as low as -1.5501.

This is confusing because if a DC offset of 0.5 is added to a zero-centered sine wave, the values should ideally be positive and centered around 0.5. Could you explain at what stage and how the DC offset was applied? Furthermore, why do the real datasets contain negative values while the synthetic ones remain strictly positive?

Understanding these preprocessing and normalization details is vital for ensuring our custom dataset's distribution matches the F-TöRF framework.

Thank you for your time and for sharing your work.

[ranrandy]

Hi,

Thanks for your interest in our project.

Quads Order. Yes, you are right. To map from the quads order in each dataset to [cos, -cos, sin, -sin], which is how we implemented the renderer, each real scene uses the tof_permutation.npy file. Each synthetic scene instead uses [0, 1, 2, 3] by default.

Synthetic Data Generation. As far as I understand and know:

• We created the scene with animation in Blender and used the btop add-on to specify PBRT materials and generate PBRT-ready render files.
• We used our customized PBRT implementation to render quad images. The important point is that if the original PBRT radiance/intensity of a point is I, then in our implementation it becomes I * w, where w is determined by the path length and quad type. For example, I * cos(d * 2π / dr) would be the 0th quad's intensity, where d is the path length, dr is twice the unambiguous depth range (2 * c / f), c is the speed of light, and f is the camera modulation frequency.
• We then preprocess the images to fit our code (e.g., normalization, etc.).

Data Types. The precision of the rendered images from PBRT is float32, but I found that the line in our data preprocessing code that rescales the intensity values by max(amp) causes the ultimately saved type to be float64, although the actual precision should still be float32. In fact, as far as I know, our camera dumps signed integer values from -1024 to 1023. The reason why real scene measurements were stored as float32 is also likely due to data preprocessing. Since our paper did not focus on depth precision or related numerical issues, this did not matter much for our experiments.

Value Ranges. Our sequences (e.g., arcing cube) are normalized to [0, 1] across the entire sequence of frames. If you inspect all frames—especially the later ones where the cube gets closer to the camera and becomes much brighter due to reduced light attenuation—the value range should be close to [0, 1]. Our synthetic PBRT-based pipeline was not able to produce images with negative values, so unfortunately we used a DC offset to make everything positive.

DC Offset. Suppose the emitted light is modulated as 0.5 * cos(t) + 0.5 over time. This would make the weight w mentioned above become, for example, 0.5 * cos(d * 2π / dr) + 0.5. If you average the four quads, you can obtain an image that is lit only by a constant DC component without modulation. The mean of this image may not be 0.5. It depends on the specified scene materials.

Please let us know if you need any further clarification. Happy to meet as well if that helps.

Best,
Runfeng

[roslein]

Hi Runfeng,

Thank you so much for your detailed response earlier. It was incredibly helpful.
I’ve been working with the dataset based on your advice, but I encountered a few more things I’d like to clarify.

Could you please help me with the following questions?

1. Phase Sequence Order
   You mentioned that the renderer uses [cos, -cos, sin, -sin] sequence. I am curious why you chose this specific order instead of the standard [0, pi/2, pi, 3pi/2] phase shifts (which usually correspond to sin, cos, -sin, -cos or cos,-sin,-cos, sin). Is there a specific reason or advantage to this sequence?

2. ROI Masks
   I noticed that union_dynamic_ROI_mask seems to be mandatory for all synthetic datasets. However, some datasets also include optional masks like dilated_ROI_mask and dynamic_ROI_mask.
   Could you explain the difference between them and how these optional masks are utilized during training?

3. Unexpectedly Long Training Time
   The paper mentions that training takes around 40 minutes. However, for my custom dataset, it is taking significantly longer—almost 6 hours to reach 50,000 iterations out of 60000, which was used for your dataset. For the first 30000 iterations of training, it was quite fast, but it got really slow.
   Below is a snippet from my training log (tqdm output) showing the slow progress (~1.48 it/s). Do you have any idea what might be causing this slowdown? (Note: I am running your code with the A100 GPU runtime option in Colab.)

[Attached Log from my Notebook]

Training progress:  85%|████████▍ | 50770/60000 [6:02:28<1:48:12,  1.42it/s, Loss=0.7244306]
Training progress:  85%|████████▍ | 50780/60000 [6:02:28<1:46:22,  1.44it/s, Loss=0.7244306]
Training progress:  85%|████████▍ | 50780/60000 [6:02:34<1:46:22,  1.44it/s, Loss=0.8804859]
Training progress:  85%|████████▍ | 50790/60000 [6:02:34<1:43:23,  1.48it/s, Loss=0.8804859]
Training progress:  85%|████████▍ | 50790/60000 [6:02:43<1:43:23,  1.48it/s, Loss=0.7297633]

4. Confirmation on Custom Synthetic Data Normalization (Important)
   I performed normalization on my custom synthetic dataset based on your advice and paper: "Calculate amplitude for the whole sequence, find the Global Maximum Amplitude, and divide all frames by it."

Unlike real-world data (which ranges from -1024 to 1023), my synthetic data is based on photon counts, so it naturally starts from 0. Therefore, I did not apply any DC offset subtraction (keeping the dc_offset parameter as 0.0) and only performed the scaling using the code below.

My Pre-processing Code:

import os
import numpy as np
import glob
from tqdm import tqdm

dataset_root = '/content/gftorf/data/ftorf_synthetic_scenes/custom_dataset'
folders = ['tofType0', 'tofType1', 'tofType2', 'tofType3']

def find_global_max_amplitude():
    print("Calculating Global Max Amplitude across the sequence...")
    type0_files = sorted(glob.glob(os.path.join(dataset_root, 'tofType0', '*.npy')))

    if not type0_files:
        return None

    global_max_amp = 0.0

    for f0_path in tqdm(type0_files, desc="Scanning Amplitudes"):
        idx = int(os.path.splitext(os.path.basename(f0_path))[0])

        try:
            l0 = np.load(os.path.join(dataset_root, 'tofType0', f"{idx:04d}.npy"))
            l1 = np.load(os.path.join(dataset_root, 'tofType1', f"{idx+1:04d}.npy"))
            l2 = np.load(os.path.join(dataset_root, 'tofType2', f"{idx+2:04d}.npy"))
            l3 = np.load(os.path.join(dataset_root, 'tofType3', f"{idx+3:04d}.npy"))

            amp_map = 0.5 * np.sqrt((l0 - l1)**2 + (l2 - l3)**2)

            current_max = np.max(amp_map)
            if current_max > global_max_amp:
                global_max_amp = current_max

        except Exception:
            continue

    return global_max_amp

def apply_normalization(max_amp):
    if max_amp <= 0:
        return

    print(f"Normalizing all raw frames by factor: {max_amp}...")

    for folder in folders:
        dir_path = os.path.join(dataset_root, folder)
        files = sorted(glob.glob(os.path.join(dir_path, '*.npy')))

        for file_path in tqdm(files, desc=f"Processing {folder}"):
            data = np.load(file_path).astype(np.float32)
            norm_data = data / max_amp
            np.save(file_path, norm_data)

if __name__ == "__main__":
    max_val = find_global_max_amplitude()
    if max_val:
        apply_normalization(max_val)

Resulting Statistics:
After applying this code, my custom dataset stats are as follows:

Dataset Name              | Dtype      | Min        | Max        | Scale Factor
--------------------------------------------------------------------------------
jacks1 (Real)             | float32    | -3.4235    | 0.7726     | 2.5
baseball (Real)           | float32    | -0.4891    | 1.9639     | 1.0
...
custom_dataset (Mine)     | float32    | 0.0000     | 0.9407     | 1.0

The range [Min: 0.0, Max: ~0.94] looks correct for a synthetic dataset but I want to make sure whether it is ok.
Since the real datasets have negative values (due to AC component extraction), I want to confirm if it is safe to train with this **positive-only range [0, 1]** for synthetic data without additional offset adjustment.

5. Intermediate Result Issue (20k Iterations)
   Regarding the training time mentioned in Q3, I attempted a shorter training run of 20,000 iterations (scaling the densification schedule accordingly) to get a quick preview, as the full 60,000 iterations take too long.

However, the results were quite disappointing compared to the ground truth ToF depth derived from the raw data.

My Result (at 20k iterations):

Reference ToF Depth:

I am planning to run full 40k and 60k iterations as the next step. However, I am currently unsure if this poor quality is simply due to "under-fitting" (insufficient iterations) or if there is a fundamental error in my custom dataset preparation (e.g., normalization, mask, offset issues, the way of determining option values of run_optimize.py(like "--max_depth_fac" "--quad_scale"), or something else that was not mentioned in the paper). So apart from the normalization process mentioned (finding Global Max Amplitude and dividing by it), are there any other tips, specific processes, or subtle details for creating a synthetic F-ToRF dataset that are not explicitly mentioned in the paper or our previous discussions? I want to ensure I haven't missed any crucial steps.

Thank you again for your time and guidance.

[ranrandy]

Hi Kyungmin,

Sure.

1. I meant our GS renderer, and that was only to align our PBRT renderer, thus the synthetic quads. I'm not aware of any particular reason for this quads order in the PBRT renderer.
2. In fact, these masks are not mandatary and were not used in the G-ToRF project but in the F-ToRF project. And as far as I know they are only used to mask out the dynamic object from each frame for evaluation. As you can see from Table 1 in F-ToRF paper.
3. The training time is usually proportional to the number of Gaussians. Also, 3DGS optimization is based on heuristics and can be brittle. So, I guess something happened at the 30000th iteration. It might be because after densification at some point, the number of Gaussians reached certain GPU tolerance threshold. Or at some point the parameters in the motion model (MLP) exploded and the canonical set of Gaussians (if you are training a dynamic scene) doesn't make sense anymore, and thus the number of Gaussians also explodes. But anyway, I would check which line(s) / mechanism during optimization caused the number of Gaussians to explode, and anything unusual happened there, such as if the MLP exploded. Or you might have modified some optimization hyperparameters like densify_grad_threshold. But since the first 30000 iterations were fine, I guess that's less likely the reason. You can also try a few sanity checks like starting exactly from the run_optimize.py script and the original dataset, or optimize a static scene first. In addition,
   1. 40 minutes was an average across all the scenes. Depending on the complexity of quad images to reproduce, it can fluctuate between 20-70 minutes, though it never reached 6 hours.
4. I think I am missing some details on how you created your synthetic dataset. The DC offset does not necessarily depend on the range of the data. It depends on how you modulate your light source. For example, if the light source emitted intensity is a function of 0.5+0.5cos(t), then the DC offset would be 0.5. If the DC offset is zero, and your modulation function is like 0.5cos(t), then it probably has negative values.
5. Optimizing for 20000 iterations is usually good enough for debugging. As in 4, I guess you might need to set DC offset to some value that matches how you create your synthetic data. Otherwise, the model cannot work. If you have set parameters accurately, you should see decent results at 20000 iterations or even earlier. Other parameters also matters, too. For example, depth range should be twice the unambiguous depth range, or c/f, where c is the speed of light and f is the camera modulation frequency. Some other parameters such as densify_grad_threshold also needs to be a reasonable value so that the model doesn't produce either too many or too few Gaussians. But the default numbers should usually work fine, and I would check DC_offset and depth_range first.

[roslein]

Hi Runfeng,

Thank you for your previous detailed response. It was truly helpful.

Regarding the DC Offset, I've confirmed that using 0.5 is indeed correct for our dataset. Although our data is based on real-world static scenes with synthetic motion, our normalization process (dividing by Global Max Amplitude) makes the signal-to-DC ratio consistent with your PBRT-based [0.5 * cos(t) + 0.5] model.

I have now fully populated the dataset, including tofType0,1,2,3, cams, synthetic_tof (phasors), and a depth folder derived from raw correlation data for initialization. Since the paper mentions that RGB is optional, and I noticed that the pipeline can run without optical flow, I am currently setting lambda_color = 0(already set in config/ftorf.json) and lambda_flow = 0 in run_optimize.py and using dummy data for those folders to isolate and focus purely on the ToF reconstruction.

However, I am still encountering an extremely high initial loss and oscillating loss without converging.

To resolve this, I attempted to use init_method: pcd to leverage the depth maps for a better starting point. However, I found that:

1. PCD mode fails: It triggers an UnboundLocalError: local variable 'xyz_all' referenced before assignment in dataset_readers.py.
2. Official datasets too: This error occurs even when I try to run the official datasets provided in the repository with the pcd option.

I have a few follow-up questions regarding this:

1. Is pcd initialization fully implemented? The code seems to skip the xyz_all assignment if certain file naming or path conditions aren't met exactly. Is there a specific format or directory structure required for pcd mode to work?
2. How to stabilize the initial loss? Even with 100k random points, the loss starts at a massive scale. Would you recommend significantly decreasing the initial_opacity (e.g., to 0.01 or lower) or using a smaller num_points for custom synthetic scenes to prevent this divergence?
3. Supervision in synthetic_tof: For my custom data, I've stored the phasors (, ) in the synthetic_tof folder. Should these values be normalized in a specific range to match the model's loss function expectations?

I also have other problems regarding parameters in run_optimize.py:

1. Loss Stabilization & Lambda Selection
   I observed that changing lambda_tof from 5.0 (which was used for the baseball scene) to 1.0 resulted in a drastic decrease in initial loss (from ~1.8 down to ~0.3).

• Question: What is the general criteria for balancing lambda_tof? Should it be tuned based on the signal-to-noise ratio or the specific scale of the synthetic photon counts?

2. Max Depth Factor vs. Physical Range
   I’ve been analyzing the depth range logic in the code. I am using a 20MHz modulation frequency, which sets my depth_range to 15.0.

• I noticed that the maximum rendering distance is calculated as: depth_range * max_depth_fac.
• With the current setting of 0.45, the max depth is capped at 6.75m.
• Since the maximum physical distance in my scene is 7.5m (which is exactly for 20MHz), I would like to change max_depth_fac to 0.5.
• Question: Is it safe to set this to 0.5 (or slightly higher like 0.6) to ensure the entire scene is within the rendering frustum, or does this factor impact the stability of the Gaussian densification?
  • I had a ValueError at Iteration 3000, and I fixed this after setting zfar to 0.5. Was there any intention for the number 0.45?

Thank you!

[ranrandy]

Hi Kyungmin,

1. Regarding init_method, the second option other than random init is phase, not pcd, as you can see here:
   

   gftorf/scene/dataset_readers.py

   Line 904 in 803459b

   elif args.init_method == "phase":

   
   Let me know if this branch does not work. Init by phase is not strictly necessary, and I did not double-check whether this code still works.

2. The model should only use the synthetic_tof folder for evaluation, or possibly not use it at all. The only images that are required are the tofType0-3 images.

3. lambda_tof should not matter too much. It mainly makes the optimization faster.

4. depth_range = 15.0 is correct in your case. max_depth_fac = 0.45 should be enough because of this line:
   

   gftorf/scene/dataset_readers.py

   Line 867 in 803459b

   zfar = args.max_depth_fac * depth_range * 1.1

   
   0.45 * 1.1 = 0.495. Also, this is the z-depth, not the distance. The actual distance range would be larger depending on pixel locations, so it should be fine. Don’t worry too much about the line above — it is something I inherited from previous specifications. You can change it to 0.5 as well. However, since we are only handling single-frequency C-ToF data, the model can produce Gaussians at the next depth period, which would become ambiguous, because for example an infinitely small Gaussian at 0.5m or 8.0m away would contribute similarly, ignoring opacity and reflectivity. It might still work if this value is not too large, and this should not impact stability too much. What ValueError did you get?

From my experience, if the model is drastically not working (like what you showed above), it is usually a DC offset, depth range, or related issue like quads order. If possible, it might be easier if I can take a closer look at your data. Four quads would be enough. I can try it in my free time this week. You can email me if you are not comfortable sharing publicly. In the meantime, I would recommend finding a set of parameters (e.g., from run_optimize.py) and a set of quads (e.g., from our data) that works, and then slowly moving toward your new data and settings by debugging line by line. Another thing you can try is subtracting the ambient + DC component from your data to get a version whose value range spans from -1 to 1 (depending on quad types), similar to our real-world case, and then setting DC_offset = 0.0. Alternatively, it might be an image dimension issue, since I see your resolution is 480×640 while our data is 240×320.

Best,
Runfeng

[roslein]

Hi Runfeng,
Thank you again for your previous detailed response — it was very helpful.

Following your advice, I adjusted several parameters and obtained noticeably better results compared to the very noisy output I had before.

Result video:

iteration_20000_video_panel.mp4

---

As I previously explained, I modified the dc offset,lambda_tof, and zfar, and added a depth folder.I believe my earlier poor results were largely due to the missing depth folder, which seems to be used as an initialization. After adding it, the reconstruction quality clearly improved. However, the results are still not satisfactory. It seems that some Gaussian splats are incorrectly placed and end up occluding the true object, hiding the correct geometry behind them. This makes the reconstruction look “blocked” or over-smoothed in certain regions.

Questions:

1. Are there recommended hyperparameters or refinement strategies to mitigate this issue? During the validation process at the iteration of 15000, PSNR also decreases from 44.69697660605112 in the beginning to 36.723173491160075 at the end, while PSNR_p increases from 7.609906284014384 to 11.160832834243774. Something is going wrong, surely, but I can't figure out why.

2. Is there a known way to encourage Gaussians to better respect object boundaries or avoid floating occluders? I read the paper and saw the two bias strategies which would help this problem, but didn't get how it plays in the code.

Any guidance on which parameters are most sensitive for this kind of artifact would be greatly appreciated.

---

I am also very interested in the Option A results that include outputs from other algorithms.
Currently, I can only find the depth images for gf-torf, located at: ours_30000/depth. However, I cannot find depth results for the other algorithms used for comparison.
(note: I uploaded my result here)

Questions:

1. Are depth maps for the other algorithms saved somewhere else that I might be missing?
2. Or is the comparison MP4 generated directly during evaluation, without saving each method’s depth images to disk?
3. If depth files do exist for other methods, could you point me to their expected directory structure?

---

Thank you very much for your time and for releasing this work.
Any clarification or suggestions would be extremely helpful.

Best regards,
Kyungmin kim

[ranrandy]

Hi Kyungmin,

It's good to see you have improved the results.

PSNR. This is computed between color images, which is not used in the optimization. So you should not rely on that number. PSNR_p means the PSNR on phasor images, which is the number you should pay attention to. Its increase from 7.60 to 11.16 means the model is optimizing raw images. But it optimized quite poorly, which aligns with your results.

Occluder. The occluding artifacts in the paper is different from what is in your results. In the paper, it means that the model can very easily fit the raw images, even with just 5k iterations, but the mean depth from Gaussians can be quite wrong. And the biases are used to handle this problem. However, the occluding artifacts in your result happens in the raw images (bottom right in your video), which on contrary are not easily fitted yet. In this case, I still suspect something might not be working compatibly with the model, such as the DC offset, quads order, or related things. One other thing I can think of right now is the dynamic range of the images. So in our pre-processing, we did the following to handle very bright pixels:

    # === Amplitude normalization ===
    _, _, amp = tof_integrate_np(data, perm=perm)
    amp_norm = amp / np.max(amp)
    amp_norm[amp_norm > 0.1] = 0.1
    amp_norm = amp_norm / np.max(amp_norm)
    data_wo_fpn_normed = data_wo_fpn * amp_norm[..., None] / (amp[..., None] + 1e-6)

You can try if this might affect the training, and in any way it can be related to problems handled by some HDR/RAW Gaussian splatting papers.

On the other hand, in general, to handle over-smoothed areas, you can try to decrease the densification gradient threshold.

Baselines. If you are talking about baseline results, they are already in the baseline subfolder in each scene folder you uploaded.

In addition, I still believe random initialization should work. And something might be off in your setting. Also, the depth init uses depth computed from tof images. I'm not sure why adding a depth folder helped in your case. But it's good to see you seems to be able to reproduce results on our scenes. Also, since your scene looks static and only the camera is moving, make sure you do not use the motion model as it is used for dynamic objects.

Best of luck,
Runfeng

[roslein]

Hi Runfeng,

Thank you very much for the detailed and helpful explanation — especially the normalization code. I'll try once again, considering your advice.

I found the baseline results provided as MP4 files. However, I’d like to inspect the differences in more detail, so I was wondering whether the underlying depth (or amplitude) maps produced by the baseline methods are available as actual data files (for example, .npy, similar to the Option B results under ours_20000/renders/depth).

I usually prefer to run things on my own, but as noted in the paper, some of the baseline methods take quite a long time to run from scratch. So I wanted to ask in case the depth or amplitude outputs were already saved. If so, would it be possible to share them or point me to their expected directory structure?

Access to the raw numerical depth/amplitude outputs (rather than only MP4 visualizations) would be extremely helpful for deeper analysis and debugging on my side.

I completely understand if these data are not available for release — I just wanted to ask in case they exist.

Thank you again very much for releasing this work and for your time.

Best regards,
Kyungmin Kim

[ranrandy]

Ah I see. Sorry I misunderstood Kyungmin.

We might have the raw data file from some methods. Let me check and get back to you soon.

FYI, you can actually get some ok rendered depths from training a static scene using ToRF within a few hours. It was usually for training dynamic scenes and for the best quality that they were trained for that long time as reported in the paper.

Best,
Runfeng