More ideas to prevent confusion with another Python XTF implementation?

[shamrin]

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: https://github.com/shamrin/pyxtf/issues/3#issuecomment-762267792

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: https://github.com/shamrin/pyxtf/pull/5

Please let me know if I could do more :)

[oysstu]

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]

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]

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]

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.