← Jobs

Fix Python/OpenCV script for measuring fracture dip angle (α) on drill core photos

Budget: $30.0 - $60.0 HOURLY / PART_TIME ⭐ 4.96 (10) United States

python, opencv, computer-vision, geometry

I have a working Python/OpenCV/Open3D tool (`core_frame.py`, ~1400 lines, attached in full) that measures a structural geology angle (**α**, fracture dip relative to the core axis) on photos of HQ3 diamond drill core (Ø61.1 mm). The photo is taken through a curved paper cutout frame that I also 3D-printed as a physical orange overlay jig, so the same window can be placed on the core and photographed consistently. **How it works today:** 1. User loads a photo of the core taken through the orange frame. 2. User clicks ≥3 points along each of the two short curved edges of the cutout window ("Rail A" = top, "Rail B" = bottom — 44 mm apart along the core arc ≈ 82.5°, 84 mm apart along the core axis). 3. The tool fits a polynomial to each rail and builds a dense remap that rectifies + cylindrically unwraps the core surface between the rails into a flat strip image. 4. User clicks ≥3 points along a visible fracture trace in that unwrapped image. 5. Each clicked point is projected back onto the 3-D cylinder surface, a plane is fit via SVD, and the tool computes **α** = `arcsin(nz)` of the plane normal — the 3-D angle between the fracture plane and the core axis (0° = axial fracture, 90° = transverse). 6. Results render in an Open3D 3-D viewer and save to JSON. **Built-in self-check:** pressing `g` overlays a reference grid of sinusoid curves for α = 10°,20°,…80° (formula `A = R·cot(α)`) on the unwrapped image, meant to be compared visually against the curves printed on a paper calibration template (see attached photos). If they match, the author's own docs say "math, constants, and rails are all correct." ## The problem They do **not** match — see the attached screenshot (`WhatsApp Image ...31.51 AM.jpg`), which is the tool's own reference grid (cyan) overlaid on the printed calibration chart (black). The cyan curves are visibly tighter/steeper near the apex than the printed ones — this is the tool's own built-in check failing, not just "output looks off."
Open job