From: Tom S. <tks...@gm...> - 2010-01-14 18:15:42
|
Hi hugin developers, The general Pannini projection is very close to working with the current hugin preview windows (which are greatly improved, thanks very much). The only problem is that the hFOV slider behaves badly when you change the compression parameter. The problem seems the same for both the slow and fast previews. This must have something to do with the fact that the max feasible hFOV for this projection varies with compression: from a bit under 180 deg at minimum compression (same as rectilinear) , to a bit under 360 deg at standard compression (same as equirectangular panini) and back to 180 at max. compression (orthographic). However the hFOV limit actually set on the slider seems to be about half the expected value, in most cases. I have no idea how these numbers are arrived at. The function, getMaxHfov(), in PanoramOptions.cpp, seems to get called when the preview needs to check for a feasible hfov. It calls panoProjectionFeaturesQuery() in libpano, which I know for a fact currently always returns 320 degrees as the max hFOV for panini_general. The true hFOV limit is not computed until setMakeParams() calls setup_panini_general() to process the parameters, preparatory to running a transformation stack. And all it does is clip the requested hFOV. Naively I would expect the hFOV limit to always be 320, since that is what getMaxHfov() returns; but clearly there is something more going on. I hope one of you can enlighten me on that. Meanwhile it does seem there needs to be a way to send projection parameters to libpano and get back the corresponding hFOV limit. I think that requires a new API, because adding an argument list to panoProjectionFeaturesQuery() would likely break several unrelated things. So I propose to add a function to libpano: getFOVLimits ( proj, ¶ms, &lims ) which will set lims[] to {hFOV,vFOV} according to the passed params[], defaulting to the constants returned by panoProjectionFeaturesQuery() in most cases, but computed values for the general Pannini (and Albers conical ?). In hugin I would make getMaxHfov() call the new API, then hugin could at least start off with some realistic numbers. Another useful behavior for the preview windows would be default values for the projection parameters, and a button to reset them. Then the panini_general compression parameter could be displayed as a more intuitive "0 to 150 percent" instead of having zero in the middle. To support that possiblility, I propose to add a default value field to the struct returned by panoProjectionFeaturesQuery(). I assume constant default values are acceptable. I think all values in the panoProjectionFeaturesQuery() struct should be treated as constant limits for the the projection, and anything dynamic should be handled by a new API. Regards, Tom |