Idea for horizontal/vertical lines
Lukáš Jirkovský
think hugin could make use of a similar tool to the tool proposed on
Rawtherapees forum.
Long story short. Currently there is only one way how to specify
horizontal or vertical lines. For defining either of them you need to
manually specify control points. This is not very user friendly and it
can take a lot of time. The idea is to allow drawing the lines in fast
preview window. There would be two new tools in Fast Preview window –
draw vertical line and draw horizontal line. User then would just draw
the line over the image and hugin would automatically add control
points defining line here.
[0] http://rawtherapee.com/forum/viewtopic.php?p=17063#17063
Bart van Andel
started using it, it just didn't bother me enough to file a request I
guess (or it didn't cross my mind).
But now we're at it: we'd need 3 tools actually. Besides horizontal
lines (lines at the equator) and vertical lines (lines perpendicular
to the equator) there is a third type of line, referred to as "add new
line" in the control point interface. This is a general type of line,
IIRC this just means a straight line in any direction (maybe someone
has a better definition?). I've used it in a couple occasions, maybe
only with rectilinear output, I don't remember. Anyway, it should
definitely not be forgotten, if this feature request is accepted and
implemented.
By the way, I believe we had someone working on line detection in the
past (GSOC project)? Has this resulted in anything but a dead branch?
I remember uploading some test images but I don't think I ever read
anything about results...
--
Bart
On 7 dec, 21:20, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> Today I've found an interesting idea for RawTherapee project [0] and I
> think hugin could make use of a similar tool to the tool proposed on
> Rawtherapees forum.
>
> Long story short. Currently there is only one way how to specify
> horizontal or vertical lines. For defining either of them you need to
> manually specify control points. This is not very user friendly and it
> can take a lot of time. The idea is to allow drawing the lines in fast
Yuval Levy
> Today I've found an interesting idea
excellent idea! put in output space (fast preview) what is related to output
space (lines) instead of cramming it into input space (cp tab).
I would say: file a feature request in the tracker, tag it as gsoc (could be
an interesting gsoc project, or at least part thereof).
Yuv
kfj
On 7 Dez., 21:20, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> can take a lot of time. The idea is to allow drawing the lines in fast
> preview window.
At first glance this seems like a good idea. But points on the lines
you draw still have to refer to points in individual images - each
fixed point on the line has to be attached to one image or another -
after all you want to use this information to optimize the position
and orientation of the individual images, that's the point of control
points. So simply drawing a line in the preview does not work, unless
you introduce a new tool along the lines of 'level the panorama by
reference to a line' - while you can achieve the same effect by just
moving/dragging, which affects all images simultaneously.
I agree, though, that editing of line control points should change. It
is annoying that you have to follow the same UI as for 'point' type
CPs, always having to set two points and one in the left, one in the
right window, where all you want to do often is just click a few times
on a linear feature in one or several images, even if it might be an
odd number ;-)
with regards
Kay
Peter Suetterlin
> I agree, though, that editing of line control points should change. It
> is annoying that you have to follow the same UI as for 'point' type
> CPs, always having to set two points and one in the left, one in the
> right window, where all you want to do often is just click a few times
> on a linear feature in one or several images, even if it might be an
> odd number ;-)
Yes, that's how I see it, too. 'Drawing' a good line with a mouse is probably
quite difficult anyhow (at least my lines drawn that way rather look like an
inked ant running around...).
So maybe a new tab 'control lines' is a good idea that works on single images
where you can just do the clicks Kay mentions and select the line type for
them?
Pit
--
Dr. Peter "Pit" Suetterlin http://www.astro.su.se/~pit
Institute for Solar Physics
Tel.: +34 922 405 590 (Spain) P.Suet...@royac.iac.es
+46 8 5537 8507 (Sweden) Peter.Su...@astro.su.se
Lukáš Jirkovský
> Excellent idea! The way adding lines works has bothered ever since I
> started using it, it just didn't bother me enough to file a request I
> guess (or it didn't cross my mind).
On 8 December 2010 03:24, Yuval Levy <goo...@levy.ch> wrote:
>
> excellent idea! put in output space (fast preview) what is related to output
> space (lines) instead of cramming it into input space (cp tab).
I didn't expect such a good reception. I'll fill a wish in launchpad soon.
On 8 December 2010 11:10, kfj <_k...@yahoo.com> wrote:
> But points on the lines
> you draw still have to refer to points in individual images - each
> fixed point on the line has to be attached to one image or another -
> after all you want to use this information to optimize the position
> and orientation of the individual images, that's the point of control
> points.
They don't have to. You would draw a line in a way similar to eg.
vector editors (click on a first point, then on the second point
creating the line and so on). The logic "under the hood" could
translate this to creating more control points even across multiple
images.
I quickly draw a sample image. I deformed the upper area a bit to
imitate possible deformed lines in panorama due to a bad fit. In fast
preview you would see something like this. Then you would draw lines
on it (red and green lines in image) - the crosses (yeah, that strange
thing is supposed to be cross) are control points of the line.
The GUI would translate drawn line into control points defining a
line. The control points of the line doesn't have to correspond to the
"panorama" control points (ie. points which are now generated by
cpfind or any other detector). For example vertical lines in the
picture consists of three line control points but internally it could
create two control points defining a vertical line in each image
separately and add another two control points defining vertical line
across the images. NOTE: this was just an example, it could be
implemented differently. These control points could even be hidden to
the user in the control points tab, but that's an implementation
detail.
Lukas
panhobby
Actually, controlling of horizontal and vertical lines is very
important for the final image. Especially, when you are shooting
handheld like myself. For my point of view, the most interessing
addition feature would be a visual representation of line while
defining them. At the moment, you define lines by defining two points
and you almost really see your lines. An idea would be to extend the
page where points are currently defined, the process could be:
1) Select the vertical or horizontal mode
2) Put a first point in one image, as soon as this is done, whe you
move the mouse over the other image, you see the corresponding line in
realtime
3) It is then easier to control the orientation of the line in the
most appropriate way.
PH
kfj
On 8 Dez., 19:29, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> I quickly draw a sample image. I deformed the upper area a bit to
> imitate possible deformed lines in panorama due to a bad fit. In fast
> preview you would see something like this. Then you would draw lines
> on it (red and green lines in image) - the crosses (yeah, that strange
> thing is supposed to be cross) are control points of the line.
>
> The GUI would translate drawn line into control points defining a
> line. The control points of the line doesn't have to correspond to the
> "panorama" control points (ie. points which are now generated by
> cpfind or any other detector). For example vertical lines in the
> picture consists of three line control points but internally it could
> create two control points defining a vertical line in each image
> separately and add another two control points defining vertical line
> across the images. NOTE: this was just an example, it could be
> implemented differently. These control points could even be hidden to
> the user in the control points tab, but that's an implementation
> detail.
The preview shows you an assembly of warped images, warped and
positioned according to the roll, pitch, yaw, X, y, Z, fov etc. values
currently in effect for each image. An arbitrarily picked point on the
preview will correspond to a point in each of the images which
populate that area. But the corresponding points in the images don't
have to be images of the same object (in other words: the overlap
isn't always perfect). They may be (within the bounds of matching
precision) - particularly if the chosen point coincides with a fine-
tuned control point, but somewhere else there may be a significant
difference. You can visualize that in the preview by selecting to show
differences - you'll see that the areas where images overlap aren't
necessarily totally black. If there is a difference (and mostly there
is, even if it may be small) - then which object point do you refer to
- the one depicted by the first image, or the second image - or the
third...?
Control point creation - be it 'point' points or 'line' points always
has to make references to locations in individual images, and not to
the output, which isn't even known at that stage, that's why there is
only a preview of it. Since hugin is such a good piece of software ;-)
one sometimes forgets that the overlaps between images aren't perfect
- even the preview often looks very convincing, and the intelligent
stitching puts the seam so the errors are minimized - but, especially
where one image's margin or corner overlaps with some other image, or
where there are parallactic errors in the images, the differences are
larger.
Still the point remains that line control point creation currently is
a bit awkward and could well do with a UI better suited to it's
purpose. I have previously stated and am still convinced, that some
editing features should be available that display warped images and
possibly work on an assembly of those images in a view similar to the
preview. My idea to deal with the issue of which of the images to
apply the edit to is to allow to put them 'into focus' individually or
in groups, thereby making it possible to set points in several images
synchronously (if they overlap where the click happens) - but you must
have a choice to do so, it mustn't be done automatically to all images
which happen to be where you click.
The current fast preview is not a totally precise instrument - it is
there to give you an idea what the output will look like, but it's not
as precise as the actual stitching process, and it doesn't know where
the stitcher will put the seams. Control point picking should be done
as precisely as possible - that's why in the control points tab you
have the option to look at the image in 100% size, and then you can
even fine-tune the control point to achieve sub-pixel precision. So
the current fast preview is not precise enough for that, and it does
not have a zoom facility yet. Bearing these inadequacies in mind, one
could still attempt to instrumentalize it for the purpose of CP
editing by equating image visibility to 'in-focus' status and then
apply the picked points to all visible images, which would be very
close to what you would like to have - it might be enough for many
applications, and if more accuracy is needed one could fine-tune with
the control points tab.
But - and that's where I will end my tedious nit-picking monolog ;-)
someone has to do it. I can't, since I still have only very vague
ideas HOW hugin actually does what it does. It's apparently been put
together by extremely clever people using very advanced libraries (and
a fair number of those, too) - assuming that mere mortals (like me)
could figure it out by just reading the code :(
So all I can do for now is write wish-lists.
with regards
Kay
panostar
> Long story short. Currently there is only one way how to specify
> horizontal or vertical lines. For defining either of them you need to
> manually specify control points. This is not very user friendly and it
> can take a lot of time.
click on two pairs of vertically aligned features (not necessarily
"lines" BTW)? And if you are going to click on both ends of a line to
create a line on which to set points on, there's hardly much saving of
effort either.
John
Andreas Metzler
[...]
> I've never found it takes a lot of time. How long can it take to
> click on two pairs of vertically aligned features (not necessarily
> "lines" BTW)? And if you are going to click on both ends of a line to
> create a line on which to set points on, there's hardly much saving of
> effort either.
It can take a lot of effort there is dozens of almost identical lines,
think e.g a brickstone wall. Using two separeate windows you can end
up literally needing to count from the bottom of the screen to make
sure you get the correct line.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
kfj
On 13 Dez., 19:07, Andreas Metzler <ametz...@downhill.at.eu.org>
wrote:
> It can take a lot of effort there is dozens of almost identical lines,
> think e.g a brickstone wall. Using two separeate windows you can end
> up literally needing to count from the bottom of the screen to make
> sure you get the correct line.
automatically position the CP in the second window when you click in
the first - the 'auto estimate' mode. If the images already overlap
correctly, the automatically generated second half of the control
point would appear in the right position in the second image. Alas,
this mechanism seeems to be flawed; I find it forever puts the new
point some 20-100 pixels away from where it should be, for no reason I
can figure out. That's why I never use it. The manual points out that:
'auto estimate: Tries to estimate the position of the second point by
estimating the translation between the two images. This is very crude
and probably only works for single row panoramas created from
Rectilinear Projection images.'
Crude indeed. This would be the place where a guiding line cold pop up
if you had the same image in the left and right window - if you could
choose that you want a line control point before you click -
annoyingly enough, though, you can only choose after you've set the
point.
I feel it's been a while since anyone has had a good look at the
control point editor. It feels awkward - it's UI has something
haphazard and arbitrary to it, and it could certainly do with some
TLC. I hope that eventually CP editing on warped images with a preview-
like view will appear, maybe making the old CP editor redundant.
Luckily, though, the brickstone wall scenario is a bit of a
'pathological case' and doesn't happen so often particularly now that
manual CP editing is rarely needed since the automatic CPGs are doing
such a reliable job. That's probably why the old CP editor has been
left untouched. But precise positioning with 'auto estimate' and
automatic horizontal and vertical helplines popping up in both images
when the same image is in both windows, or when line control points
are preselected (if that was possible) would help.
with regards
Kay
Jeffrey Martin
Jeffrey Martin
true, but it takes TIME. it should not take any time.
Please, I am very curious, why hasn't this been automated to any degree whatsoever, yet?
I have a nagging feeling that it has simply been not important enough for any genius out there to solve it :) I mean, after all, look at everything else that has been built. Look at Photosynth for example. There are far more sophisticated things that have been done, but still, we can't detect some vertical lines in a pano to straighten it? Yes, I know it's not as easy it may first appear (believe me, I know!) but still, i find it troubling that no one is trying to solve this. Instead we have a thread suggesting to copy a UI feature that has already been in Autopano Giga for quite some time (and something similar in PTGui)
I don't want to sound like I'm complaining - I'm not, I'm simply wondering if this discussion is a bit misplaced.
cheers!
Jeffrey
kfj
On 14 Dez., 16:25, Jeffrey Martin <360cit...@gmail.com> wrote:
> I don't want to sound like I'm complaining - I'm not, I'm simply wondering
> if this discussion is a bit misplaced.
Why would it be misplaced? If you know a good feature in Autopano
Giga, why not promote it and explain what it does and why you think
it's a good idea to have, rather than state that it can do something
hugin can't? If you own copies of these commercial products and are
happy with some feature or other, It'd be more helpful to explain it
to those of us who don't.
> Instead we have a thread suggesting to copy
> a UI feature that has already been in Autopano Giga for quite some time (and
> something similar in PTGui)
with regards
Kay
Jim Watters
> excellent idea! put in output space (fast preview) what is related to
> output space (lines) instead of cramming it into input space (cp tab).
>
Yes it makes sense to move the line creations to the output window.
Horizontal and vertical lines are for the output projections and makes sense to
have in the output window.
It would be nice to update straight lines too. I recently stitched two
different hand held panos. One a table top with a striped table cloth and
another a room with planks.
In both cases when I changed to rectilinear and tilted the preview down to look
at the nadir I could see that things were not aligned but there was not enough
detail to find exact points. Being able to set straight line control points in
this window and have them optimized correctly when the view is horizontal and
equirectangular again, would help a lot. The current problem is that these are
not straight lines when viewed as equirectangular image.
Even adding normal control points in the output window could be useful for the
few images that fail to get auto-generated control points.
Select the image you want to align to the others.
With no points connecting the images moves around freely.
With one point connecting the image rotates around the point already added.
With two or more points added the image can be pulled to connect another point
and misalign the others, but there is resistance. More points connected = more
resistance.
--
Jim Watters
http://photocreations.ca
Tom Sharpless
direction. As I see it the key problems are
1) only the rectilinear projection displays all straight lines as
straight;
2) if the source images are not already aligned (which is the expected
case for purposes of this discussion) then you need a separate
straight line on each image to specify how they should line up.
So it seems to me the solution must involve showing rectilinear
previews of one overlap region at a time, and giving the user the
ability to position several straight lines on it -- say in a different
transparent color for each image. That done, the s/w could easily
generate a bunch of straight line CPs.
A 'blink' key, to switch the view between individual images and the
composite, would be a great help. There would also need to be a nice
intuitive way to grab one line with the mouse and hold it despite the
blinking. And of course the mouse would have to both position and
rotate the line -- 3 degrees of freedom.
IMHO, it is silly to try to draw the curved versions of straight lines
on, say, an equirectangular preview, and just as silly to discard
straight lines just because they don't happen to look straight on such
a preview.
Excelsior!
-- Tom
paul womack
> I agree that it should be easier to specify straight lines, in any
> direction. As I see it the key problems are
> 1) only the rectilinear projection displays all straight lines as
> straight;
> 2) if the source images are not already aligned (which is the expected
> case for purposes of this discussion) then you need a separate
> straight line on each image to specify how they should line up.
>
> So it seems to me the solution must involve showing rectilinear
> previews of one overlap region at a time
If the images are not aligned, overlap is (surely) undefined?
BugBear
kfj
on the subject of control point editing:
http://groups.google.com/group/hugin-ptx/t/a78d16171087c2d4
Kay
Yuval Levy
> It can take a lot of effort there is dozens of almost identical lines,
> think e.g a brickstone wall. Using two separeate windows you can end
> up literally needing to count from the bottom of the screen to make
> sure you get the correct line.
yes, I like Lukas original idea to have a tool actually drawing a line
visually on the features, even if in the end it only registers the two end
points.
Yuv