Local settings storage for Depth Quality Tool?

[StevenSpringlab]

Due to a bug (reported: https://github.com/IntelRealSense/librealsense/issues/3645) that caused corrupted settings, I am unable to use the Depth Quality Tool and I haven't found where the tool stores its persistent data.

Therefore I would like to know where I can find this, so I can manually clear it.

Edit - Additional information:

The tool itself runs, but I can no longer edit the emitter value, which got stuck as disabled.

Example of the error in the DQT 2.19.0

[MartyG]

Have you tried resetting the Depth Quality Tool in its settings window, please?

STEP ONE

Left-click on the gear-wheel icon in the top corner of the tool's window and select the Settings menu option.

STEP TWO

Select the General category of the Settings window and left-click on the Restore Defaults button

STEP THREE

Click the Apply button.

[StevenSpringlab]

Wasn't sure if I should repeat what I filled into the bug report that I linked, but yes I tried that.

Figured that it didn't pertain to this question of finding the local storage and the details were in the linked ticket.

Clarified that the ticket is mine and about this setting.

The corrupted setting is the emittor checkbox, now also displayed as a slider with value 0.

This same error occurs with the Depth Quality Tool version 2.16.1 as well as 2.19.0.

For completeness, steps I took were:

• Rebooting the computer
• Changing the slider value 1, both via sliding and via the text input
• Trying to reset the values to default, via the Presets or via Options - Settings - General, then Restore Defaults

Neither actually changes the emitter value even without the corrupted settings (on another computer).

[MartyG]

Apologies, I missed that information in your link about having tried a reset to default already.

It looks as though the SDK tools are sharing the menu settings, implying that they are being read from the same source. Enabling or disabling the emitter tick-box in the Depth Quality Tool sets the emitter to that value at start-up in the RealSense Viewer., and vice versa.

I see too that changing the Preset didn't help. It seems to me as though the corruption might be in the Imgui code that defines the menu layout, rather than the value of the setting.

You could try completely uninstalling all occurrences of the SDK. If you type 'remove programs' into the text box at the bottom of your Windows screen (next to the button where you shut down the PC), you will find the 'Add and Remove Programs' tool.

Run that and uninstall any versions of 'Intel RealSense SDK 2.0' that are in the list. It asks you if you want to uninstall the SDK and all of its components. Doing so may leave the shortcut icons for the Viewer and the Depth Quality Tool on your desktop but they no longer work, as the program location they linked to have been removed.

Then do a clean download and install of the SDK from the Releases web-page. Try the Depth Quality Tool again and see if the menu is now fixed.

[StevenSpringlab]

There isn't an entry for the Realsense SDK under the installed programs, since I've built it from the git repo.

I've also checked in the AppData folders, but there are only some Intel folders with a few hidden files that all seem unrelated to Realsense. No folders exist of Realsense itself.

I also just now noticed I had missed a file in AppData/Roaming, called `realsense-config.json`, however looking inside this appears to be the default preset.

It doesn't contain any information on the emitter and removing it didn't help either.

As for the generated imgui.ini file next to the DepthQualityTool, I had tried removing this, but this didn't help.

[MartyG]

Other than wiping the computer and doing a completely fresh install of it, I do not know what else to suggest, unfortunately. Hopefully the message that you also posted on the GitHub will get a response that helps you.

[StevenSpringlab]

Yes, either that or maybe someone from Intel might be able to show where the data is stored.

Thanks in any case

[Alexandra_C_Intel]

Hi StevenSpringlab, Thank you for your interest in the Intel RealSense D435 camera. Can you please try restoring the calibration tables to factory defaults? Download and install the Calibration Tool (CalibrationTools-2.x.x.x-setup.exe) from: https://downloadcenter.intel.com/download/27415/?v=t Run Intel.Realsense.CustomRW.exe -g to recover the calibration table Let me know if this solves your issue. Regards, Alexandra

[StevenSpringlab]

Hi Alexandra,

Thank you for your reply.

Unfortunately this didn't help, though the Calibration Tool indicated it reset successfully.

I downloaded and installed the most recent version, 2.6.8.0 and used the command prompt both with and without admin rights.

In both cases it successfully reset:

For completeness, I also added a screenshot of the error occurring to the initial post.

[Eliza_D_Intel]

Hello StevenSpringlab, Could you please test the Emitter Enabled checkbox in RealSense Viewer to determine if the problem is with the camera or just the Depth Quality Tool software? Also, you should download and install the SDK binary from https://github.com/IntelRealSense/librealsense/releases/download/v2.20.0/Intel.RealSense.SDK.exe After installing the binary, run the Depth Quality Tool and RealSense Viewer from C:\Program Files (x86)\Intel RealSense SDK 2.0\tools. Thank you and best regards, Eliza

[StevenSpringlab]

I have verified that the emitter in the RealSense Viewer shows the same error and the same UI interface (slider instead of checkbox).

For clarity, I'll update the error report on github to mention this was tried.

Between various attemps (using the Depth Quality Tool as well) only the "Last Error: <...>" seems to vary to some degree.

So far I hadn't yet kept track of variations, due to the nature of the setup. Should this be of use to track the origin of the bug, please let me know.

The setup with the corrupted setting is a ceiling mounted computer with beamer that projects on the ground, which isn't easy to read fine print on.

I'll later look into installing the SDK on the computer, since for now the more practical workaround for testing is swapping to another physical device.

Furthermore to avoid mixing currently used SDK versions, I would do this with the 2.16.1 version of the SDK.

I've only run the DQT 2.19.1 to see if this made any difference and would like to avoid introducing new variables that may affect more than the DQT.

Could you explain whether installing the SDK is the desired approach for a certain reason, or just something to try in case it might help?

If it's possible to provide the location where the camera settings such as the UI / emitter value are stored, clearing these manually, even if it's in the registry, is preferable.

I've not looked into this yet, since I have no clue if this is where the settings might be stored and it is not a significant enough issue.

Considering the slider value shows 0, I should note that I expect the problem (as MartyG mentioned) to be with the UI layout, but it may not be limited to that.

In any case, deleting the generated imgui file didn't work.

[JesusG_Intel · Accepted solution]

Hello StevenSpringlab, The default config file shared by the RealSense tools is stored at c:\users\<username>\AppData\Roaming\realsense-config.json. You can also export and import your own custom configs to any location using the "Export" and "Import" buttons in the Settings dialog as Marty showed above. However, the json config file does not have an entry for the Emitter setting. The "emitter enabled" setting is stored in the camera's storage, not in the json file. Unfortunately, if a FW upgrade doesn't work and resetting the calibration tables don't work either then your camera may be faulty. The best way to verify this is trying a different camera on your system and see if it works. The reason we asked you to run the tools from the binary installation of the SDK is to ensure you are using a known good copy. Regards, Jesus

[StevenSpringlab]

Thank you for your reply.

Updating the firmware fixed the problem.

I had not expected this value to stored on the camera, since it appeared in earlier testing that turning off the emitter only did so for the tools, not when using the camera via the SDK.

Though in hindsight, updating the firmware should've been a step to try sooner.