Section 4 - Well Log Extensions

4.1 Scope & Introduction

This section contains the definitions of a set of CGM extensions for drawing well logs, the Basic Well Log Extensions of PIP/III and the Advanced Well Log Extensions of PIP/IV.

When used without modifier in this section, the phrase Well Log Extensions shall refer to both the Basic Well Log Extensions and the Advanced Well Log Extensions.

Volume 1 defined extensions for Seismic Trace and Continuous Rendering.

The Well Log Extensions are implemented by a set of GENERALIZED DRAWING PRIMITIVE (GDP) and ESCAPE elements as defined in this specification. A conforming PIP metafile shall contain the declaration "Extension: Extended/WellLog" in a METAFILE DESCRIPTION substring if it contains any of the extensions defined herein.

If the metafile contains seismic and continuous rendering extensions in addition to Well Log Extensions, it shall contain the METAFILE DESCRIPTION substring "Extension: Extended/WellLog/Seismic/CR" (the /Seismic and /CR suffixes may be in either order).

The scope of this Volume is limited to a specification for a set of Basic Well Log Extensions to CGM*PIP, denoted as PIP/III, and a set of Advanced Well Log Extensions denoted as PIP/IV. The extensions of PIP/IV are a superset of the extensions of PIP/III.

The basic extensions of PIP/III are expected to provide enough functionality to allow the efficient description of simple well log plots. The following functionality was excluded from the scope of PIP/III:

• Trace Modulation

• Waveforms in Well Logs

• Azimuthal Offset Images

• Depth Indexed Objects

These advanced capabilities comprise the additional well log functionality of PIP/IV.

Because PIP/III is a proper subset of PIP/IV (a valid PIP/III metafile is a valid PIP/IV metafile), references in the following subsections to PIP/III are to be construed as applying to PIP/IV as well, unless otherwise qualified.

4.2 Concepts

4.2.1 Overview

This section describes the concepts and principles involved in well log drawing in sufficient detail that the usage and interpretation of the elements, whose encoding is described in Section 4.3, Encoding the Extensions is unambiguous and well defined.

The Basic Well Log Extensions fall naturally into the following functional groups:

• Tracks, Timing Lines, Depth Lines and Grids - a set of elements which define the basic "track" structure of well log plots, and elements which draw the graph paper upon which well logs are presented.

• Well Log Traces and Well Log Curves - includes the basic well log data element (Log Trace), the mapping element (Trace Mapping) which describes the transformation between well log data and plotting positions, and the Log Curve element which describes a well log curve to be drawn based on the previous two elements.

• Log Area - an element (Log Area) which describes a well log area to be drawn, based on Log Trace and Trace Mapping elements, similar to the manner in which a well log curve is defined.

• Data Delivery - a set of elements used to define a depth-ordered "frames" organization of well log data, an association of data frames with various log traces, and the incremental presentation of depth-ordered data frames to one or more traces so that their associated curves and areas can be drawn.

The Advanced Well Log Extensions fall into the functional groups:

• Waveform Traces, Curves and Areas - the plotting of depth-constant waveforms whose time parameter varies horizontally is supported in the Advanced Well Log Extensions by the Waveform Trace, Waveform Curve and Waveform Area objects.

• Azimuthal Offset Images - an object to support borehole-based images strips which wander about in a unwrapped borehole projection because of original tool rotation during data acquisition.

• Depth Indexed Objects - a set of special primitives and objects for features such as fanplots and tadpoles commonly found in dipmeter logs.

• Trace Modulated Attributes- an enhancement of the CGM and PIP attribute models, which may be applied to both basic and advanced well log objects, in which the data in trace elements are used to carry drawing attribute variations (colour, size, and pattern) to be applied to curves and logs.

4.2.2 Well Log Principles

Conceptually, a Well Log metafile of PIP/III or PIP/IV has a fundamentally different nature than either generic CGMs or PIP/I and PIP/II Seismic Trace metafiles. The latter are fundamentally declarative in nature - the picture is described as a collection of graphic primitives together with their properties and attributes. The occurrence of the graphical primitive carries sufficient graphical information to completely render and display the primitive.

The Well Log Extensions require a more procedural drawing model. A set of fundamental objects which correspond to components of the well log plot is defined. Then commands are given which either use these objects in a procedural manner to draw parts of the plot, or well log data is incrementally "delivered to" the objects. Delivery of this data in turn "triggers" the rendering of an appropriate incremental section of the well log plot. This approach can be very efficient for the sort of extreme (in size and complexity) plots which are typical of well logging.

At a high enough level of abstraction, the drawing of a well log plot is nevertheless conceptually simple. A Basic Well Log plot of PIP/III is drawn as follows:

• a "track" structure for the plot is defined using appropriate objects,

• Templates are defined and used for generation of the graph paper of the plot,

• the well log data objects ("traces") are defined,

• mappings of the well log data of the traces to Cartesian plot coordinates onto the tracks are defined,

• drawn curve and area objects are defined based on the foregoing object definitions,

• the bundles ("frames") by which data are incrementally delivered to the well log traces are defined,
• and finally the data are incrementally "delivered to" the well Log Traces, causing the rendering of the appropriate sections of the dependent drawn objects.

This hierarchy of objects in Basic Well Log Extensions comprising a typical well log plot is illustrated in Figure 1.

Figure 1. Hierarchy of Basic Well Log Objects

Advanced Well Log plots follow the same basic conceptual model with the addition of some advanced drawing primitives and objects, and the inclusion of the more sophisticated drawing attribute controls of trace modulated attributes. The drawable objects that are added include:

• waveform data objects ("waveform traces"),

• mappings of the waveform data traces to Cartesian plot coordinates onto the tracks are defined,

• drawn waveform curve and waveform area objects are defined based on the foregoing object definitions,

• drawn "azimuthal images" that rely on both log and waveform traces for their data,

• drawn "tadpole curves" that rely on log traces for data and "tadpole objects" for their geometry,

• fanplots.

This hierarchy of objects associated with Advanced Well Log Extensions is illustrated in Figure 2. Note that PIP/IV objects are in Bold and PIP/III objects are in Italics.

Figure 2: Hierarchy of Advanced Well Objects

The concept of data delivery is fundamental to PIP Well Log plots and also distinguishes these geotechnical graphical extensions from core-CGM and the seismic extensions. In core-CGM and seismic plots, all of the data of a graphical primitive is present in the instance of the primitive itself. In well log plots, it would be difficult or impossible to do this. Typically well log plots are very long (contain a large amount of data), and they contain several objects which are defined over the whole span of the plot and are related in ways that may vary over the extent of the plot. In addition, it is a requirement of an interchange standard for well log plots that it be feasible to record the plot in real time during well logging.

For these reasons, the Well Log Extensions rely on the concept of "data delivery", in which the data of the traces are organized into "frames" which appear in the metafile incrementally and in longitudinal order. The essential aspects of data delivery are:

• traces (along with associated drawing objects such as curves and shaded areas, plus their drawing characteristics) are defined, but none of their data is included in the definitions;

• the data characteristics (data type, number of samples per frame) are established at the time of trace definition;

• one or more data frame definitions are made, which associate a data frame identifier with a list of trace identifiers;

• finally, the log data GDP contains one or more instances of a frame of data to one or more identified frames, and thereby data is "delivered" to the entities (traces) which are associated with the identified frames.

4.2.3 Motivation

It has been the experience of graphics practitioners that geotechnical displays require special graphics objects. Although most of the display requirements discussed in this section could be obtained by using standard graphics primitives of lines, polylines, rectangles, and polygons, the generation costs, metafile sizes, and therefore rendering times become prohibitive because of the larger number of lower-level primitives required to describe the same picture.

The use of higher-level, application-specific graphics primitives and objects has the following major benefits:

• simplification of the complexity of the metafile generator software;

• reduction of metafile sizes;

• increased rendering and plotting efficiency;

• the capability for well log data to remain as a single coherent object rather than breaking it down into little pieces that have no relationship to one another - this is important for manipulating/editing the data once it is in the CGM.

As shown in Table 1, metafile sizes are very dependent on coding technology used. PDS is a proprietary metafile format used for describing well logs and contains special well log description primitives. CGM:1992 Version 1 contains only standard graphics primitives. In most cases, the CGM file is 1.5 or more times larger than the equivalent PDS file.

4.2.4 Wells, Well Logging, and the Well Log Plot

An oil well is logged by lowering a set of sensors (a logging tool), attached to a telemetry cable, down a borehole. The logging operation is accomplished by slowly pulling the tool uphole while recording the sensor measurements at appropriate time and depth intervals.

The well log plot is made by drawing a long and narrow strip chart (see Figure 3). As a well log plot is typically viewed, the longitudinal direction (along the paper) represents vertical well depth measured in scaled feet or meters, and the latitudinal direction (across the paper) represents sensor response, scaled to some appropriate coordinate system.

A sequence of data for a sensor is called a log trace, and is typically drawn using a curve that runs along the vertical direction. Often, this vertical direction is called the logging direction. During logging operations, one never knows how long the log will be, so the length of this axis is considered to be indefinite. This is also sometimes called the "continuous rendering" direction.

In some well logging environments, sequences of data are acquired by performing sampling over time at a given depth, and these "waveform traces" are displayed as horizontally oriented or latitudinal curves. Throughout this document, a "log coordinate system" will be used when describing how well log primitives are drawn. Fragments of well logs are shown in portrait oriented plots, with longitude running vertically and latitude running horizontally, which is the preferred viewing orientation. When CGMs are generated, specific CGM commands are used to tie the orientation of the log to CGM's x and y coordinate directions.

Figure 3. Typical WellLog Section

4.2.5 Tracks, Timing Lines, Depth Lines and Grids

4.2.5.1 Role of Tracks and Grids in Well Log Plots

Well Log plots are organized around a structure of "tracks". A track is an area bounded by two parallel lines, extending an undefined distance, aligned with either the Virtual Device Coordinates (VDC) x-axis or y-axis. A track provides boundaries where other objects like grids, areas and curves are to be placed or drawn. It is used mainly for reference by these other objects. For instance, assuming that the vertical direction of the well log is aligned in the well log plot with the y-axis of the CGM coordinate system, a vertical track would be specified by left and right x values and a horizontal track would be specified by top and bottom y values.

A track also provides the framework for mapping the data of well logs into Cartesian coordinates (VDC) for plotting.

Conceptually, a track extends indefinitely along the selected logging axis orientation.

Henceforth, latitudinal refers to the direction "across" the track, i.e., perpendicular to its boundary. Longitudinal refers to the direction that is "along" the track, i.e., the direction of indefinite extent. It should be noted that the CGM specifications provide no recommendations as to how the X and Y axes are oriented with respect to the paper a plot is drawn on. This is usually handled via an instruction to a CGM renderer.

Well log plots are graphs which display data obtained during various data acquisition and processing operations. These graphs are meaningless unless they are plotted on some form of scaled graph paper from which the data values may be read and interpreted. Timing lines, depth lines, and grid line objects are used to draw this graph paper. In a typical log (see Figure 4), tracks run vertically from the bottom to the top of the plot. A standard log has a left track (Track_1), 2.5 inches wide, extending from the left edge of the paper. (NOTE: All log plots in this document are drawn at 60% of true size.) Next, a 0.75 inch wide depth track is used to record vertical depths, typically every 10, 20, 50, or 100 feet/meters, depending on log scale and coordinate system. Next come two 2.5 inch wide tracks, sometimes used separately, and sometimes used in combination. In this case, Track_2 and Track_3 are divided into ten equal increments.

Summing up these track widths gives a standard log width of 8.25 inches. Since vertically oriented data is to be plotted in these tracks, horizontal depth lines are used to delineate the depth scale: thin depth lines occurring most frequently (every 2 borehole feet); less thin depth line occurring less frequently (every 10 borehole feet); thickest depth lines occurring least frequently (every 50 borehole feet).

One way to draw this "graph paper" would be to use vectors. For 100 borehole feet this would imply: 50 two-foot lines plus 10 ten-foot lines plus 2 fifty-foot lines giving 124 vectors per track per 100 feet of log for the horizontal depth lines. The vertical grid lines required here are: 10 for Track_1 plus 20 for Track_2 plus 10 for Track_3, giving 40 vectors. To summarize, using vectors to draw this grid system requires about 290 vectors for every 100 borehole feet.

Figure 4. Typical Three-Track Log Layout

4.2.5.2 Templates

Special objects are used for drawing grid and depth lines so that customized graph paper can be constructed for geotechnical plots. The use of these objects is more efficient than the hundreds or thousands of vectors that would otherwise be needed to draw the scales required for geotechnical plots. With a few template objects, it is possible to specify complex graph paper. For example, in well logging, one often displays the vertical wellbore at a 1/240 display scale. In such a scale, a horizontal depth line is drawn at each scaled two-foot depth. Thus, depth lines occur every 0.1 inch longitudinally, with 50 of them contained in every 100 feet of well (5 inches of log plot). A well log might contain hundreds or thousands of depth lines. Using generic CGM elements, 1000 2-point lines would require 8000 bytes of data as a DISJOINT POLYLINE, or 12000 bytes as 2-point POLYLINEs. So the data size of typical well log graph paper represented by conventional CGM elements might span a range something like 5000 to 50,000 (or 100,000, or...) bytes of CGM data to represent. Even more space is required when latitudinal depth lines are discontinuous.

4.2.5.3 Drawing Depth Lines with Templates

Instead of drawing a log's "graph paper" using vectors, PIP/III defines a system of templates to describe and draw the vertical and horizontal lines. One template (see Figure 5) describes how to draw the depth lines using a 2.5 inch long horizontal line, then a 0.75 inch gap, then another 5.0 inch wide segment.

Pseudo code for describing a depth line template might look like:

      Escape Id     : <run_template_definition_id>
      Template Id   : Depth_Line_1
      # of Runs     : 3
      Run List      : 2.5, .75, 5.0

A narrow version of this template (Figure 5(a)) can be regularly placed between the left edge of Track_1 and the right edge of Track_3 to draw the two-foot depth lines. The pseudo code would be:

      Escape Id     : <template_use_id>
      Draw Id       : Draw_2_Foot
      Template Id   : Depth_line_1
      Track Id      : Track_1_thru_3
      Start/Stop    : 0.0, 7.5
      Draw Extent   : .005
      Repeat Extent : 0.10

Similar pseudo code is used for the ten foot lines. They occur every half inch and are 0.01 high:

      Escape Id     : <template_use_id>
      Draw Id       : Draw_10_Foot
      Template Id   : Depth_line_1
      Track Id      : Track_1_thru_3
      Start/Stop    : 0.0, 7.5
      Draw Extent   : .01
      Repeat Extent : 0.5

For the 50-foot depth lines, the pseudo code is:

      Escape Id     : <template_use_id>
      Draw Id       : Draw_50_Foot
      Template Id   : Depth_line_1
      Track Id      : Track_1_thru_3
      Start/Stop    : 0.0, 7.5
      Draw Extent   : .015
      Repeat Extent : 2.5

Putting these pieces together results in the plot fragment shown in Figure 5(b). Note that the width of the depth line rectangles comes from the template description and the height comes from template usage command. For this example, drawing the depth lines requires one template for describing the depth lines and three commands for describing how to use that template.

Figure 5. Depth Lines for a Well Log

4.2.5.4 Drawing Grid Lines

Vertical grid lines (see Figure 6) can be described in a template which shows how each grid line would intersect with a thin horizontal raster (Figure 6(a)). Pseudo code for the grid template is:

      Escape Id   : <run_template_definition_id>
      Template Id : Grid_Lines_13
      # of Runs   : 63
      Run List    : .015 .235 .005 .245 .005 .245 .005 .245 .005 .245
                    .010 .240 .005 .245 .005 .245 .005 .245 .005 .235
                    .015 .735 .015 .205 .005 .155 .005 .115 .005 .095
                    .005 .075 .005 .07  .005 .06  .005 .055 .005 .370
                    .005 .210 .005 .155 .005 .115 .005 .095 .005 .075
                    .005 .07  .005  .06 .005 .055 .010 .365 .015 .235
                    .005 .245 .005 .245 .005 .245 .005 .245 .010 .240
                    .005 .245 .005 .245 .005 .240 .005 .235 .015 

In the Run List, lines 1 and 2 describe Track_1 and the Depth Track. Lines 3 and 4 describe the two-decade logarithmic grid in Track_2. Track_3 is described by lines 5 and 6. This raster description can then be continually "extruded" vertically between Track_1_Left and Track_3_Right to draw the vertical grid, as shown in the pseudo code below.

      Escape Id     : <template_use_id>
      Draw Id       : Draw_Grid
      Template Id   : Grid_lines_13
      Track Id      : Track_1_thru_3
      Start/Stop    : 0.0, 7.5
      Draw Extent   : .005
      Repeat Extent : .005

The results are shown in Figure 6(b). Note here also that the width of the various rectangles comes from the run values in the template and the height comes from the combination of draw extent and repeat factor parameters in the Template Use ESCAPE. In this example, the grid requires only one template description and one Template Use ESCAPE.

Figure 6. Grid for a Well Log

4.2.5.5 Template Definition Objects in PIP

The previous sections defined and illustrated the PIP concept of templates, which are used to efficiently define and draw graph paper for geotechnical plots. A straightforward method for specifying these templates is to use a virtual, device independent raster at some nominal resolution. The renderer then converts this virtual description into a device dependent description at the specified resolution of the target drawing device. While it is often the case that the rendering is to a corresponding physical raster template of a raster device, there is nothing in the PIP/III definition that mandates this - vector plotting commands could just as well be used.

In either case, during the rendering process the device dependent realization of the virtual raster template (whether it be physical raster or vectors) is repeatedly copied at appropriate places into the plot being formed.

PIP/III defines two coding techniques for specifying such a virtual template. One method (Raster Template) is essentially a 1-dimensional cell array which can handle monochrome, colour, and transparent colour cells. The other method (Run Template) is a set of monochrome runs which obtain their colour from the current line attributes. These two template definition techniques are described below. The operation which utilizes these templates and causes graph paper to be generated in a plot is described in section 4.2.5.6.

Raster Template

A raster template is parameterized similar to a 1-row cell array. An extent parameter gives the span in VDC which the template is to cover, and a list of "template pixels" gives the colours to be assigned to the virtual raster which is defined. Raster Templates are full colour. All colours in the template's virtual raster definition are opaque unless specified as transparent by Transparent Cell Colour (Version 1 ESCAPE or Version 3 element). Line width is determined by the parameters of the Template Use ESCAPE.

Run Template

By contrast with the Raster Template, the Run Template is bi-level (two colours). The Run Template is parameterized by a number of runs and a list containing that many runs. Each run consists of a single VDC scalar which defines the length of that run. Runs alternate between drawn and not drawn, with the first run being drawn. The drawn portions are drawn with the current metafile line colour, individual or bundled according to the setting of the metafile. The not-drawn portions are either transparent or opaque, according to the metafile values of AUXILIARY COLOUR and TRANSPARENCY. Line width is determined by the parameters of the Template Use ESCAPE

4.2.5.6 Template Usage Objects in PIP

PIP/III defines a system of templates for generating graph paper for geotechnical plots. Section 4.2.5.5 described the two types of template definition objects. This section describes the template usage object - the object commands how a defined template is to be applied to actually generate the graph paper (grid, depth, timing lines).

Typically, the generation of the graph paper by the template method requires that one or more template objects be repeatedly placed over a long longitudinal extent of a geotechnical plot. Each time such a template is placed, it may be copied into the plot over a given longitudinal extent. When that extent is complete, the template object may be:

• deleted - the template object is no longer required in this plot;

• used again immediately - it is being copied continually as in longitudinal grid line drawing;

• reactivated at a given longitudinal distance from the current start position, to display regularly spaced depth or time lines.

The template usage object of PIP - the Template Use ESCAPE - is parameterized to support these operations. The template alignment position parameter gives the VDC coordinate along track at which template drawing is to start. Drawing is accomplished by extending the template along the positive direction perpendicular to the track's orientation and dragging the template through a rectangle for an extent along the track as specified by the draw extent parameter.

After each placement, the repeat factor is examined as described above to determine the status of further drawing.

It is convenient and typical to define the template objects near the beginning of a plot, and to immediately define the template usage object(s) thereafter. In this way, the orientation commands are given once and for all to have the renderer automatically draw the template from then on until the "graph paper" for the plot is completely drawn, at which time the template can be deleted.

It is also common practice to independently command the placement of depth line and grid line templates, by including separate template usage objects for each of the two. Thereby it is possible to "sandwich" shaded areas above depth lines and below grid lines.

Any portions of a template that extend beyond the track's boundary are clipped to that boundary.

4.2.6 Well Log Traces and Well Log Curves

A trace of well log data is a sequence of data values derived from a process that samples some physical property at discrete depths along a well bore. The display of a well log trace is called a well log curve. A well log plot may contain one or more such curves. These curves are displayed in one or more parallel tracks. One track may contain any number of associated curves. Individual curves represent various physical properties of the well and use unique drawing attributes (line type, width, and colour) so that they can be easily identified and distinguished from one another. Depending on scale, well log traces can be very long; hence a requirement for incremental data delivery exists. Requirements for real-time log drawing and the need to draw multiple curves also imply a need for multiplexed data, i.e., the ability to deliver data to several traces simultaneously.

4.2.6.1 Well Log Traces

A well log trace is a sequence of pairs: sample ordinate and measurement value. Often the ordinate is regularly sampled borehole depth. A Log Trace object is defined by the PIP/III Log Trace Definition ESCAPE. Each trace is identified by a unique log trace identifier, and the type and number of data (per frame) are parameterized in the Log Trace Definition ESCAPE. In some cases the measurement value may be a set of values.

The Log Trace object acts as a data repository which is then referenced during the drawing process. The trace data will be drawn as some form of a curve, or might also be used to control the drawing attributes of a curve or area (the latter only in PIP/IV).

The process of drawing a well log trace involves the mapping of the (ordinate, value) pairs to plot positions. This mapping is defined by the Trace Mapping Definition ESCAPE. For each plot position, the longitudinal position is derived from the sample ordinate and the latitudinal position is derived from the measurement value.

Typically, a well log curve is then drawn by connecting these successive plot positions with straight lines rendered with the specified curve attributes. In some cases the drawing attributes specify other drawing behaviors (e.g., a well log curve parameter may be used to specify that a 'dot log' is drawn, in which markers are plotted at the data positions according to the current CGM marker attributes, and no lines are drawn).

Sometimes the data at one or more trace positions is deemed to be bad or unusable, in which case it is classified as "absent data". PIP/III defines a mechanism for dealing with these situations - the trace is disabled over the regions containing absent data, and then enabled again when the data are acceptable (see section 4.2.17).

Additionally, there is no information inherent in the Log Trace's definition which specifies where the trace starts and where it stops in the longitudinal extent of the Well Log plot. Therefore each trace must be enabled at its start longitudinal coordinate and disabled at its stop coordinate (see section 4.2.17).

4.2.6.2 Trace Mapping

The Trace Mapping Definition ESCAPE defines how a trace's data is transformed, usually to derive plot positions (but sometimes the values are used differently), for the purposes of drawing the various curve and shaded area objects of PIP/III and PIP/IV. The Log Curve Definition ESCAPE and Log Area Definition ESCAPE reference a Trace Mapping Definition, not a Log Trace itself.

The advanced drawing objects of PIP/IV - waveform curves and areas, azimuthal images, and depth indexed objects - similarly make use of trace mapping definitions. The Waveform Curve Definition ESCAPE, Waveform Area Definition ESCAPE, Azimuthal Image Shader Definition ESCAPE, and Tadpole Curve Definition ESCAPE reference a Trace Mapping Definition to determine plotting positions, not a Trace itself (however, some of these may reference a Trace directly for other purposes).

The mapping of trace data to plotting coordinates is defined relative to a particular named track and its boundaries. There are four defined mapping modes: normal, clip, clamp and wrap (and the latter is applied only to mappings for well log curves).

Normal mode

where:	Mv = Mapped Value	Dv = Data Value
	Tl = Track Lesser	Dl = Data Lesser
	Tg = Track Greater	Dg = Data Greater

The Data Lesser and Data Greater values correspond to the data lesser and data greater parameters of the Trace Mapping Definition, while Track Lesser and Track Greater come from the lesser and greater track boundaries parameter of the Track Definition which is named in the Trace Mapping Definition. Data Value is the particular piece of data being mapped. Mapped Value is the value that results.

Clip mode

Clipped curves require special handling if the Mapped Value is less than the inherited Track Lesser or greater than the inherited Track Greater. Let P be the computed plot position for longitudinal position Y, and P´ be the plot position for longitudinal position Y´, where Y > Y´ (i.e., on Trace sample boundaries). The following rules apply for clip drawing mode:

• If P and P´ are both with the track (i.e., T₁ (P, P´) T_g. Then the line from (P,Y) may simply be drawn to (P´,Y´).

• If P is on-track and P´ is off-track, the line is drawn from (P,Y) to an interpolated point at the track boundary closest to P´, and then implicitly disabled. If P´ > T_g, then the curve is said to be off-track greater, and the interpolated point is (T_g, Y+(T_g - P)(Y´- Y)/(P´- P)). If P´ < T_l, then the curve is said to be off-track lesser, and the interpolated point is (T_l, Y+ (P - T_l)(Y´- Y)/(P´- P)).

• If P is off-track and P´ is on-track, the curve is drawn from an interpolated point on the track boundary closest to P to (P´,Y´). The curve is not drawn for latitudinal positions outside the track boundaries.

• If P and P´ are both off-track on the same side, the curve is implicitly disabled, and no line is drawn.

• If P and P´ are both off-track, but on different sides of the track, then interpolation of the end-points on both sides of the track is required.

All this may be accomplished by imposing a clipping region that encloses the track, prior to drawing a curve whose positions come from Mapped Values.

Clamp mode

Clamped curves require special handling if the Mapped Value is less than the inherited Track Lesser or greater than the inherited Track Greater. Clamping never lets a sample value go out of the data range. If the Mapped Value is less than Data Lesser, then Data Lesser is used instead. If the Mapped Value is greater than Data Greater, then Data Greater is used instead.

The difference between a wrapped Log Curve and a clipped Log Curve is that a wrapped curve draws when its data values are either inside or outside the range. A clipped curve draws only when its data values are inside the range and is clipped when its data values are outside the range. Wrapped plot position calculations are made modulo the range.

Wrap mode

where the variables are the same as those defined in the equation under Normal mode above:

	Mv = Mapped Value	Dv = Data Value
	Tl = Track Lesser	Dl = Data Lesser
	Tg = Track Greater	Dg = Data Greater

To correctly enable and disable the wrapped curve, along with possible interpolation from or to a track boundary, it is necessary to compare the data value to the range before computing the plot position. The computation always yields a value in the range from Track Lesser to Track Greater, inclusive. It should be noted that if the modulo operation can be done with a division, the quotient is a measure of how many times the data value is off-track; the so-called "wrap count". If the wrap count is 0, the curve is on-track; less than 0, the curve is off-track left; greater than 0, the curve is off-track right. A one-sample transition with a wrap count change of more than one means that the wrapped curve can be drawn many times, interpolating points at the track boundary. Wrapped curves are usually derived from Log Traces. Wrapped curves shall not be used as boundaries for Areas.

The same Trace Mapping Definition ESCAPE extension is referenced by the advanced well log drawing objects of PIP/IV. The mapping modes which are allowed in Trace Mappings referenced by PIP/IV waveform drawing objects are the following:

• Normal - the position which is computed by the given normal mapping equation (above) is used as a vertical offset from the horizontal baseline of a waveform. This is true whether the track is vertical or horizontal (as in Waveform Curves).

• Clip - the position is computed by the given normal mapping equation and the drawing is clipped at the waveform track boundary.

• Clamp - the position is computed by the given normal mapping equation and the drawing is clamped at the waveform track boundary. This means that wherever the drawing would go outside of the track boundary, it is constrained and drawn along the track boundary instead.

4.2.6.3 Well Log Curves

A Log Curve is a drawn representation of a Log Trace, using a set of drawing attributes (line type, width, and colour) that are specified for that particular curve. The definition of a Log Curve object is specified by the PIP/III Log Curve Definition ESCAPE. The Log Curve Definition ESCAPE identifies a mapping (and thereby a trace), and the drawing style.

The Log Curve Definition ESCAPE only defines the Log Curve object, in terms of tracks, log trace objects, and trace mapping objects. The occurrence of the ESCAPE does not in itself cause drawing. Drawing is triggered by the occurrence of a Log Data GDP, which presents frame(s) of data for the Log Trace object upon which the Log Curve is dependent.

Before the curve can be drawn, a mapping must be made which associates those portions of a given log trace whose values fall within a specified data range with specified plot positions within a named track. A three stage process is used: (1) a log trace receives the data; (2) a trace mapping computes the positions of the data within the track; (3) the visual attributes from the curve element describe how the drawing at the computed positions is to be done. It should be noted that the first data value received for each trace serves as an anchor position for curves and areas derived from that trace.

The trace identified by such a mapping may only be drawn over the longitudinal coordinate range for which it is enabled. The Log Curve object may not be referenced by any data primitives, nor does it carry any data that may be referenced by other drawable objects.

A Log Curve may be drawn or marked. For a drawn curve, the curve's drawing properties are inherited from the CGM line drawing attributes in effect at the occurrence of the Log Curve Definition. A marked curve is displayed by placing a marker at each enabled data position along the mapped trace. The marker attributes are inherited from the CGM marker attributes in effect at the time of the curve definition.

4.2.7 Log Areas

In well log plots, Log Areas are used to display the relationship between two curves or between a curve and some threshold value. A Log Area (or just "Area" for short) is defined to be the region bounded by two curves, a curve and a fixed position, or two fixed positions. The Area is typically enabled (see section 4.2.17) at some starting longitudinal coordinate, and is filled with a specified pattern and colour until it is disabled, provided it meets the specified drawing constraints. Some Areas display time-varying or longitudinally-varying properties by modulating a display attribute such as colour or pattern, or a combination of these. Property modulation is not allowed in PIP/III, but it is allowed in PIP/IV.

Log Areas are defined by the PIP/III Log Area Definition ESCAPE. The following key properties of Areas are controllable by the parameters of this ESCAPE.

Boundaries - In PIP/III only longitudinal areas are defined. Longitudinal areas are bounded by two longitudinal curves, a curve and a latitudinal position, or two latitudinal positions. Note that a trace's longitude, and hence a longitudinal area, may be oriented either with the VDC x-direction or with the y-direction. In the parameterization of the Log Area Definition ESCAPE, the two boundaries of an area are termed the lesser boundary and the greater boundary. Curves used for Area boundaries shall be normal, not wrap.

Filling Mode - PIP/III defines two modes of filling areas. If the mode is fromto, then the shading takes place only when the lesser boundary is strictly less than the greater boundary. If the value of a boundary is unknown at some given longitudinal coordinate, for example because a bounding trace is missing some data, then the shading cannot take place at that longitudinal coordinate. Between shading takes place from the minimum value of the two boundaries to the maximum value of those boundaries. When a boundary goes off track, the area is shaded only to the track boundary.

Fill Pattern - The fill pattern attribute of Areas specifies the pattern that is used to fill the interior of an Area. The Basic Well Log Extensions of PIP/III use the standard CGM pattern definition elements. The fill pattern parameter of the Log Area Definition is used as the pattern index into the metafile's pattern table. In PIP/IV, the Pattern Modulation ESCAPE may be used to associate trace-modulated patterns with an Area.

All CGM pattern-related fill attributes apply. The Fill Reference Point defines a point to which pattern origins are "locked" so that when the same pattern is used to fill two areas which are contiguous, the pattern will be continuous across the boundary. The transparent cells capability of CGM (either the Transparent Cell Colour ESCAPE in Version 1 metafiles or the Transparent Cell Colour element in Version 3 metafiles) allows the realization of transparent patterns as well as opaque patterns.

In advanced well log plotting, the pattern may either be constant or trace-driven. When the pattern is trace-driven, a separation line may be drawn between pattern transitions to clearly identify the changes. The colour, line width and line type of this separation line are specified via an Area Separator ESCAPE. This is not supported in Basic Well Log Extensions of PIP/III. It is supported in PIP/IV.

The Well Log Extensions of PIP/III and PIP/IV do not support bitonal patterns - a binary pattern template to which different foreground/background colour pairs can be assigned. Instead, the metafile must contain different pattern definitions for each unique pattern. The bitonal pattern capability could be achieved by using indexed Colour Selection Mode, defining the pattern in terms of colour indexes, and then changing the CGM Colour Table definitions for those colour indexes. However the basic PIP rules (see Volume 1, section 4.3.7, Note 8 following Table 6) prohibit changing colour index definitions once they have been defined and used.

CGM filled-area edge attributes do not apply to Areas.

4.2.8 Waveform Objects -Trace, Curve, Area

4.2.8.1 Waveform Traces and Trace Mapping

In well logging situations where waveforms are gathered for each selected depth, the data collected is a set of waveform traces. Because the well's depth is laid out vertically along the log, the time axis for the waveform trace is plotted horizontally, across the log.

Each data frame delivered to the waveform trace represents a complete instance of a waveform curve. A waveform trace has plot positions in which the vertical position is derived from the measurement value (waveform amplitude) and the depth at which the waveform was sampled, and the horizontal position is a measure of the time at which the amplitude was recorded. A waveform curve is then drawn by connecting these successive trace positions with straight lines rendered with the specified curve attributes.

In PIP/IV, waveform traces are defined by the Waveform Trace Definition ESCAPE. As with all PIP well logging objects, each waveform trace is identified by a unique waveform trace identifier. The remaining parameters are number of sample values and trace data type. The parameterization is identical to the parameterization of the Log Trace Definition ESCAPE. Number of sample values defines the number of data which are delivered to the trace in each data frame, and trace data type specifies the data encoding that is used for each of this trace's sample values in each of the future data frames.

The Waveform Trace object acts as a data repository which is then referenced during the mapping process. Waveform trace data might be used to draw a waveform curve or waveform area, or used to control the drawing attributes of a waveform curve or waveform area.

4.2.8.2 Waveform Curve

A waveform curve is the plot of a waveform trace. More precisely, a waveform curve is a plot of a mapping of a waveform trace. Each waveform curve refers to a Trace Mapping Definition ESCAPE which refers to a Waveform Trace Definition ESCAPE.

Waveform curves are defined in PIP/IV by the Waveform Curve Definition ESCAPE. Each waveform curve is identified by a unique waveform curve identifier parameter.

A waveform curve receives data from a waveform trace via the mapping named by the mapping identifier parameter. The referenced trace mapping shall in turn reference a waveform trace, and this in turn refers to a (horizontal) track for the waveform curve plotting.

Waveform curve drawing takes place with respect to a specified waveform (rectangular) window, which is composed from an absolute vertical track and a horizontal track which is placed relative to the vertical coordinate of the current frame data for the referenced waveform track. The vertical track is defined by the waveform track identifier parameter of the waveform curve. The horizontal track is the track that is associated with the trace mapping identified by the mapping identifier parameter.

The waveform trace data samples are positioned for plotting as follows. The plotting ordinates are positioned uniformly between the lesser and greater boundaries of the track named by the waveform track identifier. This track should be orthogonal to the track associated with the trace mapping for this curve. Given:

The data plotting positions are computed as:

The plotting modes allowed for a waveform curve are normal, clip, and clamp, as defined in section 4.2.6.2.

A drawing style parameter specifies whether the curve is to be rendered as a polyline or a polymarker. The defined values are drawn and marked. For a drawn curve, the drawing properties are inherited from the line drawing attributes in effect at the time of the log curve definition (or supplied by the mechanism of trace-modulated attributes). A marked curve is displayed by placing a marker at each data position along the mapped trace. The marker attributes are inherited from those in effect at the time of the waveform curve definition. The marker colour may be trace-modulated.

The trace identified by such a mapping is only drawn if it is enabled for the longitudinal coordinate at which the trace data is received (see section 4.2.17).

The Waveform Curve object, just like all other drawable objects, shall not be referenced by any data primitives, nor does it carry any data that may be referenced by other drawable objects. It should only be referenced from within a log object group.

4.2.8.3 Waveform Area

A PIP/IV Waveform Area object is defined to be the area between two waveform curves, a waveform curve and a fixed (vertical) position, or two fixed (vertical) positions. The waveform area object is analogous in many ways to a Log Area object. Unlike log areas, which are most commonly drawn between two curves derived from log traces, waveform areas are most commonly drawn based on a single waveform trace and/or the boundaries of the "window" for that trace.

Waveform areas are defined in PIP/IV by the Waveform Area Definition ESCAPE. Each waveform area is identified by a unique waveform area identifier parameter.

Waveform area drawing takes place with respect to a pair of vertical boundaries and a pair of horizontal boundaries. Like waveform curves, the horizontal boundaries correspond to the boundaries of a vertical track identified by a waveform track identifier parameter.

The vertical boundaries are specified by a pair of parameters, the lesser boundary parameter and the greater boundary parameter. Each boundary may be either a fixed VDC value (vertical coordinate) or a trace mapping identifier associated with a waveform trace (i.e., defining the locus of a waveform curve). In the latter case, the boundary locus is as defined by section 4.2.6.2.

The appearance of a waveform area object is determined by two additional parameters, the fill mode parameter and the fill pattern parameter.

Like the Log Area object, the fill mode parameter has defined values fromto and between. It determines how the defined area is filled. In fromto filling mode (see Figure 7), the area is filled from the lesser boundary to the greater boundary at each longitudinal coordinate for which the lesser boundary value is less than the greater boundary position.

In between filling mode (see Figure 8), the area is filled at each longitudinal coordinate, regardless of the sense of relationship between the lesser boundary value and the greater boundary position. The fill pattern parameter specifies which pattern is to be used to fill the designated region.

The data plotting positions are computed as follows. Given:

The data plotting positions are computed as:

Note that these are the same transformation as are used to compute the plotting positions of the Waveform Curve object (see section 4.2.8.2).

Figure 7. Waveform Areas using filling: FROM curve TO baseline

Figure 8. Waveform Areas using filling: BETWEEN baseline and curve

For each index i, a quadrilateral region, as shown in Figure 9, is constructed and filled:

Note that the AG_i values are the WV_i values for the area's greater boundary and the AL_i values are the WV_i values for the area's lesser boundary. A "bow tie" quadrilateral (as shown in Figure 10) may result. In fromto fill mode, the amount of area that gets filled depends on the sense of the fromto option. Each quadrilateral region is filled according to the fill attributes in effect at the time the waveform area definition was encountered, or by trace-modulated attributes as appropriate.

Figure 9. Quadrilateral region

Figure 10. A "bow tie" quadrilateral

4.2.9 Azimuthal Images - Unwrapped Borehole-based Images

It is common practice to operate borehole tools which acquire image data. Some sensors operate by performing a helical scan of the borehole surface, and thus capture a full borehole image (a "full coverage" image) by obtaining a known number of image samples per revolution. Other tools have discrete sampling pads that only sense a part of the borehole wall. For these latter tools, the images extracted do not fully cover the borehole wall (a "partial coverage" image). Each pad's image only covers a small percentage of the borehole circumference. Because the sensing tool's rotational orientation can be determined by a "tool azimuth sensor", the image's orientation within the borehole can be determined.

Such "full coverage" borehole images are displayed in well logs by "unwrapping" the borehole cylinder so that normalized hole azimuth is plotted latitudinally, while borehole depth is plotted longitudinally. Using such an approach, images can be plotted by a defining a latitudinal area:

• longitudinal bounds are two successive borehole depths, mapped to be longitudinal coordinates;

• a longitudinal track is used to define the image's latitudinal extent;

• the area can either be a curve-modulated bi-tonal shading pattern or solid-filled with curve-modulated colour.

This approach will not work however for "partial coverage" images because the tool containing the sensor pads tends to rotate in somewhat a random fashion as it drawn up the borehole. Thus, the tool is likely to be at a different azimuth at each sampling depth, so the plot of an image from any single pad is likely to look like an "image strip" with a wavering boundary. As the tool's azimuth gets closer and closer to 360 degrees, more of the image must be wrapped around the track.

These sorts of plots require a special area shading primitive. This requirement is fulfilled in PIP/IV by the Azimuthal Image Shader Definition ESCAPE.

Each azimuthal image object is identified by a unique azimuthal image identifier parameter .

The image is rendered in the (vertical) track identified by a track identifier parameter. The left edge of the image starts at a position within that track derived from a log trace, via a trace mapping which is identified by a left edge mapping identifier parameter. The image extends for width VDC units. If left_edge + width exceeds the track's greater boundary, the remaining portion of the image that would extend beyond the track's greater boundary is to be drawn starting at the track's lesser boundary.

Image data is delivered to the Azimuthal Image object by the waveform trace identified in the image trace identifier parameter.

The image is to be constructed as a sequence of small rectangles. Each rectangle is width/n units wide, where n is the number of data samples delivered to the azimuthal image in each data frame, i.e., n corresponds to the number of data samples parameter of the waveform trace identified by the image trace identifier parameter. The height of the rectangles is determined by the difference in VDC longitudinal coordinates of successive image traces. Specifically, the data delivered by a given occurrence of a Log Data GDP is applied to the rectangles whose height is defined by that GDPs vertical coordinate and the vertical coordinate of the next instance of a Log Data GDP which delivers data to this object.

The colour of the rectangles is determined by using the image trace data as indexes into the CGM colour table. The data type of the waveform trace must be type IX.

Figure 11 shows a segment of a log containing four such images

Figure 11. A segment of a log containing four Azimuthal Images

4.2.10 Depth Indexed Objects -Tadpole and Fanplot

4.2.10.1 Principles

Well logs often contain special geophysical objects that are placed at specified longitudinal coordinates.The PIP/IV objects described in this section draw symbols that are used sufficiently often in geological plotting that special objects have been designed to encode them efficiently.

Some of these objects have one or more parameters expressed as an angle. Such angular parameters observe these conventions:

• 0 degrees is the +Y direction;

• +90 degrees is the +X direction;

• angles therefore increase "clockwise" (+Y to +X direction)

Note that this convention is opposite to the convention of the CGM standard itself (but the CGM standard also has no parameters representing angles).

4.2.10.2 Tadpole and Tadpole Curve

Tadpoles are marker symbols, drawn in a manner particular to well logs, whose drawn appearance is controlled by a number of parameters in the PIP/IV Tadpole and Tadpole Curve objects. They are called "tadpoles" because their body shape and tail often resemble frog larvae.

Each tadpole placement is specified by a position, a rotation angle, various "tail" attributes, and a colour. Tadpoles are similar in nature to area shading objects, where several longitudinal curves may be used to modulate various visual and geometric attributes.

The Tadpole Attribute Definition ESCAPE defines the basic visual and geometric properties of a tadpole, and the Tadpole Curve Definition ESCAPE then references that tadpole, plus a number of traces defining the placement positions and other properties.

Each tadpole object is identified by a unique tadpole identifier parameter.

The tadpole's body is a regular polygon whose number of vertices is defined by the number of vertices parameter. The polygon is inscribed in a circle of whose radius is defined by a body size parameter. The minimum number of vertices shall be three, which creates a triangle. Four vertices will create a diamond and a large number will approximate a circle.

The first vertex is drawn at 0-degrees on the circumscribing circle, plus an angular offset defined by an offset angle parameter. An offset angle of forty-five degrees will convert a diamond shape into a square.

Tails are lines that are drawn from the body boundary. There can be two tails. Whether or not the second tail is drawn is controlled by a parameter of the Tadpole Curve object (the Tadpole Curve Definition ESCAPE). The sizes of the two tails are defined by tail1 size and tail2 size parameters. The first tail is drawn at 0-degrees (after the body of the tadpole is generated, including offset angle).

Since an unrotated tadpole vertex starts at zero degrees, if the offset angle is zero, then tail1 will always touch one of the tadpole vertices.

When the tadpole is actually drawn by the delivery of data to a Tadpole Curve object, the entire tadpole including attached tail1 is rotated by data in the tadpole curve.

Tadpoles are actually plotted by the PIP/IV Tadpole Curve object. A tadpole curve is defined by a Tadpole Curve Definition ESCAPE. Each tadpole curve is identified by a unique tadpole curve identifier parameter. Each tadpole curve references a single tadpole definition, which is identified by the tadpole identifier parameter.

Figure 12. Tadpoles with various angle offsets and rotations

A tadpole curve definition references three other objects. The log trace mapping identified by the position mapping identifier parameter defines the latitudinal (horizontal) positions at which the tadpoles are to be plotted. See section 4.2.6.2. The longitudinal (vertical) position is supplied by the longitudinal coordinate of the Log Data GDP which delivers data to the tadpole curve.

The value supplied by the azimuth1 trace identifier parameter identifies a log trace which supplies a rotation angle for each of the tadpole placements.

If the azimuth2 trace identifier parameter value is non-null, then it identifies a log trace which specifies the angle at which tail2 is rotated from north when it is drawn. That is, tail2 is drawn at the angle given by the azimuth2 parameter after the tadpole is placed and rotated by azimuth1.

With the Tadpole Curve object, each of the tadpole's drawing properties (placement and rotation(s)) can be changed on a depth-by-depth basis. In practice, a data frame is defined that carries data to an named tadpole curve. Each data frame carries all of the drawing properties which are used to control the plotting of the tadpole named for this curve.

The colour and line style used to draw the tadpole, as well as any pattern for filling the tadpole interior, are derived from the current draw and fill styles in effect when the Tadpole Curve Definition ESCAPE is encountered. Dynamic colour and pattern changes may be accomplished via the Colour Modulation and Pattern Modulation ESCAPES.

All trace data affecting a tadpole curve - placement/rotation plus any modulated attributes - must be carried within the same data frame.

4.2.10.3 Fanplot and Fanplot Curve

A fanplot is a polar histogram whose frequency values are defined at a number of equally spaced azimuthal values. A single fanplot can be fully characterized by a size, center, a set of 36 azimuths.

Given a center at (C_x,C_y) and a set of 36 azimuths, a fan is drawn as follows:

      let maxi represent the index of the greatest azimuth
      for i = 0,...,35
      {
         if (draw_mode == normal)
            radius = size * azimuthi / azimuthmaxi
         else
            radius = 10 * azimuthi
            ang = 455 - i*10
            XSi = Cx + radius * cos(ang)
            YSi = Cy + radius * sin(ang)
            XFi = Cx + radius * cos(ang + 10)
            YFi = Cy + radius * sin(ang + 10)
      }
      moveto(XS0,YS0)
      for i =0,...,35
      {
         drawto(XFi ,YFi)
         j = (i+1) % 36
         if (XFi  != XSj || YFi != YSj)
            drawto(XSj,YSj)
      }
      drawto(XS0,YS0)
      let ang be the angle at which the greatest azimuth exists
      X = Cx + radiusi * cos(ang)
      Y = Cy + radiusi * sin(ang)
      moveto(Cx, Cy)
      drawto(X, Y)

Fanplot objects are defined similarly to tadpole objects in PIP/IV. The Fanplot Attributes Definition ESCAPE defines the basic visual and geometric properties of a fanplot, and the Fanplot Curve Definition ESCAPE then references that fanplot plus traces which define the placement positions and the azimuthal data.

Each Fanplot object is identified by a unique fanplot identifier parameter in the Fanplot Attributes Definition ESCAPE. The Fanplot Attributes Definition ESCAPE also defines the size of the fanplot by a size parameter. The draw mode parameter specifies whether the fanplot is constrained to lie within a circle or have its radii be scaled by a factor of 10.

The Fanplot Curve Definition ESCAPE provides the rest of the data needed to actually draw fanplots. The Fanplot Curve object is uniquely identified by a fanplot curve identifier parameter. A position mapping identifier parameter identifies a mapping and trace which supply the latitudinal coordinate of the plot position. The longitudinal coordinate is the coordinate of the Log Data GDP which delivers data to the Fanplot Curve object. Finally, an azimuth trace identifier parameter identifies a trace which delivers the azimuths for the drawing of the fanplot.

The remaining drawing properties for the fanplots in a fanplot curve are inherited from the current CGM drawing attributes, or else may be curve-modulated.

There can be at most, one fanplot per data frame record, but multiple fanplot symbols can be drawn from a single Log Data GDP by using multiple data frame records.

Figure 13 shows a log segment containing tadpoles and fanplots.

Figure 13. A dipmeter log segment containing tadpoles and fanplots

4.2.11 Trace Modulated Attributes

Sometimes in well logging, the visual attributes of a curve, area, tadpole curve, etc. are not fixed constants, but vary over the depth (or time axis) of the primitive. For example, it is typical to vary both the pattern and colour shading of a longitudinal area to display a borehole's lithology on a depth-by-depth basis. This modulated pattern and colour is accomplished by a two step process: for each particular depth, the modulating trace carries a value which specifies the desired property; for each modulated property (colour and pattern) the trace value is used as an index into a lookup table to provide a mapping to the desired display property.

The data type for any trace used in colour or pattern modulation must be IX.

The term "trace modulation" refers to the various methods in which any one of a well log object's drawing properties can be varied by specifying that property is "trace-driven" rather than being a constant. In these situations, the "modulating trace" carries values which are mapped into visual attributes. For example, when a colour is specified with a trace name, then data values of that trace will be indices into a colour lookup table, and object being drawn will be coloured according to the colour looked-up for that plot position.

PIP/IV supports the trace modulation of colour and pattern for the various PIP/III and PIP/IV well log objects.

Areas whose pattern or colour are modulated can also have separation lines drawn between their boundaries wherever a modulated attribute changes.

4.2.11.1 Colour Modulation

Sometimes it is desirable to change the colour of an object along the length of a well log object. The PIP/IV Colour Modulation ESCAPE provides such a capability.

Each Colour Modulation ESCAPE is parameterized by an object identifier parameter which identifies the object to which the colour modulation is to be applied. A trace identifier parameter identifies the trace object which is to supply the data (colour indices) for the colour modulation.

The type of the trace associated with trace identifier - log trace (vertical) or waveform trace (horizontal) - shall be the same as the type of the trace associated with object identifier of the object being modulated.

Table 2 lists those PIP/III and PIP/IV objects which may be referenced by object identifier.

The trace data is offset by the value of the colour table base parameter before being used to look up the colour in the CGM colour table. In some well log plotting systems, where multiple images are shown, it is possible to have a different colour table for each image. It is possible to simulate multiple logical colour tables within CGM's single colour table by populating the CGM colour table appropriately and using the colour table base parameter.

4.2.11.2 Pattern Modulation

Sometimes it is desirable to change the pattern of an object along the length of a well log object. The PIP/IV Pattern Modulation ESCAPE provides such a capability.

Each Pattern Modulation ESCAPE is parameterized by an object identifier parameter which identifies the object to which the pattern modulation is to be applied. A trace identifier parameter identifies the trace object which is to supply the data (pattern indices) for the pattern modulation.

The type of the trace associated with trace identifier - log trace (vertical) or waveform trace (horizontal) - shall be the same as the type of the trace associated with object identifier of the object being modulated.

As indicated in Table 3, only Log Areas, Tadpole Curves, and Waveform Areas may be pattern modulated.

The trace data is offset by the value of the pattern table base parameter before being used to look up the pattern in the CGM pattern table. In some well log plotting systems, where multiple images are shown, it is possible to have a different pattern table for each image. It is possible to simulate multiple logical pattern tables within CGM's single pattern table by populating the CGM pattern table appropriately and using the pattern table base parameter.

In some well log plotting systems, it is possible to modulate both the colour and binary pattern used for fill in lithology logs. In CGM the pattern definitions carry the colour. This requires a larger number of patterns that the system where a bitonal template is combined with foreground and background colours. For example, if a curve were to be modulated with 10 different bitonal patterns and 5 colours, this could be accomplished with two modulating traces. With CGM-style patterns, there would just be one trace, but it must carry 50 different indices, and the associated CGM pattern table would need up to 50 combinations entries.

This requirement has necessitated in PIP/IV the only change to the basic limits of core-CGM requirements of PIP/II - the increase in the maximum pattern table size from 1024 to 16384. See section 3.2.3.

4.2.11.3 Area Separator ESCAPE

Sometimes it is desirable to draw a separation line, from area's lesser boundary to the area's greater boundary whenever it's modulating pattern or colour changes. This desire is expressed by an Area Separator ESCAPE that specifies that an identified area is to have separator lines drawn between its lesser and greater boundaries. The line attributes are inherited from the current line attributes at the time the escape is encountered.

4.2.12 Data-Driven Displays

One of the distinctions between graphics for the E&P industry and other industries is that many of the pictures drawn are plots of data. It is common to define methods for delivering data to drawing primitives and then rely on numerous instances of this data delivery mechanism.

4.2.12.1 Data Frame Definition

A data frame is a data grouping mechanism that allows data to be carried for and delivered to one or more objects (i.e., traces) at the same longitudinal coordinate. The trace identifier list is a parameter of the Data Frame Definition ESCAPE.

Each trace shall appear in at most one Data Frame Definition.

While all the objects named in a frame receive their data at the same longitudinal coordinate, some objects may receive multiple data values. These values may affect not only plot position, but also several of a drawn object's visible attributes. Most plots contain traces which are sampled at different rates. Thus, it is reasonable to find plots containing multiple data frame definitions. The frames that carry the actual data may occur at either regular or irregular sampling rates along the longitudinal coordinate.

PIP/IV adds some new objects to the Well Log Extensions, but does change the rules about how data frames deliver data to traces. Trace data may be used by both PIP/III and PIP/IV objects, and both log traces and waveform traces may be delivered within the same data frame or Log Data GDP.

4.2.12.2 Frames of Trace Data

A frame of data is a collection of data values for a specific longitudinal coordinate. The data values are required to conform in number and type to the specifications given for the traces mentioned in the frame's definition (in the Data Frame Definition ESCAPE). The received data is to be distributed, in sequence, to the traces defined within the named frame. Frames of data are required to arrive in ascending longitudinal order. The manner in which a trace actually uses its frame data depends on the drawing objects that reference that trace, but it is common that graphic fragments, representing differences between a trace's current and previous data values, will be drawn into the final picture in the drawing order specified.

The data representations used within data frames match the type of data being delivered to the objects that do the actual curve drawing. For example, data that is used to specify the latitudinal position of a log curve might require a 16-bit integer, while data specifying colour or pattern index might be carried as an 8-bit unsigned integer.

In practice, it is typical to carry one data sample per longitudinal curve per frame. An often-used sampling rate is one sample every 6 inches. Curves whose sampling frequency is higher, such as one sample every 2 inches, can carry 3 samples per frame. Traces which carry several data values per frame are often called "fast channels".

Drawing is accomplished by using the trace data arrival to trigger the objects within the group which derive their data from the traces. The data is actually delivered by the Log Data GDP, which identifies the list of frame definitions to receive the data.

The group's objects are drawn in a priority order that is determined by the order in which they are defined in the Log Object Group. Objects that are defined first are drawn first. For a log curve whose trace receives a single data value, a single line segment would be drawn from the coordinate position <mapped trace data at previous coordinate, previous rendering coordinate> to the position <mapped trace data at current coordinate, current rendering coordinate>. When multiple data values in a data frame are sent to a log trace (i.e., "fast channel"), then the data values are still mapped, but they are positioned at equally spaced intervals between the previous rendering coordinate and the current rendering coordinate. Given n values, and a rendering distance called delta = (current rendering coordinate - previous rendering coordinate), the data values are placed at position(i) = previous rendering coordinate + (i*delta)/n  for  i=1,..,n.

The situation is slightly different for waveform traces. All the trace data delivered to a waveform trace from a data frame shall be used to plot an instance of the derived waveform curve or waveform area derived from that trace. The longitudinal coordinate is determined from the data frame itself.

While it is possible to define a unique frame for each trace, it is more typical to determine all the traces that have equivalent sampling rates and carry their data in a single frame. Allocation of traces to frames is at the convenience of the program generating the metafile. Traces for tracks having different orientations shall not be in the same frame definition.

4.2.13 Rendering Models

No E&P graphics standard is complete without a discussion of rendering. There has been considerable discussion as to what rendering model is implied or required for CGM. This section defines some of the algorithms commonly used and discusses rendering of the PIP/III and PIP/IV Well Log Extensions.

4.2.13.1 Immediate Rendering

The CGM standard clearly implies a temporal drawing priority, and in fact this is made normative by many profiles. PIP is such a profile - see Volume 1, section 4.3.12.1.

The CGM:1992 specification is moot on the issue of rendering algorithms. This is considered to be the business of interpreter implementations, and any algorithm is acceptable which produces the correct result. The correct result is unambiguous under CGM and a proper profile.

Many implementors have chosen a "render-as-you-go", Immediate-Rendering algorithm. In this form of rendering algorithm, it is expected that CGM graphic primitives are drawn as soon as they are encountered by the CGM interpreter. Given that the size of a picture is known, as defined by the VDC extent, this is possible to do. But, many pictures, especially those for the E&P Industry, require a very large VDC extent, and it is not practical to allocate enough picture memory to directly implement this "draw as you go" style.

Some implementors have dealt with this difficulty by devising schemes for handling drawing onto virtual paper. A mapping array which shows how to draw onto "pages" of this virtual paper is held in memory, and these pages are read into and written from memory as drawing takes place. These "private virtual memory systems" have the potential to be costly and inefficient.

4.2.13.2 Multi-Pass, Banded Rendering

An alternative to the Immediate Rendering approach is a "banded" approach. One variation of this is the Multi-Pass, Banded algorithm. In this algorithm an in-memory buffer is allocated, large enough to hold the rasters for a certain size band, extending across the paper, but limited in extent along the paper. During metafile interpretation, only those primitives that are contained within this band are drawn. Primitives that extend beyond the band are clipped to the band's boundary. When rendering for the band is complete, the raster buffer is written to disk or device and the process starts over. The metafile is "rewound", the band boundaries are updated to be the second strip across the paper, the metafile is interpreted and rendered for all the primitives which affect the second band, and the rasters are output. This process continues until all bands in the picture have been rendered.

This algorithm does not require a large amount of memory, only large enough to hold a band, whose size is presumably controlled by a command line switch given at renderer invocation. The drawback of such a scheme is that it requires that the metafile be interpreted many times, once per band. And, as the ratio of band size to plot size gets smaller and smaller, the number of passes over the metafile increases. Also, this scheme requires that the total metafile be available when the rendering starts, a situation which does not favor real-time plots.

4.2.13.3 Single-Pass, Banded Rendering

In a Single-Pass, Banded algorithm, banding is still used, but with the aid of some additional memory and/or disk storage. An intermediate (internal) representation is chosen for graphics primitives. Each primitive is converted into its internal form and written to a disk file for the band(s) within which it lies. Once the metafile has been banded, the rendering process itself can start. The primitives for each band are read into memory, sorted by drawing order, and then rendered in sequence into the raster memory for the band. Once a band is rendered, its rasters are output and the process can be repeated until all bands have been rendered.

This algorithm, while similar to the Multi-Pass, Banded algorithm, has the superior attributes that metafile interpretation takes place only once, and each primitive is only processed for the band(s) that it is drawn in. In general, each primitive is only handled twice, rather than n times as in n passes for a Multi-Pass algorithm.

4.2.13.4 Single-Pass, Continuous Rendering

This method uses instances of a synchronizing primitive, carried within the metafile, like the "Data Complete Coordinate" ESCAPE (DCC) in CGM*PIP (see Volume 1, section 9.3.9.2), to delineate where the band boundaries are. A generation program can take advantage of this feature by putting "just enough" metafile in each band so that rendering can take place in real time. As the metafile is interpreted, the contents of the current band are stored in internal form on a "waiting-to-be-rendered" list until the band boundary is encountered.

The definition of a DCC escape is that no metafile primitives that affect the current band will be encountered later in the metafile. This allows the renderer to switch from interpreting to rasterizing whenever the band boundary is reached. All elements on the "waiting" list which intersect the current band can be moved onto a "now-to-be drawn" list. The "now" list can be processed to render the current band, and any elements of the list whose extent does not exceed the band boundary can be discarded. Those elements remaining on the list will be drawn in future bands, and will be joined by other elements as the next band is processed. Once rendering for the current band is finished, the rasters for it can be output, and processing can switch back to metafile interpretation.

4.2.14 Rendering Algorithms and Drawing Priority

As explained in Volume 1, section 4.3.12.1, the CGM:1992 standard implies but is not explicit that the drawing priority of primitives in a metafile is temporal - later primitives overlay earlier ones. This can be modified slightly using the Segment Display Priority segment attribute when segments are in use. Profiles such as PIP have made the implication of temporal priority explicit.

A "draw as you go" rendering algorithm matches temporal priority display rules naturally.

The correct implementation of a delayed-rendering algorithm requires that the correct drawing order be maintained. This is accomplished by assigning a priority number to each primitive as it is encountered, before it is stored into the "waiting-to-be-drawn" list. This priority value stays with the object during the entire rendering process, regardless of whether it affects a single rendering band or all the bands within the plot. The assignment of sequentially increasing numbers as priority keys assures that the earliest primitives get the lowest priority while the later primitives get higher priority. When it comes time to render, items are moved from the "waiting" list to the "now" list, and placed in sorted order by increasing priority key. Then, the drawing process moves along the list, drawing each primitive encountered, in a low-priority to high-priority order. This maintains the initially imposed drawing order. In this way, a delayed-rendering algorithm may be used without fear of breaking CGM's drawing order.

4.2.15 Rendering Requirements for Well Log Extensions

The PIP/III and PIP/IV Well Log Extensions are devised to work properly under the following conditions:

• they will work with both an "immediate mode" and a "delayed" renderer

• when they are used in conjunction with the Continuous Rendering Escapes (see Volume 1, section 9.3.9 ):
  • the "Rendering Direction" lies along the path of paper movement (i.e., along the paper)

  • the "Data Complete Coordinates" increase along the rendering direction

• All CGM Identifiers used must be unique. They shall not be redefined.

4.2.16 Log Layers and Drawing Priority - the Log Object Group

Well logs can be fairly complex plots containing a number of drawn layers. A key to the correct rendering of a well log is to ensure that the various depth lines, shaded areas between curves, grid lines, and curves that are sandwiched together to make the log get drawn in the desired order. In typical, generic CGM graphics this is not a problem - the Temporal Priority Rule of CGM suffices, in combination with correctly chosen rendering algorithms.

However, the complex, interrelated, and persistent (defined once, with the definition and drawing action persisting over numerous rendering bands and data delivery frames) drawing objects of well log plots do present a problem. It can be extremely difficult (or impossible) for metafile generators to get the correct result in all required cases by relying solely on the Temporal Priority Rule.

PIP/III resolves this difficulty with the Log Object Group. The Log Object Group explicitly lists the objects to be drawn and the order in which they are to be drawn. Data delivery in PIP/III and PIP/IV is actually to Log Object Groups, not directly to Log Data GDPs.

In order that the contents of the metafile be consistent and interpretable, there are several rules that apply to the relationships between the objects in Log Object Groups, Log Data GDP, and data frame definitions:

• Each eligible PIP/III and PIP/IV object shall appear in at most one Log Object Group.

• All data to draw each object in a Log Object Group shall be delivered by each occurrence of the Log Data GDP which identifies that group.

• The list of traces which may be derived from the Log Data GDP for a Log Object Group shall be a subset of the list of traces which may be derived from that Log Object Group Definition.

The last rule needs some explanation. From each occurrence of a Log Data GDP can be derived a list of frame identifiers, which corresponds to a list of Data Frame Definitions. Each Data Frame Definition contains a list of trace identifiers, defining those traces which receive their data from the given Data Frame. Thus each occurrence of a Log Data GDP implies a list of traces which ultimately receive their data from the GDP. Each Log Data GDP delivers data to an identified Log Object Group. The Log Object Group may contain Template Use objects, Log Curve objects, and Shaded Area Objects. The defining ESCAPEs for each of the latter two point to defined Trace Mapping objects, each of which in turn points to a Log Trace object. Therefore each Log Object Group implies a second list of trace objects. The third rule above states a required relationship between these two lists of trace objects.

Table 4 shows which objects can be contained within a Log Object Group and why.

Table 4. Eligible Objects within Log Object Groups

Element	Log Object Group Element?	Reason
Tracktest	NO	This is not a drawn object
Raster Template	NO	Only a definition, only drawn via a Template Use
Run Template	NO	Only a definition, only drawn via a Template Use
Template Use	YES	May need to control when drawing is started and stopped
Log Object Group	NO	This is not a drawn object
Log Trace	NO	This is not a drawn object
Log Curve	YES	This is a drawn object
Shaded Area	YES	This is a drawn object
Trace Mapping	NO	This is not a drawn object
Data Frame	NO	This is not a drawn object
Log Data	NO	This triggers the drawing of a Log Object Group
Waveform Trace	NO	This is not a drawn object
Waveform Curve	YES	This is a drawn object
Waveform Area	YES	This is a drawn object
Azimuthal Image	YES	This is a drawn object
Tadpole Attributes	NO	Only a definition, only drawn via a Tadpole Curve
Tadpole Curve	YES	This is a drawn object
Fanplot Attributes	NO	Only a definition, only drawn via a Fanplot Curve
Fanplot Curve	YES	This is a drawn object
Colour Modulation	NO	This is not a drawn object
Pattern Modulation	NO	This is not a drawn object
Area Separator	NO	This is a drawing style for modulated areas.

4.2.17 Object Enabling and Disabling

Many of the graphical objects defined within a Well Log metafile will be drawn over a long longitudinal extent of the plot. Properly transformed instances or fragments of these objects are available for drawing whenever data arrives to trigger the trace from which these objects derive their positional information for drawing.

However sometimes it is necessary that an object not be drawn for some portion of this extent. The most typical case is when a trace has bad or absent data values over some longitudinal coordinate interval. Rather than removing all the objects based on the trace and creating new ones later, it is more efficient to disable the trace object at some longitudinal coordinate, and then enable it again at a later index.

PIP/III defines a means to control enabling and disabling of drawing objects. The Object Enable/Disable ESCAPE identifies a well log drawing object, identifies an enabling position in the longitudinal direction of the log plot, and specifies the enabling mode which is to take effect at that position - enable or disable. Not all Basic Well Log objects may be named in the Object Enable/Disable ESCAPE. In general, the "definition" objects may not be named and the "drawing" objects may.

The enabling position specifies a position along the track that the object is drawn in, a longitudinal coordinate, at which object drawing is to be enabled or disabled. Some objects, such as curves, may have multiple enable and disable positions. The enabling and disabling escapes need not be sent in a monotonically increasing or decreasing order, but must be sent before a rendering band in which they will take effect. Conceptually, the rendering model expects these to be retained in a longitudinally sorted order, so that objects may be turned on and off as object rendering enters an enabled region and the enters into a disabled region.

By default, an object is disabled everywhere initially. An enabling Object Enable/Disable ESCAPE must be given for the longitudinal coordinate at which drawing is to start, and a disabling Object Enable/Disable ESCAPE must be given for the longitudinal coordinate at which drawing is to stop. For depth lines and grids, it is typical to see just one enable and one disable.

For logging curves, enabling must also be done at the beginning of a log and disabling at the end. But when there is bad or "absent data" for some depth in the borehole, the associated curve must be disabled for the corresponding longitudinal coordinate at which bad data occurs, and then enabled again when good data is available. In this case, it may be either the curve or its associated trace or both which are disabled. Both the curve and its associated trace must be enabled for drawing to occur. This might happen quite frequently for a log containing many bad data values. Enabling and disabling commands must occur in the metafile before the occurrence of the VDC coordinate (or data delivered at the VDC coordinate) in the longitudinal direction at which they are to be effective.

A similar philosophy holds for the various curve objects defined within PIP/IV. Waveforms are a slightly different matter. There is no enabling/disabling for elements of an individual waveform instance. Enabling is done at the longitudinal depths at which the individual waveform traces occur. Either the entire trace is enabled or the entire trace is disabled.

Table 5 summarizes the rules for the Object Enable/Disable ESCAPE and the reasons for those rules.

Objects which derive data from multiple traces may only be drawn when all these traces are enabled.

4.2.18 Summary of PIP/III Object Dependencies

Figure 14, an annotated version of Figure 1, summarizes the relationships between Basic Well Log objects. The numbered references are explained below.

Figure 14. Annotated Hierarchy of PIP/III Objects

1. A Template Use references the Template that is to be drawn, as well as the Track in which it is to be drawn.

2. A Trace Mapping identifies the Log Trace that is to be mapped, and the Track into which it is to be mapped.

3. Both Log Curves and Log Areas derive their boundaries from specific Trace Mappings.

4. Log Object Groups list the Log Objects that are drawn whenever the Log Object Group is drawn.

5. A Data Frame lists the Log Traces for which Data Frame Records of its type carry data.

6. A Log Data GDP carries the Data Frame Records required to draw a Log Object Group for a depth interval along a log.

4.2.19 Summary of PIP/IV Object Dependencies

Figure 15, an annotated version of Figure 2, summarizes the relationships between Advanced Well Log objects and shows how they relate to Basic Well Log objects. The numbered references are explained below. Note that PIP/IV objects are in Bold and PIP/III objects are in Italic.

Figure 15. Annotated Hierarchy of PIP/IV Objects

1. PIP/IV adds Fanplot Curve, Tadpole Curve, Azimuthal Image, Waveform Curve, and Waveform Area as objects that can be drawn by a Log Object Group.

2. A Tadpole Curve identifies the Tadpole that it draws, as well as the Log Traces it uses to derive its position and orientation(s).

3. An Azimuthal Image identifies the Track in which it is drawn, the Log Trace that defines its left boundary, and the Waveform Trace from which it derives its data.

4. Both Waveform Curves and Waveform Areas derive their boundaries from specific waveform Trace Mappings.

5. A waveform Trace Mapping identifies the Waveform Trace that is to be mapped and the Track into which it is to be mapped.

6. A Data Frame lists the Traces for which Data Frame Records of its type carry data.

4.3 Encoding the Extensions

4.3.1 Overview

The following Well Log Extensions which comprise PIP/III and PIP/IV are defined in this section:

PIP/III:

PIP/IV:

4.3.2 Encoding Notes

The Well Log Extensions follow the format defined in Volume 1 of the CGM*PIP Specification. Each GDP or Escape is presented as:

<name of command> [Escape or GDP]

The syntax of the <member definitions> is as described in Volume 1, section 9.3.2.

4.3.3 Well Log GDPs

CGM:1992 defines a GDP as equivalent to a graphical primitive (therefore it has a Point List parameter), whereas an Escape is equivalent to an Attribute or Control function. This distinction was observed in the Seismic Trace extensions of PIP/I&II. Because of the procedural nature of the Well Log Extensions, the distinction between Escape and GDP is not as meaningful as in the Seismic extensions.

There is a single GDP defined in the Basic Well Log Extensions of PIP/III, the Log Data GDP. This GDP is also used for data delivery in PIP/IV.

4.3.3.1 Log Data GDP

4.3.4 Well Log Escapes

4.3.4.1 Track Definition

4.3.4.2 Raster Template Definition

4.3.4.3 Run Template Definition

4.3.4.4 Template Use

4.3.4.5 Log Trace Definition

        8: ix_IF8, 9: ix_IF16, 10: ix_IF32, 12: ix_R, 18:ix_UI8, 
        20: ix_UI32, and 22: ix_UI16

4.3.4.6 Trace Mapping Definition

4.3.4.7 Log Curve Definition

4.3.4.8 Log Area Definition

4.3.4.9 Log Object Group Definition

4.3.4.10 Da