Low Cost Log Image Digitizing Software Needed

  • Thread starter Thread starter Kevin Myers
  • Start date Start date
K

Kevin Myers

Following is a copy of an extended thread that I previously started on
sci.geo.petroleum with regard to the need for some specialized software for
digitizing curve values from extremely long scanned tiff images of well
logs. I am reposting the thread here in the hopes that someone on this list
may know of or be willing to consider development of this software. More
information regarding the software requirements is included in this thread,
and I can provide any necessary additional information upon request.

Right now, this market is dominated by a single vendor with outrageously
high prices (see NeuraLog at www.neuralog.com). There is a significant
opportunity here for someone who could develop a reasonably competitive
product with a much lower price tag.

s/KAM


Robert Baer said:
Thank you for your detailed response.
I also was able to get a printes copy of a scan of a log (Tipton #3,
Woodson KS 07/23/84) run at 25 ft/min with about 1/4 for gamma ray graph
on one scale, and about 2/3 for neutron plus shifted CCL.
In between, is foot designations; ...50...150...200 etc with the dots
representing appropiate spacing; two feet between minor chart
increments, 10 feet between emphasized chart lines.

You may see two or more different depth scales on a single log. Typical
scales are 1, 2, 2.5, and 5 inches per 100 feet of well depth. Normally the
largest available depth scale is used for digitizing, since that will give
the best resolution and accuracy.

I see no "zero" on either chart and i guess that there is no such
thing.

The scales for each track of the log are noted at the very top and/or very
bottom of the track. For some curves 0 is an appropriate scale value, while
for other curves including a value of 0 in the scale would scrunch the curve
together too much, resulting in poor resolution and readability. However,
that is not a problem, since both the minimum and maximum scale values for
each scale are almost always provided. In addition to linear scales, there
are also logarithmic (used for resistivity) and some other more unusual
scales. Also, it is common for some curve values to exceed the minimum or
maximum scale values. Such situations are commonly handled by "wrapping"
the curve back around to the other side of the track. The scales
corresponding to such wrap-around curve values are known as backup scales.
Unfortunately, there are not a number of "pens" on one chart to show
the crossing that you refer to.

I will supply an example which illustrates that. BTW, at one time well logs
were plotted using actual pen plotters. But these days most logs are
produced on thermal or inkjet printers.
How do the dotted and/or dashed curve patterns created: sampling
plotters that "bash" pens against paper (eg: RustRack)?
Or is it a "sometimes" thing due to "inkmanship" of the pen?

Occasionally you will see some skipping due to poor ink delivery, especially
when there are fast value changes and the old style pen plotters were in
use. But what I am really talking about is a true dash or dot pattern that
allows you to distinguish one curve from another in a given track.
Sometimes different line thicknesses are also used. Occasionally different
colors are also used, but 1) that is only on very modern logs, and 2) dash
patterns are almost always still used in conjunction with colors because
some user may end up working from a monochrome copy of the original log.
With zero or minimal slip, stretch, and skew in the log image, scaling
is simple. But i would need samples that have some of those features to
see if they can be corrected to a reasonable amount.
The scale grids might make that a "simple" task, if approached
properly (do not ask me how, yet - i am still learning).

Yes, programs such as Neuralog and LogDig attempt (with varying levels of
success) to follow and use the grid pattern to insure that the scale is
properly maintained in spite of scanner and copier slip, paper stretch, and
skewing. This approach is highly recommended, and almost a necessity, but
again can be much more difficult than it might seem. Faded grid lines that
are difficult to pick up are a common problem. Adding to this problem is
the fact that it is generally impractical to store well log images in color
or grayscale format. They are almost always stored with only a single
monochrome bit of color information per pixel, i.e. black or white only, and
generally use some form of image compression, commonly CCITT Group 4 fax
compression. This is necessary in order to avoid image files of
unreasonable size, which is especially important when you are dealing with a
large number of stored images, and want to fit a reasonable number on CD or
DVD for example. Unfortunately, this means that relatively faint
information such as thin, faded grid lines often suffer greatly in the
scanned images. Fortunately, major grid lines are usually retained, but the
minor grid lines are often lost or seriously degraded.

Image resolution is also related to these issues. Higher resolutions
produce better quality images (and lose fewer small/faint features such as
minor grid lines). However they also produce significantly larger images.
From practical considerations of file size vs. image quality, it has been
found that 200 dpi for large scale logs and 400 dpi for small (half) scale
logs is a resolution that provides a good compromise between image quality
and file size, and you will find that most scanned log images are at or near
this resolution.
The are also often dotted and dashed curve patterns, may be a problem,
depending on their "structure", and may really play hell on "curve
following" - most especially if tow curves cross (!!).

You got it. These are a very tricky problems to handle. The approach that
is generally attempted is first to detect and effectively "remove" the grid
lines from the image (after their postion has been noted), followed by some
kind of pattern detection and recognition process to follow the dashed
and/or dotted curve patterns.
Faded spots, and stained paper is a rather nasty problem that may not
be soluable, given everything else is OK.

There are reasonably easy approaches such as adaptive contrast and
brightness adjustment that can be used to help minimize difficulties due to
these types of problems, but they must be applied either at scanning time or
to gray scale images. It is amazing to me how few log scanning applications
actually provide any facilities whatsoever for dealing with this. I
wouldn't start out worrying about this too much, since this problem is
probably better to address on the scanning side rather than while
digitizing.
I have done some preliminary investigation.
For starters, i would support files only in BMP format, since it is a
fixed standard, and to simplify things, it should be B&W; conversion
from TIFF to BMP is easy, and the file sizes seem to be similar (at
least in one case for the TIFF).

BMP would be fine for a prototype application, but not really for a
production app, because CCITT Group 4 compressed monochrome TIFF images are
effectively the industry standard, and folks won't want to be constantly
converting their images to BMP.
The reason why i do not want to support TIFF, is that there are
hundreds of formats; it seems that TIFF is a means to transport a bitmap
only, with no spec as to how that bitmap is formatted.

Yes, TIFF is a complex spec to handle thoroughly. However, there are
existing public domain libraries such as libtiff that are designed to
facilitate working with TIFF images, including reading and writing from/to
disk files, etc.
Would you be so kind as to forward one or two "typical" TIFF scans, at
least one or two that have the poor quality that you refer to, and one
OK quality?

I've uploaded a few examples (see below), though haven't included too much
in the way of image quality variations at this point. Don't have a lot of
free time on my hands to hunt around at the moment. I would strongly
suggest that you start off by just worrying about a relatively simple, clean
log with one curve per track, then move on to more curves and other
complications only after you get a relatively simple log working reasonably
well. As an experienced software developer myself, who has spent a fair
amount of time pondering this problem, I have to warn you that you are
likely to find even a relatively simple log to be a significant challenge.

Uploaded the following moderately sized, farily decent quality log images to
our web site where you should be able to download them (let me know if any
problems):

http://www.myersoil.com/images/42003389030000_ALL.tif - modern resistivity
log, mult curves and dash patterns per track, logarithmic scale
http://www.myersoil.com/images/42003389030000_CNLD.tif - modern
neutron-litho density log, multiple curves and dash patterns per track
http://www.myersoil.com/images/42135017480000_GRN.tif - older gamma
ray-neutron, simple one curve per track, couple of spots illustrate backup
scales
http://www.myersoil.com/images/42135017480000_LL.tif - intermediate age
(1950s) resistivity log, note oddball non-linear scale

One further note: NO automatic, curve following, log digitizing program is
going to be able to follow curves perfectly. The goal is simply to make the
curve following good enough that it greatly speeds up the process and
improves accuracy in comparison to trying to follow the curve by hand.
Given this situation, one extremely important feature of any program of this
type is the relative ease with which corrections can be manually applied
where the curve following routine screws up. One approach would be for the
user to simply click on the correct location where the curve following
algorithm has messed up, then have the curve following routine start over
from that point, while leaving data above that point unchanged.
Replace robert with bob if you do so.

I can give no guarantees at this stage, as i have never tried such a
project.

Good luck! I hope that all of this is helpful.
 
Back
Top