DEV Community: Amna Hafeez

Katas Raj Heritage 3D: Building an AI-Powered Digital Preservation Tool

Amna Hafeez — Fri, 07 Aug 2026 15:20:32 +0000

Katas Raj Heritage 3D: Building an AI-Powered Digital Preservation Tool

A PMW case study by Amna Hafeez · Team Indus

Problem

The Katas Raj Temples in Chakwal, Punjab, are a partially ruined but actively protected heritage site — a Hindu temple complex built around a sacred spring-fed pond. Documentation for sites like this is usually static: a handful of photos and a paragraph of history. That approach loses the spatial and material detail that actually matters for preservation — how large the structures are, what condition the domes and walls are in, and what the site looks like from angles a flat photo can't show. My goal was to build a tool that could classify, measure, and reconstruct the site digitally, and present it in a way that felt like a working survey record rather than a static gallery.

My Role

I was the sole developer and Team Indus lead on this build. I designed and implemented the full stack: the ML image classifier, the AR measurement overlay, the Three.js 3D viewer, and the site's information architecture and visual design (the "field survey record" aesthetic). I also ran and interpreted the site's own performance/accessibility audits and fixed what came out of them.

Live site: katas-raj-heritage-3d.vercel.app
Repository: github.com/Anfey-SE/katas-raj-heritage-3d
Commit history: github.com/Anfey-SE/katas-raj-heritage-3d/commits/main

What I Built

The site is organized as a "site survey record" with three exhibits per location:

Exhibit A — Photograph: the base documentation shot, captioned like a field photo log (location, condition, protection status, capture angles logged).
Exhibit B — AR Survey Lines: an HTML5 Canvas overlay drawn on top of the photograph showing measured distances across the site — diagonal spans, wall heights, and pond width (e.g., 21.1m diagonal, 18.7m and 12.4m spans, 9.2m elevation) — simulating how a real AR measurement tool would annotate the ruins.

Exhibit C — Capture-to-3D: a Three.js-rendered depth relief generated from photo luminance, giving an orbit-able first-pass 3D read of the site's terrain and structures, with drag-to-orbit and pan controls.

Underneath this, I trained and integrated a MobileNetV2 image classifier to automatically categorize heritage site photos. Tested against three real Katas Raj photographs, it correctly identified the site type ("castle" — the closest ImageNet-class match to a fortified temple complex) with 74.7%, 88.4%, and 98.6% confidence respectively, with the next-closest guesses (monastery, cliff dwelling, palace) trailing far behind. That's a meaningful signal for a model that was never trained on Pakistani heritage architecture specifically.

Process

Photographed and sourced reference images of the Katas Raj complex.
Built the classifier pipeline in Google Colab (CPU-only local hardware made this the practical choice) and validated it against the three site photos, visualizing confidence scores per class.
Built the Exhibit A/B/C tabbed interface, including the Canvas-based AR measurement overlay and the Three.js depth-relief viewer.
Ran a Lighthouse audit and found the results were being skewed by Chrome extensions loading in the profile — the first pass showed misleadingly low Performance alongside perfect Accessibility/Best Practices/SEO. I re-ran the audit in a clean incognito window with no extensions to get a valid reading.
Documented the corrected results.

Result

Valid Lighthouse audit (incognito, no extensions):

Metric	Score
Performance	52
Accessibility	100
Best Practices	100
SEO	100

Accessibility, Best Practices, and SEO are all perfect. Performance sits at 52, held down mainly by the Three.js/Canvas-heavy Exhibit C view, which is the honest number rather than the artificially poor one caused by browser extensions on the first (invalid) run.

What I Learned

Running the same audit twice taught me something I wouldn't have learned from a single clean pass: tooling itself can lie to you. The first Lighthouse run reported a Performance score of 37 — a number I could have submitted as evidence without realizing it wasn't measuring my site at all, but the extensions in my browser profile. Catching that and re-running in incognito was a small thing, but it's the difference between real evidence and a false read. I also learned, more directly, how much weight a 3D canvas view carries on load performance versus a static image — the gap between my Performance score and my other three scores is basically a map of where the actual rendering cost lives in this app.

Next Improvements

Lazy-load or defer the Three.js/Canvas exhibits so they don't block initial paint, to close the gap between Performance and the other three scores.
Extend the classifier training set with more Pakistani heritage sites so classifications move from "closest ImageNet analog" (e.g., castle) toward more accurate custom labels (e.g., temple complex, stepped pond).
Replace the simulated AR measurement overlay with actual computed distances from the COLMAP reconstruction pipeline once sparse reconstruction quality improves.

Evidence: live site · commit history · classifier confidence charts and Lighthouse audit screenshots above.

Real Fixes on My Heritage 3D Site: An Audit Trail and a Rendering Polish Pass

Amna Hafeez — Sat, 01 Aug 2026 12:22:16 +0000

What I built

Katas Raj Heritage 3D is a site I built for my Platform & Web Engineering internship with PreserveMy.World — it combines a MobileNetV2 image classifier, an HTML5 Canvas AR measurement overlay, and a Three.js 3D mesh viewer for the Katas Raj temple complex in Chakwal, Punjab.

Live site: katas-raj-heritage-3d.vercel.app
Repo: github.com/Anfey-SE/katas-raj-heritage-3d

Why I went back to it

This is Week 6 of my internship's make-up work track, and the task was to take a prior artifact and prove I'd actually improved it — not just say I did. I picked this project because I had a real audit trail: a Lighthouse-driven fix I made and verified in Module 21, plus a follow-up check I ran while preparing this write-up.

What the first audit showed

Back in Module 21, I ran a Lighthouse audit (Mobile, Navigation mode) on the deployed site and found real, specific issues:

SEO: 83
Accessibility: 92

Specifically: a missing meta description, an invalid/missing robots.txt, a missing <main> landmark, a non-sequential heading order (h1 jumping to h3), and a favicon 404 in the console. I didn't screenshot that run before fixing things — a mistake I'm not repeating this time — but the flagged issues and scores are saved in a text output from that session.

Performance wasn't part of this claim. That run flagged Performance as unreliable due to browser extensions and throttling, so I didn't treat it as fixable data — more on that below.

What I actually fixed

Real commits, in order:

e5b6fbf — add robots.txt
The site had no robots.txt at all. Added one so crawlers have explicit instructions instead of guessing.
52fb5ac — add meta description, favicon, main landmark, heading hierarchy
The page was missing a meta description (so it had no real search-result snippet), had no favicon, no <main> landmark for screen readers to jump to, and its heading tags weren't in a logical order. Fixed all four.

After making these fixes, I verified the Vercel deployment shipped correctly, then re-ran Lighthouse and confirmed:

SEO: 83 → 100
Accessibility: 92 → 100

That's the core result — two real, measured scores moving because of specific, identifiable fixes, not a rerun trick.

A performance note

While preparing this write-up, I ran Lighthouse again to double check the site's current state, and noticed the Performance score came back invalid — Chrome extensions were interfering with the page load. I re-ran it in a clean incognito window and got a real Performance score of 62. That's not something I'm claiming as "fixed" here since it wasn't part of the original scoped work, but I did make one real change along the way: I noticed the Exhibit C iframe was loading eagerly on first paint and switched it to lazy-load, since it's one likely contributor to a slower initial load. That's a smaller, secondary improvement worth mentioning honestly rather than folding into the headline numbers above.

Lighthouse flagged this run as invalid due to Chrome extensions

Clean incognito re-run — real Performance score

A separate fix: smoothing the 3D relief

Alongside the audit work, I also went back into capture_to_3d_depth.html — the capture-to-3D viewer — and fixed something that had nothing to do with Lighthouse scores: the relief mesh looked noisy and jittery instead of smooth.

The cause was that depth displacement was being computed directly from raw per-pixel luminance values, which produces a static-like bump surface. The fix was to box-blur the luminance data before using it as depth, while leaving the actual photo texture untouched and sharp — so the surface reads as smooth geometry with a crisp photo on top, instead of a jittery mesh.

While I was in there, I also added a soft radial contact shadow under the mesh so it reads as resting in the scene rather than floating above it, and eased the camera's starting distance so it dollies in gently on load instead of snapping straight to position.

None of this shows up in a Lighthouse score. It's a rendering-quality fix, verifiable by opening the page and comparing the mesh surface and camera behavior before and after — commit d40e511.

The hard part

The heading hierarchy fix looked trivial but wasn't — changing h3 to h2 meant tracking down the matching CSS selector too, since the site's styling was keyed to the tag name, not a class. Missing that would have fixed the semantic structure but broken the visual layout. That's the kind of thing an automated score won't warn you about either way.

What I'd improve next

Get a valid Lighthouse baseline before making any changes next time, run in incognito from the start, so before/after numbers are directly comparable.
The AR canvas and Three.js viewer are still the heaviest parts of the page — next step would be code-splitting them so they load on demand instead of on initial page load.

Connection to PreserveMy.World

A heritage site is only as useful as the number of people who can actually load and read it. Slow performance and weak semantic structure quietly gatekeep who gets access — someone on a low-end phone, or someone using a screen reader, is exactly the kind of public audience PMW's mission is built around: students, researchers, and diaspora communities engaging with Pakistani heritage sites they may never visit in person. A technically solid, accessible page isn't a side detail to the preservation work — it's part of what makes the preservation actually reach people.

What I verified manually

I ran the Lighthouse audit myself, read through the flagged issues to confirm which were real and fixable, edited index.html directly, verified the Vercel deployment succeeded (Ready status, correct commit hash), and re-ran Lighthouse afterward to confirm the score changes. For the performance check, I re-ran in a clean incognito profile and cross-checked the fix against the live deployed site.

Evidence:

Audit-driven commits: e5b6fbf, 52fb5ac
Rendering polish commit: d40e511
Full commit history: github.com/Anfey-SE/katas-raj-heritage-3d/commits/main/
Live site: katas-raj-heritage-3d.vercel.app

Choosing a 3D Reconstruction Method for Heritage Sites With No LiDAR Access

Amna Hafeez — Tue, 28 Jul 2026 11:30:59 +0000

When I built the COLMAP pipeline for Mohenjo-daro's Great Bath (Module 11), I hit a wall early: Wikimedia Commons, my planned image source, was blocked by my ISP. I had to fall back to Google Images photos instead — and at the time it felt like a compromise. Digging into the research afterward, it turns out this fallback is a documented, legitimate method in heritage photogrammetry, not a shortcut.

COLMAP itself is built exactly for this kind of problem: it's a Structure-from-Motion and Multi-View Stereo pipeline designed to reconstruct 3D geometry and camera positions purely from overlapping 2D photos, with no LiDAR or specialized capture equipment required.

More importantly, this isn't a novel workaround — it's an established research approach. Researchers rebuilt Palmyra's Temple of Bel, destroyed in 2015, using nothing but public visitor photos pulled from social media and web search engines. If a fully destroyed UNESCO heritage site can be reconstructed from scraped web images, then a Google Images fallback for an accessible site like Mohenjo-daro is well within reason.

The tradeoff is real, though: crowdsourced or web images lack the consistent overlap and camera orientation of a controlled capture, which is exactly why researchers have studied using web-sourced photos for heritage documentation specifically, treating image volume and redundancy as compensation for inconsistent capture conditions.

On the tool side, COLMAP compares favorably to alternatives like Meshroom for this kind of work: comparative reviews mark COLMAP as producing high-detail reconstructions with minimal smoothing, though it's less plug-and-play than Meshroom's drag-and-drop workflow. For a one-off heritage reconstruction where output quality mattered more than setup speed, COLMAP was the right call.

Takeaway: the Google Images fallback wasn't a limitation I had to work around — it's a recognized method with real precedent in cultural heritage preservation, and COLMAP was the right tool to pair it with.

Sources

Rohtas Fort: The Fortress That Was Never Stormed

Amna Hafeez — Fri, 10 Jul 2026 11:20:17 +0000

Rohtas Fort: The Fortress That Was Never Stormed
Perched on a hilltop above the Kahan River in Jhelum district, Rohtas Fort has stood since 1541 without ever falling to a direct assault. It was inscribed as a UNESCO World Heritage Site in 1997, recognized as an outstanding example of early Muslim military architecture in Central and South Asia. Researching it for this module reminded me that a heritage site's story doesn't end at its founding — it's still being written today, through conservation battles and community disputes that rarely make it into the tourist brochures.
Built to Keep an Emperor Out
Rohtas Fort exists because of one man's fear of losing what he'd just won. After defeating the Mughal emperor Humayun at the Battle of Kannauj in 1540, the Afghan ruler Sher Shah Suri needed a way to block Humayun's return route into the subcontinent and to subdue the Gakhar tribe, who remained loyal to the Mughals. Construction began in 1541 under Sher Shah's revenue minister, Todar Mal, on a hilltop chosen specifically because it commanded the old route between Kabul and the Punjab plains.
The build wasn't smooth. The Gakhars, on whose land the fort was rising, initially refused to supply labor. According to several historical accounts, Todar Mal only secured workers after Sher Shah authorized dramatically higher wages — a costly decision that shows how much strategic weight the emperor placed on this single fortification. Sher Shah died in 1545, before the fort was finished, and by 1555 Humayun had reclaimed the region anyway, making Rohtas's original military purpose almost moot within a generation of its construction.
An Architectural Hybrid
What makes Rohtas historically significant isn't just its scale — over 4 kilometers of walls, 68 bastions, and 12 gates — but what it represents architecturally. UNESCO's listing describes it as blending Turkish and South Asian building traditions into a new fortification style developed in response to the spread of gunpowder and cannon, one that went on to shape Mughal military architecture for generations afterward.
Inside the walls, the fort tells a layered story rather than a single one. The Shahi Masjid near Kabuli Gate reflects Sher Shah's original Suri-era construction, while the Haveli Man Singh — built later under Mughal general Raja Man Singh — is Hindu in architectural style and bears no resemblance to the surrounding Afghan-style fortification. Stepped wells called baolis gave the garrison self-sufficient water access, meaning the fort never depended on outside supply lines even under siege conditions.
A Living Site, Not a Frozen One
Here's the part that doesn't usually make it into travel writeups: Rohtas Fort has an actual village inside its walls, and that's been a source of tension for decades. Communities have lived within the ramparts continuously since the Suri era, and by some estimates the resident population reached around 4,000 people in recent years. That's created a genuine conflict between heritage preservation and people's homes.
UNESCO's own assessment is direct about the risk: encroachment inside the fort has disrupted its original drainage system, and parts of the fortification wall have already collapsed as a result. This isn't a hypothetical threat — it's an ongoing management problem. The Punjab government and the Directorate General of Archaeology have run repeated anti-encroachment operations over the years, including a demolition drive in August 2024 targeting unauthorized structures, but the underlying tension between conservation and a resident community hasn't disappeared.
Conservation work has also had real wins. The Rohtas Fort Conservation Programme, launched in 2000 by Pakistan's Department of Archaeology and Museums together with the Himalayan Wildlife Foundation, has restored several gates — including Shah Chandwali and Talaqi — and established the Sher Shah Suri Museum inside Sohail Gate. A steering committee formed in 2003 continues to oversee this work, and more recent excavation projects have aimed to uncover and protect structures still buried at the site.
Why It Still Matters
Rohtas Fort is a reminder that heritage sites are rarely static monuments — they're contested, lived-in, and still being fought for. Its 16th-century engineering genuinely earned its UNESCO status, but keeping that status meaningful depends on solving very present-day problems: drainage, encroachment, and the balance between preserving a monument and respecting the people who call it home.

Sources

UNESCO World Heritage Centre. "Rohtas Fort." whc.unesco.org/en/list/586.
"Rohtas Fort." Wikipedia.
"Rohtas Fort — Grokipedia." grokipedia.com/page/Rohtas_Fort.
"The Preservation of Rohtas Fort." The News on Sunday (thenews.com.pk), 22 January 2023.
"The Perfect Castle? The Indestructible and Unconquered Rohtas Fort." Ancient Origins, 20 January 2022.
Meemjee. "Rohtas Fort Gate.jpg." Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:Rohtas_Fort_Gate.jpg

What I Learned About 3D Reconstruction in Week 1 of My AI Internship at PreserveMy.World

Amna Hafeez — Fri, 26 Jun 2026 19:23:40 +0000

This week marked the beginning of my internship at TechRealm x PreserveMy.World —
a nonprofit using AI to preserve cultural heritage sites in 3D. I'm on the Core Tech
track, focused on Platform & Web Engineering.

What is PreserveMy.World?

PreserveMy.World is a nonprofit initiative that uses AI and 3D reconstruction to
document and preserve historical sites — starting with Lahore's heritage landmarks
like Badshahi Masjid.

What I Set Up This Week

Python, Git, GitHub CLI, and VS Code
Gemini CLI as my AI coding assistant
My first GitHub repo: PMW-day1

3D Reconstruction Methods I Researched

I compared five methods for reconstructing heritage sites in 3D:

1. COLMAP (Structure-from-Motion)
Takes multiple photos and produces a 3D point cloud. Great starting point for PMW.

2. NeRF (Neural Radiance Fields)
Creates photorealistic 3D scenes from images. Needs a GPU but produces stunning results.

3. Gaussian Splatting
Fast, high-quality 3D rendering — ideal for web platforms like PreserveMy.World.

4. Monocular Depth Estimation
Works from a single image or video. Most practical for field use with limited equipment.

5. Multi-View Stereo (MVS)
Dense reconstruction from multiple calibrated images. Good for building facades.

My Python Experiment

I wrote a Python script simulating monocular depth estimation and generated a depth
map output. Small experiment, but it confirmed the pipeline concept works.

What Failed

The first attempt at downloading a heritage image in Python returned a 403 error —
so I switched to a simulated depth map instead. Real-world data acquisition will need
proper API access or local images.

What's Next

I'll continue researching 3D reconstruction methods, run more experiments,

and contribute to the PreserveMy.World platform as the internship progresses.

This post is part of my TechRealm x PreserveMy.World internship journey.
GitHub: https://github.com/Anfey-SE/PMW-day1