Random line strange behavior

[Fernando Bordignon]

Hi guys, I am having a problem when trying to show a random line from contents of a 3D volume.

The problem is that I get the data corresponding to random line positions from the 3D volume, process it, and write the result in another empty volume.

When I show the random line of the results cube, the visualization shows a lot of undefined columns of data, but the data is there on the 3D volume. Here it is an image of what I am describing:

In this scene there is a z-slice and a random line limited to one sample in Z. Both are in the same AI scale for undef transparency.

Another example where the random line crosses right through a data point and undef is reported.

Here you can see the white line of the random line track.

Anyhow, I can probably do what I want to do using an approach similar to what the attribute engine does, but I've noticed some problems like this when using a full dense volume of data.

This is the global view of my random line with the glitches:

I'm using the same code as of Seis/seisrandlineto2d.cc to get the data and calculate the positions to set the results.

Thanks in advance for suggestions,

Fernando Bordignon.

[Fernando Bordignon]

Hi, I've looked into this problem once more today.

I've come to the conclusion that the function void RandomLine::getPathBids at line 303 of Geometry/randomlinegeom.cc is flawed.

Almost the same functionality is accomplished by the constructor of SeisRandLineTo2D::SeisRandLineTo2D at line 29 of Seis/seisrandlineto2d.cc

I suggest replacing the code at getPathBids by the code in the constructor of SeisRandLineTo2D. After that, use the corrected getPathBids function to perform the functionality at the constructor, improving code maintenance by reducing redundancy.

I am almost certain of this, because when I create a 2D line from the random line - by right clicking at the random line and saving it as 2D - the results are as expected when viewing the 2D line at the 2D Viewer.

But when I use the 2D Viewer to show directly the randomline and selecting the cube as input, the results are the ones I've been noticing.

This problem occurs at all OD volumes, but when the volume is dense, wrong traces were being shown giving the impression everything was fine.

I do not have the OD environment set up here to correct and compile the fix myself, but I am available to discuss this further at any time.

2D line saved from random line:

Random Line displayed directly at the 2D Viewer:

[Fernando Bordignon]

Sorry, for the images. Here it goes again.

2D line saved from random line:

Random Line displayed directly at the 2D Viewer:

[Raman Singh]

Hi Fernando,

There is a fundamental difference between the two code blocks you referred to. In OpendTect, the positions on a Random line are snapped to the nearest BinIDs. This makes life easier for developers while extracting Seismic traces or interpretation data. But it comes with a drawback that the distances between adjacent positions are not consistent because of the snapping. This sometimes results in gaps in 2D viewer as seen in your snapshots. We are trying to find a way to solve this display issue.

On the other hand, when we convert a Random line into a 2D line, we create new trace positions with regular spacing. Ideally, the seismic data should be interpolated to extract data exactly at these new positions, but as of now we are just extracting traces from the nearest BinIDs. Because of the regular spacing between trace positions, when you display the 2D line in 2D viewer, you do not see any gaps.

Best regards,

Raman K Singh

Manager Software Development

______________________________

dGB Earth Sciences, India
Phone:	+91 22 25704984
E-mail:	raman...@dgbes.com
Internet:	dgbes.com

SEG Distinguished Achievement Award 2016
______________________________

[Fernando Bordignon]

Hi Raman, thanks for your reply.

I now understand that the methods must do different things, but for the time they are doing the same stuff minus the trace coordinates for the 2D section.

Perhaps the problem is at the snapping, because the "gaps" are actually wrong snaps. Even when using a volume with data in every cell, we can see wrong traces being shown at the 3D random line visualization. 

This is evident when comparing a random line with a z-slice both on classification texture - bear with me through one more snapshot at the end of the email.

Anyhow, I will find some time to compile OD and contribute with the project. 

Thanks, Fernando.

[Raman Singh]

Hi Fernando,

I did not quite understand the image you sent, but let me try to clarify things further with the help of the image I attached here.
- The grid lines are the inlines and crosslines. If you join the blue dots you would get the random line as seen in the 3D scene.
- The blue dots are actually the trace positions in the resulting 2D line if you save the random line as 2D.
- The red squares are the positions (BinIDs) where the seismic traces are extracted to display on the random line.

As you can see, the red squares follow a zig-zag pattern as they coincide with the exact BinIDs. The distance between two consecutive red squares is not consistent which results in the white patches you see in the 2D viewer. We have fixed this display issue now and the fix will be available in the patch v6.2.4.

Best regards,
Raman

--
You received this message because you are subscribed to the Google Groups "OpendTect Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.
To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.
To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/e79f34eb-7ca6-4268-ad70-4657761ec945%40opendtect.org.
For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

[Fernando Bordignon]

Raman, thanks for the image. It does a good job clarifying the issue.

We are talking about the same thing. My point is that the way the function Geometry::RandomLine::getPathBids actually compute the red squares of your image is a bit off.

Take a look of these two more prints:

1- BinIDs (your red squares) gotten from Geometry::RandomLine::getPathBids shown on a zslice with the corresponding randomline in yellow (your blue squares joined)

2- BinIDs gotten using the code on the constructor SeisRandLineTo2D

1 and 2 are exactly in the same position of the scene, please download the images and flip them to see the difference.

I've limited the display of the randomline to one vertical sample and the BinIDs are traces that I've written on a 3D volume, showing only a zslice with AI color table for undef transparency.

In my opinion, image 2 is the correct mapping of our blue to red squares, because the randomline interception with the resulting BinIDs is better, i.e. the randomline intercept less empty bids.

I've also made a simple plugin that calculates the bids using a randomline with 2 nodes, wrote the results on a text file and used matlab to plot the bids from both methods. I've also computed the average distance from the bids to the randomline.

The average distance of the bids to the randomline calculated with Geometry::RandomLine:getPathBids is 1.2006 and with  SeisRandLineTo2D code is 1.137. This proves my point that the bids calculated from SeisRandLineTo2D are closer to the randomline.

Thanks,

Fernando.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.
To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/e79f34eb-7ca6-4268-ad70-4657761ec945%40opendtect.org.
For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OpendTect Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/opendtect.org/d/topic/developers/1AbBe8L5qRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to developers+unsubscribe@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/79e000c0-97a3-8dd2-ed01-f20cb2e00970%40dgbes.com.

[Raman Singh]

Hi Fernando,

Snapping to the nearest BinIDs is expected to give errors. Using the SeisRandLineTo2D code would actually generate more points and could result in lower overall error, but what I do not expect is a wrong snap. That would indeed mean we need to improve the code in Geometry::RandomLine::getPathBids function to snap to better/closer BinIDs. Could you please send me your random line? You can just send me the corresponding .rdl file from the Locations folder of your survey. I also need the .survey file unless you are using F3_Demo.

Thanks in advance.

Cheers,
Raman

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/CAAPEE1B441wRyzuv0Ugm%2BWmF_pekmm014503J5VSRxe61pd_4Q%40mail.gmail.com.

[Raman Singh]

Hi Fernando,

There was indeed a loss of precision in snapping the positions of some Random Lines to the nearest BinIDs. We have fixed that now. Thanks a lot for bringing this up and providing the relevant test data.

Cheers,
Raman

On 03/17/2018 07:57 PM, Fernando Bordignon wrote:

Raman, thanks for the image. It does a good job clarifying the issue.

We are talking about the same thing. My point is that the way the function Geometry::RandomLine::getPathBids actually compute the red squares of your image is a bit off.

Take a look of these two more prints:

1- BinIDs (your red squares) gotten from Geometry::RandomLine::getPathBids shown on a zslice with the corresponding randomline in yellow (your blue squares joined)

<See image in previous email>

2- BinIDs gotten using the code on the constructor SeisRandLineTo2D

<See image in previous email>

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/CAAPEE1B441wRyzuv0Ugm%2BWmF_pekmm014503J5VSRxe61pd_4Q%40mail.gmail.com.

[Fernando Bordignon]

Thank you, Raman. I'm glad I could help. Sorry if I was not very clear at first.

Fernando. 

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/e79f34eb-7ca6-4268-ad70-4657761ec945%40opendtect.org.
For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OpendTect Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/opendtect.org/d/topic/developers/1AbBe8L5qRs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to developers+...@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/79e000c0-97a3-8dd2-ed01-f20cb2e00970%40dgbes.com.

For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpendTect Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@opendtect.org.
To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.
To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/CAAPEE1B441wRyzuv0Ugm%2BWmF_pekmm014503J5VSRxe61pd_4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/a/opendtect.org/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "OpendTect Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/opendtect.org/d/topic/developers/1AbBe8L5qRs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to developers+...@opendtect.org.

To post to this group, send email to devel...@opendtect.org.
Visit this group at https://groups.google.com/a/opendtect.org/group/developers/.

To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/developers/987a45ff-4f76-7183-be65-f70d1f0d3c62%40dgbes.com.