Yes. I went through the paper itself and then checked the current Nepal LiDAR/data situation, available benchmark datasets, existing open implementations, Nepal forest-type data, and the practical acquisition/permit side.

The main conclusion is:

This is a viable research project, but I would not implement the paper literally and assume it will work in Nepal. The paper is better treated as a conceptual framework than as a completely reproducible implementation specification. For Nepal, the most important changes are terrain normalization, density robustness, overlapping spatial inference, real instance-level evaluation, and a better-defined self-supervised objective.

There is also a realistic data path: Nepal already has airborne forest LiDAR, including a 2021 central-Terai campaign with at least 15 points/m², but the data are not publicly downloadable. The FRTC has an official data-sharing process. Meanwhile, you can build and debug essentially the entire pipeline on public forest LiDAR benchmarks before Nepalese data arrives. (www.mdpi.com frtc.gov.np)

---

1. What the paper is actually doing

A useful way to think about the paper is:

LiDAR → preprocessing → self-supervised PointNet features → geometry-derived energy → feature refinement → adaptive soft clustering → tree instances

It is not a conventional end-to-end instance-segmentation neural network. A large part of the final segmentation comes from engineered geometric assumptions about what a tree should look like.

The paper's Figure 1 on page 3 shows the two-stage framework: a geometric-transformation pretext task followed by the actual individual-tree clustering task. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Stage A — LiDAR preprocessing

The authors first:

• statistically remove outliers using mean k-nearest-neighbor distance,
• calculate local surface normals and remove abnormal structures,
• independently normalize X, Y and Z to [0,1],
• divide the scene into non-overlapping XY chunks.

The statistical outlier threshold is

$$T_n=\mu_d+2\sigma_d$$

where $d_i$ is the mean distance from point $i$ to its $k$ nearest neighbors. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

The independent coordinate normalization and non-overlapping chunking are described explicitly on the next page. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

That preprocessing design is one of the first things I would change for Nepal.

---

2. The self-supervised pretext task

A point cloud is transformed with:

Transformation	Paper range
Z-axis rotation	−45° to +45°
Translation	−1 to +1 on each axis
Scale	0.5 to 2.0

A PointNet-like network processes the transformed cloud.

For each point:

$$f_i = MLP(p_i)$$

A max pool generates a global feature:

$$f_{global}=\max_i f_i$$

Then local features, the global feature, and geometric properties are concatenated. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

The network predicts the transformation parameters and is trained with MSE:

$$L_{pretext}={1\over N}\sum_i ||T_i-\hat T_i||^2$$

The reported training setup is 100 epochs, learning rate $5\times 10^{-4}$, batch size 16. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf) (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

The idea is that this creates robust geometric features without manually labeling trees.

There is, however, an important conceptual problem here that matters for your implementation.

Predicting a transformation is not the same thing as being invariant to it

If the network has to predict rotation, translation and scale, its representation has to contain information about those transformations.

That is closer to learning an equivariant/sensitive representation than explicitly forcing transformation invariance.

A truly invariant objective normally does something like

$$f(x)\approx f(T(x))$$

for two transformed versions of the same cloud.

There is no explicit representation-consistency term like that in the paper.

The authors report a cosine similarity of 0.98 between original and transformed features, but it is an observed metric rather than the principal optimization objective. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

For your project, I would therefore preserve their transformation-regression objective for the paper-faithful baseline, but add a second Nepal model using a feature-consistency objective such as VICReg/BYOL/contrastive consistency.

That gives you a very good ablation study.

---

3. The important part: the energy model

After the PointNet features have been learned, the paper tries to impose the geometry of trees on the feature space.

It defines three energies.

Height energy

$$E_h(p_i)=\sigma \left({z_i-\mu_z\over\sigma_z}\right)$$

Higher points therefore receive higher energy. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Density energy

Local density is:

$$\rho_i=\sum_{j\in N(i)} \exp\left( -{||p_i-p_j||^2\over2\sigma_\rho^2} \right)$$

which is subsequently normalized into a density energy. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Slope energy

The paper calculates:

$$s_i= \sum_{j\in N(i)} {|z_i-z_j|\over||p_i-p_j||}$$

and then

$$E_s(p_i)=\exp(-s_i/\sigma_s)$$

The final energy is

$$E(p_i)= {w_hE_h+w_dE_d+w_sE_s \over w_h+w_d+w_s}$$

The purpose is to produce high-energy regions corresponding approximately to treetops/dense crown regions. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

---

4. The feature-space loss

The energy values are then used to manipulate the learned PointNet features.

For neighboring points with similar energy:

$$w_{ij}= \exp\left( - {|E_i-E_j|\over\sigma_h} \right)$$

and the intra-cluster loss pulls their representations together:

$$L_{intra} = \sum_i\sum_jw_{ij}||f_i-f_j||^2$$

The inter-cluster term pushes points with dissimilar energies apart.

A third slope-based term is added.

Finally:

$$L_{total} = \lambda_1 L_{intra} + \lambda_2 L_{inter} + \lambda_3 L_{slope}$$

(Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf) (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Then the feature extractor is frozen and the segmentation stage is reported as being trained for 30 epochs over 48 spatial chunks with an 80:20 train/validation split. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

---

5. Adaptive soft clustering

This is how the actual trees finally appear.

High-energy, spatially separated points become initial candidate centroids.

The probability that point $p_i$ belongs to tree $k$ is

$$P(C_k|p_i)= {\exp[-d(p_i,\mu_k)] \over \sum_j\exp[-d(p_i,\mu_j)]}$$

Clusters can then be:

merged if centroids are spatially close and energetically similar,

pruned if too few points belong to them,

and refined by recalculating centroids from membership-weighted points.

This lets the number of trees change instead of requiring $K$ to be given beforehand. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf) (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Conceptually, this is quite attractive for Nepal because you do not know how many trees are in each scene.

---

6. But the paper has substantial reproducibility problems

This is probably the most important part of my review.

I would not claim that this paper can be reproduced exactly from the publication alone.

There are quite a few missing or contradictory details.

Problem	Why it matters for your implementation
No value for SOR $k$	Controls what is classified as noise
Normal-estimation neighborhood/threshold absent	Strongly affects branches and thin structures
Chunk dimensions are absent	Determines how often crowns get cut
Number of points fed into PointNet isn't reported	Required to construct actual batches
MLP architecture/dimensions are not given	Core network cannot be exactly reproduced
$\sigma_\rho,\sigma_s,\sigma_h$ not reported	They control all energy neighborhoods
$w_h,w_d,w_s$ not reported	Relative importance of height/density/slope is unknown
$\lambda_1,\lambda_2,\lambda_3$ not reported	Segmentation training objective cannot be reproduced exactly
$N'(i)$ in the inter-cluster loss isn't clearly defined	Cannot implement exact negative-neighbor selection
$s_{ij}$ in slope loss isn't sufficiently defined	Same problem
Energy threshold for centroid selection absent	Determines the original tree count
$d_{min},\epsilon,\delta,T_{min}$ absent	Cluster initialization/merging/pruning depends on them
No softmax temperature	Affects membership sharpness
No cluster convergence/stopping rule	Inference is underspecified
No random seed	Reproducibility
No clear optimizer/config for the segmentation refinement	Training isn't fully specified

The paper itself acknowledges sensitivity to hyperparameters and the need for additional validation across LiDAR acquisition conditions. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

There are also deeper inconsistencies.

Dataset-size discrepancy

The abstract says that the study uses “over 850,000 points.” (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

But Table 2 on page 8 reports approximately:

• dense: 12,590,373 points,
• mixed: 18,199,087,
• scattered: 9,339,438,

or about 40.1 million points in total. (www.researchgate.net)

Those numbers are not reconciled in the paper.

Result discrepancy

The abstract claims elliptical-fit error “as low as 0.12.” (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

But the reported forest-type results are:

• dense: 0.30,
• mixed: 0.35,
• scattered: 0.36.

(Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Again, no explanation is given for the 0.12 value.

Coordinate-system discrepancy

The paper says the Estonian dataset is referenced to GDA94 / UTM Zone 55S. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

GDA94/MGA zone 55 is an Australian coordinate reference system. (epsg.io)

The Estonian Land Board's actual ALS products are reported in L-EST97, with heights in EH2000. (geoportaal.maaamet.ee geoportaal.maaamet.ee)

So this is almost certainly a documentation error.

Point-density question

The paper's page-8 datasets report approximately 29–57 points/m². (www.researchgate.net)

The official Estonian national ALS program lists typical point densities of roughly 0.8 p/m² for forestry mapping, 2.1 p/m² for national mapping, and 18 p/m² for dense urban acquisition. (geoportaal.maaamet.ee)

That does not mean the paper's dataset cannot exist, but the paper does not adequately explain where its significantly denser forest scenes came from or how they were produced.

I also did not locate an official implementation from the paper in searches by title/DOI/authors, so I would plan the project as a reimplementation rather than a code-porting exercise.

---

7. There is a serious evaluation problem

This is actually more important than most of the architecture.

The paper assesses segmentation using primarily:

• convexity,
• solidity,
• elliptical-fit error.

(Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Those tell you whether predicted clusters look geometrically plausible.

They do not tell you whether Tree 17 was actually separated correctly from Tree 18.

For example, two neighboring crowns could be incorrectly merged into one smooth convex cluster and still obtain decent convexity and solidity.

So when the paper calls this “accurate segmentation,” the evidence is weaker than what I would require for a Nepal study.

You need manually validated trees for the test set, even though training is self-supervised.

That distinction is crucial:

Self-supervised training means you do not require labels to learn the representation. It does not mean you should evaluate the model without ground truth.

Modern tree-instance evaluations generally use predicted-to-ground-truth tree matching, point-set IoU, precision, recall, F1 and coverage. An IoU threshold of 0.5 is commonly used to determine successful tree matching in available evaluation code. (github.com tomesphere.com)

---

8. Why Nepal changes the problem substantially

The original height model is:

$$E_h\propto z_i$$

That is dangerous in Nepal.

Suppose two trees grow 50 metres apart on a steep hillside. A point at the bottom of Tree A's crown may have a larger absolute $z$ coordinate than the top of Tree B simply because Tree A stands uphill.

The algorithm can then interpret terrain elevation as tree structure.

That might not severely hurt relatively flat forest scenes.

It can destroy the method in Churia and middle-mountain terrain.

The single most important Nepal modification

Replace absolute elevation

$$z_i$$

with height above local ground

$$h_i=z_i-DTM(x_i,y_i)$$

Every height-, slope- and crown-related calculation should use $h_i$, not raw elevation.

Interestingly, existing Nepal forest-LiDAR work already does exactly this. The 2021 central-Terai ALS study normalized LiDAR heights using a 1 m DTM before calculating canopy variables. (www.mdpi.com)

The older Nepal LAMP campaign similarly calculated a DTM from ground returns and transformed vegetation elevations into distance above ground. (nepjol.info)

So this should be a fundamental design choice for your Nepal version.

---

9. I would also remove the paper's independent XYZ min-max scaling

The paper independently maps X, Y and Z into [0,1]. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

That destroys the physical relationship between horizontal and vertical distances.

For example, a 40 × 40 × 25 m forest tile becomes a 1 × 1 × 1 cube.

Consequently a real-world slope of

$${1\,m\over2\,m}=0.5$$

no longer corresponds to the same geometric slope after separate X/Y/Z scaling.

That is especially undesirable when your energy function explicitly uses Euclidean distances and vertical gradients.

Nepal version

Keep two coordinate representations:

Metric geometry

$$p_i^{metric}=(x_i-x_c,\ y_i-y_c,\ h_i)$$

used for:

• neighborhoods,
• density,
• slope,
• clustering,
• crown distance.

And optionally a normalized version

$$p_i^{NN}={p_i^{metric}\over S}$$

with one isotropic scale factor $S$ for neural-network stability.

Do not independently stretch X, Y and Z.

---

10. Another issue: paper translation augmentation

Remember that preprocessing supposedly happens before SSL.

Coordinates have therefore already been put inside approximately [0,1].

The paper then says it translates them between −1 and +1.

That is potentially a displacement as large as the whole point-cloud extent, despite describing it as a small sensor/GPS displacement. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

So it is ambiguous whether “one unit” means:

• one normalized coordinate unit,
• one metre,
• something else.

For the reproduction, record the assumption explicitly.

For Nepal, I would center every tile first and either:

• eliminate translation prediction entirely, or
• make translation physically meaningful in metres.

---

11. Scaling from 0.5 to 2.0 is also too aggressive

A 25 m tree can become equivalent to a 12.5 m or 50 m tree.

That can teach scale tolerance, but it can also erase biologically useful information.

For a Nepal-adapted version I would initially test something closer to:

$$s\sim U(0.8,1.25)$$

while retaining [0.5,2.0] as the paper-faithful baseline.

This becomes another experiment rather than an arbitrary change.

---

12. The slope-energy formulation needs investigation

There is a subtle contradiction.

The text repeatedly associates slopes/gradients with structurally important crown regions.

But the formula is

$$E_s=\exp(-s_i/\sigma_s)$$

which means:

larger slope → smaller slope energy.

Yet high energy is subsequently supposed to help identify important/treetop regions.

That may be intentional—the authors could want smooth high crown areas to have high energy—but the explanation and equations are not completely aligned. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Do not silently guess.

Implement:

Variant P: formula exactly as published.

Variant N: a Nepal-specific, terrain-normalized crown-gradient term.

Then perform an ablation.

---

13. There is also an ambiguity in clustering space

The paper says distances to centroids are computed in the learned feature space. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

But centroid refinement subsequently averages $p_i$, i.e. spatial point coordinates. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Those are not the same domain.

For your implementation I would explicitly maintain two representations per cluster:

$$c_k^f = \text{feature-space centroid}$$

and

$$c_k^{xyz} = \text{metric spatial centroid}.$$

Feature distance determines semantic/structural similarity; XY spatial distance prevents physically unrelated trees from joining.

A practical distance can be:

$$d_{ik} = \alpha ||f_i-c_k^f||^2 + \beta {||xy_i-c_k^{xy}||^2\over r_k^2}$$

with candidate clusters restricted spatially.

That also greatly reduces computation.

---

14. What data actually exist for Nepal?

This is better than I expected.

A. 2021 central-Terai airborne LiDAR — your best existing lead

A 2024 Nepal study reports helicopter ALS collected in January 2021 by Geo3dModeling, provided by Nepal Ban Nigam Limited, Government of Nepal, with a point density of at least 15 points/m². The study used a 1 m terrain model for height normalization. (www.mdpi.com)

The study area was the Sagarnath Forestry Development Project in the central Terai, including plantations and natural forest, with Sal, Eucalyptus and Teak among major trees. It also had field-inventory plots and 1,138 measured trees. (www.mdpi.com)

However:

the authors explicitly say the LiDAR data are not publicly available because they were intended for ongoing research. (www.mdpi.com)

This is nevertheless your strongest potential Nepal source.

Important qualification

The inventory does not appear to provide a full individual-tree 3D segmentation ground truth. Plot-level tree measurements are not automatically enough to associate every LiDAR point with a specific stem.

So even if you get this dataset, you will probably still need a small manually annotated instance-segmentation test set.

---

15. FRTC is worth approaching directly

The Forest Research and Training Centre currently publishes:

• a Data Sharing Protocol DFRS,
• a data-request application format,
• forest inventory resources,

and provides the contact [email protected]. (frtc.gov.np)

Other Nepal forest research explicitly directs data-access requests to FRTC. (www.frontiersin.org)

So this is not a speculative contact.

I would formally request:

Ask for	Why
Raw LAS/LAZ	You need point-level processing
Ground-classified points	Essential for terrain normalization
Existing DTM	Avoid rebuilding it unnecessarily
CRS and vertical datum	Absolutely necessary
Sensor and acquisition metadata	Domain adaptation
Return number / number of returns	Strong canopy features
Intensity	Potential extra feature
Scan angle	Density/domain effects
Flight-line ID	Diagnose strip differences
Acquisition date	Seasonality
Nominal and actual point density	Density normalization
Plot boundaries	Validation
Tree locations, if available	Tree-level validation
Tree height/DBH/species	Downstream analysis

FRTC data-sharing and reports page

---

16. Nepal also has the older LAMP LiDAR

The 2011 LiDAR-Assisted Multisource Programme in the Terai Arc Landscape used:

• 20 blocks,
• each 5 × 10 km,
• ALS in March–April 2011,
• a Leica ALS50-II,
• approximately 1.26 pulses/m²,
• 792 forest plots with tree-level measurements.

(nepjol.info www.nepjol.info)

That is useful historical data, but 1.26 pulses/m² is far below the paper's approximately 29–57 p/m² datasets.

I would therefore not use it as your main dataset for precise point-level crown segmentation.

It would be excellent for a later question:

“How far can this model degrade before individual-tree segmentation becomes unusable?”

That would actually make a nice robustness experiment.

---

17. Public data you should use immediately

The lack of public Nepal LiDAR should not stop implementation.

The best starting resource I found is FOR-instance.

It contains:

• UAV laser-scanning point clouds,
• 1,130 manually segmented individual trees,
• semantic labels,
• five different forest collections,
• Norway, Czech Republic, Austria, New Zealand and Australia,
• provided development/test splits,
• about 1.6 GB.

(zenodo.org)

FOR-instance public dataset

Use it in an unusual way:

Ignore its tree labels during self-supervised training.

Then use the labels only for evaluation.

That lets you test whether your implementation of the paper actually works before touching Nepalese data.

This is much stronger than trying to visually determine whether colored clusters “look right.”

---

18. A very useful baseline already has open code

ForAINet has an official public implementation for forest point-cloud instance segmentation. It includes experiments using intensity, returns, hand-crafted features and different point densities. It even provides a large-point-cloud workflow that divides scenes into 50 m tiles with overlap and stitches predictions afterward. (github.com)

ForAINet implementation

It should serve as a supervised upper/reference baseline, not as a replacement for your research idea.

One published density experiment specifically evaluates 10, 25, 50, 75, 100, 500 and 1000 points/m², covering conventional ALS through very dense UAV LiDAR. (doi.org)

That is encouraging for the 2021 Nepal data at ≥15 p/m², but expect it to be substantially more difficult than the dense point clouds in the paper.

---

19. The Nepal forest-type map is extremely useful even though it is not LiDAR

FRTC and ICIMOD have released the Forest Types of Nepal 2022 dataset. It was developed using Sentinel-2, Google Earth Engine, field sampling and stakeholder consultation, and is available under CC BY 4.0. (rds.icimod.org)

Forest Types of Nepal dataset

Do not use this as a substitute for LiDAR.

Use it to:

• stratify your samples,
• determine which forest domains your model has actually seen,
• make geographically separated train/validation/test splits,
• report performance per forest type,
• identify missing ecological domains.

This is how you eventually justify the phrase “works in Nepali forests.”

---

20. Do not start by claiming “all Nepali landscapes”

This should probably be staged.

A sensible progression is:

v1: central Terai.

v2: Terai + Churia/Siwalik.

v3: add middle-hill forests.

v4: temperate/higher-elevation forests.

If your only Nepal training data are from central Terai, a claim that the system works “across Nepal” would not be scientifically defensible.

The whole interesting research problem is whether the self-supervised representation can generalize across those domains.

---

21. Define what “a tree” means before training anything

This matters enormously.

For ALS, I recommend the target be:

A canopy-visible individual tree whose crown is sufficiently represented in the airborne point cloud.

Not:

every stem recorded in a forestry inventory.

Why?

Because an airborne sensor can have essentially no useful returns from a suppressed tree underneath a dense upper canopy.

No machine-learning algorithm can segment a tree that the sensor did not observe.

If your research objective is all stems including understory, you need denser UAV LiDAR, terrestrial/mobile LiDAR, field observations, or multimodal fusion.

That is a sensing limitation, not a model failure.

---

22. The Nepal-ready pipeline I would build

Component	Paper	Nepal implementation
Terrain	Raw Z	Height above ground
Coordinates	Independent XYZ min-max	Metric coordinates + isotropic NN normalization
Denoising	SOR + normals	Conservative SOR; preserve fine branches
Tiling	Non-overlapping	Overlapping tiles + halo
Point density	Assumed relatively dense	Density normalization + density augmentation
Pretext	Transformation regression	Reproduce first; then consistency + transform auxiliary
Rotation	Z ±45°	Paper baseline; test wider yaw invariance
Scaling	0.5–2	Baseline + moderate-scale version
Geometry	height/density/slope	HAG/density/HAG-gradient + optional eigenfeatures
Clustering	Feature/spatial ambiguity	Separate feature and metric centroids
Boundaries	No tile reconciliation	Instance stitching
Validation	Shape proxies	Manually labelled tree instances
Generalization	Random chunks	Site/forest-type held-out splits

---

23. Tiling is particularly important

The paper uses non-overlapping tiles. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Imagine a 10 m-wide Sal crown whose center is 1 m away from a tile boundary.

Half of the crown enters Tile A.

Half enters Tile B.

Both may become separate “trees.”

For Nepal I would use something like:

50 m core tile + 5–10 m halo

and remove duplicate instances during stitching.

A better rule is:

$$halo \geq P_{95}(\text{crown radius})$$

once you have enough Nepal data to estimate crown size.

The existing ForAINet code independently arrived at the same general approach, using overlapping tiles for large point clouds. (github.com)

---

24. Point-density robustness should become one of your research contributions

Nepal data may vary enormously by:

• sensor,
• flight altitude,
• scan angle,
• topography,
• canopy closure,
• overlapping flight strips.

So during self-supervised training I would randomly thin point clouds.

For example, a 50 p/m² tile can be randomly reduced to approximately:

$$50,\ 30,\ 20,\ 15,\ 10\ p/m^2$$

The representation of the same tree should remain similar.

This can become a density-consistency SSL objective.

It is particularly relevant because the public evidence currently gives you:

• paper scenes: about 29–57 p/m², (www.researchgate.net)
• newer Nepal central-Terai data: ≥15 p/m², (www.mdpi.com)
• historical Nepal LAMP: 1.26 pulses/m². (nepjol.info)

That is a very nice experimental spectrum.

---

25. I would change the energy function for Nepal

For a Nepal model, I would start with:

$$h_i=z_i-DTM(x_i,y_i)$$

Then use something like

$$E_h(i)=\sigma \left( {h_i-\operatorname{median}(h) \over IQR(h)+\epsilon} \right)$$

rather than raw absolute Z.

For density:

$$\rho_i= \sum_{j\in N_r(i)} \exp \left( -{||p_i-p_j||^2\over2\sigma_\rho^2} \right)$$

but calculate it within a physical radius in metres.

And normalize it locally so a low-density flight does not automatically produce lower “tree energy.”

For crown gradient:

$$s_i= \operatorname{median}_{j\in N(i)} {|h_i-h_j| \over ||xy_i-xy_j||+\epsilon}$$

rather than using raw terrain elevation.

I would additionally test local PCA eigenfeatures:

• planarity,
• linearity,
• verticality,
• curvature.

Those may help distinguish crown interiors, trunks, ground artifacts and irregular vegetation.

But those should be an ablation, not silently mixed into the original model.

---

26. Consider adding point-cloud corruption to SSL

The transformation task in the paper only addresses geometry.

Nepal's actual domain shift will also come from acquisition.

So your Nepal self-supervised views should eventually include:

$$x^{(1)} = A_1(x), \qquad x^{(2)}=A_2(x)$$

where $A$ can include:

• random point dropout,
• local missing patches,
• mild positional noise,
• changing density,
• scan-like anisotropic thinning,
• rotation about vertical,
• small scale changes.

Then force

$$f(x^{(1)})\approx f(x^{(2)}).$$

This is much closer to the actual problem you need to solve:

“This is the same tree/forest geometry even though the sensor sampled it differently.”

---

27. Your ground-truth problem is smaller than it first appears

You do not need to manually label your entire Nepal dataset.

You need a sufficiently good evaluation set.

As an initial research target, I would aim for roughly 300–500 manually verified canopy-visible trees distributed across multiple plots and forest conditions.

That number is my project-design recommendation, not a threshold from the paper.

For example:

10–15 independent plots × approximately 20–50 evaluable trees.

The crucial thing is diversity rather than sheer count.

Annotate in 3D, preferably using CloudCompare or another point-cloud tool.

Each point gets:

text
tree_id
0 = non-target vegetation / background
1 = tree 1
2 = tree 2
...

Have a second annotator independently check at least a subset.

Ambiguous understory trees should be flagged rather than forced into artificial ground truth.

---

28. Evaluation I would require

Your primary metrics should be instance metrics:

Metric	Purpose
Tree detection precision	How many predicted trees are real
Tree detection recall	How many visible trees were found
Instance F1	Overall tree-detection performance
Mean matched IoU	Boundary/point assignment quality
Coverage	How completely true trees are represented
Omission rate	Missed trees
Commission rate	False trees
Over-segmentation rate	One tree → multiple predictions
Under-segmentation rate	Several trees → one prediction
Tree-count MAE	Forest inventory usefulness
Height MAE	Forestry usefulness

Then retain the paper's:

• convexity,
• solidity,
• elliptical-fit error,

as secondary replication metrics.

That gives you comparability with the paper without confusing crown regularity with actual segmentation accuracy.

---

29. The data split is critical

Do not perform an ordinary random 80:20 split of neighboring tiles if you're trying to demonstrate Nepal generalization.

Nearby chunks can contain almost identical:

• species,
• crown architecture,
• flight geometry,
• soil/topography,
• sensor characteristics.

This produces spatial leakage.

Use whole sites or geographically separated blocks.

I would actually report two protocols.

Transductive Nepal adaptation: unlabeled point clouds from the deployment forest may be used for SSL, but labels are hidden.

Inductive generalization: the entire test forest/site is unseen during SSL training.

The second one is the stronger research result.

---

30. Your experimental structure could become a strong paper/thesis

I would compare these systems:

Model	Purpose
Classical CHM/watershed or DBSCAN	Simple baseline
P-SSL	Paper-faithful implementation
N-SSL-T	+ Nepal terrain normalization
N-SSL-D	+ density/occlusion augmentation
N-SSL-O	+ overlapping tiles/stitching
N-SSL-C	+ representation-consistency SSL
ForAINet	Supervised reference/upper baseline
Optional small-label model	Practical semi-supervised comparison

Then run controlled ablations:

$$\text{raw Z} \quad vs \quad \text{height above ground}$$ $$\text{nonoverlap} \quad vs \quad \text{overlap}$$ $$\text{no SSL} \quad vs \quad \text{SSL}$$ $$E_h,\quad E_h+E_d,\quad E_h+E_d+E_s$$

and density tests:

$$10,\ 15,\ 25,\ 50,\ 100\;p/m^2.$$

That gives you actual scientific questions rather than simply “we ran another model on Nepal.”

---

31. Four research questions I think are especially strong

RQ1 — Terrain

Does ground-normalized height significantly improve self-supervised individual-tree segmentation on sloped Himalayan forest terrain compared with absolute elevation?

RQ2 — acquisition density

Can density-aware self-supervised augmentation make individual-tree features invariant to Nepalese ALS point-density variation?

RQ3 — ecological generalization

How well do self-supervised geometric representations transfer between Nepalese forest types without instance-level retraining?

RQ4 — annotation efficiency

How much Nepal-specific annotation is actually required to calibrate or evaluate a self-supervised model?

Those give the Nepal adaptation an actual research contribution beyond reproducing the original paper.

---

32. What hardware/software you need

The original experiments used an i7 laptop CPU, about 16 GB RAM and an RTX 4050 laptop GPU with 6 GB VRAM, although the paper curiously also reports PyTorch 2.3.0+cpu. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

The reported segmentation time was around 117 minutes for the dense scene and 143 minutes for the mixed scene, versus about 7 minutes for the scattered scene. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

For development I would target:

Resource	Recommended
GPU	16–24 GB VRAM if available
RAM	32–64 GB
Storage	Fast NVMe SSD
Language	Python 3.10/3.11
Deep learning	PyTorch only
LAS/LAZ	laspy + lazrs / PDAL
Point neighborhoods	torch-cluster / FAISS / PyTorch3D
Geometry	NumPy/SciPy/Open3D
Evaluation	scikit-learn + custom tree matcher
Manual inspection	CloudCompare/QGIS

There is no real reason for your implementation to mix TensorFlow and PyTorch.

---

33. Computational scaling needs redesign too

Straight soft assignment between every point and every tree centroid is roughly

$$O(NK)$$

and naive pairwise point operations can become

$$O(N^2).$$

That is unacceptable for Nepal-scale mapping.

Use local spatial graphs:

$$O(Nk), \qquad k\ll N$$

for energy/loss computations.

During clustering, each point should evaluate only nearby candidate trees rather than every centroid in the entire tile.

Combine that with:

• GPU kNN,
• voxel-grid downsampling,
• overlapping tile inference,
• parallel tiles,
• feature caching.

Otherwise the model may work academically on a 0.3 km² point cloud and become unusable at operational scale.

---

34. One more Nepal-specific problem: shrubs, bamboo and non-tree vegetation

The energy model assumes:

tall + dense + geometrically crown-like → probably tree.

Nepalese landscapes can also contain:

• shrubs,
• bamboo,
• dense regeneration,
• agricultural vegetation,
• riparian vegetation,
• tree plantations,
• scattered agricultural trees.

Therefore you should decide whether input data are first masked to forest or whether your model must simultaneously distinguish tree versus non-tree vegetation.

For the first project, I recommend:

forest mask → tree segmentation

rather than trying to solve semantic vegetation classification and individual-tree segmentation simultaneously.

The FRTC/ICIMOD forest-type product is useful at this stage. (rds.icimod.org)

---

35. If you must collect new Nepal LiDAR

I would only make this Plan B after trying to acquire the existing data.

As an engineering target, I would prefer ≥50 p/m² effective vegetation density for new acquisition if the budget allows. That is not a magic threshold; it puts you nearer the paper's 29–57 p/m² range and gives substantially more flexibility than the available ≥15 p/m² dataset.

If the research requires small trees, stems or under-canopy structure, go substantially denser.

Also obtain:

• multiple returns,
• RTK/PPK trajectory,
• scan-angle metadata,
• cross-flight strips where feasible,
• ground points,
• a high-quality DTM,
• acquisition metadata,
• a simultaneous field-validation campaign.

There is a regulatory component. CAAN currently has a drone registration/approval pathway, and registration itself does not automatically constitute authorization to fly. (caanepal.gov.np caanepal.gov.np) The Department of Survey also publishes an Aerial Survey Permit Procedure, 2079. (dos.gov.np)

A 2026 CAAN public notice specifies operational restrictions including 100 m AGL, VLOS and additional controls around airports and protected/conservation areas. (epaper.gorkhapatraonline.com)

So a UAV-LiDAR campaign in a national park or sensitive forest is not something I would put into the schedule without budgeting permit time.

---

36. Concrete implementation roadmap

I would execute the project in this order:

1. Freeze a written reproduction specification first. Turn every missing paper parameter into an explicit YAML configuration rather than hiding assumptions inside code. Create paper_faithful.yaml and never change it after the baseline is established.

2. Build on FOR-instance before obtaining Nepal data. Implement LAS loading, terrain handling, tiling, PointNet pretraining, energy calculations, clustering and instance evaluation. Ignore its labels during SSL training and use them only for evaluation.

3. Reproduce the paper as closely as possible. Use its transformations, raw formulas, non-overlapping chunks and geometry losses. The objective here is not maximum performance—it is establishing exactly what “paper-faithful” means.

4. Request the 2021 Nepal ALS and relevant FRTC data simultaneously. Prioritize raw point clouds, ground returns/DTM and acquisition metadata rather than only derived canopy rasters.

5. Build Nepal preprocessing before touching the model. Verify CRS and vertical datum; ground-classify if necessary; generate DTM; calculate height above ground; remove buildings/noise; create metric overlapping tiles; calculate density maps and slope/topography statistics.

6. Create the terrain-aware Nepal model. Replace raw Z with HAG, preserve metric geometry, separate feature/spatial centroids, implement overlap/stitching, and add density-aware augmentations.

7. Build a small Nepal instance-ground-truth dataset. Aim for several hundred canopy-visible trees distributed by forest structure, topography, tree height and point density. Keep entire sites unseen for final testing.

8. Run ablations rather than one final experiment. Paper faithful → HAG → overlap → density augmentation → consistency SSL. Evaluate every stage with the same test data.

9. Only then expand geographically. Start with central Terai, then Churia/Siwalik and middle hills. Do not call the model Nepal-wide until an entire unseen ecological region has been tested.

10. Optimize only after correctness. Once segmentation is validated, GPU-optimize neighborhood construction, cluster candidate search and tiled inference. Then export a tree_id for every LiDAR point plus per-tree crown, location, height and confidence products.

---

37. What the final system should output

I would not stop at a colored point cloud.

For every input LAS/LAZ point:

text
tree_id
membership_confidence
height_above_ground

And for every tree:

text
tree_id
x
y
tree_height_m
crown_area_m2
crown_diameter_m
point_count
mean_membership_confidence
forest_type
source_tile

Then export:

LAZ with a tree-instance attribute,

GeoPackage/GeoJSON crown polygons,

and a CSV/Parquet tree inventory.

That turns the model into something forestry people can actually use.

---

38. The project I would actually propose

Rather than:

“Implementation of Self-Supervised Learning for Tree Segmentation in Nepal”

I would frame it closer to:

Terrain- and Density-Robust Self-Supervised Individual Tree Segmentation for Airborne LiDAR in Heterogeneous Nepalese Forests

Your contribution then becomes:

reproduction of the original framework,

plus terrain normalization for mountainous forests,

plus density-robust self-supervised learning,

plus overlapping large-scene segmentation,

plus proper tree-instance evaluation across Nepalese forest conditions.

That is substantially more defensible than simply translating someone else's code to a Nepal dataset.

---

My recommendation on the data problem

You do not currently need to wait for the perfect Nepal dataset.

There is a clear path:

FOR-instance → get the implementation correct → FRTC/Nepal Ban Nigam request → central-Terai Nepal v1 → manually label a small test set → terrain/density adaptations → Churia/mid-hill transfer.

The public benchmark gives you 1,130 true segmented trees immediately. (zenodo.org) Nepal already has ≥15 p/m² ALS that is technically relevant, but access needs to be negotiated. (www.mdpi.com) And FRTC has an actual data-sharing mechanism rather than this being a dead end. (frtc.gov.np)

The biggest mistake would be spending the first several weeks coding the formulas exactly as written and only later discovering that absolute Z, non-overlapping tiles, missing hyperparameters, no ground-truth instance metrics, and 15 p/m² Nepal LiDAR make the assumptions of the original experiment fundamentally different.

The next step should therefore be a formal implementation specification: module-by-module repository structure, exact tensors and dimensions, preprocessing algorithms, corrected equations, assumed values for every missing hyperparameter, paper_faithful.yaml versus nepal.yaml, training pseudocode, clustering pseudocode, evaluation code design, and the data-request specification for FRTC/Nepal Ban Nigam. That will turn this research review into something you can start implementing directly.

Yes — I think you should stay in this area, but I would change the exact project you pursue.

I would not make your final-year project simply:

“Implement the 2025 self-supervised tree-segmentation paper for Nepal.”

And I would probably not use the exact title:

“Terrain- and Density-Robust Self-Supervised Individual Tree Segmentation for Airborne LiDAR in Heterogeneous Nepalese Forests.”

That title promises too much: terrain robustness, density robustness, self-supervision, individual-tree segmentation, airborne LiDAR, and heterogeneous forests across Nepal. For a final-year project, that can easily become a PhD-sized problem.

What I would pursue is a narrower, more current version of the same research direction:

Low-Label, Terrain- and Density-Robust Individual Tree Segmentation in Nepalese Airborne LiDAR Using Self-Supervised 3D Representations

Or, even better as a research question:

Can Self-Supervised 3D Pretraining Reduce the Need for Labeled Data in Individual Tree Segmentation of Nepalese Airborne LiDAR?

I think that is a very strong 2026 final-year project.

---

Why I would modify it rather than abandon it

The technology landscape has moved noticeably since the paper you uploaded was published in April 2025.

The original paper uses a PointNet-inspired architecture, transformation prediction, hand-designed height/density/slope energies, and soft clustering. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

That is useful as a baseline, but in 2026 it should not be your definition of state of the art.

Modern point-cloud research has moved toward considerably stronger backbones and self-supervised representations. For example, Sonata, a CVPR 2025 Highlight paper, self-supervises a Point Transformer V3 encoder and provides pretrained weights and public implementation. Its authors specifically argue that earlier point-cloud SSL can suffer from a “geometric shortcut,” where models learn relatively low-level spatial features rather than genuinely transferable representations. (openaccess.thecvf.com github.com)

Point Transformer V3 itself is an efficient modern point-cloud architecture with an official open-source implementation, and the wider Pointcept ecosystem now includes Sonata and newer representation-learning work. (github.com github.com)

So your idea is not obsolete.

But the interesting question has changed.

---

What is interesting in 2026

The question is no longer simply:

“Can deep learning segment individual trees from LiDAR?”

Clearly it can.

There are now end-to-end methods specifically targeting heterogeneous aerial LiDAR. ITS-Net, published for 2026, explicitly targets platform- and sensor-agnostic individual-tree segmentation and introduced AerialTrees, with 121 million manually annotated points across multiple aerial platforms, sensors and forest conditions. (www.sciencedirect.com github.com)

Likewise, the new FGI-EMIT benchmark contains 1,561 manually segmented trees, including difficult understory trees. Its benchmark found deep models substantially outperforming conventional unsupervised approaches; the reported best deep model achieved a 73.3% F1 compared with 52.7% for the strongest tested unsupervised method. Interestingly, the deep models remained superior even at point densities down to about 10 points/m². (www.sciencedirect.com github.com)

And density heterogeneity is still explicitly being researched in 2026: recent work proposes density-adaptive sampling and multi-scale processing specifically because variable point density continues to hurt tree instance segmentation. (link.springer.com)

So terrain shift + density shift + label scarcity + geographic/domain transfer is actually very timely.

That is where I would position your work.

---

The problem with the original project framing

Suppose your project is:

“I implemented Shaheen et al. and ran it on Nepalese LiDAR.”

That's decent engineering, but the academic contribution is weak.

Someone can reasonably ask:

Why this architecture?

Why PointNet when PTv3/Sonata exists?

Why handcrafted transformation prediction?

Why those energy equations?

How does it compare with modern supervised instance segmentation?

Are improvements actually caused by self-supervision?

Does it generalize, or did you tune everything to one Nepal forest?

Those are difficult questions if your work is just an implementation.

Your uploaded paper itself acknowledges that performance requires validation under changing pulse density, scan angle and sensor type, that hyperparameters need dataset-specific tuning, and that highly dense/overlapping canopies remain problematic. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

Those limitations are a better starting point for your project than the model itself.

---

The project I would choose

I would formulate your problem as:

Low-label adaptation under domain shift

You have:

$$D_{\text{public}}$$

large, labeled foreign forest LiDAR datasets,

and

$$D_{\text{Nepal}}$$

a smaller Nepalese dataset containing different:

• topography,
• forests,
• tree architecture,
• point density,
• sensor properties.

The question becomes:

Can unlabeled Nepalese LiDAR be used to adapt a 3D representation so that individual-tree segmentation requires very few manually labeled Nepalese trees?

Now you have a much stronger thesis.

---

Your experiment could look like this

Instead of inventing one huge new neural network, build a rigorous comparison.

System	What it tells you
Classical watershed/TreeIso/DBSCAN	Non-DL baseline
Original paper reproduction	2025 self-supervised baseline
Modern supervised tree model	Strong upper/reference baseline
PTv3 from scratch	Modern backbone baseline
Sonata/PTv3 pretrained	Effect of generic point-cloud SSL
Sonata + unlabeled Nepal adaptation	Effect of Nepal-specific SSL
+ terrain normalization	Effect of mountainous terrain correction
+ density augmentation	Effect of varying ALS density
+ small labeled Nepal set	Practical low-label system

Then vary the amount of Nepalese supervision:

$$0,\;10,\;25,\;50,\;100,\;200$$

labeled trees.

Plot something like:

$$\text{Instance F1} \quad \text{versus} \quad \text{Number of labeled Nepal trees}.$$

If your self-supervised model reaches approximately the same accuracy with 50 labels that a conventional model requires 200 labels to reach, that is an excellent result even if you have not invented a new transformer architecture.

It answers a real problem.

---

And this is much more defensible

Your eventual contribution can be:

Generic models require $N$ manually segmented Nepalese trees to reach performance X.

Self-supervised adaptation using unlabeled Nepalese LiDAR reaches X with approximately $N/4$ annotations.

Terrain normalization improves performance particularly on slopes.

Density augmentation reduces degradation when point density falls from 50 to 15 p/m².

That is a much stronger final-year dissertation than:

“Here is our segmentation visualization.”

---

I would actually simplify the terrain component

I still think terrain normalization is extremely important, particularly for Nepal.

But you don't need to invent an enormous “terrain-aware neural architecture.”

Your hypothesis can simply be:

$$z_{\text{absolute}}$$

versus

$$h=z-DTM(x,y).$$

Then test performance as terrain slope increases.

For example divide your test sites into:

$$0^\circ-10^\circ, \quad10^\circ-20^\circ, \quad20^\circ-30^\circ, \quad>30^\circ$$

and evaluate instance F1.

If the original method deteriorates with slope while height-above-ground remains stable, you have demonstrated something scientifically useful.

---

And density should become another controlled experiment

Take exactly the same trees and synthetically thin them:

$$100\% \rightarrow 75\% \rightarrow 50\% \rightarrow 25\%$$

or approximate density levels such as:

$$50,\;25,\;15,\;10\text{ points/m}^2.$$

Then compare:

ordinary model

against

density-augmented SSL model.

This is especially timely because current 2026 research is still explicitly targeting density-heterogeneous forest point clouds. (link.springer.com)

Now “density robust” actually means something measurable.

---

One thing I would remove from your title

I would remove:

heterogeneous Nepalese forests

unless you really have data from several ecological zones.

Nepal's current national forest-type dataset distinguishes many forest classes ranging from Shorea robusta and tropical mixed broadleaf through Pinus roxburghii, temperate broadleaf, fir mixtures and rhododendron systems. (rds.icimod.org geoapps.icimod.org)

Validating across “Nepalese forests” is therefore a huge claim.

For the FYP, something like:

...in Nepalese Airborne LiDAR

is safer.

Or, if you obtain the central-Terai data:

...in Central Terai Forests of Nepal

Much better.

You can put cross-ecoregion generalization under future work.

---

The biggest reason I still like this project: it isn't another generic AI application

In 2026, it is very easy to make a project like:

LLM chatbot for university X

RAG chatbot for legal documents

AI agent that reads PDFs

GPT-based recommendation system

chatbot with vector database

Those can be useful products.

But academically, they are increasingly difficult to distinguish unless there is a genuinely difficult technical or research problem underneath them.

Your LiDAR project gives you:

• 3D deep learning,
• self-supervised learning,
• transformers,
• domain adaptation,
• geospatial data,
• remote sensing,
• point-cloud algorithms,
• experiment design,
• data engineering,
• GPU training,
• spatial statistics,
• real environmental application,
• an underrepresented geographic domain.

That combination is much rarer.

---

From a career perspective

It depends somewhat on where you want to go after graduating.

Intended direction	How I rate this project
MSc/PhD in AI/CV/remote sensing	10/10
Computer vision / 3D perception	9.5/10
Robotics/autonomous systems	8.5/10
Geospatial/earth-observation ML	10/10
Environmental AI/climate tech	10/10
General ML engineer	8/10
Data science	7.5/10
General software engineer	6.5/10
Web/mobile development	4/10

Because the actual skills — PyTorch, model training, profiling, spatial data pipelines, reproducible experiments — transfer quite well.

The tree-specific knowledge is niche.

The ML engineering is not.

---

There is one condition under which I would tell you to change topics

If you cannot obtain any Nepalese LiDAR.

Not just labels.

I mean no Nepal LiDAR whatsoever.

In that case, don't spend your entire final year waiting for a government agency or collaborator to send data.

Your project needs a guaranteed success path.

I would establish this rule immediately:

The thesis must be completable using open data. Nepal data must improve the thesis, not determine whether it can exist.

Fortunately that is increasingly realistic.

AerialTrees is now publicly represented with multi-platform/multi-sensor data. (github.com)

FGI-EMIT gives you another modern, manually annotated 2026 benchmark with 1,561 trees. (github.com)

You also have the older FOR-instance dataset we discussed.

So you can implement and test the complete methodology before Nepal data arrives.

---

That changes your project risk enormously

Your project can have three success levels.

Minimum successful FYP

Public datasets only:

Study the effect of self-supervised representations and density shifts on airborne-LiDAR tree segmentation.

Still a complete dissertation.

Good outcome

Public training + Nepal unlabeled LiDAR:

Self-supervised domain adaptation to Nepal.

Much stronger.

Excellent outcome

Public training + unlabeled Nepal LiDAR + a small manually segmented Nepal test set:

Low-label domain adaptation and quantitative Nepal evaluation.

That is the one I would aim for.

---

If you want something related but slightly more modern

There are three directions I would consider.

1. My first choice — 3D foundation/self-supervised model adaptation

Instead of centering your thesis on PointNet, center it on the question:

Do modern self-supervised 3D representations transfer to forest LiDAR?

For example:

$$\text{PointNet SSL from the paper}$$

versus

$$\text{PTv3}$$

versus

$$\text{Sonata-pretrained PTv3}.$$

Sonata is particularly attractive because pretrained models and code already exist; you therefore avoid trying to pretrain a huge foundation model yourself. (github.com)

Your contribution becomes forest-domain adaptation, not “I rebuilt CVPR-scale pretraining.”

This is probably my favourite option for you.

---

2. Multimodal forestry AI

Another interesting extension would be:

$$\text{LiDAR} + \text{Sentinel-2} + \text{forest-type/context data}.$$

Nepal now has a national forest-type dataset produced by FRTC and ICIMOD from Sentinel-2, field sampling and Earth-observation processing, available under CC BY 4.0. (rds.icimod.org)

This could eventually lead to:

individual tree segmentation + tree-type prediction,

or

individual tree segmentation + forest inventory/carbon attributes.

And multimodal integration is one of the future research directions explicitly identified in your uploaded paper. (Self-Supervised_Learning_for_Precise_Individual_Tree_Segmentation_in_Airborne_LiDAR_Point_Clouds.pdf)

But I would not do this in v1.

It increases data-registration and ground-truth complexity substantially.

Tree segmentation first.

Multimodality later.

---

If you really want to leave forestry completely

There's one Nepal-specific project I think competes seriously with this one:

Multimodal landslide detection / mapping for Nepal

Something along the lines of:

Domain-Robust Landslide Detection in Nepal Using Multi-Temporal Sentinel Imagery, Terrain Data and Foundation Models

Why I like it:

• Sentinel imagery is open.
• DEMs are open.
• Nepal-specific landslide datasets exist.
• The societal relevance is very strong.
• Data acquisition risk is far lower than airborne LiDAR.

For example, ICIMOD released a 2024 Koshi Basin landslide inventory in 2026 under CC BY 4.0, created using automated detection followed by manual quality control. (rds.icimod.org)

There is also an open Nepal landslide inventory covering 2010–2021. (zenodo.org)

And ICIMOD/NASA currently operate Nepal landslide hazard products using soil moisture, observed/forecast precipitation and machine-learning models. (threddsdataserver.icimod.org)

So in terms of data availability + Nepal relevance + likelihood of completing the FYP cleanly, landslides arguably beat tree LiDAR.

---

If I scored the choices today

These scores are my judgment rather than objective measurements.

Project	Research value	Data feasibility	Technical depth	Distinctiveness	FYP risk	Overall
Reimplement original SSL tree paper	6	6	8	6	Medium	6.5/10
Your current broad Nepal title	9	4	10	9	Very high	7/10
Modern low-label/SSL Nepal LiDAR project	9	7	9	9	Medium	9/10
3D foundation-model transfer for Nepal forestry	10	7	10	10	Medium-high	9/10
Multimodal LiDAR + imagery forestry	9	5	10	9	High	7.5/10
Nepal landslide detection/EO project	8.5	10	8	8	Low-medium	9/10
Generic LLM/RAG application	5	10	5	3	Low	5.5/10

So there are really two choices I would put at the top.

---

Option A — more ambitious and more distinctive

Self-Supervised 3D Representation Learning for Low-Label Individual Tree Segmentation in Nepalese Airborne LiDAR

Do this if you enjoy:

• ML research,
• 3D vision,
• PyTorch,
• mathematical models,
• experiments,
• remote sensing.

This has the greater research upside.

---

Option B — safer data, still strong AI

Domain-Robust Multimodal Landslide Mapping in Nepal from Earth Observation Data

Do this if you care more about:

• guaranteed completion,
• access to lots of data,
• national-scale experiments,
• satellite imagery,
• deployment/mapping.

This has the lower project risk.

---

Between those two, I would choose the tree project for you

Based solely on the direction you've already investigated, I wouldn't throw that work away to chase whatever technology is fashionable this year.

But I would pivot from:

“implement this tree-segmentation paper”

to:

“investigate whether modern self-supervised 3D representations can overcome Nepal-specific label scarcity, terrain shift, and LiDAR-density shift.”

That distinction is enormous.

The first is reproduction.

The second is research.

---

The exact FYP title I currently recommend

I would use:

Low-Label Individual Tree Segmentation in Airborne LiDAR Using Self-Supervised 3D Representations: A Study in Nepalese Forests

I prefer this over the earlier title for several reasons.

“Low-label” clearly expresses your actual motivation.

“Self-supervised 3D representations” lets you test the 2025 paper and Sonata/PTv3 rather than locking yourself into PointNet.

“Terrain and density robustness” can be your major experimental questions without making the title enormous.

“A study in Nepalese forests” is considerably more defensible than claiming a system robust across all heterogeneous Nepalese forests.

---

Your core thesis question would be one sentence

Can modern self-supervised point-cloud representations substantially reduce the amount of manually annotated Nepalese LiDAR required for accurate individual-tree segmentation while remaining robust to terrain and point-density variation?

That is specific.

It is measurable.

It is current.

It has a real research gap.

It can fail scientifically and still produce an interesting result.

And you do not need to invent a completely new neural network for it to be a good project.

---

What I would do if this were my FYP

I would commit to this topic only with one scope rule:

Don't attempt to build a new foundation model, a new segmentation architecture, a new clustering algorithm, terrain robustness, density robustness, multimodal fusion, all-Nepal generalization, and a production application simultaneously.

I would make the contribution:

$$\boxed{\text{self-supervised domain adaptation + low-label Nepal evaluation}}$$

and treat

$$\text{terrain robustness}$$

and

$$\text{density robustness}$$

as two carefully designed experiments.

The original 2025 paper becomes Baseline A, not your entire project.

Sonata/PTv3 becomes Baseline B / modern representation.

A contemporary tree segmentation model becomes Baseline C.

Nepal becomes the domain-shift problem.

And the headline result becomes a graph showing segmentation accuracy versus number of Nepalese labels.

That is the version of this idea I would be comfortable recommending as a 2026 final-year project.