Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Deal with wiggle traces #7

Open
kwinkunks opened this issue Sep 23, 2015 · 1 comment
Open

Deal with wiggle traces #7

kwinkunks opened this issue Sep 23, 2015 · 1 comment

Comments

@kwinkunks
Copy link
Member

Possibly very hard indeed. Here's a real challenge...

https://files.slack.com/files-pri/T02SXUB1V-F0B6AL89X/pasted_image_at_2015_09_23_09_10_am.png

(private image shows scanned seismic data with wiggle traces.)

@EvanBianco
Copy link
Collaborator

FWIW, I’ve seen a whack of TIFFs digitized by other companies, (who knows who), who end up making the equivalent of 30 some odd “traces” for each wiggle trace. It’s the notion that they aren’t actually digitizing the wiggle function values, but rastering the image straight up. I’m inclined to think that doing a sparse decimation of the images at the exact trace location (at the zero crossing of the wiggle) would achieve essentially a two bit image (black or white), but that time series would more like variable density than oversampling. One would have to deal with the vertical lines, perhaps by slightly offsetting. In sum, I don’t think anyone actually “digitizes” seismic data properly (is hard), rastering a wiggle plot…sure. It occurs to me instead of dealing with all the lines and wiggles when digitizing, maybe better to smooth the image (2Dconv) once digitized? And then take every 30th “trace”.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants