Installation not completed?

[JOSUÉ CASADO RABASCO]

I have followed the steps (the only one step) to install asp, but when I try 

./stereo --help

this error appears: ./stereo: 48: export: (x86)/NVIDIA: bad variable name

I'm using Linux in Windows by WSL.

Thanks,

Josué

[Oleg Alexandrov]

There is a good chance you installed ASP in a directory having spaces in its name. Not sure what your full path is. Also not sure about the NVIDIA thing. Maybe you can unzip it in C:\Users\YourName or something like that. 

We never tested Linux under WSL. I guess it should work since ours is a straightforward Linux build.

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/0f7997de-fbb4-47c4-b74a-4893f05fdb9an%40googlegroups.com.

[JOSUÉ CASADO RABASCO]

The directory path seems okey, don't know what can be the problem. All I have to do is  tar -xvf StereoPipeline-3.0.0-2021-11-29-x86_64-Linux.tar.bz2 in the c/users/tidop directory right?

[Tricia Nelsen]

Josué -

Have you had any luck solving this? I've tried installing in a couple different places, none with spaces in the path, and am getting the same error. Instead of "NVIDIA" it's saying "(x86)/Common:". I restarted WSL and my computer with no change. 

When I try --help with some executables that aren't unique to the ASP like xzmore and tput it doesn't give me bad variable name.

Thanks,

Tricia

[Oleg Alexandrov]

Well, (x86)/Common is likely a fragment of a path called " "Program Files (x86)/Common", so there is still a space somewhere. I think if you have some variables in your PATH with a space, it will complain, even if you don't use those variables. So you can check your PATH (also maybe LD_LIBRARY_PATH). Those can be set to something without spaces before ASP is called. 

This is in fact a simple problem to fix, and I hope to get it in a few days. Our scripts don't use quotes where they should, and I think that's what is causing the problems, but I'd have to look at this in detail to say for sure, which I hope to do next week.

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/f2ca2c00-481e-457c-8922-a0733813fc72n%40googlegroups.com.

[Oleg Alexandrov]

Thank you for the report. This was a bug. Traditionally on Linux, unlike on Windows, no spaces are used in directory names, and when they are used, many things break unless great care is taken. 

I modified our shell scripts which start the ASP tools to handle spaces by putting all the strings I could find in quotes. I tested that if ASP is in a directory having spaces anywhere in its full path, or if PATH, LD_LIBRARY_PATH, and ASP_PYTHON_MODULES_PATH have spaces, the tools will still run. My hope is that there's no strange case I did not consider, but it is hard to say for sure. 

The latest build at https://github.com/NeoGeographyToolkit/StereoPipeline/releases, for date 2022-01-20, has the changes.

[Tricia Nelsen]

Thank you for fixing this! I was able to find a way to change the Windows paths so there are no spaces, but you have to change it every time Ubuntu is opened, so this will save me some time, thank you.

Once I did get it running, however, when I ran mapproject I started getting a ton of tiles produced instead of one. My stereo images only cover about 5x5km area, any idea why this is happening? It doesn't happen when I run mapproject with conda.

[Oleg Alexandrov]

The reason mapproject produces a lot of tiles is because I changed its behavior so it starts multiple processes by default. The hope is that this will be faster than with one process, even for non-ISIS cameras (before, only for such cameras the tiling has happening).  

Hopefully those tiles get merged into one at the end. The default --tile-size is 1024. If you don't want tiles, you can increase this option value to something bigger than image size, such as 1000000. 

[Tricia Nelsen]

Ah, I see, I thought it was an error. Thank you!

[David Shean]

Hi Oleg,

Has anyone done any benchmarking with mapproject for non-ISIS cameras?  I’ve always seen excellent performance with single-process, multiple-thread mapproject for RPC and DG models.  Continuously hits all available CPUs at 100% and finishes relatively quickly.  

I’m thinking that the preprocessing and I/O to deal with 1000s ( >10K for large WV-3 image) of small tiles for large images will be detrimental, esp for Lustre file system (used on Pleiades and other HPC), which performs poorly with many small files.

I think there is still a separate mapproject_single utility in libexec.  Is that depreciated, and we should use this new large tile size option?  Thanks!

-David

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/CADDkNmOegKzfchv9zFiWfeRUW9MMv%3Dg18oO2JXkPZKf14mT5og%40mail.gmail.com.

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

David,

I spent same time understanding precisely why suddenly the multiple-tile functionality gets triggered in mapproject.

Even before, the tile size was 1024, and each time the user specified more than one process or more than one machine, it would get used that way, which I agree may not be great especially for RPC cameras, where the amount of processing is small, and I/O is a bigger issue.

Now, it started going through the multi-title logic when it detected there are RPC coefficients somewhere in in the input metadata that need to be saved in the final mapprojected image. Such metadata is easiest to deal with in the multi-tile framework (even if called for just a tile), as then a plain text VRT file is written, the RPC can be appended there, and then the VRT can be converted to TIF. The mapproject_single tool on its own can't do that. 

To make the whole process consistent, now I set the tile size for ISIS cameras at 1024 as it was, and for non-ISIS cameras at 5012, unless the user explicitly sets a value. Regardless of number of processes or machines. This may be some kind of compromise. 

The benchmarking you mention may not be so straightforward. Lustre does save individual files to individual disks, so I/O is done in parallel, at some level, as I know, and a big mapproject job split over many machines will still run faster than one on a single machine. Or even on a single machine multiple processes may write to multiple output files which may be faster than a single process. Especially for cameras where non-trivial processing happens per tile, such as DG and CSM camera model, unlike RPC which is very fast.

So, the hope is that a tile size of 5012 may be somehow in the ballpark, and the user can tweak that further depending on what their file I/O and camera type may be. How does that sound?

Oleg

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of David Shean <dsh...@gmail.com>
Sent: Friday, January 21, 2022 8:59 AM
To: Oleg Alexandrov <oleg.al...@gmail.com>
Cc: Tricia Nelsen <tene...@gmail.com>; Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] Re: Installation not completed?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/65391645-0207-49DC-BFA3-EDCEA3D19BED%40gmail.com.