Where to place feature requests?
Bernd Hohmann
feature requests for the gui?
Or better discuss them here first?
My small wish: a flag in the "Images" list for multirow panoramas
0 = image is a nadir shot
1 = image is a horizontal shot
2 = image is a zenith shot
And then feed the CP detectors:
1) All nadir shots in a row
2) All horizon shots in a row
3) All zenith shots in a row
4) Nadir(s) to horizon(s)
5) Zenith(s) to horizon(s)
Maybe someone can do this with light hand (I'm not very keen in C++ GUI
development).
Bernd
--
Bernd Hohmann
Dipl. Organisationsprogrammierer
DV Sachverständiger & Gutachter
Höhenstrasse 2 * 61130 Nidderau
Telefon: 06187/900495 * Telefax: 06187/900493
Blog: http://blog.harddiskcafe.de
Yuval Levy
On October 31, 2010 03:13:09 pm Bernd Hohmann wrote:
> As a newcomer to the development process of hugin: where to place
> feature requests for the gui?
In the feature request tracker, currently at [0]
> Or better discuss them here first?
discussion here is a good idea anyway. The tracker is not very
user/discussion-friendly. Threads on Hugin-PTX can always be hyperlinked from
the tracker.
> My small wish: a flag in the "Images" list for multirow panoramas
>
> 0 = image is a nadir shot
> 1 = image is a horizontal shot
> 2 = image is a zenith shot
what for?
there is a more generic case: pre-distribution of the images based on shooting
pattern. Then the images would have y/p/r pre-sets and the above information
could be extrapolated.
> And then feed the CP detectors:
>
> 1) All nadir shots in a row
> 2) All horizon shots in a row
> 3) All zenith shots in a row
> 4) Nadir(s) to horizon(s)
> 5) Zenith(s) to horizon(s)
have you seen the relatively recent multi-row mode introduced by Thomas?
Yuv
[0] https://sourceforge.net/tracker/?group_id=77506&atid=550444
Bernd Hohmann
>> My small wish: a flag in the "Images" list for multirow panoramas
>>
>> 0 = image is a nadir shot
>> 1 = image is a horizontal shot
>> 2 = image is a zenith shot
>
> what for?
To define the shooting pattern.
2 examples:
A shot in the nature requires 6 shots around the horizon, one nadir and
at least 3 half-zenith shots where you can see the horizon in the lower
part of the image (trying to stitch an almost blue-sky-only zenith image
against the remaining parts of the pano isn't very funny).
A cathedral may require 6/1/1 only, some need 6/1/3.
I usually doing 6H, 1N, 6Z shots and sometimes even 12H shots to mask
out the tourists.
> there is a more generic case: pre-distribution of the images based on shooting
> pattern. Then the images would have y/p/r pre-sets and the above information
> could be extrapolated.
Ok. And what is your idea how to pre-distribute it?
> have you seen the relatively recent multi-row mode introduced by Thomas?
Sure, I'm using this mode for my ASIF wrapper. Either something is wrong
in Thomas implementation or I did something wrong: it simply counts
file_0+file_1, file_1+file_2 and so on.
Didn't found any special multirow feature.
Yuval Levy
> On 31.10.2010 20:41, Yuval Levy wrote:
> >> My small wish: a flag in the "Images" list for multirow panoramas
> >>
> >> 0 = image is a nadir shot
> >> 1 = image is a horizontal shot
> >> 2 = image is a zenith shot
> >
> > what for?
>
> To define the shooting pattern.
so I'd have to go over each image (potentially hundreds of them) and give them
a 0/1/2? inefficient.
> Ok. And what is your idea how to pre-distribute it?
first: assume there is a shooting patter - if the pictures are all over the
place, only manual positioning helps (and your 0/1/2 scheme is an incomplete
system for manual positioning)
so the whole patterns boils down to a "snake" from zenith to nadir or the
other way around. Can't know which one is which, so this must be manual
input.
> > have you seen the relatively recent multi-row mode introduced by Thomas?
>
> Sure, I'm using this mode for my ASIF wrapper. Either something is wrong
> in Thomas implementation or I did something wrong: it simply counts
> file_0+file_1, file_1+file_2 and so on.
>
> Didn't found any special multirow feature.
I would dare to hint at something on your end. Nothing wrong, you just
overlooked that this sequence is the "snake" going from zenith to nadir or the
other way around. It makes a simple and very powerful assumption: pictures
that are next to each other in the shooting sequence are also next to each
other in the panorama. good enough for CP detection.
So again my question to you: what for do you need to define the shooting
pattern for?
Yuv
Bernd Hohmann
>> To define the shooting pattern.
>
> so I'd have to go over each image (potentially hundreds of them) and give them
> a 0/1/2? inefficient.
Pardon me: you sound like my daughter in her younger years by mentioning
"hundreds". Why not thousand or a million shots for a pano?
6H 1Z 1N is common, 6H 3Z 1N usual, 6H 6Z 1N and 6N 6Z also.
No 100 shots. 10-12 shots. Maybe 18.
>> Ok. And what is your idea how to pre-distribute it?
>
> first: assume there is a shooting patter - if the pictures are all over the
> place, only manual positioning helps (and your 0/1/2 scheme is an incomplete
> system for manual positioning)
Well, if you're shooting your panos while doing the "Jumping Jack" I
understand your concern. Me (and likely most of the others) is shooting
360° around then zeniths and nadir.
> so the whole patterns boils down to a "snake" from zenith to nadir or the
> other way around. Can't know which one is which, so this must be manual
> input.
Yes, manual input. That was my proposal. So what is yours?
>> Sure, I'm using this mode for my ASIF wrapper. Either something is wrong
>> in Thomas implementation or I did something wrong: it simply counts
>> file_0+file_1, file_1+file_2 and so on.
>>
>> Didn't found any special multirow feature.
>
> I would dare to hint at something on your end. Nothing wrong, you just
> overlooked that this sequence is the "snake" going from zenith to nadir or the
> other way around. It makes a simple and very powerful assumption: pictures
> that are next to each other in the shooting sequence are also next to each
> other in the panorama. good enough for CP detection.
Unfortunately I don't make my panoramas in the order "column 1, column
2..." but "row 1, row 2".
If you ever used a panorama adapter / panorama head you know where the
"row order" comes from.
> So again my question to you: what for do you need to define the shooting
> pattern for?
Because your workflow is crackbrained?
Eric O'Brien
first, then the zenith, then the nadirs. That is, I don't proceed top
to bottom or bottom to top but shoot the middle row, the top "row" and
then the bottom "row."
For me, the assumption that "pictures that are next to each other in
the shooting sequence are also next to each other in the panorama."
will be incorrect.
On the other hand, if I (we) are shooting a sequence that is standard
for us, it seems that using a Template would work. Apply the template
would distribute the images in close to the correct locations on the
sphere. Then the trick would be to get the control point generators
to generate points only between adjacent images.
Next, it would be nice to specify a series of optimization runs (that
preferably could be run automatically). For example, first a series
of runs on the horizon row, then a series on the zenith using also the
horizon row's control points but *not* optimizing the horizon row this
time. Then a similar run for the nadir images. And now that things
are very close, maybe optimize the whole bunch again.
eo
Yuval Levy
> Pardon me: you sound like my daughter in her younger years by mentioning
> "hundreds". Why not thousand or a million shots for a pano?
Not pardoned. Your daughter in her younger year was probably brighter and
wiser than you. What kind of glasses do you wear? ever seen a tele-lens? you
seem to have a very very narrow vision, with the FoV of a 400mm lens.
Unfortunately you don't seem to see that far.
> 6H 1Z 1N is common, 6H 3Z 1N usual, 6H 6Z 1N and 6N 6Z also.
>
> No 100 shots. 10-12 shots. Maybe 18.
There is a guy in the room who has never heard of the gigapan? not only
short-sighted, but also deaf?
> >> Ok. And what is your idea how to pre-distribute it?
> >
> > first: assume there is a shooting patter - if the pictures are all over
> > the place, only manual positioning helps (and your 0/1/2 scheme is an
> > incomplete system for manual positioning)
>
> Well, if you're shooting your panos while doing the "Jumping Jack" I
> understand your concern. Me (and likely most of the others) is shooting
> 360° around then zeniths and nadir.
before speaking for "most of the others", you may want to do some research,
for example on Flickr. Most panoramas are shoot with very simple point and
shoot cameras, in the range of 28mm to 200mm, not with 8mm fisheye. I leave it
to you to figure out the math of the rows and columns @ 28mm, you seem to be so
smart.
> Yes, manual input. That was my proposal. So what is yours?
Don't assume that there is a zenith or a nadir. It is a needless
complication. Most of the time there is neither zenith nor nadir. Also for
sphericals. I have done most of my sphericals with either three around or six
around. No zenith/nadir. At this very moment I am processing a spherical -
15mm fisheye on a full frame camera. 6 around looking down 15° plus one zenith
and there is no need for a nadir.
I still don't see the purpose of your request other than complicating
something that does not need complication. The way Hugin works now is to
assume that *if* there is a zenith and a nadir, they are the first/last shoot
in the sequence. It works pretty well. For everything else, you can place
the images manually on the fast preview canvas and at some point position
information will be passed to the CP detector.
> >> Sure, I'm using this mode for my ASIF wrapper. Either something is
> >> wrong in Thomas implementation or I did something wrong: it simply
> >> counts file_0+file_1, file_1+file_2 and so on.
> >>
> >> Didn't found any special multirow feature.
> >
> > I would dare to hint at something on your end. Nothing wrong, you just
> > overlooked that this sequence is the "snake" going from zenith to nadir
> > or the other way around. It makes a simple and very powerful
> > assumption: pictures that are next to each other in the shooting
> > sequence are also next to each other in the panorama. good enough for
> > CP detection.
>
> Unfortunately I don't make my panoramas in the order "column 1, column
> 2..." but "row 1, row 2".
you are seeing the snake through dirty glasses. An overflying pigeon made a
poop on them. You tried to clean them with your handkerchief but you forgot
that you just blew your nose with it.
A snake going from zenith to nadir or the other way around does not
necessarily do so in vertical movements. picture a Z, not a N. You are
currently imagining a sequence of N next to each other, which you obviously
know it is the wrong way since you know how a panorama head looks like.
> If you ever used a panorama adapter / panorama head you know where the
> "row order" comes from.
At the moment I happen to have half a dozen such adapters, Over time I had
many more. I even built a few of my own, and I think you need to make some
homework and understand what you are talking about before making wrong
assumptions, wrong statements, and offensive comments.
> > So again my question to you: what for do you need to define the shooting
> > pattern for?
>
> Because your workflow is crackbrained?
Or your brain crackflowd?
Yuv
Bernd Hohmann
>> Because your workflow is crackbrained?
>
> Or your brain crackflowd?
Well - your pleading was the lowest of the low I ever had read.
All the best to your liver,
Bernd
Bernd Hohmann
> For me, the assumption that "pictures that are next to each other in
> the shooting sequence are also next to each other in the panorama."
> will be incorrect.
Same for me.
A rough selection into "nadir / horizon / zenith" should cover 95% (if
not more) cases.
> On the other hand, if I (we) are shooting a sequence that is standard
> for us, it seems that using a Template would work. Apply the template
> would distribute the images in close to the correct locations on the
> sphere. Then the trick would be to get the control point generators
> to generate points only between adjacent images.
Good suggestion.
I would accept such templates too, but this leads to the question "how
to input the sequence?" into the template.
I'm currently writing a wrapper around my ASIFT wrapper which asks for
the number of the Nadir/Horizon/Zenith shots - just to build its own queue.
And after reading Yuval Levy, its time for me to move my daily routine
of work into external scripts.
> Next, it would be nice to specify a series of optimization runs (that
> preferably could be run automatically). For example, first a series
> of runs on the horizon row, then a series on the zenith using also the
> horizon row's control points but *not* optimizing the horizon row this
> time. Then a similar run for the nadir images. And now that things
> are very close, maybe optimize the whole bunch again.
Yes, I'm missing this too.
On the other hand its difficult to put all this requirements under one
hat (or GUI).
keyrecorder, macrorecorder, scripting... hm...
Bernd
Eric O'Brien
Yuval's part could have avoided an escalation. :(
eo
Yuval Levy
> I will say that I think a slightly more tolerant original response on
> Yuval's part could have avoided an escalation. :(
here [0] is my original response. Would you please be so kind and point me to
which part of it is not tolerant enough to your taste?
Yuv (being way to tolerant of your bad habit of top posting [1])
[0] http://groups.google.com/group/hugin-ptx/msg/8a23f6f8a238c5e2
[1] from the netiquette http://www.faqs.org/rfcs/rfc1855.html "If you are
sending a reply to a message or a posting be sure you summarize the original
at the top of the message, or include just enough text of the original to give
a context. This will make sure readers understand when they start to read your
response."
Eric O'Brien
of Hugin. So the way to "input the sequence" would be to manually
adjust a project so that the positions of all the images are as you
desire, and saving that project.
Then probably copy it somewhere else to a new name that makes you
think of whatever pattern you used for shooting it. Later, start a
new project, import your image and Apply Template. I don't believe
there is an explicit "Save Template," and that might make the feature
less obvious to many users.
eo
Bernd Hohmann
Well - after reading the last postings from you: be well with the
project, I'm out from contributions and discussions.
Bernd
PS: yes - you scared away another hopeful member for the community.
Bruno Postle
> Well, this is an interesting point. I also shoot the horizon row
> first, then the zenith, then the nadirs. That is, I don't proceed
> top to bottom or bottom to top but shoot the middle row, the top
> "row" and then the bottom "row."
>
> For me, the assumption that "pictures that are next to each other
> in the shooting sequence are also next to each other in the
> panorama." will be incorrect.
The multi-row option is more sophisticated than this, matching
consecutive images is only the first step in the process. It is
able to deal with rows or columns in any order.
> On the other hand, if I (we) are shooting a sequence that is
> standard for us, it seems that using a Template would work. Apply
> the template would distribute the images in close to the correct
> locations on the sphere. Then the trick would be to get the
> control point generators to generate points only between adjacent
> images.
Yes you can do this in Hugin currently, use an existing project as a
template with the File -> Apply Template function, then use a
'prealigned panorama' control point detector preset.
This is definitely the most efficient way to align multiple
panoramas taken with the same setup.
Sorry, we are really suffering from a lack of documentation
considering how often we get requests for features that already
exist.
--
Bruno
Bernd Hohmann
> The multi-row option is more sophisticated than this, matching
> consecutive images is only the first step in the process. It is
> able to deal with rows or columns in any order.
Sure? I'd seen a process like 1,2 2,3 1,3 but nothing beyond this.
Bernd
Eric O'Brien
I appreciate you technical contributions to the project but I've grown
quite weary of your impatience and short temper with people who, even
slightly, might disagree with you or perhaps write something that
turns out not to be completely precise.
You often seem to work hard at MIS-understanding people's intentions
and quickly take offense at perceived slights. Why so sensitive?
Maybe some of your time would be better spent studying mediation or
taking an anger management class. I mean, you bother to work up some
outrage about top or bottom posting?? How tiresome. Go outside for
some fresh air. Practice your breathing exercises.
eo
Eric O'Brien
> On Sun 31-Oct-2010 at 14:20 -0700, Eric O'Brien wrote:
>
>> Well, this is an interesting point. I also shoot the horizon row
>> first, then the zenith, then the nadirs. That is, I don't proceed
>> top to bottom or bottom to top but shoot the middle row, the top
>> "row" and then the bottom "row."
>> For me, the assumption that "pictures that are next to each other
>> in the shooting sequence are also next to each other in the
>> panorama." will be incorrect.
>
> The multi-row option is more sophisticated than this, matching
> consecutive images is only the first step in the process. It is
> able to deal with rows or columns in any order.
Does this require using a pre-aligned panorama (as below), or is it
expected to succeed with images in the project in any order and all
beginning placed at 0, 0, 0?
>
>> On the other hand, if I (we) are shooting a sequence that is
>> standard for us, it seems that using a Template would work. Apply
>> the template would distribute the images in close to the correct
>> locations on the sphere. Then the trick would be to get the
>> control point generators to generate points only between adjacent
>> images.
>
> Yes you can do this in Hugin currently, use an existing project as a
> template with the File -> Apply Template function, then use a
> 'prealigned panorama' control point detector preset.
Out of curiosity, is it the *control point generator* that
"understands" to create control points only between overlapping
images, or is that some information that Hugin generates and passes to
the CP generators? Or...?
>
> This is definitely the most efficient way to align multiple
> panoramas taken with the same setup.
>
> Sorry, we are really suffering from a lack of documentation
> considering how often we get requests for features that already exist.
Since I believe you work with Linux, you may not be to aware of the
Macintosh text editor TextMate. The interface is very simple looking,
but it packs a *huge* amount of functionality. "Requests for features
that already exist" are fairly frequent on the discussion list. Also,
requests for help figuring out a complicated way to achieve something
when the right use of a menu command will do the trick. ;)
>
> --
> Bruno
>
kfj
On 1 Nov., 01:02, Bruno Postle <br...@postle.net> wrote:
> Sorry, we are really suffering from a lack of documentation
> considering how often we get requests for features that already
> exist.
might as well not be there. Someone has spent time and effort
implementing a solution to a problem they have seen, it's gone through
'peer review' and testing - but it can't be used by the general
public, because it's so obscure or badly documented hardly anyone can
figure it out.
The person implementing a feature is really in the best position to
document it, because they have the clearest insight in the feature -
why it was introduced, how it was implemented, how it can be used. But
of course it's much more fun just writing the thing and then moving on
to the next interesting problem.
What to do about it?
whith regards
Kay
john doe
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
T. Modes
On 1 Nov., 06:34, Eric O'Brien <eri...@extramonday.com> wrote:
> > The multi-row option is more sophisticated than this, matching
> > consecutive images is only the first step in the process. It is
> > able to deal with rows or columns in any order.
>
> Does this require using a pre-aligned panorama (as below), or is it
> expected to succeed with images in the project in any order and all
> beginning placed at 0, 0, 0?
The order is relevant, because as a first step is matches only
consecutive images.
> > Yes you can do this in Hugin currently, use an existing project as a
> > template with the File -> Apply Template function, then use a
> > 'prealigned panorama' control point detector preset.
>
> Out of curiosity, is it the *control point generator* that
> "understands" to create control points only between overlapping
> images, or is that some information that Hugin generates and passes to
> the CP generators? Or...?
calculates the overlaps and pass the information to the cp generator.
Thomas
Bernd Hohmann
>> Does this require using a pre-aligned panorama (as below), or is it
>> expected to succeed with images in the project in any order and all
>> beginning placed at 0, 0, 0?
>
> The positions of the images has no influence on the multi-row option.
> The order is relevant, because as a first step is matches only
> consecutive images.
What are the requirements for the output of the cp generator then?
Just asking because my wrappr for ASIFT uses the new multirow option but
as far as I can see the sequence is 1+2, 1+3, 2+3, 2+4 only.
Bernd