Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix lidar_hd pre-transform to allow full 16-bits integer range for co… #135

Closed
wants to merge 1 commit into from
Closed

Fix lidar_hd pre-transform to allow full 16-bits integer range for co… #135

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
# CHANGELOG

- Fix lidar_hd pre-transform to allow full 16-bits integer range for color/infra-red values
- Add a github action workflow to run a trained model on the lidar-prod thresholds optimisation dataset
(in order to automate thresholds optimization)

Expand Down
5 changes: 4 additions & 1 deletion myria3d/pctl/points_pre_transform/lidar_hd.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@
import numpy as np
from torch_geometric.data import Data

# COLORS_NORMALIZATION_MAX_VALUE should be 2**16 - 1 to match 16-bits integers full range
# It is currently kept to its initial value of 255 * 256 to prevent having to retrain (as it
# is used to normalize the color channels), while being able to run with saturated IR pixels.
# Todo: update COLORS_NORMALIZATION_MAX_VALUE in next training campaigns.
COLORS_NORMALIZATION_MAX_VALUE = 255.0 * 256.0
RETURN_NUMBER_NORMALIZATION_MAX_VALUE = 7.0

Expand Down Expand Up @@ -29,7 +33,6 @@ def lidar_hd_pre_transform(points):
)

for color in ["Red", "Green", "Blue", "Infrared"]:
assert points[color].max() <= COLORS_NORMALIZATION_MAX_VALUE
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C'est quoi la raison pour supprimer cette vérification ?

Et puisque les couleurs sont limitées sur 16bits, peut-être que si on change les choses pour un réentrainement on peut aussi envisager de changer la ligne 42: dtype=np.float32 en dtype=np.float16 ? Histoire de gagner un peu en mémoire.

Il ne faudrait pas oublier de faire la même manip côté lidar-prod par contre

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finalement, on avait la mauvaise solution à un problème qu'on n'avait pas compris :
COLORS_NORMALIZATION_MAX_VALUE vient de la façon qu'on a de stocker la colorisation dans le las : c'est une couleur en 8-bits qui est multipliée par 256 (cf. IGNF/ign-pdal-tools#64), donc cette assertion vérifie qu'on n'a pas eu de problème de colorisation.

Pour le fait de changer le type, je préfère ne pas y toucher dans l'immediat pour ne pas nécessiter de nouveaux entraînements et des changements dans d'autres codes

points[color][:] = points[color] / COLORS_NORMALIZATION_MAX_VALUE
points[color][occluded_points] = 0.0

Expand Down