If a map template file is given to the --map argument of cam2map4stereo.py that specifies "LongitudeDomain = 180" and the input cube is in the western hemisphere (longitudes from 180 E to 360 E), the output projected cubes will be full of NULLs.
Although I have not tested, I suspect that if "LongitudeDirection = PositiveWest" were specified, this would also cause this behavior.
The problem is a combination of the map template parameters and some programming decisions we made within cam2map4stereo.py.
The short solution is to just remove the "LongitudeDomain = 180" line from the .map file, and then it will work.
Let's assume you have a HiRISE image with a longitude of 270 E, which is equivalent to -90 E.
Here is what is going on: cam2map4stereo first runs ISIS's camrange on each image to learn what the resolution and lat/lon bounds are. This ISIS program returns a lot of information (http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/camrange/camrange.html). Our cam2map4stereo looks into the "UniversalGroundRange" group to get the lat/lon bounds, these bounds are "LongitudeDomain = 360". So the longitude that we pull from camrange is 270 for our example.
When cam2map4stereo calls cam2map, it passes the worst common resolution and a set of lat/lon boundaries that are the mathematical intersection of the two footprints. To make cam2map take these arbitrary bounds, we set "DEFAULTRANGE= MAP" for cam2map.
What this means is that when cam2map is called it reads the .map file, and because DEFAULTRANGE=MAP, it makes the output cube and the output location calculation "LongitudeDomain = 180" (because that's what your .map file says). So for our example, when cam2map is in "LongitudeDomain 180 mode" and it looks out at lon 270, there are no source pixels out there (there are some only at around lon -90) so NULLs are written to the output cube. You'll notice that if you were working at E longitudes between zero and 180, the specification of 'LongitudeDomain' in your .map file is irrelevant to this 'location calculation' that cam2map does and it would work fine.
So in the meantime, a solution would be to just remove that "LongitudeDomain = 180" from your map template, and things will run just fine, and you can do a coordinate transform later (which is better than a resampling that gdalwarp does).
Alternately if you're really excited about working in -180 to 180 from the start, another work-around is to run cam2map4stereo.py as usual, but add the '-n' switch. This will cause cam2map4stereo to run camrange and instead of running cam2map, will just write out the command line it would have run to the terminal. You can then take the 0-360 longitudes there, manually convert them to -180 to 180 longitudes, and then cut and paste the cam2map command lines and run those manually, and you should be all set.
The solution that we should implement will be that if cam2map4stereo is given a .map file via --map, we will parse it for the "LongitudeDomain" and "LongitudeDirection" keywords, and use those to pull the correct min/max longitudes from the appropriate "LongitudeRange" group in the camrange output instead of just defaulting to pull the boundaries from the "UniversalGroundRange" group. And then things should work no matter what a user has in their .map file.
Fix for cam2map4stereo.py config bug issue #108