<div dir="ltr"><div><div>Will do! I am very grateful for your support.<br><br></div>All the Best,<br><br></div>Pol<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 4:37 PM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 16, 2016, at 10:12 AM, Helimap Postmaster <<a href="mailto:postmaster@helimap.ch">postmaster@helimap.ch</a>> wrote:<br>
><br>
> 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.<br>
<br>
</span>Indeed it does not. It's just a top-down projection.<br>
<span class=""><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>The default pdal::PointTable storage implementation doesn't contiguously allocate.<br>
<br>
Note that my calling things The Hard Way was not meant to imply it was The Wrong Way :)<br>
<span class=""><br>
> 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.<br>
><br>
> 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?<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span></blockquote></div><br></div>