For a progress indicator, an off-by-one caused by insufficient locking
does not matter.
I don't know how the threads could measure their progress. But simply
incrementing a global variable (common to all threads) allowing a
"progress-reporting-thread to inspect it and report it.
The "no locking"
Would it be possible to move the DVI target to DVI_internal and
include make -j 1 DVI_internal as the rule for DVI in the makefile? (I
think the command line overrides what the master make got as
arguments, right?)
--
You received this bug notification because you are a member of Hugin
Marked as private to limit the benefits for the spammers.
** Information type changed from Public to Private
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1330054
Title:
Tips On How To Gain
Marked as private to limit the benefits for the spammers.
** Information type changed from Public to Private
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1330049
Title:
Muscle Building Tips
On Sun, Dec 01, 2013 at 07:31:06PM -, Lukas Wirz wrote:
If I recompile without openmp I get exactly the same output.
Image_cache has been disabled in 842, so I can't switch that on. I'll
spend some time having fun with valgrind.
Good idea. Valgrind will be able to find problems when you
I used to have the strong impression that it was the image_cache that
caused this... Now you are contradicting that feeling.
If you manage to change the configuration (yes/no openmp ... yes/no
imagecache) and isolate the cases where it happens, that would help
locate the problem.
Keep in
Yes, I've found that things are related to imagecache. On the other
hand, yes, I too have heard that it had been removed. But are you
running such a version? Can you check if you can make the program show
its configuration? (-V? -v?) (I don't know the cmdline options by
heart).
--
You received
It's a makefile.
In Hugin you can select the button: Keep intermediate files. Then: enblend
yourprojectname00*.tif -o tourprojectname.tif should be the enblend commandline.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
Is your userspace 32-bit or 64-bit?
A 32-bit userspace program will run out of addressable memory at 3G. So
that's unlikely to exhaust your swap. (in fact it's unlikely to start
filling your swap). But just to be sure
To allow developers to work with your images, are you willing to upload
Downloading for hours? Haven't seen that happen for quite a while. Would
probably download in one minute here... :-)
(download speeds of 11 megabytes per second have been known to occur... :-) At
those speeds, it mostly depends on the server ) (Your upgrade may take a
few hours. Please
You scaled by 0.25, Correct? Then I can scale them back up to normal
size. Which, under most circumstances is very similar to using the
original files.
I also need the hugin project file
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed
For you, I'd think it is easiest to do:
apt-get source enblend
apt-get build-deps enblend
cd enblend-version
dpkg-buildpackage
Now you've rebuilt your distro's version with those options. Now you
have a source directory that you know compiles and you can tune to your
liking.
--
You
Thomas,
How good a debugger are you?
This is a bug where a good programmer/debugger just has to spend a day
or two finding/fixing it.
This bug resides in the image library that allows the image to be moved
to disk if it becomes too large (I forgot its name). So reducing the
output image size
FYI,
with enblend 4.0-753b534c819d, I too get correct output. Both when I put the
'11 image before or after the '10' image.
(if you load '00 and '10 first, they do not overlap and you get two seams with
'11. But if you load 00, then 11, you have one seam, and another seam once you
load '10. )
Public bug reported:
Wishlist item:
Sometimes it is convenient when it would be possible to delete
controlpoints from the layout window. Switch to delete controlpoints
mode, and click on a link. Whsh and the controlpoints between those
pictures are gone.
(I've suggested in the past that
Yeah. it cannot be the default action for that reason. But a 'delete
controlpoints' mode is possible as I suggested.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1093099
Title:
Hugin: delete
The idea behind if hfov (pano) 360 then optimize v(images) is that
if the v(images) is say 10% larger, you'll get a reasonable pano with a
10% larger hfov. i.e. it will grow from say 150 degrees to 165. This
does not significantly impact the panorama.
When you WOULD optimize v, the panorama
Public bug reported:
I have a panorama that might require separate V optimization for each of the
images.
(in this case because the object is not flat, the distance from the object is
not constant, and the camera was moved between shots. However this also happens
if the camera is allowed to
Public bug reported:
Should be an easy addition:
Allow the setting of the nice level in the batch processor.
(Usage: I process a batch of images, align them and then hit stitch.
I'll be working on aligning the next pano during the time that the
stitch is running. And I'll be WAITING for the
Kay,
How big is your output image?
Does the problem go away if you make your output image size half that
what it is now? (both X and Y).
What happens if you start with horribly compressed jpg images? If you
set the quality very low, they will become very ugly, but this doesn't
matter for the
Apparently I did misread your comment. I thought you were saying that
multirow did the overlapping-parts thingy.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/936090
Title:
cpfind does not
Bruno others,
I've decided to make a low-res (because of data-size reasons) version of
my project available.
At http://prive.bitwizard.nl/demo.zip you can find a 78Mb file that
contains 380 pictures I took. (I took about double that amount, this is
just the run until the battery ran out. I now
On Wed, Feb 22, 2012 at 10:46:51PM -, Bruno Postle wrote:
This is what the 'auto estimate' option in the Control Points tab is
supposed to do, but it doesn't appear to be functional in
2011.3.0.426bd4721b14 here.
Bruno,
As the auto exstimate only works after you've added at least one
I don't understand why matrixmode works so horribly then.
There is a tendency to say: Oh, but this program can do that too. This
results in complex programs that work when the programmer was thinking
of exactly what you want, and that it won't do what someone else wants
when he wants something
Public bug reported:
I'm shooting my images with a motorized setup. So I more or less KNOW
the layout of the images.
To prevent wrong controlpoints from pulling the images completely out of
whack, I would like to create controlpoints between each image and the
background.
** Affects: hugin
Public bug reported:
I'm shooting big panos now. I'm also shooting images that contain
nothing but sky. Controlpoints in that area are lowsy at best.
When I've got things lined up reasonably, I would like to be able to
say: Get me a controlpoint HERE.
i.e. I click on the left image, and using
Public bug reported:
Sometimes the finetune gives a low coefficient, so you get a popup.
This would be a good moment to ask: Do you want to keep the point where
it was or do you want me to move it anyway.
A visual aid to help me visualise which one is better would be a
terrific aid.
On the
Public bug reported:
I'm shooting panoramas in matrix mode. So I do a row, move to the next
row and then move along the row again.
for example 16 pictures might be taken as follows:
0 12 3
7 65 4
8 9 10 11
15 14 13 12
I use the snake algorithm to reduce the amount of
Public bug reported:
when cpfind runs on a project that has images with identical names (but
from different directories), the control points get assigned to the
wrong images.
I have not personally reproduced this: reported by a friend.
** Affects: hugin
Importance: Undecided
Aaargh. I've been trying (for hours and hours) to find where to fix
this, I'd gotten and compiled the 2011.2 sources, but appear to have
been running the older 2010.4 version. :-(
It seems that currently, as I wanted, the apply anyway dialog is
shown, even if you cancel the optimization step.
Public bug reported:
When I try to abort the assistant while it's detecting the control
points it simply says:
i23 i24 : Found 22 matches
i24 i25 : Found 18 matches
make: *** wait: No child processes. Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes. Stop.
Attached is the patch that implements matrixmode (shooting left-to-right rows
bottom-up (*)).
It also implements snake mode: going left-to-right alternates with
right-to-left.
These modes just cause a second neighbor to be checked for matches.
The neighbor is predicted using the user-supplied
Public bug reported:
When I select say images 100-110 and hit remove selected images (in
the images tab), no visual feedback is given that the remove actually
happened. So the user is encouraged to hit remove selected images
again (and again). It turns out that after deleting say images 100-110,
The version I have may be a bit old: 2010.4.0.854952d82c8f, but I doubt
this has changed.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/882968
Title:
Gui: Removing images doesn't change
Public bug reported:
I have built my own gigapan hardware. I made a test shot with only
200 images.
The camera swept across the FOV snake-mode left-to-right, up one row and
then right-to-left.
CPfind found matches between most adjacent images. Whenever the camera
went UP the controlpoiints are
Public bug reported:
background:
the default for the -m option is 1024Mb. This means that you'll need
about 1Gb of swap if your machines has less than 1G of RAM. Fine. When
you have 1G of RAM, you'll be fine. You'll waste some RAM if you have
2G, but if you have 4, 8 or 16Gb, enblend will run in
So: yes it blends when you try it without imagecache and have enough
swap space available. Enblend crashes without any reason according to
your first message. Just enblend was killed is output by make.
Probably segmentation fault is somewhere in there, but lost
I personally stitch at one
On Tue, Apr 05, 2011 at 08:38:43PM -, the_mechanical wrote:
Still no output (enblend built with imagecache)
make -j 4 -f pano.pto.mk NONA='nona -t 1' ENBLEND='enblend -m 6000'
...
enblend: info: loading next image: project0027.tif 1/1
make: *** [project.png] Getötet
make: *** Datei
Just to add WHY the = sign is so problematic. When you say: make
'foo\=bar'
make assigns the value bar to a variable named foo\. See attached
makefile, test with the above commandline.
** Attachment added: Makefile
Bruno, exactly.
Just to clarify, I'm not the original reporter, but I can understand the
issue. Also, a friend ran into this, as she works in the NFS-mounted
directory that has backups etc etc, but there is no reason to send the
temporary nona remapped images over the network (back and forth).
The pto file names are obviously generated with some mstemp function.
That's all fine and dandy, but how about the following? We do the random
filename thingy once per session (reinitialize on loading a new
project?). Now we have a fixed filename pto file and Makefile.
Now for the dependency,
I now managed to find the correct placement by quitting hugin, and
manually adjusting RPY values. This is not the usability level that
hugin should be aiming for
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
I increased the resolution of the output and it went away too. (I had
decided not to worry about it for now)
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/721136
Title:
enblend creates an
The problem is that at my preview window resolution the pictures were
already automatically aligned to sub-pixel accuracy. But at a test-
rendering resolution of 4000 horizontal I could see the discontinuity in
the horizon. (I usually use the optimal size for the final render, but
may go for only
Public bug reported:
enblending http://prive.bitwizard.nl/t80001.tif
and http://prive.bitwizard.nl/t80003.tif
results in http://prive.bitwizard.nl/t8a.tif
I cannot say I expected that black triangle in the output. My enblend
was pulled from hg this morning (no
oops. I see that I forgot to include the commandline I used. I had
intended to include it. On the other hand. It can't be simpler
enblend t80001.tif t80003.tif -o t8a.tif
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
here is the pto file.
** Attachment added: DSC05514-DSC05527.pto
https://bugs.launchpad.net/hugin/+bug/720556/+attachment/1855597/+files/DSC05514-DSC05527.pto
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
After removing one image, it still crashes, but now it crashes earlier!
** Attachment added: blendbug2
https://bugs.launchpad.net/hugin/+bug/720556/+attachment/1855602/+files/blendbug2
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to
I was going to add my PTO, but I can reproduce it with:
enfuse -w -o dsc_3210-dsc_3254_stack_ldr_0005.tif
dsc_3210-dsc_3254_exposure_layers_0018.tif
dsc_3210-dsc_3254_exposure_layers_0019.tif
dsc_3210-dsc_3254_exposure_layers_0020.tif
The source images have just one small triangle of data
Just found that this is the master bug, so marked the other one bug
#685903 as duplicate. My source images are downloadable:
http://prive.bitwizard.nl/dsc_3210-dsc_3254_exposure_layers_0018.tif
http://prive.bitwizard.nl/dsc_3210-dsc_3254_exposure_layers_0019.tif
*** This bug is a duplicate of bug 685105 ***
https://bugs.launchpad.net/bugs/685105
** This bug has been marked a duplicate of bug 685105
enblend fails to blend large pano
* You can subscribe to bug 685105 by following this link:
https://bugs.launchpad.net/enblend/+bug/685105/+subscribe
OK. I tried it with the original images, and the tip version of
hugin. Seems fixed. - Fix released.
(I tried it with the .pto I found in the directory with my images, as
well as the one I saved here with this bug, and both will fire up the
fast preview window just fine. Lots has changed since I
** Tags added: build
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/706709
Title:
build fails with gcc-4.6.0
Status in Hugin - Panorama Tools GUI:
Fix Committed
Bug description:
Fedora
** Tags added: internationalization portugese
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/704352
Title:
Portuguese translation updated - brazilian portuguese
Status in Hugin - Panorama Tools
** Tags added: macos stitching
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679353
Title:
Stitching fails with '' character in path
Status in Hugin - Panorama Tools GUI:
Incomplete
Bug
** Tags added: calculation focal fov length preview rendering
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679317
Title:
[layout] Focal length is incorrect for portrait images
Status in Hugin
Does this still happen
** Tags added: crash optimizer
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/678980
Title:
Optimizer crashes when images are given Exif+lens file
Status in Hugin -
** Tags added: ev exposure optimization value
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/678963
Title:
EV value 8 steps off with a linear camera
Status in Hugin - Panorama Tools GUI:
** Tags added: images layout tab
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679338
Title:
EXIF-data mangles layout of Images Tab
Status in Hugin - Panorama Tools GUI:
Confirmed
Bug
** Tags added: alloc large memory nona stitch
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679163
Title:
Nona runs out of memory over 500Mpixels.
Status in Hugin - Panorama Tools GUI:
** Changed in: hugin
Status: Triaged = Confirmed
** Tags added: optimizer save settings
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679080
Title:
Exposure settings not saved
Status
We should not crash but print an error message.
** Changed in: hugin
Importance: Low = Wishlist
** Tags added: error file message open preview
** Changed in: hugin
Importance: Wishlist = Low
--
You received this bug notification because you are a member of Hugin
Developers, which is
Question:
Downscaling would lose data, upscaling the 8-bit image to 16-bit would
be the right thing to do.
The little I have been able to look at the code, wouldn't it be possible
to easily upscale the images that have a lower bit-depth? Just allocate
a new image object of the right size, and
Christoph, Even though you're a (the?) major enblend developer, this
fact doesn't make this into your private bug-database or todo list.
Developing open source is a cooperation effort between different people.
Each doing what they are good at. . You're the one who messes around
with the source.
*** This bug is a duplicate of bug 685105 ***
https://bugs.launchpad.net/bugs/685105
I think this is the same issue: The image cache corrupts the data or
causes a crash.
** This bug has been marked a duplicate of bug 685105
enblend fails to blend large pano
* You can subscribe to bug
** Tags added: enblend stops
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679303
Title:
enblend: mask is entirely black but white image was not iden
Status in Enblend:
Fix Released
Bug
*** This bug is a duplicate of bug 679303 ***
https://bugs.launchpad.net/bugs/679303
** Tags added: enblend stops
** This bug has been marked a duplicate of bug 679303
enblend: mask is entirely black but white image was not iden
* You can subscribe to bug 679303 by following this link:
*** This bug is a duplicate of bug 679303 ***
https://bugs.launchpad.net/bugs/679303
** Tags added: enblend stops
** This bug has been marked a duplicate of bug 679303
enblend: mask is entirely black but white image was not iden
* You can subscribe to bug 679303 by following this link:
Sean, Feel free to Email them to me. Click on my name to go to my
profile, and then don't use the sourceforge address...
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/687393
Title:
When HDR
** Changed in: hugin
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679975
Title:
FoV weirdness with projections and preview
Status in Hugin - Panorama Tools GUI:
fixed for me. now 2010.4 beta.
** Changed in: hugin
Status: New = Fix Released
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/678647
Title:
Crop Screen Image Artifacts
Status in Hugin -
** Changed in: hugin
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/678765
Title:
getFocalLength() warnings
Status in Hugin - Panorama Tools GUI:
Triaged
Bug
** Changed in: hugin
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679035
Title:
Incorrect TempDir Parsing Prevents any Stitching.
Status in Hugin - Panorama Tools
** Changed in: hugin
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679399
Title:
hugin fails to compile when using Intel's MKL as lapack lib
Status in Hugin -
Confirmed.
** Changed in: hugin
Status: New = Confirmed
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679414
Title:
Duplicate file names confuse align_image_stack
Status in Hugin -
moeep: Your test doesn't provide any confusion: It shows that without
image cache, it all works fine.
** Tags added: corruption image imagecache
** Changed in: enblend
Status: New = Confirmed
** Changed in: enblend
Importance: Medium = High
--
You received this bug notification
** Changed in: enblend
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/685877
Title:
Push VIGRA changes to the right place
Status in Enblend:
Triaged
Bug
Thomas, you have to learn to distinguish between a work-in-progress
patch and a final suggested fix patch.
Yes, I'm sure that on Unix you can keep an open filedescriptor to a file
and rename it. The common way to prevent temporary files from cluttering
the filesystem is to open the temporary
** Tags added: glpreview
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679157
Title:
Distortions in OpenGL preview
Status in Hugin - Panorama Tools GUI:
Confirmed
Bug description:
It happens with 4.0 TOO.
I have blended my panorama now with a 4.0 build on a 64bit machine. I
just let the OS swap. It required over 12Gb of RAM/swap, and finished
the blend just fine!
I'm now pretty sure that it is imagecache that causes the corruption or
crashes.
I chose to NOT use
On Tue, Dec 07, 2010 at 12:47:47AM -, Yuv wrote:
Share the patch please. Can't promise (lot of things on my todo list),
but if it still does not have a preference setting I can contribute
that.
Place = storage space in the file system? how about taking the time when
the Hugin instance
Public bug reported:
I have embedded my panorama in google earth (through gigapan). But the
location of the panorama is slightly off. I was thinking I could put a
few controlpoints on google earth and my pano, so that I could get a
perfect location match for my panorama.
** Affects: enblend
Ok. Guys... With these reports about enblend I need to know wether or
not you have Image cache enabled or not.
** Project changed: hugin = enblend
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
** Project changed: hugin = enblend
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/679456
Title:
stitching failure
Status in Enblend:
Triaged
Bug description:
Attempting full res HDR
** Also affects: enblend
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679520
Title:
hdrmerge fails due to differing image sizes
Status in Enblend:
Yuv, If I have half-a-person on a picture, I know I don't want that in
the final picture. This is easily masked.
If I have a full person on a picture I might want to mark it as:
please include all this, because otherwise enblend might cut of a head
or a foot. These are the red and green areas in
Harry, you see what you do with this. EMail me if you're not in the
bughunters group to modify the states. (or mail Yuv to have yourself
added).
** Project changed: hugin = enblend
** Changed in: enblend
Assignee: (unassigned) = hvdwolf (hvdwolf)
--
You received this bug notification
*** This bug is a duplicate of bug 678946 ***
https://bugs.launchpad.net/bugs/678946
** This bug has been marked a duplicate of bug 678946
nona: bad allocation with high-resolution panorama
* You can subscribe to bug 678946 by following this link:
*** This bug is a duplicate of bug 678946 ***
https://bugs.launchpad.net/bugs/678946
** This bug has been marked a duplicate of bug 678946
nona: bad allocation with high-resolution panorama
* You can subscribe to bug 678946 by following this link:
Someone should check if this is still valid. But it sounds like a valid
request to me.
** Changed in: hugin
Importance: Undecided = Wishlist
** Changed in: hugin
Status: New = Triaged
** Tags added: alpha channel matchpoint
--
You received this bug notification because you are a
I have tested this, and this set of images comes out just fine when I
run it through hugin.
Apparently fix released in the last two years.
** Changed in: hugin
Importance: Undecided = Medium
** Changed in: hugin
Status: New = Fix Released
** Tags added: autopano-sift-c hang
--
You
Careful examination shows that you're enblend-ing a stack that should be
enfused. Could this be a user-error? The stitcher tab has been changed,
and will change even more.
** Changed in: hugin
Status: New = Invalid
** Changed in: hugin
Importance: Undecided = Low
** Tags added:
Probably user error: Nona couldn't find the source image.
** Tags added: nona precondition
** Changed in: hugin
Importance: Undecided = Low
** Changed in: hugin
Status: New = Invalid
--
You received this bug notification because you are a member of Hugin
Developers, which is
There is a workaround, (hover over the menu items).
Does this still happen?
Can anybody reproduce this with 2010.4 ?
** Changed in: hugin
Status: New = Incomplete
** Changed in: hugin
Importance: Undecided = Low
** Tags added: controlpoint-tab corruption display
--
You received
This is probably due to the other scaling program doing something wrong
/ unexpected.
** Changed in: hugin
Importance: Undecided = Low
** Changed in: hugin
Importance: Low = Wishlist
** Changed in: hugin
Status: New = Triaged
** Tags added: crop factor fov
--
You received this
** Tags added: autopano-sift-c fisheye projection
** Changed in: hugin
Importance: Undecided = Medium
** Changed in: hugin
Status: New = Triaged
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
Oh. If it crashes, can you post the images so that we can check if it
happens cross-platform, and that someone with coding skills can run with
your images inside the debugger.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
save / load should not lead to different results
** Changed in: hugin
Importance: Undecided = Medium
** Changed in: hugin
Status: New = Triaged
** Tags added: preference pto save
--
You received this bug notification because you are a member of Hugin
Developers, which is
Build problem?
The program enblend fails to start, giving an immediate error. This is
so basic, someone will show up with a bug report if this still happens.
** Tags added: build enblend
** Changed in: hugin
Status: New = Fix Released
** Changed in: hugin
Importance: Undecided = Low
It should be using enfuse. I think modern Hugin now detects this
situation and calls the right programs.
** Changed in: hugin
Importance: Undecided = Medium
** Changed in: hugin
Status: New = Fix Released
** Tags added: enblend enfuse hdr
--
You received this bug notification
1 - 100 of 175 matches
Mail list logo
