-
Notifications
You must be signed in to change notification settings - Fork 31
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
zgy_writer #117
Comments
this code works. I would like to be able to set a compressor and lodcompressor Does anyone have a syntax for using the compressor arguments to Writer ? |
Thanks for your feedback. Ideally this code needs to be migrated to use You can see the openzgy code in the Otherwise:
To change the output datatype, in the segysak code you could add additional checks for the |
Hi Tony,
Thanks for the info. I did modify your code for the datatype and datarange
and it works. I was wondering how to go even further but it looks
compression only is available for float datatype.
Anyway I shared my modif on GitHub.
Note: I am using octave and multi threading to read segy files and netcdf
as storage. Writing goes mulch faster precasting the headers as uint32
swapping bytes correctly first.
Thanks again. Good work.
On Thu, May 25, 2023 at 03:32 Tony Hallam ***@***.***> wrote:
Thanks for your feedback.
Ideally this code needs to be migrated to use pyzgy on the backend and as
a natural xarray backend
<https://docs.xarray.dev/en/stable/internals/how-to-add-new-backend.html>
but that is low priority with focus being SEGY.
You can see the openzgy code in the pyzgy library which is a fork of the
code from the OSDU implementation
<https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-zgy/-/tree/master/python/openzgy>.
It also uses the Python API reference implementation which does not
natively support compression. Additional instructions must be followed on
their website to install the ZFP compressor.
Otherwise:
- blocks are [64,64,64] by default.
- references to output type are given here
<https://github.com/equinor/pyzgy/blob/36c8f4d640dd03510ca47569b8b36eaca0104334/openzgy/api.py#L138>
To change the output datatype, in the segysak code you could add
additional checks for the datatype to select the correct format to output
to ZgyWriter.
—
Reply to this email directly, view it on GitHub
<#117 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZG2VEB4DWZBSG7EYR2ZR33XH4KJTANCNFSM6AAAAAAYLDB3OY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Vincent Favreau.
|
@ksurf1 depending on your aims here, you may find converting your SEG-Y files to either the fully opensource seismic-zfp or Bluware's nearly-open compressed VDS format helps you further with disk space. Either of these could be read through segysak (writing would take effort) since they have segyio-like reading syntax available (pyvds for VDS). However, if you have more than half the volume as a constant value you'd win more from ZGY/VDS than seismic-zfp as the latter favours regularity in the data over identifying constant-value bricks in order to make offsets computable rather than requiring a disk location lookup for bricks. |
Hi Tony,
Openvds is a possibility but I don’t get requests yet. I am aware of the
tools to create such files. Segy is the go to for archiving anyway. Zgy is
for petrel users.
Thanks for your time. How do I follow future developments ?
On Sun, May 28, 2023 at 01:35 David Wade ***@***.***> wrote:
@ksurf1 <https://github.com/ksurf1> depending on your aims here, you may
find converting your SEG-Y files to either the fully opensource seismic-zfp
or Bluware's nearly-open compressed VDS format helps you further with disk
space. Either of these could be read through segysak (writing would take
*effort*) since they have segyio-like reading syntax available (pyvds for
VDS). However, if you have more than half the volume as a constant value
you'd win more from ZGY/VDS than seismic-zfp as the latter favours
regularity in the data over identifying constant-value bricks in order to
make offsets computable rather than requiring a disk location lookup for
bricks.
—
Reply to this email directly, view it on GitHub
<#117 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Vincent Favreau.
|
Hi Tony,
I have a segy with a group scalar of -100 in bytes 71. This means the XYs
must be divided by 100 to get a float from uint32.
When I check the corners, they are all nan. I tried the defaults for cdpx
cdpy, same result. I know my segy is correct and the byte positions are
correct.
Solution ?
Python code
from segysak.segy import segy_loader, well_known_byte_locs, segy_writer
fn = "path2segy.segy"
ds = segy_loader(fn, iline=189, xline=193, cdpx=73, cdpy=77, offset=None)
ds.seis.calc_corner_points()
corners = tuple(ds.corner_points_xy[i] for i in [0, 3, 1, 2])
print(corners)
((nan, nan), (nan, nan), (nan, nan), (nan, nan))
…On Sun, May 28, 2023 at 1:35 AM David Wade ***@***.***> wrote:
@ksurf1 <https://github.com/ksurf1> depending on your aims here, you may
find converting your SEG-Y files to either the fully opensource seismic-zfp
or Bluware's nearly-open compressed VDS format helps you further with disk
space. Either of these could be read through segysak (writing would take
*effort*) since they have segyio-like reading syntax available (pyvds for
VDS). However, if you have more than half the volume as a constant value
you'd win more from ZGY/VDS than seismic-zfp as the latter favours
regularity in the data over identifying constant-value bricks in order to
make offsets computable rather than requiring a disk location lookup for
bricks.
—
Reply to this email directly, view it on GitHub
<#117 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
----------------------------------------------------------
Vincent FAVREAU
*"No one can make you feel inferior without your permission."~Eleanor
Roosevelt*
|
The ds variable seems ok in terms of il xl dimensions but the coordinates ?
Type: DatasetString form:
<xarray.Dataset>
Dimensions: (iline: 1234, xline: 1875, twt: 1001)
Coordinates:
* iline (il <...> None
percentiles: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
coord_scalar: -100.0
…On Tue, May 30, 2023 at 8:44 AM vincent favreau ***@***.***> wrote:
Hi Tony,
I have a segy with a group scalar of -100 in bytes 71. This means the XYs
must be divided by 100 to get a float from uint32.
When I check the corners, they are all nan. I tried the defaults for cdpx
cdpy, same result. I know my segy is correct and the byte positions are
correct.
Solution ?
Python code
from segysak.segy import segy_loader, well_known_byte_locs, segy_writer
> fn = "path2segy.segy"
> ds = segy_loader(fn, iline=189, xline=193, cdpx=73, cdpy=77, offset=None)
ds.seis.calc_corner_points()
> corners = tuple(ds.corner_points_xy[i] for i in [0, 3, 1, 2])
> print(corners)
((nan, nan), (nan, nan), (nan, nan), (nan, nan))
On Sun, May 28, 2023 at 1:35 AM David Wade ***@***.***>
wrote:
> @ksurf1 <https://github.com/ksurf1> depending on your aims here, you may
> find converting your SEG-Y files to either the fully opensource seismic-zfp
> or Bluware's nearly-open compressed VDS format helps you further with disk
> space. Either of these could be read through segysak (writing would take
> *effort*) since they have segyio-like reading syntax available (pyvds
> for VDS). However, if you have more than half the volume as a constant
> value you'd win more from ZGY/VDS than seismic-zfp as the latter favours
> regularity in the data over identifying constant-value bricks in order to
> make offsets computable rather than requiring a disk location lookup for
> bricks.
>
> —
> Reply to this email directly, view it on GitHub
> <#117 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
----------------------------------------------------------
Vincent FAVREAU
*"No one can make you feel inferior without your permission."~Eleanor
Roosevelt*
--
----------------------------------------------------------
Vincent FAVREAU
*"No one can make you feel inferior without your permission."~Eleanor
Roosevelt*
|
I've moved your second issue to #119 please put separate questions in separate issues. |
Hi, great job on the segysak package !
It might not be the best venue to write this since it is not a real issue with the existing code.
I would like to harvest the ZGY compression options and write 16bit ZGY files.
Having worked in the past with ZGY files on the development side, there are variable like bias and factor to set in the metadata in order to be able to write data as int16 or int8. (float32 = int16*factor+bias). Also there is a "brick" size which is by default [64,64,64] to compress the data: if all the data values are identical in one brick, only one value is dumped to disk not 64^3. This compresses the file size a lot when portion of the data is 0.0 for instance.
Right now your code writes data as float32 uncompressed if I am not mistaken.
Can you give me some pointers to modify your code to achieve the best compression possible ?
Much obliged.
Would this work in your code ?
V
The text was updated successfully, but these errors were encountered: