running phow_caltech101 stops in failure OSX 10.8.5 64 about vlfeat

I'm stuck at the same place - any word on what the deal is?

[vedaldi]

Thank you for reporting this problem. I can only assume that it is Octave-specific, since the library works correctly with MATLAB. Could you please confirm your environment?

Octave 3.6.4 on Mac OS X 10.8.5

Lewis Barnett
Dept. of Math and CS, University of Richmond

On Apr 7, 2014, at 2:36 PM, Andrea Vedaldi <[email protected]mailto:[email protected]>
wrote:

Thank you for reporting this problem. I can only assume that it is Octave-specific, since the library works correctly with MATLAB. Could you please confirm your environment?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-39766874.

I can offer a little more information on this problem. After applying the fixes to phow_caltech101 suggested by gmnamra, the error was occurring during the process of computing spatial histograms. In the loop over images, a call is made to getImageDescriptor with a file read in using the imread() function. This is an MxNx3 matrix from a .jpeg file.

In getImageDescriptor, the error occurs when vl_phow() is called on the image. By this point, the image has been passed through standarizeImage() (by the way, I suspect that name should be "standardizeImage"), which should have converted the image to single format.

vl_phow() passes each color channel of the image to vl_dsift(), which sometimes produces this error complaining that the image matrix isn't SINGLE.

This can be corrected by changing the parameter to vl_dsift() from ims(:,:,k) to im2single(ims(:,:,k)).

For whatever reason, if an rgb image is converted to single, then one color channel extracted, vl_dsift doesn't recognize the resulting 2D matrix as being type single, so it is important that the call to im2single operates on the final matrix going to vl_dsift.

With that fixed, octave gets past the image that was causing that error, but segfaults on a later image in that same loop.

If I could make a suggestion, the error message from the vl_dsift.c code produced in this case isn't as informative as it could be - the same error message is produced whether the image passed in is not grayscale or is not single. Splitting those cases out would be helpful. Maybe by definition an rgb image in matrix form isn't "single" format, but I was assuming that "single" format referred to the intensity values being normalized to be single precision floating point values between 0 and 1.