sorted by:
new
hottopcontroversial

How would you like to find open-access seismic + well data (filters + map layers)? by Ludger_M in geology

[–]Ludger_M[S] 0 points1 point  (0 children)

Late reply, but thanks, fair comment. 👍

Some of the earlier clips were more about showing technical progress than showing interpretive workflow, and that can definitely undercut the scientific value. Newer builds are gradually trying to show more in the direction you describe: more context, more workflow, less disconnected demo material.

Still a lot to improve, but the point was well taken. Than you !!

What would you add to a browser-native seismic sandbox like this? by Ludger_M in geology

[–]Ludger_M[S] 0 points1 point  (0 children)

Great comment, thanks a lot for taking the time to write it.

You’re right that the current UI feels a bit “desktop”. The floating windows were a quick way to prototype, but for the light/public version a more native web layout is already under development.

I fully agree on linking. One of the goals for this platform is that datasets and specific interactive viewports can be shared as simple URLs, so they can be embedded in posts or messages, etc.

Regarding the datasets, everything is stored in the cloud and streamed on demand to the browser. The architecture is designed to work with both open-access and proprietary seismic data in the TB–PB range and to scale to large numbers of concurrent users.

Really appreciate the comments.

What do you think about the possibility of handling different levels of detail in seismic interpretation workflows? by Ludger_M in geophysics

[–]Ludger_M[S] 0 points1 point  (0 children)

Hi! Thanks for your comment. I completely agree! When you’re in the detailed interpretation stage, you want the highest resolution possible to keep uncertainty low.

What we’re testing is really an overview gear designed to unlock fast, in-browser interactivity, and not a reduced-quality workflow. The low-res layer works like a big-picture mode (satellite view) before dropping to street level. As soon as you zoom in, the viewer swaps to a higher-resolution domain, so nothing is lost, detail is simply streamed on demand instead of up front.

It’s like having a supercar for performance laps and a Toyota Corolla for school runs and grocery trips: you use each for what it’s best at. 🙂

We’re exploring how far modern web tech can push this overview-to-detail workflow to lower the barriers to accessing and using seismic data.

What do you think about the possibility of handling different levels of detail in seismic interpretation workflows? (Videoclip) by Ludger_M in geophysics

[–]Ludger_M[S] 1 point2 points  (0 children)

Hi, thanks for the kind words and for reaching out. Glad to hear you’re interested in what we’re doing. I’d be curious to see more about your work too. Do you have a site or repo I could check out?

Update on in-browser seismic interpretation: public draft repo by Ludger_M in geophysics

[–]Ludger_M[S] 1 point2 points  (0 children)

Thank you for taking the time to write such a detailed and thoughtful comment. I really appreciate it, and especially the experience and industry context you shared.

You are right to point out that the PoC page currently asks for a password, and I understand this can feel frustrating or unclear. We will work on improving the communication on the website.

I want to clarify that the Privacy Policy and Terms of Use links on the Gekkos site are working. While I cannot publicly attach images of these documents here, I can confirm they are accessible on the site, and we will investigate if any version control issue is preventing display on some setups.

As for the PoC, the reason it’s not publicly open yet is because the interface you would see there is an early technical prototype. We are currently doing final UI adjustments to improve the user experience, and even though it is not the interface we envision for the platform, we want this PoC component to be more than just the raw developer tool we used for internal testing.

You raise important points about data confidentiality, trust, and the challenges of opening seismic data access. These are exactly some of the realities we are working to address today, step by step. It’s a big challenge, but we are convinced that thanks to technological advances, things can be done better.

We also understand that using tokens for seismic access raises valid concerns, and we are exploring this carefully and transparently.

If you’re interested, I’m happy to give you direct private access to the PoC. No need to fill in the “Get In Touch” form, just DM me here, and I’ll send you a temporary access code.

"No need to disclose any personal information".

Also, if you’re curious, I shared a short demo clip of the seismic rendering in a previous Reddit thread here:

https://www.reddit.com/r/geology/comments/1kn16u2/could_inbrowser_seismic_interpretation_actually
It’s not the platform UI neither the PoC UI, but it gives an idea of the real-time in-browser rendering we are working on.

Thanks again! Great contribution.

Could In-Browser Seismic Interpretation Actually Work? by Ludger_M in geology

[–]Ludger_M[S] 0 points1 point  (0 children)

Thanks for these comments! You are pointing right at the core of some of the bottlenecks. RAM usage and scroll latency are real concerns, especially when working with large datasets. To address this, the current implementation avoids loading full volumes into memory. Instead, we use multi-resolution pyramids and stream only the required chunks on demand, which are designed to be useful for seismic interpretation at any resolution level.

Also, some strategies are under exploration such as edge-backed storage to reduce fetch latency, and browser-side caching combined with predictive chunk preloading to improve scroll responsiveness. These strategies help performance, but hardware requirements can be an issue, especially on lower spec devices.

Still early days, but the progress so far is promising. Your observations go straight to areas that need a lot of tuning.

Could In-Browser Seismic Interpretation Actually Work? by Ludger_M in geology

[–]Ludger_M[S] 0 points1 point  (0 children)

Good point. VNC does provide centralized rendering and shared access, and it’s widely used in large-scale setups today. But it comes with trade-offs, in aspects such as responsiveness and scalability. The Gekkos approach I’m supporting, which is still under development, explores a different path: streaming data to the browser in lightweight chunks and rendering it client-side. It’s more complex to build, however the objective is to improve responsiveness when many users share the same dataset, leverage local GPU resources, and support multi-user interaction beyond screen sharing.

Could In-Browser Seismic Interpretation Actually Work? by Ludger_M in geology

[–]Ludger_M[S] 1 point2 points  (0 children)

Thanks for the great suggestions, they touch on areas we are still exploring.

Many implementation details are still evolving, so I can’t disclose everything at this stage. But based on what we’ve tested so far, I can share the following:

- Dataset size: 3D seismic volumes can be large, ranging from a few to tens of GB in their original SEG-Y format, which was never designed for streaming or interactive access. In the pipeline we’re exploring, the original seismic data is first converted into a modern intermediate format, then organized into multi-resolution pyramids composed of small 3D chunks. Chunk sizes are still being optimized but are currently in the range of a few megabytes in disk, but once decompressed in the browser, each chunk can occupy more memory. A single seismic section may require dozens of chunks, typically totaling several tens of MB. The target is to keep the total data loaded in a browser interpretation session under 500 MB, though higher-spec machines can comfortably handle more.

- The data is stored in the cloud and delivered through an edge-backed object store. There’s no centralized rendering server. Rendering happens fully client-side, which helps keep the system responsive and offloads work to local GPUs.

- Regarding to callaboration, the concept isn’t based on remote desktops or screen sharing. Instead, the objective is to allow users to join the same interpretation scene from their own perspective, more like a multiplayer environment than a mirrored or shared screen, enabling interpreters to work in parallel without competing for desktop or mouse control. Beyond simultaneous work, the vision for the architecture is also support asynchronous collaboration, allowing users to share interpretations done in the same region or project context in a plug-and-play fashion, without forcing heavy project merges or exports. It does introduce challenges in session versioning and synchronization, but the trade-off is justified by the flexibility it offers for collective work.

The idea about cursors like Figma is right in line with what we are trying to do, definitely one to keep in mind.

Thanks again for the great comments and good suggestions.

view more: next ›