Fix lidar_hd pre-transform to allow full 16-bits integer range for co… #135
Conversation
…lor/infra-red values
| @@ -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 | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
Finalement, on avait la mauvaise solution à un problème qu'on n'avait pas compris : 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 |
…lor/infra-red values
FYI @DaliCHEBBI