-
Notifications
You must be signed in to change notification settings - Fork 6
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
file format version and theta readers #20
Comments
I added a read_theta the reader.py to help in the process |
That makes sense, I'll give it a try and report back with concerns or questions. Do we have 13 xfluo data that we can test with? 'version' is currently determined by whether or not the path 'exchange_x' exists, so it doesn't actually make use of the value associated with version. We would have to move version up one directory or put it in 'MAPS' since MAPS is in all h5 files. I agree though, extending version to represent a file format version/type is a good idea. |
13 data are here; OK regarding 'version'. I will use the same logic when using it for now. It seems 'version' is only required to determine the theta location, correct? |
From Stefan: I would strongly recommend saving version info. If you start now, just call it 1.0. If the version tag is missing, you can call it internally 0.x, where you enumerate x depending on exchange_x or other features of the file. |
Once is decided is also important to document the file format. I maintain the data exchange documentation for tomography here . An idea could be to add on the same web page under: Introduction X-ray Fluorescence For now, I added a space holder web page here to host the X-ray Fluorescence file format documentation. To edit, feel free to fork and submit a pull request to the dxfile repository. |
That and to determine which drop-down menu options to set and/or disable under the first tab. |
thanks, I missed that! |
I’m working on moving ‘loadThetas’ over to reader.py and I just want to make sure I’m understanding things correctly. Is reader.py responsible for handling multiple file formats (ex, different beam-lines) or should the converting process be done elsewhere? Once we have ‘version’ defined correctly, the version number can be used to call the appropriate ‘load___’ function for the specific beam-line. |
For now my suggestion would be to make the reader.py responsible for handling all multiple file formats and make the rest of the code file format independent. At one point in the future we may think of splitting the reader.py in a low level (direct handling of different files) and and higher level (beamline/instrument specific formatting) similar to reader.py and exchange.py of dxchange but this will depend largely on how big our reader.py turns to be. This is also in line with this suggestion. |
+1 |
closed (see this pull request) |
Would it make sense to move the loadThetas code:
and
from file_table.py to the reader.py module?
This way we can use the same table/gui with different file formats (I am thinking of 13 xfluo data etc.) by simply extending "version" (now just True or False) to the actual file format version/type.
The text was updated successfully, but these errors were encountered: