Mark I vs Mark II Differences with Dec 9th SDK and Firmware

The new Mark II SDK and Firmware has brought a lot of stability which is awesome! But, I’m noticing some issues in the quality of scans when comparing the Mark I vs Mark II. Below are 3 sets of images from various apps for the sensor where I did the same action with the Mark I followed by the Mark II. These differences are some of the last remaining issues I am seeing with the App I am working to upgrade to the Mark II support. Has anybody else seen these issues? I’m trying to narrow down if I have a hardware issue or something that I need to patch with a code fix.

Mark I using SDK Dec 9th Scanner App Demo

Mark II using SDK Dec 9th Scanner App Demo

As can be seen above, the Mark II in the demo app provided with the newest SDK is not picking up as many surfaces as the Mark I is using the same software.

Mark I using Expert Calibrator Depth Sensor View

Mark II using Expert Calibrator Depth Sensor View

The expert calibrator app is an app specifically sent by Occipital to use for IR sensor calibration and is not available on the store publicly. This app was mentioned in other forum posts and is what I originally thought was an issue but doesn’t seem to have fixed the root problem as hoped. The depth view clearly shows that the Mark II is not picking up as much as the Mark I.

Mark I using Calibrator App on AppStore (post calibration success)

Mark II using Calibrator App on AppStore (post calibration success)

After calibration, the Mark II still shows the issues from the previous images. I also noticed that the bounding box of where the depth data is coming in is smaller than in the Mark I. Not sure if that is a sign of another type of issue or not.

Is anybody else dealing with these issues? Any guidance on if there is a calibration I’m missing or some type of action that I have forgotten to take with the Mark II is greatly appreciated. All issues above combine to create an odd user experience in the App I’m trying to add Mark II support to since it is definitely handling data differently than the Mark I.

Thanks again in advance!

1 Like

I discovered the same issue in comparsion between Mark I and Mark II. Currently i have no image but i can confirm that we have the same behavior.

With a first feeling from the new SDK and Firmwareupdate for the Mark II there is more coverage for the Mark II than before but still less than the Mark I


The client I work with has a second Mark II in their office and they confirmed yesterday evening that they are getting the same results too so at least I feel confident that it’s not a software issue on my part. Makes me feel a bit better, but it is still surprising that the Mark II is being outperformed by the Mark I. I can tell that the Mark II has slightly higher quality when the scan is done, but the process of taking the scan is a lot less user friendly.

My main question now is if this is intended functionality for some reason due to the change in hardware, or if there is going to be another SDK/firmware update that will bring it up to full parity with the Mark I in all aspects.

I’ve noticed similar sensitivity to shininess with the Mark II. Have you had a chance to play with IR gain and exposure settings?

1 Like

Do you guys experience battery issues as well. It’s no where near the first generation Structure sensor. Battery gets depleted very quick. Unfortunately the new firmware and SDK don’t seem to have resolved this issue.

BTW, I really don’t like the new way of charging Mark 2. That cable is so inconvenient to plug in and if you want to charge both camera and iPad you need to remove the whole connector cable.

@jim_selikoff I haven’t gotten a chance to mess with those settings much so thanks for the suggestion! I’m going to play around with those this morning and see if I can find a good sweet spot. I’ll post anything I find here on improvements I see.

@OGuler I have still been experiencing battery issues since the new SDK launched too, but they did fix some of them. The main things they seem to have fixed for me are some of the low battery errors that showed up in the logs. But, the battery still seems to drain pretty fast compared to the Mark I and it also seems to be a bit squirrelly with having accurate battery readings. I also agree with the new charging format being a slight pain. I liked being able to charge the Mark I while I was testing on occasion.

@jim_selikoff I tested a bit with the settings using the new Dec 9th SDK Scanner App and saw only the slightest improvements with two of the settings mentioned below.

By using the Depth Stream Preset set to “Body”, the bounding box tended to be more stable while on more reflective surfaces (honestly just surfaces in general as well) and the scans seems ever so slightly better, but it was pretty hard to tell it apart from the default by more than a little. I should note that all testing was done indoors so that setting could change depending on the environment, but my use case is indoors so I didn’t take into account other environments.

Setting IR Analog Gain to 8x also resulted in the best results with reflective surfaces. It looks like the sensor defaults to 8x (at least in the demo app it did) so it was in line with the experience I’ve had in other apps. Just when I put it to anything lower it got a lot worse fast with more difficult surfaces.

None of the other settings have resulted in visible improvements for me yet.

1 Like

Looks like you are not running applyExpensiveCorrection on the depthFrame.

1 Like

@n6xej I actually am running applyExpensiveCorrection on the depthFrame. Below are two images showing this on the Mark II. The first is with applyExpensiveCorrection being called as it is today in the application I’m working on and the second is what happens when I turn it off. Definitely looks like it’s not enabled though so I can see where it seemed that way. Just seems like another big gap with the Mark II since I it looks like the Mark I with applyExpensiveCorrection turned off which is weird. Thanks for the suggestion though! Gave me another thing to look into and confirm so I appreciate it.

applyExpensiveCorrection being called

applyExpensiveCorrection not being called

Depending on your settings, black and white colors and the reflectivity of the surface can affect it. When you scan do the holes in the preview fill in? Are you using STCaptureSession or STSessionController? If using STCaptureSesssion, try setting IR exposure to auto and gain to 8. Also set capture preset to default.

1 Like

Did you mean STSensorController instead of STSessionController because I use STSensorController right now. I know it’s just been deprecated, but I haven’t had time to switch everything over yet. Using the new SDK scanner demo though and tweaking all of the setting in there to match what you have mentioned have produced scans not discernibly different in most cases than the current app configuration I have setup. And it kinda fills in the holes once I start scanning but it take a lot more moving around and waiting for it to pick up all of the surfaces. And usually there will still be holes in the end but they are a lot smaller than the depth preview.

Yes it should be STSensorController, I had STCaptureSession on my brain!

1 Like

Hi @christopher.wood,

Have you found a way to bring ST02A on par with ST01 performance with regards to surface detection? ST02A being an update to ST01, we would assume it would catch more surfaces than ST01, if not at least the same amount…

I have posted a much similar request to yours here:

1 Like