[ panotools-Bugs-2995662 ] Uninitialized variable used

Bugs item #2995662, was opened at 2010-05-03 01:40
Message generated for change (Tracker Item Submitted) made by gloinson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=613954&aid=2995662&group_id=96188

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: windows build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Georg Becker (gloinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninitialized variable used

Initial Comment:
My compiler (VC9) tells me, that in 'math.c', line 1103 the uninitialized local variable 'a' is used. I
looked over the code and do not find any macro that might initialize 'a'. The line has been comitted with
rev1251 and I really can't extrapolate how to initalize 'a' ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=613954&aid=2995662&group_id=96188

------------------------------------------------------------------------------

[ panotools-Bugs-2995662 ] Uninitialized variable used

Bugs item #2995662, was opened at 2010-05-02 19:40
Message generated for change (Comment added) made by tksharpless
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=613954&aid=2995662&group_id=96188

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: windows build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Georg Becker (gloinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninitialized variable used

Initial Comment:
My compiler (VC9) tells me, that in 'math.c', line 1103 the uninitialized local variable 'a' is used. I
looked over the code and do not find any macro that might initialize 'a'. The line has been comitted with
rev1251 and I really can't extrapolate how to initalize 'a' ...

----------------------------------------------------------------------

Comment By: Tom Sharpless (tksharpless)
Date: 2010-05-03 08:28

Message:
Thanks for catching this bug.  It may have been causing part of the trouble

Theorical question about Exposure Values...

Hello,
I am trying to implement an idea I have since sometimes about enfuse and 
stacks:

The background:
My camera can do 7 different exposure in bracketting mode.

The idea:
Find a way to determine which combinaison of image should be enfused for 
the best setting.

How to determine it:
Test all the available simple possibility to enfuse: equals to  
2^(number of brackets)-1 images.

An example:
http://esby.free.fr/perso/images/temp/EV/list.html

The first seven images are reducted images of the bracket.
The other images are combinaisons of them.
labelled like: P1350354-P1350360-123567.png where 123567 corresponds to 
the bracketted images actually used to make the image in enfuse.

Now the problem:
Source Images are coming with EV in the exif, which are:
Light Value                     : 15.6
Light Value                     : 15.6
Light Value                     : 14.9
Light Value                     : 14.3
Light Value                     : 13.6

Re: GSoC - Regression tests for pano13

Hi Daniel,

OK so I have schedule for next days :).

Firstly I'll integrate tests and scripts with the build process in
libpano and add scaled reference images.

Then, I'll extend existing test generating script with options
described in doc/stitch.txt.

I have no questions about these two tasks yet. But I'm sure it is a
matter of time and I won't hesitate to write those question on this
mailing list :).

Anyway I already have question about comparing reference images with
the results. Should I assume that test and reference images will be
the same in all type of tests, and mark test as not passed otherwise?
Or should I use other method of comparison. Some of the methods are
described in: http://www.imagemagick.org/Usage/compare/ but most of
them aren't useful for automatic tests. However
http://www.imagemagick.org/Usage/compare/#statistics might be.

Best regards,
Tom

2010/5/12 D M German <dmg@...>:
>
>
> Hi Tomasz,
>

Re: GSoC - Regression tests for pano13

> Anyway I already have question about comparing reference images with
> the results. Should I assume that test and reference images will be
> the same in all type of tests, and mark test as not passed otherwise?
> Or should I use other method of comparison. Some of the methods are
> described in: http://www.imagemagick.org/Usage/compare/ but most of
> them aren't useful for automatic tests. However
> http://www.imagemagick.org/Usage/compare/#statistics might be.
>

Yes, comparing images is not trivial. PTmender is always deterministic in its
creation of the data, and hence we can use tiffcmp -t (the heathers
might be differentt).

but to compare nona and PTmender we need something less deterministic, and
here is where compare can help. But I am not sure how, and that could be
one of your duties: to find the right parameters so we can compare with relative
confidence the output of both.

> Best regards,
> Tom
>
> 2010/5/12 D M German <dmg@...>:
>>
>>
>> Hi Tomasz,
>>
>> let us move this discussion to the mailing list, since it might benefit
>> from the input of others.
>>
>> I'll fix the bug of the TIFF_M. I have been procrastinating about it.

Re: GSoC - Regression tests for pano13

On Wed 12-May-2010 at 08:44 -0700, Daniel M. German wrote:
>
>Yes, comparing images is not trivial. PTmender is always deterministic in its
>creation of the data, and hence we can use tiffcmp -t (the heathers
>might be differentt).
>
>but to compare nona and PTmender we need something less deterministic, and
>here is where compare can help. But I am not sure how, and that could be
>one of your duties: to find the right parameters so we can compare with relative
>confidence the output of both.

Gimp has a 'grain extract' tool which subtracts one image from the 
other (using signed values) and adds 128, the result is a 50% grey 
image if the two are identical, any variation from grey indicates 
that the two images are different.

A new command-line tool could do the same, then look at the average 
variation and/or maximum variation and pass/fail on a threshold 
provided as a parameter.

--

-- 
Bruno

------------------------------------------------------------------------------

Re: GSoC - Regression tests for pano13

>
> Gimp has a 'grain extract' tool which subtracts one image from the
> other (using signed values) and adds 128, the result is a 50% grey
> image if the two are identical, any variation from grey indicates
> that the two images are different.
>
> A new command-line tool could do the same, then look at the average
> variation and/or maximum variation and pass/fail on a threshold
> provided as a parameter.

That is a good idea if the pixels are perfectly overlapped. My
understanding is that
compare (from imagemagick) does something similar with one of its
metrics, but it also capable
of dealing with pixel offsets using statistics.

one problem I ran into using compare is that it does not respect
masks, which creates a huge problem
because the masks data is identical, but not relevant.

--dmg

>
> --
> Bruno
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> PanoTools-devel mailing list

Re: Hugin builds

------------------------------------------------------------------------------

_______________________________________________
PanoTools-devel mailing list
PanoTools-devel@...
https://lists.sourceforge.net/lists/listinfo/panotools-devel

bugs in libpano

Hi Tomasz,

i was looking at your message about bugs in libpano,  can you please
clarify this:

   during tests I noticed two types of errors using PTmender:

   1) errors similar to the thread I found:
   http://www.mail-archive.com/hugin-ptx-/JYPxA39Uh5TLH3MbocFFw <at> public.gmane.org/msg08005.html,
   but when I'm using tiff_m_uncropped format this errors don't appear.

Can you send me a precise script that shows this error?

   2) some of tests don't stop I marked this errors in
   gen.pl: #errors#, #time#, so it is possible to uncomment lines and check
   the problem.

Can you also explain me the causes of this error are?

--

-- 
--
Daniel M. German                  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with  <at>  and (dot) with .

------------------------------------------------------------------------------

dealing with the explosion of tests

Hi Tomasz,

I like the way you are organizing the tests by parameter. I think that
we need to reduce the explosion of potential tests, otherwise we will
have wayyy too many files, as you have discovered  :)

I think we need to divide tests into two basic types:

1. Those that test the complete workflow.

For this we don't test variants. We just drop a bunch of images with a
script and test their output. It is basically regression testing.

2.  Those that test basic/specific functionality

For example, to test f0, we only need to test f0 (in the input image) we
don't have to recreate any type of output. We can just create an 
equirectangular (as output). But there are several cases that we need to
test for each input format that might be tricky: for example, when the
input image covers an area on the edges of the field of view (and hence
wraps from one end to the other). In that case we only need 2 -4 cases
for each input format.

Then it comes output formats. To test the output formats we can do it
with one equirectangular (360x180) as input and every output format as
output.

then it comes the multiple variants of parameters in the output
line. There are soo many that is numbing :) What I suggest is that we
find 2 or 3 "fixed" sets of parameters for everything (for example,
everything equal to zero, and a 2nd test with more "real world"
parameters) and then we test each parameter with those sets of scripts
(with one rectilinear and one fish eye input image). in other words, we
have a script with 2 lines, one with all parms zero (line 1), and one
with normal values (line 2). Then we create 4 tests for a given
parameter: line 1 with parm equal 0, line 1 with parm <>0, line 2 with
parm equal 0 and line 2 with parm <> 0. This way we only need 8 output
images per parameter (4 for fisheye and 4 for rectilinear).

What do you think?

Do you feel comfortable talking in English? if so we can set some
regular time to talk using skype. 

--
Daniel M. German                  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with  <at>  and (dot) with .

------------------------------------------------------------------------------