[Developers] AttribDesc

Kristofer Tingdahl _no_spam_ at tingdahl.net
Fri Sep 10 14:54:22 CEST 2004


Dear Cesar,

I regret that the documentation is not very clear, and I will try to
clearify it as much as possible in the source-code, avaliable at next
release (but you will get it now!).

In the attribute engine of OD any number of attributes can be connected
to each other in a web of attributes, e.g. the output of an
Frequency-attribute can be used as an input to median filter.

The information about how the attributes are connected are stored in a
AttribDescSet. The AttribDescSet is a list of AttribDescs (+some
management functions).

Each AttribDesc represents one attribute that either can be stored
(StorageAttribDesc) or computed from a number of inputs
(CalcAttribDesc). Sometimes, the attribute has multiple outputs (such as
dip-calculation which has both dip in in-line and cross-line direction).
The user of the class must then select wich output that should be used
by calling AttribDesc::selectAttrib().

An algorithm can also have multiple inputs, which is queried with
AttribDesc::nrInputs(). For instance, the dip-algorithm mentioned above
has two inputs: the seismic data and the Hilbert-transform of the
seismic data.

Each AttribDesc in the AttribDescSet is identified with a unique number
named id (you can get it with AttribDesc::id().

Now when we want to set one attribute as input to another attribute, we
can do that with the following code:

AttribDesc* attrib1 = getFromSomewhere();
attrib1->selectAttrib(0);

AttribDesc* attrib2 = getFromSomewhere();
attrib2->setInput( 1, attrib1->id() );


That explains input id (the id of the attrib that should serve as
input), and input nr (specifies wich input that should be set).

At computation, the AttribDescSet is interpreted and a number of
AttribProviders are setup in memory. Each AttribProvider can compute (or
read from storage) seismic traces (SeisTrc) with the different
attributes. In contradiction to the AttribDesc (which is one object per
attrib), each AttribProvider can compute multiple attributes at the same
time as long as they originate from the same algorithm. For instance,
in-line and cross-line dip is computed by the same AttribProvider. The
two outputs are put in the same SeisTrc, but with different components.

So input component is simply which component on a seismic trace that
should be used as input.

I hope this makes it a bit clearer.

Please come back if you have any further questions,

Kristofer Tingdahl

-- 
Kristofer Tingdahl
dGB Earth Sciences
Mail sent to this e-mail address is not read. I can be contacted on
http://www.tingdahl.net/mail.php?id=kris




More information about the Developers mailing list