Reading edf files, without all restrictions of the "Klora" convention. #318
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
general header at the start of an edffile in future version. This feature is specified in the original EXPG specification. Currently, no additional features are included, only the internal order of parsing headers has been adapted. The search of the header end pattern has been improved. All existing unittests should pass as before.
when split between read buffers ("boundary")
Closed
kif
reviewed
Jun 11, 2019
| #+++++++++++++++++++++++++++++ | ||
| # PB38k20190607: ATTENTION, weird!: | ||
| # little_endian^=LowByteFirst, big_endian^=HighByteFirst | ||
| # Why should _data_swap_needed depend on bpp? |
There was a problem hiding this comment.
Hi Peter,
The code is not the right place for discussing implementation details. Please use the pull-request facility for this in order to keep the code clean an tidy.
About this topic, little- & big-endian differ only if the datatype has a length longer then 1
kif
reviewed
Jun 11, 2019
kif
reviewed
Jun 11, 2019
kif
reviewed
Jun 11, 2019
kif
reviewed
Jun 11, 2019
- global variable ROOT removed edfimage.py: - get_data_rank etc. defined as static function of class EdfFrame - function description strings updated with comment strings and latter removed - _parseheader (parseheader) renamed to _create_header. It better describes it. - _read_header_block returns a namedtuple - There are some comments left in the code. Most of them should be removed in the final version. Concerning byteswapping, there was already an issue opened for updating it (Byteswap in all cases where bpp>1 ... silx-kit#310). When this is solved the internal comment should be removed.
|
The failure on py3.4 is indeed linked to the release of lxml which was released Jun 10, 2019 |
|
We are still testing python3.4 under windows. python 3.4 makes sense on debian8 but not on windows computer where people are rather likely to use python 3.6 or 3.7. I think it is time to upgrade our appveyor policy (to be consistent with silx). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reading edf files, without assuming all restrictions of the "Klora" convention. It prepares the possibility of using a general header (see http://wikiserv.esrf.fr/bliss/index.php/ESRF_Data_Format). The following bug has been removed: A header end pattern that is split across read buffers is recognized. A test has been added (EdfBlockBoundaryCases in test_edfimage1.py). Apart from the bug-fix there no additional features have been added. All existing edf-files should be readable as before, probably with updated messages.