[OpendTect_Developers] Developers Digest, Vol 8, Issue 10

[oemergenc at gmail.com]

Hey there,

is there any update on "Gearing up to next version of OpendTect" ?
Is it possible to build OpendTect against QT5.0.0?

cheers
Ömer


2012/11/27 <developers-request at opendtect.org>

> Send Developers mailing list submissions to
>         developers at opendtect.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.opendtect.org/mailman/listinfo/developers
> or, via email, send a message with subject or body 'help' to
>         developers-request at opendtect.org
>
> You can reach the person managing the list at
>         developers-owner at opendtect.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Developers digest..."
>
>
> Today's Topics:
>
>    1. Re: Data access & Seed point generation (Jaap Glas)
>    2. Gearing up to next version of OpendTect (Kristofer Tingdahl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Nov 2012 14:31:01 +0100
> From: Jaap Glas <jaap.glas at dgbes.com>
> To: developers at opendtect.org
> Subject: Re: [OpendTect_Developers] Data access & Seed point
>         generation
> Message-ID: <50AE2915.6010806 at dgbes.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi, David.
>
> > I added a callback to OpendTect, which triggers when any
> PlaneDataDisplay is
> > updating its data.
> > mCBCapsuleUnpack(const visSurvey::PlaneDataDisplay&,pd,cb);
>
> Where do you trigger it, in TextureChannels::update(.,.)? I think that is
> not even good enough, because it would not catch a change of color map.
> I cannot find one single location that is called by both changes of
> (1) attributes, (2) color maps and (3) dimensions.
>
> > I would prefer not to change OpendTect, but to implement everything into
> a
> > plugin. Is there a way to get a notification when any SceneObject is
> changed?
>
> At the moment, no. There is one for movements of scene objects, but not for
> textural changes on scene objects. Apparently, no-one ever needed such a
> callback up-to-now. However, if there is a need for it, we can include your
> improvements, after reviewing them, in a future release of OpendTect.
>
>
> Best regards,
>
> Jaap Glas.
>
>
> --
> -- dr. Jaap C. Glas
> -- Software Engineer
> -- dGB Earth Sciences
> -- Nijverheidstraat 11-2
> -- 7511 JM Enschede, The Netherlands
> -- jaap.glas at dgbes.com
> -- http://www.dgbes.com
> -- Tel: +31 534315155, Fax: +31 534315104
>
>
>
> On 11/21/2012 01:05 PM, David d'Angelo wrote:
> > Hi Jaap,
> >
> > during debugging of my problem, I accidentally a wrong call of
> > "tc2rgba_->createRGBA(image);" into the update function of the
> TextureChannels
> > class.
> >
> > void TextureChannels::update( int channel, bool tc2rgba )
> > {
> > if ( !tc_ )
> > return;
> >
> > SbImagei32 image;
> > const int curversion = channelinfo_[channel]->getCurrentVersion();
> > image.setValuePtr( SbVec3i32( channelinfo_[channel]->getSize(0),
> > channelinfo_[channel]->getSize(1),
> > channelinfo_[channel]->getSize(2) ), 1,
> > channelinfo_[channel]->mappeddata_[curversion] );
> >
> > tc_->setChannelData( channel, image );
> >
> > if ( tc2rgba && tc2rgba_ )
> > tc2rgba_->notifyChannelChange();
> >
> > //THIS CAUSED THE ERROR (added by myself)
> > //calculate an rgba image of the data
> > tc2rgba_->createRGBA(image);
> >
> > //some debugging code
> > ...
> > }
> >
> > I added a callback to OpendTect, which triggers when any
> PlaneDataDisplay is
> > updating its data.
> > mCBCapsuleUnpack(const visSurvey::PlaneDataDisplay&,pd,cb);
> > I would prefer not to change OpendTect, but to implement everything into
> a
> > plugin. Is there a way to get a notification when any SceneObject is
> changed?
> >
> > Cheers,
> > David
> >
> >
> > On 11/21/12 11:28 AM, Jaap Glas wrote:
> >> Dear David,
> >>
> >>
> >> In my previous reply I accidently wrote one erroneous line of code:
> >>
> >> >> pd->getChannels()->getChannels()->createRGBA( img );
> >>
> >> which, as you already discovered yourself, should have been:
> >>
> >> pd.getChannels()->getChannels2RGBA()->createRGBA( img );
> >>
> >>
> >> ================================================================
> >>
> >>
> >> But let's now look at your current problem:
> >>
> >> > mCBCapsuleUnpack(const visSurvey::PlaneDataDisplay&,pd,cb);
> >> > SbImagei32 img;
> >> > SbVec3i32 size;
> >> > int bytesPerPixel;
> >> > pd.getChannels()->getChannels2RGBA()->createRGBA( img );
> >> > unsigned char* data = img.getValue(size,bytesPerPixel);
> >> > int width = size[0];
> >> > int height = size[1];
> >> > int depth = size[2];
> >> >
> >> > std::cout << "image size: " << size[0] << " "<< size[1] << size[2] <<
> >> std::endl;
> >> > std::cout << "bytes per pixel: " << bytesPerPixel << std::endl;
> >> >
> >> > Output:
> >> > PIX Image size: 360 1167
> >> > PIX bytesPerPixel: 1
> >> >
> >> > The strange thing is that bytesPerPixel is always 1. I assumed I
> would get 4
> >> for
> >> > the RGBA image. It is also strange that I always get the same pixel
> size
> >> > regardless of the displayed size of the line (in my case I tried it
> with a
> >> > crossline). See the two attached screenshots.
> >>
> >> > Could you think of a reason for this?
> >>
> >> So far, unfortunately not. I did a test by adding your piece of code
> (below)
> >> to OpendTect and call it every time a visSurvey::PlaneDataDisplay is
> updated:
> >>
> >> > SbImagei32 img;
> >> > SbVec3i32 size;
> >> > int bytesPerPixel;
> >> > pd.getChannels()->getChannels2RGBA()->createRGBA( img );
> >> > unsigned char* data = img.getValue(size,bytesPerPixel);
> >> > int width = size[0];
> >> > int height = size[1];
> >> > int depth = size[2];
> >> >
> >> > std::cout << "image size: " << size[0] << " "<< size[1] << size[2] <<
> >> std::endl;
> >> > std::cout << "bytes per pixel: " << bytesPerPixel << std::endl;
> >>
> >> If I add an inline or crossline to the scene, or use their tabs to
> resize,
> >> I always get returned 4 bytes per pixel and what look like to be the
> >> correct dimensions. So it does not seem to be a bug in OpendTect.
> >>
> >> The only line I did not use is:
> >>
> >> > mCBCapsuleUnpack(const visSurvey::PlaneDataDisplay&,pd,cb);
> >>
> >> Are you sure you receive the correct plane over there?
> >>
> >> Otherwise we may start thinking about differences in the
> >> OpendTect versions we use. Which version are you using?
> >>
> >>
> >> Best regards,
> >>
> >> Jaap Glas
> >>
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Nov 2012 06:22:51 +0100
> From: Kristofer Tingdahl <kristofer.tingdahl at dgbes.com>
> To: "developers at opendtect.org" <developers at opendtect.org>
> Subject: [OpendTect_Developers] Gearing up to next version of
>         OpendTect
> Message-ID:
>         <CA+1cFj+v=
> bLwtO_koRnjavC+yy2T8F_Zj-8QymZ95rQU45rU+g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear developers!
>
>
> I write to give you a heads-up on our plans for OpendTect. We released
> version 4.4 this summer, and we are now in the middle of the release cycle
> where we are planning for the coming release, which either will be called
> 4.6 or 5.0 depending on marketing considerations later on. We are targeting
> releasing this next summer, but timing is at this time floating.
>
> There are however a couple of decision being made that will affect third
> party developers, and I want to give a heads up so you have enough time to
> adapt.
>
> *3rd party library dependencies
> *We are planning to switch from qt 453 to 500. We are currently adapting
> OpendTect to compile with the current beta, and we plan to do the switch
> when 5.00 is out (schedule before year end). We have also added dependency
> to the zlib which is built into QtCore. One news that some of you have
> requested is that we will put the entire Qt in "OD" namespace, so plugin
> developers may chose to have their own qt if desired. We will also put a
> prefix on the library file-names, to avoid clashes on the library loading
> as well.
>
> We are also moving from Coin3D to OpenSceneGraph, and we are currently in
> the middle of that switch. The content of our SoOD library is being moved
> to a new osgGeo library which we are making available t the community under
> the LGPL license (http://osggeo.googlecode.org) benefiting all
> geoscientific visualization. We are planning to use the next stable
> release, which should be out during the spring.
>
> *Compilers and platforms
> *Linux: We will build on RHEL/Centos 4, but we will use gcc463. The reason
> for the compiler switch is that we have had quite some problem with gcc 4.1
> used in OpendTect 4.4, and we want to have access to the atomic functions
> not present in gcc 3.4.
> Mac: We will aim to be build on MacOS 10.5, but may end up on 10.6 if we
> cannot get all libraries to compile on 10.5.
> Windows: We will remain on VC2010.
>
> These decisions are not written in stone, so they may change, and we are
> always listening to the development community for input on these matters.
>
>
> Thanks for developing on the OpendTect platform!
>
>
> Sincerely,
>
>
> Kristofer Tingdahl
> --
> Kristofer Tingdahl, Ph. D.
> CEO
> dGB Earth Sciences
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.opendtect.org/pipermail/developers/attachments/20121126/273ae9b2/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> Developers mailing list
> Developers at opendtect.org
> http://www.opendtect.org/mailman/listinfo/developers
>
> You receive this mail because you are listed on developers at opendtect.orgTo unsubscribe please go to
> http://lists.opendtect.org/mailman/options/developers . If you encounter
> any problems, please contact support at opendtect.org .
>
> End of Developers Digest, Vol 8, Issue 10
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendtect.org/pipermail/developers/attachments/20130111/7c31c801/attachment.html>