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

file format version and theta readers #20

Closed
decarlof opened this issue Apr 30, 2019 · 11 comments
Closed

file format version and theta readers #20

decarlof opened this issue Apr 30, 2019 · 11 comments
Labels
enhancement New feature or request

Comments

@decarlof
Copy link
Member

Would it make sense to move the loadThetas code:

            hFile = h5py.File(self.directory+'/'+self.arrayData[i].filename)
            extra_pvs = hFile['/MAPS/extra_pvs']
            self.idx = np.where(extra_pvs[0] == thetaBytes)
            if len(self.idx[0]) > 0:
                self.arrayData[i].theta = float(extra_pvs[1][self.idx[0][0]])

and

            hFile = h5py.File(self.directory+'/'+self.arrayData[i].filename)
            self.arrayData[i].theta = float(hFile[img_tag]['theta'].value)

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.

@decarlof decarlof added the enhancement New feature or request label Apr 30, 2019
@decarlof
Copy link
Member Author

decarlof commented May 1, 2019

I added a read_theta the reader.py to help in the process

@FabricioSMarin
Copy link
Collaborator

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.

@decarlof
Copy link
Member Author

decarlof commented May 2, 2019

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?

@decarlof
Copy link
Member Author

decarlof commented May 3, 2019

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.

@decarlof
Copy link
Member Author

decarlof commented May 3, 2019

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
Core reference
X-ray Tomography
....
a new menu:

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.

@FabricioSMarin
Copy link
Collaborator

It seems 'version' is only required to determine the theta location, correct?

That and to determine which drop-down menu options to set and/or disable under the first tab.

@decarlof
Copy link
Member Author

decarlof commented May 6, 2019

thanks, I missed that!

@FabricioSMarin
Copy link
Collaborator

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.

@decarlof
Copy link
Member Author

decarlof commented May 6, 2019

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.

@dgursoy
Copy link

dgursoy commented May 6, 2019

+1

decarlof added a commit that referenced this issue May 10, 2019
@decarlof
Copy link
Member Author

closed (see this pull request)

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

No branches or pull requests

3 participants