You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LiGuard is a GUI for pointcloud and camera data processing pipelines. It is configured by yaml files and uses open3Ds gui framework and also relys on opencv. It offers build in functions for processing and allows addition of custom functions. The use case is data processing pipelines for researchers. They claim that: "This dynamic design facilitates users in focusing on researching novelties rather than the intricacies of feature-complete software development". Why would researchers focus on feature-complete software develoment? I can understand that some prefer a GUI based workflow, but researchers are indeed focused on "researching novelties" which can be done with existing packages, tools and workflows. Maybe if the authors frame it differently it would find its audience, but I doubt that it will get traction in their indented audience of research in the field of "robotics, autonomous driving, traffic monitoring, infrastructure inspection, and many areas of environmental surveying and mapping".
The authors also fail to mention PDAL which also has a pipeline functionality based on JSON configurations https://pdal.io/en/2.4.3/pipeline.html. What does LiGuard offer compared to PDAL?
The sentence that the pointcloudset is a Python package that "...can be imported to custom, ofter hard-coded scripts thus imposing limitations on reusability and scalability" is wrong. That is the strenght of any Python package that it can be used however it is needed, in scripts, jupyter notebooks, web apps, desktop apps, in the cloud or however. Is for expample pandas limited to hardcoded scripts, and not reusable and scalable because it is a Python package? Specificly pointloudset uses dask and therefore can scale to huge clusters, wheras a GUI programm such as LiGuard can not.
Also the paper needs to cite the Robot Operating System as it is closely related to their main usecase. Both ROS and open3D offer also GUIs, which is not mentioned. A section on how to solve the same problem in ROS is needed, and how their approach offers some advantage.
Lidar files are only supporded in the format of .bin and .npy which is for individual point clouds. ROS bag files are not mentioned and seems like they are not supported. Therefore, LiGuard only supports processing of individual point cloud files in bulk. How for example, would you find out the max value of x in all your point clouds?
References: The missing dois need to be fixed and ROS and PDAL needs to be cited.
Overall I recommend rejection, as the overall premise that LiGuard is more modular and reusable than existing solutions for researcher is wrong and key state of the art solutions like ROS an PDAL are not mentioned. Also LiGuard is not scalable as they inderectly claim, as it is a single thread GUI application. An in my opinion more powerful approach would be to develop processing step interactively with a Jupyter notebook and then run a script over large bulk datasets in parallel on cluster using pointcloudset, or just use PDAL, open3d and pyntcloud. Or if you are more familiar with ROS use RViz, Foxglove together with Python nodes. If the authors reframe the whole story and improve the state of the art and statement of need completely it might still be ok.
Line 24: bulk data - pointcloud time series or pointclouds over time
Software
I could not test it on my mac with M1Pro. The requirements installed fine, but when trying the run $python main.py
I get: 93263 segmentation fault python main.py
The installation is not via a package managment solution.
The tests run successfully on my mac, but do not test the gui itself.
General checks
Contribution and authorship: only one commit from a previouse private git repo. Therefor it is impossible to check the contributions.
Substatial effort: doe to the missing git commit history it is hard to judge how many authors and commits have been involved.
The text was updated successfully, but these errors were encountered:
openjournals/joss-reviews#6751
Major Coments
LiGuard is a GUI for pointcloud and camera data processing pipelines. It is configured by yaml files and uses open3Ds gui framework and also relys on opencv. It offers build in functions for processing and allows addition of custom functions. The use case is data processing pipelines for researchers. They claim that: "This dynamic design facilitates users in focusing on researching novelties rather than the intricacies of feature-complete software development". Why would researchers focus on feature-complete software develoment? I can understand that some prefer a GUI based workflow, but researchers are indeed focused on "researching novelties" which can be done with existing packages, tools and workflows. Maybe if the authors frame it differently it would find its audience, but I doubt that it will get traction in their indented audience of research in the field of "robotics, autonomous driving, traffic monitoring, infrastructure inspection, and many areas of environmental surveying and mapping".
The authors also fail to mention PDAL which also has a pipeline functionality based on JSON configurations https://pdal.io/en/2.4.3/pipeline.html. What does LiGuard offer compared to PDAL?
The sentence that the pointcloudset is a Python package that "...can be imported to custom, ofter hard-coded scripts thus imposing limitations on reusability and scalability" is wrong. That is the strenght of any Python package that it can be used however it is needed, in scripts, jupyter notebooks, web apps, desktop apps, in the cloud or however. Is for expample pandas limited to hardcoded scripts, and not reusable and scalable because it is a Python package? Specificly pointloudset uses dask and therefore can scale to huge clusters, wheras a GUI programm such as LiGuard can not.
Also the paper needs to cite the Robot Operating System as it is closely related to their main usecase. Both ROS and open3D offer also GUIs, which is not mentioned. A section on how to solve the same problem in ROS is needed, and how their approach offers some advantage.
Lidar files are only supporded in the format of .bin and .npy which is for individual point clouds. ROS bag files are not mentioned and seems like they are not supported. Therefore, LiGuard only supports processing of individual point cloud files in bulk. How for example, would you find out the max value of x in all your point clouds?
References: The missing dois need to be fixed and ROS and PDAL needs to be cited.
Overall I recommend rejection, as the overall premise that LiGuard is more modular and reusable than existing solutions for researcher is wrong and key state of the art solutions like ROS an PDAL are not mentioned. Also LiGuard is not scalable as they inderectly claim, as it is a single thread GUI application. An in my opinion more powerful approach would be to develop processing step interactively with a Jupyter notebook and then run a script over large bulk datasets in parallel on cluster using pointcloudset, or just use PDAL, open3d and pyntcloud. Or if you are more familiar with ROS use RViz, Foxglove together with Python nodes. If the authors reframe the whole story and improve the state of the art and statement of need completely it might still be ok.
Specific comments
use "lidar" typing: see https://lidarmag.com/wp-content/uploads/PDF/LiDARNewsMagazine_DeeringStoker-CasingOfLiDAR_Vol4No6.pdf
Line 24: bulk data - pointcloud time series or pointclouds over time
Software
I could not test it on my mac with M1Pro. The requirements installed fine, but when trying the run $python main.py
I get: 93263 segmentation fault python main.py
The installation is not via a package managment solution.
The tests run successfully on my mac, but do not test the gui itself.
General checks
Contribution and authorship: only one commit from a previouse private git repo. Therefor it is impossible to check the contributions.
Substatial effort: doe to the missing git commit history it is hard to judge how many authors and commits have been involved.
The text was updated successfully, but these errors were encountered: