Subscribe to this thread
Home - General / All posts - Visible Pixels
joebocop
514 post(s)
#26-Mar-14 04:19

Hello all,

I am trying to calculate an output surface where each pixel's value is the number of pixels "visible" from that location in the input surface. Alternately, it might be useful to be able to specify a search radius as well, but not necessarily.

I tried creating a vector point feature at the centroid of every pixel and then using the Drawing - Visible Areas tool, but the processing time was undetermined, and I cancelled after 3 hours. The surface is roughly 25 million pixels in size.

Is there an way of creating this surface using the Surface - Transform dialog, or with SQL?

Many thanks, as always.

tjhb
10,094 post(s)
#26-Mar-14 05:23

I think you're right that there's no realistic way to do this at present. (Not in a reasonable amount of time--your attempt is all I can think of too.)

But it would be an ideal function to implement in GPGPU.

I hope you will consider formally requesting it. (Be sure to state *why* you want to see it implemented--i.e. its real world use, something like a business case.)

tjhb
10,094 post(s)
#27-Mar-14 00:22

I have worked on something similar to what you are trying to do. Our objective was to produce surfaces showing the number of structures (electricity pylons) visible from each elevation pixel, and also their visibility impact for each pixel (discounted for distance).

In this case there were 180 structures (points) and the target surface had 16 million visible pixels.

The beginning of the workflow was to create viewsheds for every point. For this, rather than using UI scripting in Manifold, we used Global Mapper, which has a built-in option to create viewsheds for multiple selected points, as well as allowing for the curvature of the Earth, and to specify the height of the observer as well as each structure.

The structures were subdivided and processed in multiple instances of Global Mapper at once (crude parallelism). It took a more-than-trivial amount of time.

The combined output was a set of 180 overlapping areas—one complex area (usually multipart) showing the viewshed for each structure. Manifold SQL was then used to sum, for each surface cell, the number of viewshed areas with which it intersected. It wasn't as simple as that in practice—the size and complexity of the data meant it took some effort to produce a workflow and code that would complete in a reasonable amount of time.

For you, it is probably out of the question (for now) to create viewsheds for every surface pixel, unless you have a very coarse surface. Well, that is one option (at the cost of relevant detail, obviously). A better option may be to create surface-specific points (as implemented in SAGA for example), that is, points marking peaks, saddles and possibly others—which are probably the best candidates for places to view terrain from (common sense is sometimes right).

You could treat this moderate number of potential viewpoints in more or less the same way we treated structures—though conceptually, the line of sight would run in reverse.

There has to be a better way though, right? This is a case (well, two cases) where a seemingly simple question (in human terms) can easily consume a massive amount of development and processing time. It seems an ideal task for GPGPU execution.

I hope you do take the time to outline what you want Manifold to do for you "out of the box", and why, and send the request to Sales.

joebocop
514 post(s)
#27-Mar-14 04:56

Thank you very much for giving it some thought on my behalf, and for sharing your particular case.

I came to the same conclusion -that to select a subset of locations from which to generate the viewsheds is the only realistic way forward. To that end, I have used a landform classification raster (created earlier on this same project) to specify various ridge and hilltop positions from which to begin the analysis. Like you, I have used GlobalMapper to perform the viewshed analysis from multiple points.

Really, the reason I had posted the question initially was because I just assumed there would be a GPGPU way to achieve this in Manifold; it does seem a ripe candidate. The problem really does seem to be an amalgam of several other workflows whose solutions are easily acheived with Manifold.

Again, my thanks for the advice. I will indeed craft a suggestion and send it along to sales.

tjhb
10,094 post(s)
#27-Mar-14 05:58

That's great, and I agree with all your points.

I will also send in a request.

joebocop
514 post(s)
#27-Mar-14 20:24

Luckily, there's this guiding document to help me along:

http://eprints.ucl.ac.uk/191/1/kim.pdf

Had I not skipped those 4 years of college mathematics where this topic was doubtless covered in specifics, I'd be well on my way to implementing a workable solution.

joebocop
514 post(s)
#27-Mar-14 21:47

For those who in the future stumble onto this thread and are in a hurry to create themselves a "visibility index", I have found this tool to handle the job (in the supposed future absence of facilities within Manifold to directly accomplish the task):

http://www.uoguelph.ca/~hydrogeo/Whitebox/

In keeping with tradition, I have attached a screenshot of the Windows task manager during a visibility index operation. GPGPU, save me now!

Note that this operation is incredibly CPU-intensive, and each redoubling of the study area increases processing time by n^2.

Attachments:
max_power.PNG
max_power_cores.PNG

joebocop
514 post(s)
#22-Mar-17 16:30

With the release of Radian 9, does anyone think it makes sense for me to re-submit my suggestion from 3 April 2014?

Calculating a visibility index for every pixel in a raster still would be useful to me, but there still are no tools available to handle these truly large computations.

Perhaps R9 already has a GPGPU means of calculating this?

adamw


10,447 post(s)
#23-Mar-17 07:16

If you still need that, of course, resubmit the request.

Out of curiosity, how are you going to use the visibility index after it is computed? Because if you are going to use it as an intermediate step to perform further computations, it might be that computing the end result is easier.

joebocop
514 post(s)
#24-Mar-17 16:56

Thank you.

The goal here is to identify "viewpoints" by determining which pixels can see a large number of other pixels. With the visibility index image, we'd then select for high values within certain landform neighbourhoods (those landforms are the product of a TPI workflow).

So, useful (for me) only in conjunction with the landform classification image, but I can't imagine combining the two into a single function would be better in any way.

adamw


10,447 post(s)
#24-Mar-17 17:10

Is there also a requirement to select N viewpoints which together see the highest number of pixels possible? Because that "together" does not seem simple even if the visibility index is already computed.

Overall, it seems to me that it makes sense to reduce the resolution of the image significantly to compute a very rough visibility index, then compute a more precise index for pixels that were the highest in that rough index, etc. That wouldn't be exact, but then what is that "exact" that is practically obtainable (if the requirement is, again, to select a set of pixels maximizing visibility from any of them, the exact solution seems prohibitively expensive at least on first glance - although perhaps there's some clever math that proves otherwise)? Just thinking out aloud.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.