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.

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

More ideas to prevent confusion with another Python XTF implementation? #10

Open
shamrin opened this issue Jan 18, 2021 · 4 comments
Open

Comments

@shamrin
Copy link

shamrin commented Jan 18, 2021

I'm the author of another Python XTF implementation: https://github.com/shamrin/pyxtf

Thank you for making the library, @oysstu! If you solution existed in 2013, I would be using it, instead of making my own :)

I've noticed at least one person was confused by our similarly named repos: shamrin/pyxtf#3 (comment)

That's rather unfortunate, I would like more people to know about your library. Your implementation is more up-to-date and actively supported. I'm going to add a note in my repo to let people know about your library: shamrin/pyxtf#5

Please let me know if I could do more :)

@oysstu
Copy link
Owner

oysstu commented Jan 18, 2021

I remember seeing your library before implementing this. I seem to remember that there was a few reasons for starting a new implementation, python3 support, for example. I also had some XTF files that weren't supported by your library, and I was more comfortable with the ctypes interface at the time.

I originally named the library pyxtf3 to disambiguate and had a note in the readme pointing to your repository, but later renamed it once it started getting more use and Python2 became less relevant. Honestly, the XTF format isn't that good, and it looks like Triton has stopped updating (and hosting) the specification. Hopefully a better manufacturer-agnostic format can replace XTF at some point.

I think your suggestion about the note in your repository is good, and there is some plotting/gui code that may be helpful for someone. I want to keep this repository strictly for file I/O.

@shamrin
Copy link
Author

shamrin commented Jan 18, 2021

Creating a new library makes total sense! The ctypes approach is very interesting, I didn't know it was possible (or perhaps some of the relevant ctypes features were not yet available in 2013).

Plotting and gui are the reasons for not archiving my repo yet. I'll think about renaming the repo...

Yes, the lack of good universal format was actually one of the reasons I didn't add support for more outputs. If felt stupid Implementing direct a<->x, a<->y, a<->z conversions. Too many combinations.

It would indeed be cool to attempt designing a nice intermediary format. Probably based on Avro, with a lot of thinking about what kinds of fields to support and would they should mean. Have you looked at other side-scan related projects like MB-System? Perhaps they have thought about a common file format?

@CarvalhoResearch
Copy link

I saw that you have at least three "equal" projects.
Well, is there no way to hunt the best of each and make one? :}. I'm trying to install mb-system, but it seems very difficult.
Here are all formats (https://www3.mbari.org/data/mbsystem/html/mbsystem_formats.html#:~:text=MB%2DSystem%20Supported%20Data%20Formats&text=Hydrosweep%20DS2%20multibeam%20sonar,Hydrosweep % 20MD% 20multibeam% 20sonar & text = Simrad% 20EM12% 2C% 20EM121% 2C% 20EM950% 2C% 20and% 20EM1000% 20multibeam% 20sonars), I looked quickly and it seems to me that the only non-owner is XTF, well, really a shame that no longer supported you.

@oysstu
Copy link
Owner

oysstu commented Feb 3, 2021

Haven't looked at Avro before. I've looked at MB-system before for some of the multi-beam processing, but not for side-scan data. File formats used for logging online will naturally be based around sequential addition of packets, such as in XTF, to avoid corrupting previously collected data if the power is cut. An interchange format used for processing could be based around something like hdf5-files, for example, which is what NetCDF is based on I believe.

MB-System obviously has a lot of formats in its MBIO library. Perhaps its possible to call the functions there from python through the ctypes interface, but it's probably a huge task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants