Add OpenCV node for detecting architectural floor plans from JPG images

[johnpierson]

Add OpenCV node for detecting architectural floor plans from JPG images

Background

Dynamo workflows increasingly rely on image-derived geometry and lightweight computer vision workflows. Users commonly receive architectural floor plans as JPG exports, scanned sheets, screenshots, consultant markups, or rasterized PDFs.

Today, converting these raster plans into usable Dynamo geometry requires:

• manual tracing,

• external preprocessing tools,

• or custom Python/OpenCV scripts.

This issue proposes a first-party Core Geometry node that uses OpenCV to detect architectural floor plan geometry from JPG images and expose the results as Dynamo-native geometry.

---

Proposed Node

Node Name: Geometry.DetectFloorPlanFromImage
Category: Core > Geometry

---

User Story

As a Dynamo user,
I want to input a JPG floor plan image,
so that Dynamo can detect walls, rooms, openings, and linework candidates
and return structured geometry for downstream workflows.

---

Goals

• Enable lightweight raster-to-geometry workflows.

• Provide a Dynamo-native OpenCV integration point.

• Return inspectable geometry and metadata.

• Support floor plan preprocessing and detection without requiring custom scripting.

• Work in Dynamo Sandbox without Revit dependencies.

---

Non-Goals (v1)

• Full BIM reconstruction.

• Automatic room naming/classification.

• ML-based semantic understanding.

• Revit element creation.

• PDF parsing/import.

• OCR/text extraction.

• Guaranteed wall/door/window accuracy.

---

Inputs

Input | Type | Required | Default | Description -- | -- | -- | -- | -- imagePath | string | Yes | — | Path to JPG image file scale | double | No | 1.0 | Pixel-to-model scale factor threshold | int | No | Auto | Threshold value for binarization adaptiveThreshold | bool | No | true | Use adaptive thresholding minLineLength | double | No | 25 | Minimum detectable line length in pixels wallThicknessRange | double[] | No | null | Optional expected wall thickness range detectRooms | bool | No | true | Attempt room/space contour detection detectOpenings | bool | No | true | Attempt opening detection debugOutput | bool | No | false | Return intermediate debug images and metadata

---

Functional Requirements

Image Processing

The node shall:

1. Accept JPG image input from disk.

2. Convert image to grayscale.

3. Apply configurable denoising.

4. Apply thresholding or adaptive thresholding.

5. Perform edge detection.

6. Detect linework using OpenCV Hough transforms.

7. Detect contours and closed regions.

8. Detect probable wall structures using geometric heuristics.

9. Detect possible openings from wall interruptions or gaps.

---

Geometry Generation

The node shall:

1. Convert detected raster geometry into Dynamo-native geometry.

2. Support:

   • Line

   • Curve

   • PolyCurve

   • Point

3. Respect the supplied scale factor.

4. Preserve coordinate consistency relative to image origin.

---

Reporting

The node shall return:

• image dimensions,

• preprocessing settings,

• detection counts,

• warnings,

• confidence metrics,

• processing duration.

Example warnings:

• image resolution too low,

• insufficient linework detected,

• disconnected geometry,

• unsupported image format,

• likely non-floor-plan image.

---

Debug Mode

When debugOutput = true, the node shall optionally expose:

• grayscale image,

• threshold image,

• edge detection image,

• contour image,

• detected line overlay image.

---

Technical Notes

Suggested Processing Pipeline

Load JPG
→ grayscale conversion
→ denoise
→ threshold/adaptive threshold
→ morphology cleanup
→ edge detection
→ Hough line detection
→ contour extraction
→ room/wall heuristics
→ geometry conversion
→ output geometry + metadata

---

Suggested OpenCV Features

Potential APIs/methods:

• GaussianBlur

• AdaptiveThreshold

• Canny

• HoughLinesP

• FindContours

• MorphologyEx

• ApproxPolyDP

---

Performance Requirements

• Node should process a typical 3000x3000 floor plan image in under 5 seconds on a standard workstation.

• Node should avoid unnecessary file writes.

• Memory usage should remain bounded for large raster inputs.

---

Error Handling

The node shall fail gracefully when:

• image path is invalid,

• image cannot be decoded,

• image resolution is too small,

• no meaningful geometry is detected.

Errors should return warnings rather than hard crashes whenever possible.

---

Acceptance Criteria

Functional

• Given a clean JPG floor plan, the node returns usable line geometry.

• Given a floor plan with closed regions, the node returns room boundary candidates.

• Given noisy input, the node still returns partial geometry where possible.

• Given invalid input, the node returns warnings/errors without crashing Dynamo.

---

Platform

• Works in Dynamo Sandbox.

• Does not require Revit.

• Compatible with standard Dynamo preview behavior.

• Compatible with graph serialization/deserialization.

---

Testing

Implementation should include:

• unit tests,

• regression tests,

• sample fixture images,

• benchmark image cases.

Suggested fixtures:

• clean architectural plan,

• low-resolution plan,

• noisy scan,

• skewed image,

• partial floor plan,

• blank image,

• non-plan JPG.

---

Dependency Considerations

• OpenCV dependency should be isolated behind an abstraction/service layer.

• Licensing review required before dependency inclusion.

• Native binary loading strategy must support supported Dynamo platforms.

---

Future Enhancements

Potential future extensions:

• PNG/TIFF support,

• perspective correction,

• OCR/text extraction,

• door/window classification,

• ML-assisted semantic detection,

• Revit element generation,

• vector export,

• floor-plan-to-graph workflows.

---

Open Questions

1. Should OpenCV functionality live in Core or an experimental package first?

2. Should outputs remain generic geometry or introduce typed result objects?

3. Should image inputs support in-memory bitmap objects in addition to file paths?

4. Should future versions support vectorization cleanup/simplification options?

5. Should perspective correction/skew normalization be included in v1?