On 07/11/2018 11:17 AM, Marcel Brouillet wrote:
> I read about demosaic-ing and did my RAW-101 class :-). I'm still a noob on
> this. I understand the process would involve a RAW sticher, the PTO being
> generated on some initial set of (rough) converted files. Yet...
> Vladimir, why do you have
On 07/11/2018 10:07 AM, Erik Krause wrote:
> Am 10.07.2018 um 17:10 schrieb Albert Szostkiewicz:
>> Personally I am interested in stitching 360 full, true HDR images. I am
>> hoping to stitch and get as much of original data as I can. With PtGui for
>> eg. I am able to throw my Canon RAWs directly
On 07/09/2018 03:18 PM, bugbear wrote:
> Marcel Brouillet wrote:
>> so merging RAW files seems to have sense to me.
>
> How (on earth) does one perform spatial interpolation on raw data that
> hasn't been de-mosaic'd ?!
>
> BugBear
>
Hi,
when I think about it...
It might be possible to
I found one problem with ImageVariable.patch: MaskPolygon::parsePolygonString
creates MaskPolygon instance without initialized bounding box. Before it was
fixed by operator=, with ImageVariable.patch the instance is shared or copied
with default copy constructor so it never gets fixed and masks
I found one problem with ImageVariable.patch: MaskPolygon::parsePolygonString
creates MaskPolygon instance without initialized bounding box. Before it was
fixed by operator=, with ImageVariable.patch the instance is shared or copied
with default copy constructor so it never gets fixed and masks
Public bug reported:
I tried to profile hugin on a large project with 500 images and 10
control points. I identified and fixed some bottlenecks:
ImageVariable.patch - reimplemented ImageVariable with shared_ptr -
reduces complexity from O(n) to O(1)
ImageVariableGroup.patch - move some
Public bug reported:
I tried to profile hugin on a large project with 500 images and 10
control points. I identified and fixed some bottlenecks:
ImageVariable.patch - reimplemented ImageVariable with shared_ptr -
reduces complexity from O(n) to O(1)
ImageVariableGroup.patch - move some
On 07/20/2017 02:16 PM, Andreas Färber wrote:
> Hi Vladimir,
>
> Am 20.07.2017 um 00:09 schrieb Vladimir Nadvornik:
>> I have new Orange Pi Prime board and I'd like to run openSUSE on it :)
> [...]
>> I tried to compile u-boot 2017-07 from Base:System:Staging. The
&g
Hi,
I have new Orange Pi Prime board and I'd like to run openSUSE on it :)
So far I took armbian image and replaced all userspace with openSUSE. It
works ok for running osc and build.
Then I tried to compile u-boot 2017-07 from Base:System:Staging. The
board config is already there but it seems
On 04/26/2016 04:57 PM, Michael Perryman wrote:
> Thank you for assisting, Vladimir.
>
> Control Point Detection setting has no effect if you created the points
>> manually.
>>
>
> if the CPD setting has no effect when creating the points manually,
> where do I set the arguments (e.g. -S
Hi Michael,
On 04/26/2016 02:15 PM, Michael Perryman wrote:
> I am trying to use Hugin to "align" (optimise) stereo pairs. I have
> followed the stereo tutorial at:
> http://vndlinuxphoto.blogspot.co.uk/2011/01/stereo-image-alignment-in-hugin.html
> which works fine in *command line mode*. But
This might be related:
https://forums.wxwidgets.org/viewtopic.php?t=2
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1474580
Title:
hugin_executor crash
Status in Hugin:
New
Bug
This might be related:
https://forums.wxwidgets.org/viewtopic.php?t=2
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1474580
Title:
hugin_executor crash
Status in Hugin:
New
Bug
wxWidgets-2.8.12
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1474580
Title:
hugin_executor crash
Status in Hugin:
New
Bug description:
testing with hugin hg changeset 7093 on openSUSE
wxWidgets-2.8.12
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1474580
Title:
hugin_executor crash
Status in Hugin:
New
Bug description:
testing with hugin hg changeset 7093 on openSUSE
I checked the wxWidgets-2.8.12 code, there is really a limit of 127
arguments, see
#define WXEXECUTE_NARGS 127
in utilsunx.cpp
The pto file contains 160 images in one stack, plus some extra enfuse arguments.
--
You received this bug notification because you are a member of Hugin
Developers,
I checked the wxWidgets-2.8.12 code, there is really a limit of 127
arguments, see
#define WXEXECUTE_NARGS 127
in utilsunx.cpp
The pto file contains 160 images in one stack, plus some extra enfuse arguments.
--
You received this bug notification because you are a member of Hugin Bug
Hunters,
Public bug reported:
testing with hugin hg changeset 7093 on openSUSE 13.1
hugin_executor crashes on the attached file after enfuse successfully finishes.
valgrind output looks like there is corrupted stack.
steps to reproduce:
ptodummy img_3852_img_3683_2.pto
hugin_executor --stitching
Public bug reported:
testing with hugin hg changeset 7093 on openSUSE 13.1
hugin_executor crashes on the attached file after enfuse successfully finishes.
valgrind output looks like there is corrupted stack.
steps to reproduce:
ptodummy img_3852_img_3683_2.pto
hugin_executor --stitching
On 09/03/2014 09:57 AM, Einar Høst wrote:
My current solution has been to use align_image_stack on sets of 200 images
to produce a set of .pto files, merging them with pto_merge and running
autooptimizer on the merged .pto file. However, when I try to run nona on
the .pto file (nona -m
Dne 27.8.2014 06:26, Torsten Bronger napsal(a):
Hallöchen!
Vladimir Nadvornik writes:
[...]
Lensfun has data for my lenses at all focal lengths. Is there any
tool for migrating this data to the new database?
I would not want to use that. Lensfun contains the data for your
lens model
Hi,
I just noticed that 2014.0-RC4 uses it's own lens database
instead of lensfun.
So far I found only one way for filling this database - import from
existing pto files. But I am not sure if I used all possible focal
lengths so far so the database can contain holes and it can lead to
surprises
Public bug reported:
I have a project where the same images are used several times with
different rotation (I want to create fake star trails image).
Then, when I select two images and click on Create control points, the
points are added to unselected images with the same name.
The attached
Public bug reported:
I have a project where the same images are used several times with
different rotation (I want to create fake star trails image).
Then, when I select two images and click on Create control points, the
points are added to unselected images with the same name.
The attached
Public bug reported:
I have found another problem in align_image_stack: the stereo mode does not
work together with sorting images.
It expects that the order of images stays unchanged.
The attached patch fixes it.
** Affects: hugin
Importance: Undecided
Status: New
** Patch
OK, I will look into it.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1296845
Title:
PATCH: lensfun support for align_image_stack
Status in Hugin - Panorama Tools GUI:
New
Bug description:
Here is new patch.
Lensfun init is untested, I can compile it only on linux. It is just
copied from pto_gen.
There was also a bug in parsing --corr value, the patch fixes it.
** Patch added: align_image_stack-lensfun-v2.patch
OK, I will look into it.
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1296845
Title:
PATCH: lensfun support for align_image_stack
Status in Hugin - Panorama Tools GUI:
New
Bug
Here is new patch.
Lensfun init is untested, I can compile it only on linux. It is just
copied from pto_gen.
There was also a bug in parsing --corr value, the patch fixes it.
** Patch added: align_image_stack-lensfun-v2.patch
Dne 22.3.2014 08:32, kfj napsal(a):
On Friday, March 21, 2014 1:34:08 AM UTC+1, nadv...@suse.cz wrote:
Hi,
the recent discussion about exposure compensation reminded me that I
have related problem.
I have a panorama from 10 images taken with fixed exposure, EV 12.
Public bug reported:
Hi,
the attached patch adds --lensfun option to align_image_stack command.
I found it necessary for processing uncorrected raw files from Canon S95, where
the distortion
is really significant.
** Affects: hugin
Importance: Undecided
Status: New
** Patch
On 03/21/2014 05:59 AM, Terry Duell wrote:
Hello Vladimir,
On Fri, 21 Mar 2014 11:34:08 +1100, Vladimir Nadvornik nadvor...@suse.cz
wrote:
[snip]
Now, when I process it as Exposure fused from any arrangement, then
there are no burned out areas, but the extra image is still
Hi,
the recent discussion about exposure compensation reminded me that I
have related problem.
I have a panorama from 10 images taken with fixed exposure, EV 12.
A small part of the panorama is overexposed, so I added one extra
correctly exposed image with EV 14 that covers the overexposed
Public bug reported:
I am testing hugin 2013.0.0_rc2 with exiv2 0.23.
On an Image from compact camera canon s95 hugin reads the lens name as
(65535) and the lensfun lookup fails.
Changing lens name to empty string helps. This is a problem for fully automatic
workflow, for example with
pto_gen
On 04/16/2013 07:29 AM, Terry Duell wrote:
Hello Donald,
On Tue, 16 Apr 2013 12:15:20 +1000, Donald Johnston
dgjohns...@accesscomm.ca wrote:
I used align_image_stack -m -a AIS_ IMG_.JPG (using done of the
following options) and it seemed to do a good job of aligning the
images for my 3D
On 04/17/2013 05:28 PM, Vladimir Nadvornik wrote:
align_image_stack with -S adds all control points as vertical lines.
I mean horizontal lines, sorry.
Vladimir
--
--
You received this message because you are subscribed to the Google Groups Hugin and
other free panoramic software group
Hi,
In my application I want to open new gtk window on second X11 screen
(using gtk_window_set_screen). It works fine with plain gtk but
crashes if the window contains cutter embed.
Before debugging it further I want to ask if it is supported at all.
Thanks,
Vladimir
On 09/27/2012 09:54 PM, Jon Hollström wrote:
Hi all!
Thank you for developing the the best image viewer for linux!
Most of the time I use it to quickly look through the photos I take and
decide what to keep and what to delete. I mostly work with page up, page
down and delete. When two
Hi,
I am thinking about a bugfix release for 1.1.
Candidates for inclusinon are:
68619b544a553fcaf636894ec894553a0c8f650e
added Samsung and Panasonic raw extensions
085be43cb79e04341102a9922e0e0f531454089a
fixed updating of comment and keyword pane
e8cd71d6f52967d7dd63efcb186834aa9e6e53e5
On 09/13/2012 08:12 AM, Omari Stephens wrote:
On 09/12/2012 11:14 PM, David Vincent-Jones wrote:
When I apply a 'star' rating during the raw conversion process this does
not appear to match the Geeqie rating system although the rating is
correctly shown in the exif data.
What does during the
On 09/04/2012 10:47 AM, Uwe Ohse wrote:
On Fri, Aug 24, 2012 at 12:06:05AM +0200, Vladimir Nadvornik wrote:
I think that for normal operation, the timestamps can be compared per
directory, at the end of filelist_read_real() function. The filelist there
contains up-to date content
Dne úterý 21 Srpen 2012 00:07:20 Michael Schwendt napsal(a):
Could it be that the new keyword cache in Geeqie 1.1 disturbes the
keyword text box?
1. display image
2. Ctrl+K
3. focus Keywords sidebar
4. type some text
Actual results:
After typing a first character, the cursor jumps into
On Friday, August 17, 2012 06:20:28 PM Uwe Ohse wrote:
- sorting by exif date (this will requiure some sort of metadata
caching)
That certainly needs some kind of database. I remember some discussions
on that, has there some kind of consensus been achieved?
I'd personally like some kind
On Friday, August 17, 2012 01:56:18 AM vinit agrawal wrote:
Hi,
I was thinking of, as i mentioned earlier sometime that a feature like
seemless image viewing mode will be very cool thing to add.
The inspiration is of course the google picasa viewer for windows, with a
dimmed background of
On Thursday, August 16, 2012 09:42:19 PM Greg Troxel wrote:
Vladimir Nadvornik nadvor...@suse.cz writes:
But merge commits break
this rule - they contains random changes together. So my feeling is
that with merge commits the history would be harder to review and
debug but I have
On Wednesday, August 15, 2012 07:38:25 AM David Vincent-Jones wrote:
Is there an established goal, or set of goals, for Geeqie? If so where
will I find them.
If the direction is already clearly stated somewhere it should be much
easier to prioritize the next development.
Main goal is to
Dne středa 15 Srpen 2012 15:54:48 Andreas Metzler napsal(a):
Hello,
find attached two trivial fixes for GIT:
commited, thanks.
Vladimir
--
Live Security Virtual Conference
Exclusive live event will cover all the
Dne úterý 14 Srpen 2012 19:03:24 Štěpán Roučka napsal(a):
Dear all,
I have a question regarding the missing support for raw files from Samsung
cameras (EX1 in particular). Is it difficult to add support in geeqie? Does
it relay on support in some external libraries or is the problem only in
Dne středa 08 Srpen 2012 14:01:23 Vladimir Nadvornik napsal(a):
OK, I have finally reproduced it.
So far I can tell that it crashes also with view_file_icon so
vflist_setup_iter_recursive does not seem to be the cause.
I will continue debugging in the evening.
Hi Michael,
I have found 2
On Thursday, August 09, 2012 11:23:57 AM John Stoffel wrote:
Vladimir I have found 2 problems:
Vladimir 1. the exif_read_fd() could return NULL on missing file, but the
old value Vladimir stayed in cache, so it triggered assertion in
exif_free_fd().
Vladimir 2. file_data_check_sidecars()
On Tuesday, August 07, 2012 10:37:20 AM Michael Schwendt wrote:
Maybe the attached patch fixes it.
Not entirely. It's been harder to make it crash, though:
filedata.c:446: fd magick mismatch at filedata.c:629
**
ERROR:filedata.c:448:file_data_ref_debug: assertion failed: (fd-magick
Dne úterý 07 Srpen 2012 17:16:59 Michael Schwendt napsal(a):
On Tue, 07 Aug 2012 17:05:58 +0200, Vladimir Nadvornik wrote:
removing unknown sidecar /home/misc/tmp/stresstest/000454.JPG: �Jd 8 fd
magick mismatch at filedata.c:629
**
ERROR:filedata.c:448:file_data_ref_debug: assertion
Dne úterý 07 Srpen 2012 19:10:07 vinit agrawal napsal(a):
hello ,
The current version of geeqie1.1 that vladimir has putted, is not been able
to recognize the image files if the file names of these file do not
end with one of the standard image file extension. I think the application
should
On Monday, August 06, 2012 07:23:56 AM Greg Troxel wrote:
Vladimir Nadvornik nadvor...@suse.cz writes:
Dne pondělí 30 Červenec 2012 18:45:04 Vladimir Nadvornik napsal(a):
Hi,
I went through the mailinglist and bugtracker and added the easy
fixes to master. If you think that anything
Dne pondělí 06 Srpen 2012 18:09:49 Michael Schwendt napsal(a):
On Mon, 06 Aug 2012 16:51:43 +0200, Vladimir Nadvornik wrote:
The tarball I used for creating the testing packages can be downloaded
here:
http://download.opensuse.org/repositories/home:/nadvornik:/geeqie:/testin
g
Dne úterý 31 Červenec 2012 16:48:10 John Stoffel napsal(a):
Vladimir == Vladimir Nadvornik nadvor...@suse.cz writes:
Vladimir On Monday, July 30, 2012 03:04:32 PM Greg Troxel wrote:
Vladimir Nadvornik nadvor...@suse.cz writes:
Hi,
I went through the mailinglist and bugtracker
Dne pondělí 30 Červenec 2012 18:45:04 Vladimir Nadvornik napsal(a):
Hi,
I went through the mailinglist and bugtracker and added the easy fixes to
master. If you think that anything important is missing, please tell so.
I have branched stable/1.1 in git.
Testing packages for some
Hi,
I went through the mailinglist and bugtracker and added the easy fixes to
master. If you think that anything important is missing, please tell so.
For release plan, I'd propose this:
1. release the current master as Geeqie 1.1
2. migrate to gtk3, drop the compatibility stuff
3. release
Dne pátek 27 Červenec 2012 17:44:27 John Stoffel napsal(a):
Can you give a summary of the differnces between the two branches?
Maybe it would make sense to replace a 1.1beta patch release and a all
the new features in a 2.0beta release so we cna look them over and see
what's needed.
Dne pátek 27 Červenec 2012 17:37:09 Michael Schwendt napsal(a):
Is anyone still processing the bug reports in the tracker? I've submitted
a few patches there without getting any response. And while a few other
issues have been discussed on this list, I wouldn't know what to expect
from 1.1
Dne pátek 27 Červenec 2012 19:25:56 vinit agrawal napsal(a):
Hi guys,
I have not been much involved in the project. But i'd like to join.
I have few ideas related to new features that can be added. One of
feature that i'd like to see is Google picasa viewer like floating
interface image
Dne čtvrtek 12 Červenec 2012 20:39:33 M. Koehrer napsal(a):
Hi all,
please find enclosed a patch the solves the issue that processing of images
using an external tool does not work if folder of the image is readonly.
I think it should still be checked, but I changed it to a non-fatal
Hi,
I had the same problem, on intel I7, 6GB of RAM. IMHO it is a RAM issue.
I was able to fix it with --ncores 4 option, so it processes 4 images at once.
Vladimir
On Wednesday, November 30, 2011, Adam Weld wrote:
So it seems that CPFind is getting errors after 7 (16mp) images? I don't
Dne čtvrtek 24 Listopad 2011 18:40:16 T. Modes napsal(a):
Hi Vladimir,
here is a patch that implements the feature requested in hugin bug 679981
- autocrop based on image stacks.
The algorithm already works, but the integration is not yet finished. I
want to ask you for opinion on these
The attached patch implements this function.
** Patch added: cropstack.patch
https://bugs.launchpad.net/hugin/+bug/679981/+attachment/2609065/+files/cropstack.patch
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
Hi,
here is a patch that implements the feature requested in hugin bug 679981 -
autocrop based on image stacks.
The algorithm already works, but the integration is not yet finished. I want
to ask you for opinion on these issues:
- Currently it is not configurable. Should I add it as another
Hi,
after some experimenting I have found that the mosaic mode provides exactly
the right transformation for stereoscopic images.
The attached patch adds options for this mode to align_image_stack.
Regards,
Vladimir
--
You received this message because you are subscribed to the Google Groups
Hi,
Is there any documentation for the Lightness Adjustment
functionality? I find it quite difficult to use, but maybe
I am just using it incorrectly.
The problems I found:
- I haven't found a way to control the hue range on which
is the adjustment applied (hueWidth). Also some indication
Hi all,
UFRaw sometimes gives inconsistent results. The results varies if the image
was processed by ufraw or ufraw-batch. Sometimes just opening and saving ID
file changes the image.
I wrote a script for systematic testing. It is attached here:
Hi all,
I have commited these fixes and new features to master:
- rewritten check for sidecar files, it no longer tests all possible case
combinations
- support for extensions with multiple dots - the extension must be registered
as a known file type
- custom tiff loader - loading tiff
On Saturday, September 03, 2011, Klaus Ethgen wrote:
Hello folks,
After some time I start bughunting today again. Well, started to start.
;-)
I moved in the lost tag from Vlad to this tree and started a stable/1.x
tree (I do not think that we need 3 version numbers). I will cherry pick
Thanks for testing.
Filled https://bugzilla.novell.com/show_bug.cgi?id=714373
** Bug watch added: Novell/SUSE Bugzilla #714373
https://bugzilla.novell.com/show_bug.cgi?id=714373
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
It looks like that boost::signals::trackable does not work at all. Even
the boost example fails for me.
http://svn.boost.org/svn/boost/trunk/libs/signals/example/button_click.cpp
Tested on openSUSE 11.3 and 11.4 with boost 1.42, 1.44, 1.46.
Can anybody test other systems?
nadvornik@sphinx2:~
It looks like that boost::signals::trackable does not work at all. Even
the boost example fails for me.
http://svn.boost.org/svn/boost/trunk/libs/signals/example/button_click.cpp
Tested on openSUSE 11.3 and 11.4 with boost 1.42, 1.44, 1.46.
Can anybody test other systems?
nadvornik@sphinx2:~
Dne čtvrtek 04 Srpen 2011 06:03:49 Udi Fuchs napsal(a):
I've fixed some related bugs in CVS. I did some basic testing, but any
more testing would be welcome.
As long as there are no crop factor changes in LensDB, I think that
everything should work correctly.
Thank you!
Now it works fine
Dne pondělí 01 Srpen 2011 23:21:04 Vladimir Nadvornik napsal(a):
Dne neděle 31 Červenec 2011 20:21:30 Vladimir Nadvornik napsal(a):
Hi,
Is the lensfun configuration in id files supposed to work in current CVS?
I have the following problem:
1. use ufraw from CVS, delete
Dne neděle 31 Červenec 2011 20:21:30 Vladimir Nadvornik napsal(a):
Hi,
Is the lensfun configuration in id files supposed to work in current CVS?
I have the following problem:
1. use ufraw from CVS, delete the ~/.ufrawrc
2. run
./ufraw IMG_1102.CR2
(the file is from Canon S95
Hi,
Is the lensfun configuration in id files supposed to work in current CVS?
I have the following problem:
1. use ufraw from CVS, delete the ~/.ufrawrc
2. run
./ufraw IMG_1102.CR2
(the file is from Canon S95)
ufraw identifes the lens and the correction is correctly applied
3. click on
Dne neděle 31 Červenec 2011 21:03:25 Alexandre Prokoudine napsal(a):
On Sun, Jul 31, 2011 at 10:21 PM, Vladimir Nadvornik wrote:
Hi,
Is the lensfun configuration in id files supposed to work in current CVS?
UFRaw doesn't write lensfun data into id files. It's not a bug, it
simply isn't
Hi,
On St 4. května 2011, Omari Stephens wrote:
Howdy, all
I'm poking around with the marks code. Currently, marks are _really
slow_ when you connect at least one mark to an image tag — when an image
with no marks drops to zero refs, we lose track of what marks it may
have, and on the
On Čt 5. května 2011, Michael Schwendt wrote:
On Wed, 04 May 2011 16:30:44 +, OS wrote:
That said, I imagine that we'd be better off just always holding a ref
for every FileData in the current directory. On my machine, a FileData
is 176 bytes and a GList is 24 bytes, so for a
On Pá 15. dubna 2011, Klaus Ethgen wrote:
Now for my patches. They are not 100% finished, but I want to publish them
for testing, so I will push them to gitorious/nadvornik-stereo, OK?
Right.
If someone want to test, he can checkout that branch or do a (temporary)
merge to his own local
On Pá 15. dubna 2011, Klaus Ethgen wrote:
Hi Vladimir,
Am Do den 14. Apr 2011 um 22:44 schrieb Vladimir Nadvornik:
I started to hack Geeqie again and now I have a series of patches for
stereo image support. The patches also implements a base for future
improvements of image loading
Hi all,
I started to hack Geeqie again and now I have a series of patches for
stereo image support. The patches also implements a base for future
improvements of image loading and rendering.
The patches are currently in my local git. Since this is my first project with
git, I would need some
Hi,
I wrote a tutorial how to use my stereo patches (attached to bug
679753):
http://vndlinuxphoto.blogspot.com/2011/01/stereo-image-alignment-in-hugin.html
Comments are welcome.
Vladimir
--
You received this message because you are subscribed to the Google Groups
Hugin and other free
Here is more detailed usage description:
http://vndlinuxphoto.blogspot.com/2011/01/stereo-image-alignment-in-hugin.html
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679753
Title:
Stereo images
Patch no. 1 changes the matching algorithm. On images that I tested it gave the
same or better results, but in theory there can be some regression with some
images.
Patch no. 6 changes the written pto files because the original behavior was
IMHO buggy.
Otherwise there are no changes for
Public bug reported:
Auto crop sometimes gives wrong results. It can be reproduced on images
that are slightly rotated, see the attached pto file. The problem is
that the algorithm starts with some initial area which then can only
grow. It does not detect that a little shrink in one direction
** Attachment added: crop-err.pto
https://bugs.launchpad.net/bugs/702135/+attachment/1792224/+files/crop-err.pto
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/702135
Title:
Auto Crop bug
This patch fixes it, but maybe there is some better fix.
** Patch added: crop.patch
https://bugs.launchpad.net/hugin/+bug/702135/+attachment/1792226/+files/crop.patch
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
Hi,
Here are more related patches:
4. Modification of crop algorithm, that woks on intersection of image
area instead of an union. Btw, this is the algorithm requested in bug
#679981 if I understand it correctly.
** Patch added: patch4-crop.patch
5. Algorithm for stereo window alignment and autocrop, with the
corresponding commandline options.
** Patch added: patch5-align.patch
https://bugs.launchpad.net/hugin/+bug/679753/+attachment/1792235/+files/patch5-align.patch
--
You received this bug notification because you are a member of
6. The pto file was written without output format options, so it was not
directly usable for reproducing the output. This patch fixes it. IMHO an
even better fix would be possible at the cost of breaking backward
compatibility.
** Patch added: patch6-output.patch
There is still a problem that the pto file with optimized distortion and
shift is not correctly read into hugin. Manually creating a new lens for
the second image fixes it. I can't tell if the bug is in hugin or in
allign-image-stack.
--
You received this bug notification because you are a
And here is an example of use:
align_image_stack -a aligned -i -P -C left.jpg right.jpg
composite -stereo 0 aligned.tif aligned0001.tif anaglyph.jpg
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
** Attachment added: crop-err.pto
https://bugs.launchpad.net/bugs/702135/+attachment/1792224/+files/crop-err.pto
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/702135
Title:
Auto Crop bug
Public bug reported:
Auto crop sometimes gives wrong results. It can be reproduced on images
that are slightly rotated, see the attached pto file. The problem is
that the algorithm starts with some initial area which then can only
grow. It does not detect that a little shrink in one direction
This patch fixes it, but maybe there is some better fix.
** Patch added: crop.patch
https://bugs.launchpad.net/hugin/+bug/702135/+attachment/1792226/+files/crop.patch
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
5. Algorithm for stereo window alignment and autocrop, with the
corresponding commandline options.
** Patch added: patch5-align.patch
https://bugs.launchpad.net/hugin/+bug/679753/+attachment/1792235/+files/patch5-align.patch
--
You received this bug notification because you are a member of
Hi,
Here are more related patches:
4. Modification of crop algorithm, that woks on intersection of image
area instead of an union. Btw, this is the algorithm requested in bug
#679981 if I understand it correctly.
** Patch added: patch4-crop.patch
1 - 100 of 253 matches
Mail list logo
