Unsmooth First break picks

[HHTC0]

Hi @DaloroAT,

In VSP view, first break pick looks much smoother when initially picked (red line). However, only can see it unsmooth when loaded back (blue line).

If you spare sometime to fix this over weekend, that would be awesome as I am in middle of project.

Regards

[HHTC0]

This is how smooth picked first break looks after reloading.

[DaloroAT]

Hey @HHTC0 !

Sorry, but I don't understand full scenario how you get such a problem. At least I can't reproduce such a problem on SGYs that I have. Could you describe it in more details?

Btw, for picks you have Byte, Encoding and Units fields when you load and save them. So, 1) make sure that both 3 fields are the same when loading and saving. 2) if you have another software to load or save, ensure it follows the same encoding. 3) if you save picks to default headers (lag time A, B, whatever), make sure that you follow default encoding for such headers to properly load them later in professional software.

Otherwise, you can spoil values (truncate, crop, change dynamic range, etc).

[HHTC0]

Appreciate it, mate.

I think I found the answer. It’s because of high spatial sampling of my data. When I pick, software would let me pick between a millisecond let’s say 20.6ms however would round it off when saved to 21ms. Upon reloading the rounded off values cause the time picks look un-smoothed. Normally, softwares have milliseconds of accuracy just like this one.

However, do you think we can do anything to solve this problem?

[DaloroAT]

To be clear in further discussion and better understand the scope, you use only this project for loading and saving during this discussion, right?

[HHTC0]

Yes, that’s correct.

[HHTC0]

My data may have time picks like 26.3, 26.9, 27.4. Due to high spatial sampling less than a millisecond of difference between traces.

[DaloroAT]

20.6ms however would round it off when saved to 21ms

~Yep, you are right, it's kinda bug 😄 even if you save and load as Microseconds it's converted under the hood to milliseconds to plot. Let me fix it. Since it's done explicitly, should be easy to fix.~ UPD: Another problem.

[DaloroAT]

@HHTC0

Hmm... I dived deeper into the code and now see it was the wrong expression in the previous post. There is no such converting. At least without rounding.

The real problem is that the pick point corresponds not to a moment in time, but to a sample on the trace. Therefore, the pick will always be rounded towards the sample with the accuracy of the sampling time step.

I made “sample” the base unit because it is natural for computer vision, it does not require a sampling step (like the picking algorithm), however from a tomography point of view this might not be the best solution 😁

Ok, I will do a workaround for it.

[DaloroAT]

Please, check version 6.0.2 https://github.com/DaloroAT/first_breaks_picking/releases

[HHTC0]

Legend! All problem solved.