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

gdal_edit.py changes byte order from 0 to 1 on ENVI Float32 files #1796

Closed
S0sh0rt opened this issue Aug 21, 2019 · 7 comments
Closed

gdal_edit.py changes byte order from 0 to 1 on ENVI Float32 files #1796

S0sh0rt opened this issue Aug 21, 2019 · 7 comments
Milestone

Comments

@S0sh0rt
Copy link

@S0sh0rt S0sh0rt commented Aug 21, 2019

I am working with ENVI files of Sentinel-1 SAR data created with SNAP. They are type=Float32 with byte order = 1. Running a command similar to this:
gdal_edit.py -a_ullr 102 -15 103 -16 Beta0_VH.img
to adjust the georeferencing also, incorrectly changes the byte order header parameter to 0. However, the file data is not byte reordered.

Expected behavior: no change to byte order header parameter

Actual behavior: byte order header parameter changed from 1 to 0.

Operating system

CentOS 6 and 7, AMD and Intel

GDAL version and provenance

1.11 from CentOS EPL, 2.2.4 build from source, and 3.0.1 build from source

@rouault

This comment has been minimized.

Copy link
Member

@rouault rouault commented Aug 21, 2019

Isn't it the reverse case ? Apparently the ENVI driver always generate file with byte order = 0 (meaning Intel order) on Intel platforms, which is incorrect when updating a file whose byte order = 1 initially.

@rouault

This comment has been minimized.

Copy link
Member

@rouault rouault commented Sep 3, 2019

@S0sh0rt ping w.r.t above question

@rouault

This comment has been minimized.

Copy link
Member

@rouault rouault commented Sep 9, 2019

Closing due to lack of feedback. Please reopen if you can provide more

@rouault rouault closed this Sep 9, 2019
@S0sh0rt

This comment has been minimized.

Copy link
Author

@S0sh0rt S0sh0rt commented Sep 10, 2019

Evidently SNAP on Linux produces ENVI files with byte order 1 on Intel Linux servers. The files display correctly and other software correctly displays the files.
The issue here is that gdal_edit.py arbitrarily changes the byte order code to 0 when the operation is to only adjust the geocoordinates. The byte order of the file is not changing, just the geocoordinates, so changing the code to 0 is incorrect. @rouault

@rouault

This comment has been minimized.

Copy link
Member

@rouault rouault commented Sep 10, 2019

I cannot reproduce a change of byte order from 0 to 1 when using gdal_edit.py. Can you attach the original dataset (or anyone with which you could reproduce the issue?)
hum: I assumed that you were running a Intel compatible machine (or a CPU with little endian order), but if you run a CPU with big endian order, then that might explain it.

@rouault rouault reopened this Sep 10, 2019
@S0sh0rt

This comment has been minimized.

Copy link
Author

@S0sh0rt S0sh0rt commented Sep 10, 2019

I apologize for the confusion. After reading this again, I see that it is not obvious that it is just the ENVI header parameter: "byte order = 1" that is changed to 0, and not the byte order of the file that is changed. I also must have initially reported the byte order parameter reversed (0=>1 instead of 1=>0)). I have corrected my initial comments above.
The problem can be reproduced by editing any ENVI file *.hdr and changing the byte order parameter to 1, then run: gdal_edit.py -a_ullr 50.1 36.8 50.2 36.7 test.dat, which will result in byte order header parameter changed to 0, without the byte order of the data file being changed.
The image data in the attached file is byte order 0, and therefore will not display correctly with byte order set to 1 as delivered in the zip file below. The dataset is provided to just to reproduce the issue with the ENVI header file byte order incorrectly being changed by gdal_edit.py from 1 to 0.
test.zip

@S0sh0rt

This comment has been minimized.

Copy link
Author

@S0sh0rt S0sh0rt commented Sep 10, 2019

I just tested using GDAL 2.4 in Cygwin on my Windows desktop. The effect is the same. gdal_edit.py changed the byte order parameter from 1 to 0, although the data was not reordered.

@rouault rouault closed this in 71cd2bf Sep 14, 2019
rouault added a commit that referenced this issue Sep 14, 2019
rouault added a commit that referenced this issue Sep 14, 2019
@rouault rouault added this to the 2.4.3 milestone Sep 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.