More ideas to prevent confusion with another Python XTF implementation? about pyxtf HOT 4 OPEN

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.

from pyxtf.

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?

from pyxtf.

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.

from pyxtf.

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.

from pyxtf.