Windows: Hugin can not detect control points

can you please attach a copy of the temporary makefile?

Sure, see the attached file. It was left intact in my temp directory at f:\temp, after I made a modified copy (see above) and swapped the names before running make manually. Anything else has been deleted by hugin. Original full path name was F:\temp\ham35A4.tmp (I renamed id back to its original name).

It seems that you have unpacked Hugin into a c:\bin\Hugin... folder and not used the Installer provided on SourceForge.

Since you mention 2009.4: many things have changed in the preferences and the Installer takes care of them.

There is a button to reset the settings in the preferences. Can you try to hit that and see what happens?

If it does not help, would you mind trying to use the installer to install Hugin into standard location rather than unzipping the binaries into a custom folder? after that install worked, try again your custom-location binary (and it should work too).

Or, last but not least, can you start RegEdit on your system and delete the Hugin registry key?

Well, I'm somewhat unhappy when beta software shares a common set of preferences with the production version through the registry and needs installation. Anyway, I wasn't aware about that. No, I haven't reset any preferences so far, but I will try and report back. I'll do a backup of the registry key beforehand, just in case.

This could be related to a bug in GNU make. There are mentioned different bugs in relation to process_begin: e.g. http://savannah.gnu.org/bugs/?func=detailitem&item_id=28126 or http://savannah.gnu.org/bugs/?func=detailitem&item_id=16362

Some of these issues seems to be fixed in version 3.82 (but I'm not sure if the mentioned issue is fixed)

So maybe updating to gnu make 3.82 could help.

Yes, it's not nice when different versions of the software share a common set of preferences and now that we moved closer to running multiple versions at the same time (at least in Linux with the private libraries; in Windows this was already possible before) it would be a good things to save the preferences in a version-related file.

This means that we need to come up with:
1. a naming scheme so that different versions of the preferences can coexist
2. a migration process that when a newer version of Hugin is started for the first time, it checks for existing preferences and asks the users what to do: migrate them to the new version or start the new version from scratch
3. something to clean up residual preferences from previous versions

but this would be a new feature request.

I tried everything recommended (resetting preferences, trying again, deleting the registry key, trying again, ...) no change.

Finally I deinstalled all older versions of hugin, deleted the hugin registry key and did a fresh install using the installer. No change. make.exe from \program files\hugin\bin\ still chokes on the @echo line in the makefile (now from C:\Users\wolfgang\AppData\Local\Temp instead of f:\temp, because I didn't change the default).

process_begin: CreateProcess(NULL, echo Finding control points..., ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [all] Error 2

I haven't noticed any interesting changes in the registry key, btw, other than loosing my autopano-sift-c settings.

Betriebssystem: Windows NT 6.1 (build 7600)
Architektur: 32 bit
Freier Speicher: 2056828 kiB
Aktive Codepage: 1252 (Western European Windows)

Hugin
Version: 2010.4.0.c379b4821223 built by Matthew Petroff
Ressourcen-Pfad: C:\Program Files\Hugin/share/hugin/xrc/
Datenpfad: C:\Program Files\Hugin/share/hugin/data/

@tmodes:

The current beta comes with

c:\Program Files\Hugin\bin>make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for Windows32

after changing this to

C:\Program Files\Hugin\bin>make --version
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I still get

process_begin: CreateProcess(NULL, echo Finding control points..., ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [all] Error 2

Alas, that didn't help, either.

I finally grabbed the makefile again, while it existed, removed all those "@echo off" lines, and ran

F:\temp>c:makewing.exe -f ham332Amod.tmp all

That did it, sort of, but crashed one step later.

"C:/Program Files/Hugin/bin/icpfind" -o "C:/Users/wolfgang/AppData/Local/Temp/ha3319.tmp" "C:/Users/wolfgang/AppData/Loc
al/Temp/ha3319.tmp"

APSCpp, enhanced Autopano-sift-c
  Stereographic projection enabled.
Filename F:\bilder\processed\hugin\P1010257.JPG
  width 2560 height 1920 format 0 hfov 33.2292
  reduce size to 1600 x 1200
  use stereographic projection

===============================================================================
The use of this software is restricted by certain conditions.
See the "LICENSE" file distributed with the program for details.

The University of British Columbia has applied for a patent on the SIFT
algorithm in the United States. Commercial applications of this software may
require a license from the University of British Columbia.
===============================================================================

  7787 keypoints found

Filename F:\bilder\processed\hugin\P1010258.JPG"
Unsupported file format [F:\bilder\processed\hugin\P1010258.JPG"]: must have extension JPG, PNG, TIF, BMP or HDR
Syntax error: Not a valid image
0235199C
c:makewing.exe: *** [all] Error 1

Got it working, by trying and inspecting each step on the commandline.

The error in #9 was caused by an copy&paste error on my part, after deleting all preferences as suggested in #3.
There was a spurious double quote at the end of the CPG comandline in the preferences.If one looks hard enough, it is visible in #9. :-}

After repairing that and after placing an "echo.exe" in C:/Program Files/Hugin/bin/, which is a noop, as far as hugin is concerned, everything works as expected.

I guess neither the deletion of my old preferences nor using the installer nor switching make was necessary, but I haven't checked that. In addition, I suspect some of you having an echo.exe installed somewhere on your path. I don't.

Thank you for the comprehensive testing.

I subscribed Matthew Petroff to this report because he has taken up the task of producing the Windows distribution and because although he is a member of the Hugin Dev team I can not know if he receives emails for this report or not.

Agree that deletion of preferences and using the installer did not have any effect on this.

Agree with your analysis and the solution seems to be to include echo.exe with the next Windows distributions. Matthew?

I checked again. It works for me without external echo.exe (and I don't have an echo.exe in PATH).
So I would not include an additional external tool into the package.

@Wolfgang
Could you please try the following 2 ideas around the bug in gnu make:
1.) comment out the SHELL variable (remove the line SHELL="C:/Windows/system32/cmd.exe" or add a # before) in the makefile
2.) replace "@echo" with "@cmd /c echo" in the makefile (without the double quote)

If one the two works we can modify the makefile generation.

Tried it.

ad 1: doesn't make any difference, i.e. doesn't work.

ad 2: works. So does "@echo ... >con" (without the double quote).

Hello again. I believe I've found the real cause of the problem: I have a sh.exe somewhere on my path, which ist found by make (make from the beta just enumerates it, 3.82 does an open - CreateFile -, too, the effect is identical).

It isn't executed (procmon dosn't see it, a dummy sh.exe just containing "hey" has the same effect), but the mere existence of a file sh.exe in the path causes make to try to call an external echo. This is with SHELL = ..CMD.exe not commented out in the makefile. If I remove that dummy sh.exe from my path again, everything works out of the box.
I'm a bit in a hurry now, but if there are any further questions, feel free to ask.

Hello Wolfgang,

thanks for you help.

I tried also some things: the idea with @echo ... >con make problem with the display of the progress display - there are the echo lines missing; in the assistant makefile this does not make a big difference, but with the stitching makefile this removes some functionality.

So if it works for you now, we can leave the makefile as it is.

Ok, that's fine with me. Thanks for your helping!

the workaround solved the issue

I am getting the same problem but have no idea how to fix it, could you please explain in dummy talk how to fix this as I have no idea what you are talking about in this thread?

Thanks

Max