[pdal] Change the pdal container

[Helimap Postmaster]

Will do! I am very grateful for your support.

All the Best,

Pol

On Wed, Mar 16, 2016 at 4:37 PM, Howard Butler <howard at hobu.co> wrote:

>
> > On Mar 16, 2016, at 10:12 AM, Helimap Postmaster <postmaster at helimap.ch>
> wrote:
> >
> > It's not a 1to1 colorization. I didn't go into detail: I am projecting
> the images using the intrinsic and extrinsic coordinates of the images,
> which are geolocalised. Thus, there is some computation involved. My
> educated guess is the filter does not do that, given that the camera
> parameters are not part of the input.
>
> Indeed it does not. It's just a top-down projection.
>
> > Is the tiling really that rellevant here? Since I am colorizing a point
> cloud and each point is independent, 'tiling' could also mean grabbing N
> points per iteration. There is no blending necessary. Take one point, find
> the appropiate image, reproject to the image, get pixel color, save
> point+color. I'd like buffered reading for the I/O efficiency.
> >
> > I haven't brought the tiling to the mix, I didn't deem it rellevant at
> the time. But that's not really important because the las clouds usually
> fit in memory, the only possible problem being the contiguous memory
> allocation.
>
> The default pdal::PointTable storage implementation doesn't contiguously
> allocate.
>
> Note that my calling things The Hard Way was not meant to imply it was The
> Wrong Way :)
>
> > I can comment that on another application we have we do tile. Good to
> know that the usual way is paralellize per tile rather than per pixel. My
> guess to doing it The Hard Way was related to the amount of points and
> images loaded into memory. First, there are less cloud points loaded at
> once (at least the rgb cloud can be kept at tile-size), and second if I
> process per-pixel, less images will be concurrently loaded, since threads
> can share images while coloring. With 15 gb of ram, no more than 30 images
> should be loaded.
> >
> > In this second application's context, loading and unloading images takes
> as much time as coloring the clouds[1], that's why I was a little biased so
> that the processed points would be close to each other. But taking into
> consideration your comment, it might work just as well paralelizing per
> chunk... I would have to think about it, but we might be drifting to
> another discussion?
>
> It seems to me you want fine(er) control over how PDAL stores its data
> without having the copying overhead. To do that, you need to implement your
> own PointTable/PointView. There are examples of folks doing that.
>
> Howard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20160316/03250c7b/attachment.html>