3D Mapping Corruption

[JimmyBlunt]

Subject: Bug Report – LED Mapping Corruption in Marimapper

Issue Description

When working with Marimapper to create a 3D mapping setup for approximately 5000 LEDs (controlled via Pixelblaze), mappings frequently become corrupted or unusable after multiple camera-based 3D mappings.
Key issues include:
• LEDs disappearing from the mapping.
• Previously working mappings becoming corrupted and no longer usable.
• Only partial LED mappings remaining functional.

Steps to Reproduce
1. Due to the project size, LED positions, and visibility limitations, it is not possible to scan all LEDs in one pass. Mapping is conducted in smaller sections, scanning 200–300 LEDs at a time.
2. These smaller mappings are then combined into a complete 3D map of all LEDs.
3. Perform multiple mappings of different regions using the built-in laptop camera (HP Dragonfly, “Carmela”).
4. Observe corruption after several mappings:
• Example: At ~800 LEDs, only 6 LEDs display.
• Example: At ~2000 LEDs, the mapping becomes fully corrupt, leaving only a partial map (e.g., LEDs between index 1200 and 1700).

Expected Behavior
• All scanned LEDs should remain visible and functional.
• Saved mappings should not degrade or become corrupted after additional mappings.

Environment
• Software: Marimapper (V2, where the issue is observed)
• LED Controller: Pixelblaze
• Camera: HP Dragonfly Laptop built-in camera
• Project: Mapping 5000 LEDs with Pixel-Strings distributed across multiple regions. Mapping is performed in smaller spatial sections due to project size and visibility limitations.

Additional Notes

This issue has been observed since the release of the V2 version and was already present in earlier V2 updates. I have not noticed this behavior with the previous older version of Marimapper. I really love the software and would appreciate seeing a stable release.

The issue seems related to handling large mapping datasets or the save/load process. Logs and mapping files can be provided upon request.

Thank you for creating such an incredible tool! I hope this feedback helps improve the stability of the software.

[TheMariday]

Hi there @JimmyBlunt, thank you for the bug report!

I'm sorry this is effecting you this way and I think I have an inkling into what might be causing this but it might be a few different factors that will take some time to iron out.

I will have a look at this now and keep you update with progress.

In the mean time, are you able to use an older version to get around this issue? (de97a5b might be a good commit)

If not I can cobble together something that might resolve the issue in the meantime.

I would love a copy of your CSV's so I can test it locally as the biggest scan I have here is a 3'000 led best case scenario scan.

Thank you and my apologies that this bug has crept in

[JimmyBlunt]

Hi @TheMariday,

Thank you for the quick response and for looking into this issue—I really appreciate it!

I’ll try using the older version (de97a5b) as you suggested, but I was really curious about the MAX_FILL parameter. It could be so useful, especially if detecting hidden or unrecognized LEDs fails and leaves gaps in the map. That's a nice feature there.
Additionally, I’ll share the CSV files, for further testing. I’ll include:

1. The original scans (Front - -originals) are labeled with the specific index ranges scanned for each file.
2. renamed and organized to folders showing how the 3D map changes drastically and begins to miss previously scanned LEDs, illustrating the issue.

Scanning almost 5000 LEDs from multiple angles in smaller chunks took quite some time (half a night! 😅).
I’d really appreciate it if the scanned data could still be salvaged and used. If the corruption is due to a minor or easily fixable issue like an [amissed](Front - originals.zip) scan or a line issue in the files, I’d love some nailed-down troubleshooting steps to correct and reuse these scans. Any guidance on how to get the datasets back in shape would be amazing.

Cheers
Named_sorted.zip

[TheMariday]

Thank you for the files, having a look now.

I'll see what I can recover from your scans.

Also on the long runtime wise, I'm working on a new version as we speak that will vastly speed up detection time so probably not any use this side of christmas but for future reference that feature is on it's way.

Keep you posted

[JimmyBlunt]

Thanks so much!
Those features sound really promising, especially for larger LED setups.

It would be great to have an indicator showing the quality and coverage of performed scans, highlighting areas with poor data that might need a retake. A quality check could also help identify whether additional close-ups of certain areas would improve the overall 3D mapping. And if LEDs are already scanned with good accuracy and no errors, why not skip them in the next pass to save time? An automatic retry for missed or poorly scanned points would also be an awesome addition.
Can't wait to see the new version and all the exciting features! Keep up the great work—
I’ve attached screenshots showing how the map changed. Cheers!

[TheMariday]

Hi there @JimmyBlunt

I have run your data-set through MariMapper (main and pre-V2) on my machine and I get a total of 6483 detections and 378 leds reconstructed.

I can't manage to make anything look corrupted or incorrect, even when feeding in the files one by one.

I have had a look at your raw data and I have found a possible issue. (there may also be bugs I'm unaware of yet)

The route of this is a lack of transparency over camera positions which I'm going to be addressing soon.

My current hypothesis is that some of your scans either don't have enough points (9-15 is the minimum i test) or they don't have enough overlap with the rest of the scans.

Below I have made a quick relationship grid, the x and y axes both represent the file name and the values show the percentage of led id's they overlap by.

As you can see, there are distinct clusters, which on it's own isn't an issue, however if these clusters aren't "connected" by scans that can see a reasonable amount of both clusters, then they will be discarded.

I think in this case, only the yellow cluster is being reconstructed.

I'm not sure what the merge.py file does, but I also wanted to mention that each detection csv represents a particular view of the leds, so merging detection csv's is only safe to do so if the camera view has not been changed at all. (even nudging the camera will cause a failure)

I'm wondering if this is what's causing your corrupted looking scans?

I'll continue to look into this and see if it's a bug on my end and consider this when it comes to adding helper features.

[TheMariday]

We can though save this scan!

This is however dependant on the LEDs not having moved, the indexing being consistent and using the same camera.

Joining these clusters with scans that cover large overlaps of the smaller mappings should join them together.

When it comes to the "corrupted" scans though, I'm not sure how these have happened and sadly cannot recreate them locally

The last option is if you can wait a week or so, I can send you a pre-alpha version of marimapper with fast mode which might reduce your scan time from half a night to half an hour.

This would be compatible with the current marimapper, so you could use it to add new scans.

However this would be a highly experimental version and might break in new and unusual ways so might not be a good idea considering the scale of your setup.

[JimmyBlunt]

Hi mate,
First of all, thank you for the quick and detailed response. I really appreciate your effort in running the data through MariMapper and providing the insights.

After analyzing the dataset further, I observed the following points that may contribute to the issues:

Gaps in Detected Points:
It seems that maps occasionally become corrupted when there are insufficient points detected in certain scans. This aligns with your observation that 9–15 points are often the minimum needed. Some scans might be falling below this threshold.

Behavior with Individual Scans:
When I tested the scans one by one (in the sequence they were created), I noticed odd behavior. Specifically, during map creation, the process seems to "stall," refusing to incorporate new scans to fix or add to the already successfully scanned LEDs. This was evident in some cases where the map remained static even after introducing additional valid scans.

Python Scripts and Raw Data:
To clarify, none of the Python scripts included in my folder were applied to the data after they were generated by the system. The scripts were used solely for testing and analysis purposes. The raw data remains untouched from its original state.

Overlap and Connectivity:
Your hypothesis about clusters not being connected resonates with my observations. The current map reconstruction appears to favor the yellow cluster, discarding others due to insufficient overlapping scans. I have attached screenshots of the calculated maps to illustrate this behavior.

Camera Positioning:
While merging CSVs, I ensured the camera view was consistent and not altered. However, the lack of transparency regarding precise camera positions might still be affecting the reconstruction process. This is something I’ll explore further.

Based on the high level layout I have in my environment I could identify 3 main areas that are not really connectect to each other see screenshot bellolw of the red yellow and blue area.

Based on the cabeling I could determine the following grouping

I then splitted the scann files in those 6 groups and suddenly I get a working mapping for each group

and looking at the mappingthneyh match then certain areas of my scan

Group1 & 2

and from another angle

Group 3 & 4 & 5

and Group6

So it's some dataset that caused the map creation to stall
I have attached the scanned files grouped ->
Front-Grouped.zip

[TheMariday]

Hi @JimmyBlunt

Thank you for all this information!

I am glad to see our hypothesies are similar and glad that you have a few valid scans.

I think that there are a few tickets lined up for me to tackle soon that should address these from a process perspective:

Mainly #44 which would allow the LEDs to light up with a status colour to indicate if they need more scans.

I'm currently adding a new status that represents "unreconstructable" which should show areas that should be reconstructed but aren't due to low led counts or due to the cluster being cut off.

#43 should also improve visibility, giving you a warning if the current scan doesn't have enough points or doesn't overlap with the previous dataset enough.

#31 might also be good in your case so you can do scans in segments and leave them in nested directories instead of having to move the CSV files around.

I don't have much time to look into this today but considering all of the above, it sounds like this issue is mostly down to a lack of helper features.

Thank you so much for the detailed responses, I have no idea where you lot came from. This was a tiny project with like 2 users for the longest time, deffo didn't expect this influx of use!

I just hope that the % of people using it isn't equal to the people raising issues :D

[JimmyBlunt]

Hey TheMariday
First off, I really appreciate your effort and the solid approach here – it’s clear you’re not just throwing quick fixes around, and that’s awesome. This tool already has so many fans (myself included!), but yeah... hopefully, fewer bugs and less work ahead!

Also, as you kindly offered before, I’d absolutely love to test an early beta version of the new release – count me in.

Quick question: Do you know the best way to assemble one full map from the 5 separate ones I have? Would scanning different areas actually merge into a complete map?

Keep up the great work, and huge thanks for creating such an amazing tool and sharing it with all of us. The effort you’ve put into this is truly appreciated!

[TheMariday]

Hi there, quick response, will reply in full later

To join your partial scans, you need to add new scans that ensure there is a "chain" linking your unreconstructed sections to the successfully reconstructed model.

So if you have scans that cover

• A
• A&B
• B
• C
• C&D
• etc

A and B will reconstruct.

C and D will not reconstruct, even if they could on their own, as it's not connected to the base A.

So you need to add scans where areas of both B and C are in view simultaneously.

A good rule of thumb is to place the camera so that at least 1/2 of the leds in view are already part of the successfully reconstructed model.

[TheMariday]

Full response:

Thank you so much for the praise! It means a lot to me. I'm hoping to get some time this weekend to work through a few new features that will make things easier. Sadly I'm being pedantic about code quality so having to refactor stuff that doesn't quite make sense anymore as I go. I'll keep you posted and thank you for being a bit of a Guinea pig!

I'll keep you posted and I hope the above idea allows you to merge your scans.

P.S. I have found a way for Marimapper to reconstruct multiple, disconnected scans, however it seems to only be able to do 2 and I'm not sure it's what you want as their position will be arbitrary

[TheMariday]

I've moved this to a discussion to clear up the issue / feature log