texturing_orthophoto_spotscale_additions branch odm_texturing issue

[mtrl]

I'm getting the following error when running the texturing branch against a data set at the "running texturing" stage. Is there a recommended virtual environment for development/testing? I'm testing on an Ubuntu 12.04.5 x32 machine on Digital Ocean's cloud. Log output here

Images attached

  - running texturing - 
OpenCV Error: Assertion failed (ssize.area() > 0) in resize, file /build/buildd/opencv-2.3.1/modules/imgproc/src/imgwarp.cpp, line 1428
Error in OdmTexturing:
/build/buildd/opencv-2.3.1/modules/imgproc/src/imgwarp.cpp:1428: error: (-215) ssize.area() > 0 in function resize

For more detailed information, see log file.


quitting cause: 
"/root/db/../OpenDroneMap/bin/odm_texturing" -bundleFile /root/db/reconstruction-with-image-size-1200/pmvs/bundle.rd.out -imagesPath /root/db/ -imagesListPath /root/db/reconstruction-with-image-size-1200/pmvs/list.rd.txt -inputModelPath /root/db/reconstruction-with-image-size-1200-results/odm_mesh-0000.ply -outputFolder /root/db/reconstruction-with-image-size-1200-results/odm_texturing/ -textureResolution 4096 -bundleResizedTo 1200 -textureWithSize 3600 -logFile /root/db/reconstruction-with-image-size-1200/odm_texturing/odm_texturing_log.txt
returned with code 256

[dbaldwin]

Same problem here. Here is the output of my log file which is fairly similar to @mtrl but obviously different version # for opencv:

Bundle path was set to: /home/ubuntu/caliterra/reconstruction-with-image-size-1200/pmvs/bundle.rd.out
Images path was set to: /home/ubuntu/caliterra/
Images list path was set to: /home/ubuntu/caliterra/reconstruction-with-image-size-1200/pmvs/list.rd.txt
Input model path was set to: /home/ubuntu/caliterra/reconstruction-with-image-size-1200-results/odm_mesh-0000.ply
Output folder path was set to: /home/ubuntu/caliterra/reconstruction-with-image-size-1200-results/odm_texturing/
The texture resolution was set to: 4096
The resized resolution used in bundler was set to: 1200
The resolution to texture with was set to: 3600
Log file path was set to: /home/ubuntu/caliterra/reconstruction-with-image-size-1200/odm_texturing/odm_texturing_log.txt
Successfully loaded 199906 polygons from file.
Successfully read the bundle file.
Successfully read the image list file.
Visible faces: 0
Occluded faces: 199906
Faces sorted into 1 textures.
Error in OdmTexturing:
/build/buildd/opencv-2.4.8+dfsg1/modules/imgproc/src/imgwarp.cpp:1824: error: (-215) ssize.area() > 0 in function resize

[smathermather]

I haven't seen this. Are you both running 32-bit machines?

[dbaldwin]

I'm running Ubuntu 14.04 64 bit. I've been looking into this some more and here is the line of code where the error occurs:

https://github.com/Itseez/opencv/blob/2.4.8.x-prep/modules/imgproc/src/imgwarp.cpp#L1824

Am trying to see if I can isolate the problem.

[mtrl]

I'm running Ubuntu 12.04.5 32 bit against this data set https://www.dropbox.com/sh/1rt1qdh7tw2mybi/AAAv7zukDC7fszyJMXfc5x8wa?dl=0 the geotaghed folder

[dbaldwin]

I may have found the issue here. It has to do with the pmvs output file. For example, the job I just ran had a list file at this location:

/mnt/odm_data/benchmark/reconstruction-with-image-size-1200/pmvs/list.rd.txt

I ran it on the odm_data benchmark folder:

https://github.com/OpenDroneMap/odm_data/tree/master/benchmark

Notice how those images all have caps .JPG file extensions? Well the list.rd.txt output looks like this:

./DSC05510.jpg
./DSC05511.jpg
./DSC05512.jpg
./DSC05513.jpg
./DSC05514.jpg
.......

This causes the OpenCV error mentioned above since Linux is case sensitive and can't find the file. I went and lowercased all the file extension in my benchmark folder to match the list.rd.txt file and everything finished processing.

[smathermather]

Sounds like a regression. I think earlier versions auto renamed such cases.
On Jan 15, 2015 1:13 AM, "Dennis Baldwin" notifications@github.com wrote:

I may have found the issue here. It has to do with the pmvs output file.
For example, the job I just ran had a list file at this location:

/mnt/odm_data/benchmark/reconstruction-with-image-size-1200/pmvs/list.rd.txt

I ran it on the odm_data benchmark folder:

https://github.com/OpenDroneMap/odm_data/tree/master/benchmark

Notice how those images all have caps .JPG file extensions? Well the
list.rd.txt output looks like this:

./DSC05510.jpg
./DSC05511.jpg
./DSC05512.jpg
./DSC05513.jpg
./DSC05514.jpg
.......

This causes the OpenCV error mentioned above since Linux is case sensitive
and can't find the file. I went and lowercased all the file extension in my
benchmark folder to match the list.rd.txt file and everything finished
processing.

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[bgirardot]

Bah, I should have read more carefully this thread, sorry I see you already had it figured out with the file names being case sensitive sorry for the bother.

[i--storm]

Confirm issue. All works fine after renaming file extensions to lowercase

[jmwhite]

FWIW here is a simple bash command to rename the files from the bash shell. It must be run from within the data directory:

for file in *.JPG ; do echo $file; mv $file basename $file .JPG.jpg; done

[smathermather]

It's interesting. I haven't been able to confirm this issue -- I've run it on directories with files named with JPG extension in caps without event.

Is this an artifact of file system, e.g. running in a shared NTFS directory on a Linux VM with a Windows host?

[dbaldwin]

Interesting that you can't reproduce. I've run into this multiple times on
Amazon EC2 running Ubuntu 14.0.4. All with photos that have caps extensions
(.JPG). I'm going to run another set over the weekend and will report back.

On Fri, Feb 6, 2015 at 11:27 AM, Stephen Mather notifications@github.com
wrote:

It's interesting. I haven't been able to confirm this issue -- I've run it
on directories with files named with JPG extension in caps without event.

Is this an artifact of file system, e.g. running in a shared NTFS
directory on a Linux VM with a Windows host?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[smathermather]

Have you tried on a local vm?

[dbaldwin]

No, but I'll see if I can setup Vagrant on my Mac and give it a run there.
I do have a PC where I may be able to give this a try as well.

On Fri, Feb 6, 2015 at 4:50 PM, Stephen Mather notifications@github.com
wrote:

Have you tried on a local vm?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[smathermather]

Thanks @dbaldwin.

[glw]

Hi, I was running into a problem with the texturing as well, when I found this open issue. I am running Virtualbox on windows8 64, virtualmachine is ubuntu 64 14.04. Originally I ran a subset of @dbaldwin caliterra images with the upper .JPG as the file extension and got this error message:

Error in OdmTexturing:
Error in OdmTexturing:
Failed to read image:
'/home/user/source/OpenDroneMap/test//IMG_9427.jpg'

** Notice the incorrect path with double '/' as well as the lower .jpg.

I re-ran the same imagery with lower .jpg extension with a successful output.

[smathermather]

Finally replicated myself. I'm not sure why I wasn't seeing this before, but it needs a patch, perhaps a little rename for upper case extensions at the start of the script. Anyone want to take a crack at it?

[dbaldwin]

@smathermather I'm currently running a job with vagrant_odm using Ubuntu 12.04 32 bit. I'll see what happens there. Then I'll try the same with 64 bit. I'll see if I can give the extension rename a try in the next day or two.

@glw thanks for confirming. FWIW the double slash isn't a deal breaker, but would be nice to clean up. Linux will still be able to find the path.

[w0rcy]

@jmwhite, I haven't gotten your script to change to lower case .jpg to run, but I think I do not understand how to use the highlighted section in the middle. Can you give an example of how that line is used?

[bgirardot]

@w0rcy I don't know if it is on every system, but on my deb/ubuntu VMs I just do this:

cd /directory_of_images
rename 'y/A-Z/a-z/' *

It just makes everything in the filename lowercase, but that is fine for my needs.

[w0rcy]

Thanks, @bgirardot. All lower case is fine with me. Thanks also to all who are working on this software. I have been running tests on your odm_data and on my own and it is getting better all the time.

[smathermather]

I like that @bgirardot -- my approach is more crude:
for file in *.JPG; do mv "$file" "basename $file .JPG.jpg"; done;

[smathermather]

Fixed the datasets as a work around until we have a patch for automatically handling this in the codebase:

OpenDroneMap/odm_data_apt@0ece0bf
OpenDroneMap/odm_data_benchmark@2ccef98
OpenDroneMap/odm_data_caliterra@cb3476a
OpenDroneMap/odm_data_copr@faa0753
OpenDroneMap/odm_data_glam@82e18fa
OpenDroneMap/odm_data_langley@b28267b
OpenDroneMap/odm_data_pacifica@76ab267

[dbrgn]

As we see here...

quitting cause:
"/code/bin/odm_texturing" (...)

...the error message occurs in the odm texturing program.

The main error message is Failed to read image: '/images//DSC05275.jpg'. When looking at odm_texturing/src/OdmTexturing.cpp, I can find this message only in one place: OdmTexturing.cpp#L359-362:

// Read image to get full resolution size
cv::Mat image = cv::imread(cam.texture_file);

if (image.empty())
{
    throw OdmTexturingException("Failed to read image:\n'" + cam.texture_file + "'\n");
}

So the problem seems to come from the fact that cam.texture_file (and thus the bundle file) contains lowercase instead of uppercase filename endings.