Re: [hugin-ptx] Use of Hugin in remote sensing

[Frederic Da Vitoria]

Le 8 nov. 2012 08:35, "alouest" <julien....@gmail.com> a écrit :
>
> Hello,
> Every day user of Hugin in my hobby-life, I'm now trying to use it at work. I saw that Hugin has been use in remote sensing and I would like to use it as well.
> For the project I'm working on right now, I need to stitch together 5000 thousand 32 bit tiff files and/or 4 band tiff files.
> Basically I want to create a temperature raster mosaic but in order to stitch the picture together, I need the 3 RBG band, the problem is that I can't figure out a way to do it use hugin.
> I could as well trying to stitch the 32bit tiff but Hugin see them as blank.
> Any idea how to resolve that?

Does any of your 8 bit sub-image sets have enough details to detect correct control points? If so you could copy 3 times the generated .pto file and then edit the copies with e text editor to make them use the images from one of the other bands.

[alouest]

Thanks for the answer,

Well yes the sub-image might have enough detail to detect control points, the problem is how to include the temperature band in the finale result?

I don't need the RGB information, I just need the temperature, I keep the RGB because it's readable by hugin.

I have got already a full coverage of my study area with the RGB value but i can't figure out how to include my 32 float data (temperature) in the result.

I tried to save the PTO from the rgb process and then apply it on the 32 bit tiff, it works but hugin overwrite the data and put them at zero.

Nona by example while it should do a simple crop of the image, set all the value to zero :/.

[Frederic Da Vitoria]

Could you generate tiffs where one of the standard colors is replaced with the temperature band?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[alouest]

That was one of my option, the only problem is the loss in accuracy, since my value are pretty accurate I can't afford to loose the decimal.

But maybe I'm wrong? I will dig around this idea!

It's pretty frustrating though because I have the pto with all the control points and I just want to stitch the picture together without any further modification put nano or enblend or pTstitch won't let me do that :/ 

Any way I will try the temperature band

Thanks

[alouest]

I tried, it looks pretty in ArcGis, but hugin doesn't like, it crash.

I probably didn't respect the 16 tiff structure that hugin is expecting.

[Bruno Postle]

On Fri 09-Nov-2012 at 08:16 -0800, alouest wrote:
>I tried, it looks pretty in ArcGis, but hugin doesn't like, it crash.
>I probably didn't respect the 16 tiff structure that hugin is expecting.

Hugin works here with HDR floating-point RGB data, it isn't
necessary to map the data to 16bit integer values.

You can use TIFF or EXR containers for your HDR data.

--
Bruno

[alouest]

I wish!

When I process my file (32 float point) it gives me a tiff filled with the value 1.

[Bruno Postle]

On Fri 09-Nov-2012 at 11:15 -0800, alouest wrote:
>When I process my file (32 float point) it gives me a tiff filled with the
>value 1.

Can you see your float images in Hugin? i.e. start Hugin, load one
image, open the 'old preview' (View -> Preview Window) and set
Output to HDR and click Update. You should see a crudely tonemapped
version of your image.

--
Bruno

[alouest]

Thanks a lot for your help!

Yes, I see them without problem.

I tried with 3 32 floating point tiff, the process went smoothly, the only problem is that the result is empty or filled with the value one.

I'm not an expert so maybe I don't use the good settings?

A funny things, if I try to import my result and open the preview hugin crash

[Bruno Postle]

On Fri 09-Nov-2012 at 11:39 -0800, alouest wrote:
>Yes, I see them without problem.
>I tried with 3 32 floating point tiff, the process went smoothly, the only
>problem is that the result is empty or filled with the value one.
>I'm not an expert so maybe I don't use the good settings?
>A funny things, if I try to import my result and open the preview hugin
>crash

So if you can see the images tonemapped in the preview, you need to
look at the intermediate files created by nona before blending.

In the Stitcher tab, select Panorama Outputs -> High Dynamic Range,
and Remapped Images -> High Dynamic Range, and click the Stitch!
button at the bottom right.

This should create several files, are any of these ok?

--
Bruno

[alouest]

I wasn't able to run hugin on those settings, it crash saying that

 Precondition violation!

exportImage(): file format does not support requested number of bands (color channels)

"C:/Program Files/Hugin/bin/nona"  -r hdr -m EXR_m -o "bruno_try_hdr_0000_hdr_" -i 1 "C:/Users/JSCHRO~1/AppData/Local/Temp/hug8C6B.tmp"

ContractViolation: 

Precondition violation!

exportImage(): file format does not support requested number of bands (color channels)

So i ran the nona standalone which gave me 3 empty tiff.

I guess that my file are not traditionnal data and hugin or just nona doesn't know how to handle them

[Bruno Postle]

On Fri 09-Nov-2012 at 12:07 -0800, alouest wrote:
>I wasn't able to run hugin on those settings, it crash saying that
>
> Precondition violation!
>exportImage(): file format does not support requested number of bands (color channels)
>"C:/Program Files/Hugin/bin/nona" -r hdr -m EXR_m -o "bruno_try_hdr_0000_hdr_" -i 1 "C:/Users/JSCHRO~1/AppData/Local/Temp/hug8C6B.tmp"

The problem is that your HDR TIFF files have only one channel. The
Hugin tools actually support this, but HDR stitching using Hugin
uses EXR files as intermediate images - and apparently these don't
support a single channel.

You can stitch on the command line using TIFF intermediate images,
I'll attach a .pto project for your three pictures, stitch it like
this:

nona -m TIFF_m -o temp Rec-000825_50-Rec-000825_150.pto

enblend -o temp.tif temp0000.tif temp0001.tif temp0002.tif

--
Bruno

[alouest]

That is amazing!

Thanks a lot!!

# hugin project file
#hugin_ptoversion 2
p f0 w699 h891 v54  E0 R1 n"TIFF_m c:LZW r:CROP"
m g1 i0 f0 m2 p0.00784314

# image lines
#-hugin  cropFactor=1
i w640 h480 f0 v50 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r-0.165167142928385 p-10.3957432895672 y-0.566840920194418 TrX0 TrY0 TrZ0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 Rt1 n"Rec-000825_50.tif"
#-hugin  cropFactor=1
i w640 h480 f0 v=0 Ra=0 Rb=0 Rc=0 Rd=0 Re=0 Eev0 Er1 Eb1 r-0.353146083325907 p2.24067170355037 y0.350837689232161 TrX0 TrY0 TrZ0 j0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 Va=0 Vb=0 Vc=0 Vd=0 Vx=0 Vy=0  Vm5 Rt1 n"Rec-000825_100.tif"
#-hugin  cropFactor=1
i w640 h480 f0 v=0 Ra=0 Rb=0 Rc=0 Rd=0 Re=0 Eev0 Er1 Eb1 r-0.217026550579806 p13.3641170531987 y0.596663517300591 TrX0 TrY0 TrZ0 j0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 Va=0 Vb=0 Vc=0 Vd=0 Vx=0 Vy=0  Vm5 Rt1 n"Rec-000825_150.tif"


# specify variables that should be optimized
v r1
v p1
v y1
v r2
v p2
v y2
v


# control points
c n0 N1 x103.950255391367 y57.2938036679381 X88.9596120866872 Y208.380557442996 t0
c n0 N1 x152.7419876518 y104.289818004 X138.476445046596 Y256.570918457423 t0
c n0 N1 x112.853347578993 y156.51711541469 X97.9230173107695 Y309.093356944706 t0
c n0 N1 x66.4473854620143 y214.717245472465 X50.9298446572006 Y368.263909559231 t0
c n0 N1 x133.529544016685 y271.123798563837 X120.323826101043 Y425.745060745291 t0
c n0 N1 x188.446735435606 y62.7538316897661 X174.314570055983 Y214.488086426416 t0
c n0 N1 x185.17237180208 y110.909249659819 X171.598217356795 Y263.993687753127 t0
c n0 N1 x262.3158411624 y140.153541859171 X249.845480333406 Y293.59525756641 t0
c n0 N1 x223.965956881806 y229.42211803516 X210.08272423536 Y385.675118248205 t0
c n0 N1 x165.469949863746 y247.709997397152 X152.095402730339 Y401.999629302328 t0
c n0 N1 x377.825831083697 y80.337753304767 X364.753788129548 Y232.883349734231 t0
c n0 N1 x362.270513884796 y136.588148095714 X349.938624450315 Y289.790943916235 t0
c n0 N1 x369.065278072151 y153.95560970741 X356.443106405721 Y307.468820748626 t0
c n0 N1 x376.546370789279 y193.921386035317 X364.182285729999 Y348.097321317384 t0
c n0 N1 x356.259099724765 y253.017340495956 X344.047416476953 Y407.737167586604 t0
c n0 N1 x487.678287356034 y43.1780565239335 X475.462199356675 Y194.91707058027 t0
c n0 N1 x421.007731687183 y91.0750420959119 X408.449060193072 Y244.963041266381 t0
c n0 N1 x446.198713660721 y149.912175686104 X434.315605181239 Y303.312216874344 t0
c n0 N1 x389.23106484808 y219.791961835007 X377.429182491646 Y374.166458646913 t0
c n0 N1 x450.687309871055 y270.252405812848 X439.471459638493 Y425.31745558231 t0
c n0 N1 x506.057761456043 y35.901634149673 X493.987313348825 Y187.046142298863 t0
c n0 N1 x585.312321017347 y97.1068325642985 X572.614382247536 Y249.872188923869 t0
c n0 N1 x516.954436128497 y184.669502429287 X506.556992456126 Y338.04632588682 t0
c n0 N1 x611.872594121361 y201.022311228551 X602.211965624246 Y355.34873213473 t0
c n0 N1 x582.887902618172 y248.858420607281 X572.061972733346 Y403.878982646532 t0
c n1 N2 x43.7676169823029 y49.4203345872781 X36.8265737304733 Y182.689699427826 t0
c n1 N2 x61.0824188734288 y102.285417838258 X55.3539310920958 Y236.309241044921 t0
c n1 N2 x135.131055036341 y164.839488525181 X130.45851085654 Y300.305811718888 t0
c n1 N2 x138.145708200256 y205.801682682025 X134.290108344165 Y341.716776771311 t0
c n1 N2 x113.933617083295 y255.149892320969 X110.108586822036 Y391.526518484375 t0
c n1 N2 x185.160975348077 y67.0081159327115 X179.725837970576 Y200.513297980875 t0
c n1 N2 x240.247009368284 y121.768088784844 X235.693418136414 Y256.344242811182 t0
c n1 N2 x177.687382897183 y181.575372007461 X173.114009187907 Y315.873669828866 t0
c n1 N2 x167.634473318949 y217.145166891086 X163.18701372117 Y352.965171778593 t0
c n1 N2 x171.598217356795 y263.993687753127 X167.998374076801 Y400.744672518527 t0
c n1 N2 x296.382777251861 y60.5771771736 X291.829169801346 Y194.329131148208 t0
c n1 N2 x333.179914598277 y140.054307522422 X329.261824569147 Y274.631271381833 t0
c n1 N2 x316.703468143302 y145.762059306402 X312.796296432164 Y281.108168974875 t0
c n1 N2 x365.696621242511 y248.423042460927 X363.061233659035 Y384.466154140144 t0
c n1 N2 x356.443106405721 y307.468820748626 X354.423598046614 Y444.223063607025 t0
c n1 N2 x469.236924161974 y84.8231853877794 X466.117745190146 Y217.893237425439 t0
c n1 N2 x467.493344466476 y101.870843700568 X464.469245606952 Y235.096115404576 t0
c n1 N2 x474.220257271785 y155.212191454604 X471.456163050699 Y290.047230648996 t0
c n1 N2 x407.71023311976 y227.140173802604 X405.288623386757 Y362.739997692688 t0
c n1 N2 x447.509602226512 y271.667422843694 X445.466099111494 Y408.21493460829 t0
c n1 N2 x559.4538451502 y82.4221573161325 X557.444568880016 Y216.068610773264 t0
c n1 N2 x550.996689139299 y109.021436221248 X547.44078953008 Y242.981657200902 t0
c n1 N2 x520.422611325407 y177.182555032029 X518.252024834308 Y311.912389448186 t0
c n1 N2 x507.07967932259 y229.325700847749 X504.995917835462 Y365.492178786616 t0
c n1 N2 x512.799136640241 y259.439138294016 X511.099665659591 Y396.238292583398 t0
c n0 N2 x153.007975192067 y54.89052502873 X134.290108344165 Y341.716776771311 t0
c n0 N2 x138.97596259132 y74.6053448953837 X120.416228292959 Y362.214903107898 t0
c n0 N2 x175.637194632832 y93.4712444793672 X157.643411627401 Y381.682240150186 t0
c n0 N2 x123.381550891534 y134.149716085479 X105.916004751175 Y424.186452163225 t0
c n0 N2 x167.970424927964 y146.681966045216 X150.38439063616 Y436.94651087068 t0
c n0 N2 x188.446735435606 y62.7538316897661 X170.287846105395 Y350.471663424994 t0
c n0 N2 x224.014736666649 y83.2685668315503 X206.538354313403 Y371.649202639766 t0
c n0 N2 x185.17237180208 y110.909249659819 X167.998374076801 Y400.744672518527 t0
c n0 N2 x262.3158411624 y140.153541859171 X247.025111897699 Y430.508382460093 t0
c n0 N2 x382.533327641087 y53.5176806867402 X366.853127289489 Y341.080451870327 t0
c n0 N2 x390.628148169891 y73.9575306248515 X377.185420577695 Y360.740498000498 t0
c n0 N2 x378.368146955988 y95.9048341926603 X363.061233659035 Y384.466154140144 t0
c n0 N2 x362.270513884796 y136.588148095714 X347.876924406796 Y427.27125820239 t0
c n0 N2 x369.065278072151 y153.95560970741 X354.423598046614 Y444.223063607025 t0
c n0 N2 x487.678287356034 y43.1780565239335 X473.180031536293 Y330.517541152094 t0
c n0 N2 x479.874944158734 y57.3959924681908 X465.152730358401 Y344.955281971551 t0
c n0 N2 x421.007731687183 y91.0750420959119 X406.181019370736 Y381.207273681754 t0
c n0 N2 x477.107504477922 y121.198993568075 X463.555409268381 Y411.235258245237 t0
c n0 N2 x485.006722409701 y139.615918076752 X471.180571438182 Y429.875397209509 t0
c n0 N2 x506.057761456043 y35.901634149673 X491.592926660974 Y323.25976695607 t0
c n0 N2 x501.64740617211 y56.9107646406301 X486.999349187996 Y345.090848461067 t0
c n0 N2 x585.312321017347 y97.1068325642985 X571.037344258458 Y385.912046271761 t0
c n0 N2 x506.497796842491 y129.699753411445 X492.736689957952 Y419.856113690301 t0
c n0 N2 x575.358042414162 y159.788846210779 X563.586194634518 Y450.39172316112 t0

#hugin_optimizeReferenceImage 0
#hugin_blender enblend
#hugin_remapper nona
#hugin_enblendOptions
#hugin_enfuseOptions
#hugin_hdrmergeOptions -m avg -c
#hugin_outputLDRBlended false
#hugin_outputLDRLayers false
#hugin_outputLDRExposureRemapped false
#hugin_outputLDRExposureLayers false
#hugin_outputLDRExposureBlended false
#hugin_outputLDRExposureLayersFused false
#hugin_outputHDRBlended true
#hugin_outputHDRLayers true
#hugin_outputHDRStacks false
#hugin_outputLayersCompression LZW
#hugin_outputImageType tif
#hugin_outputImageTypeCompression LZW
#hugin_outputJPEGQuality 90
#hugin_outputImageTypeHDR tif
#hugin_outputImageTypeHDRCompression LZW

[alouest]

Almost done! i process this on about 5000 pictures, is there a way to do enblend -o temp.tif temp0000.tif temp0001.tif temp0002.tif  without writing all the files one by one? Something like a mask would be great like enblend -o temp.tif temp000*

Thanks

[Bruno Postle]

On Nov 10, 2012 12:54 AM, "alouest" <julien....@gmail.com> wrote:
>
> Almost done! i process this on about 5000 pictures, is there a way to do enblend -o temp.tif temp0000.tif temp0001.tif temp0002.tif  without writing all the files one by one? Something like a mask would be great like enblend -o temp.tif temp000*

This depends on your shell. You are on Windows, so you should be able to use globbing like this:

  enblend -o out.tif temp000*.tif

--
Bruno

[alouest]

Ok that works, thanks!

I keep having some errors though.

enblend : warning some images are redundant and will not be blended, I checked on arcgis, the information is still here so i don't know what wrong this time

[JohnPW]

I'd be interested in seeing some of your work product when you finish.

I'm just curious to see what some of the original temp mosaic image files and the stitched results look like.  :-)

John 

[alouest]

Enblend gave me the redundant error because I didn't have any value for yaw pitch and roll, if i run the optimizer it's ok.

Now I just have to apply that to my 5000 pictures and cross my fingers, thanks a lot for your help!

[alouest]

Well...

It's pretty weird, I use the multirow option of Cpfind, and the result give me something like 24 different groups of images, for most of them it's really easy to create the control points by hand and I don't get why Cpfind doesn't find them.

Is there a way to ask cpfind to try harder?

The documentation is not really clear especially in the control point detector tab in preference, if you create a new profile and you select multirow panorama and put cpfind -multirow, is it really different that selecting all image at once with cpfind -multirow?

[Bruno Postle]

On Tue 13-Nov-2012 at 11:23 -0800, alouest wrote:
>It's pretty weird, I use the multirow option of Cpfind, and the result give
>me something like 24 different groups of images, for most of them it's
>really easy to create the control points by hand and I don't get why Cpfind
>doesn't find them.
>Is there a way to ask cpfind to try harder?

Yes, don't use the multirow option.

Normally, cpfind compares every photo with every other photo. The
multirow option speeds things up by only comparing photos that are
likely to overlap, but it doesn't always work.

However, with the new 2012.0.0 release, Hugin tries multirow first,
then automatically falls back to matching every photo if multirow
fails.

--
Bruno

[alouest]

Ok thank you.

I solved the problem by doing all the first work with the RGB files (CPFIND + optimisation)

Then I move my pto into the 32 bit folder and finish the work ( I notice that I have to add Rt1 after the Vm5 into the i lines to keep the temperature value plus all the change that Bruno pointed out before.

That works almost perfectly. 

A small last issue is the creation of 'hot spot" in the finale file, I don't know why Hugin does that but in some area (always on the edges) it gives me crazy hot area, I join an exemple. My values are between 8 and 30 degrees and those area shows 32 35 40 degree so it's definitely a misstake, any idea how to fixe that?

Thanks a lot again

[Frederic Da Vitoria]

2012/11/16, alouest <julien....@gmail.com>:

"edges": do you mean the edges of the final image or the borders
between each individual source image?

[alouest]

Well my final images is pretty irregular so those points appeared on the border of some images, I fixed that by using the new enblend.

The problem is that now the script doesnt work anymore... I have no clue why!

When typing enblend -o final.tif 825****.tif it takes 8250001.tif 8250003.tif 8250008.tif and of course it tells me that those are not overlapping....

It's like a joke each time it's almost finished... there is a new problem!

[Bruno Postle]

On Tue 20-Nov-2012 at 13:29 -0800, alouest wrote:
>Well my final images is pretty irregular so those points appeared on the
>border of some images, I fixed that by using the new enblend.
>
>The problem is that now the script doesnt work anymore... I have no clue
>why!
>When typing enblend -o final.tif 825****.tif it takes 8250001.tif
>8250003.tif 8250008.tif and of course it tells me that those are not
>overlapping....

I'm not sure about the four asterisks, **** might do strange things.

For globbing, either 825*.tif or 825????.tif would be more likely to
work.

--
Bruno

[alouest]

Ok, I will try that.

I don't really get why I fot those crazy values even with the new enblend.

The funny things is that if  I create the mosaic with all the pictures 141 pictures I get those crazy value.

When I create it with just 131 pictures i don't get them even though the area is covered.

I join a screen copy of the same area.

[alouest]

Well I compare really carefully the source images and the final one, it seems that nona and enblend change the value during the process so all of this was kind of useless since I need my value to stay the same.

I'm kind of desperate now anyone has a way to do that without changing the values?

[Bruno Postle]

On Nov 21, 2012 10:54 PM, "alouest" <julien....@gmail.com> wrote:
>
> Well I compare really carefully the source images and the final one, it seems that nona and enblend change the value during the process so all of this was kind of useless since I need my value to stay the same.
> I'm kind of desperate now anyone has a way to do that without changing the values?

If you don't want the values to change during blending then maybe you need a simple seam without any feathering, try using an enblend -l 1 parameter. This will do a basic hard-edged montage.

Though I'm not sure exactly what your problem is without more info.

--
Bruno

[Terry Duell]

Hello Julien,


On Thu, 22 Nov 2012 09:54:22 +1100, alouest <julien....@gmail.com>
wrote:

Have you looked at GRASS GIS as a way of stitching/patching your images
together?


Cheers,
--
Regards,
Terry Duell

[alouest]

Well sorry as non-english speaker it's pretty hard to make it clear.

i have many Tiff files with temperature information and I know that they overlap since they are extracted from a thermal movie carried on a plane. So my aim is just to past the images together without any change to the value since they will be the base to some really accurate analysis.

It seems that nona as well change the value however  I will try the -l 1 option in enblend and see if it works.

The problem of Grass is that I need coordinates for that, my final image will be georeferenced afterwards but for the moment they don't have any geographical information so i can't use any GIS tools

Thanks again and if you have a magic option for nona to avoid the change of the value i would finish this crazy project!

[Terry Duell]

Hello Julien,

On Thu, 22 Nov 2012 10:47:55 +1100, alouest <julien....@gmail.com>
wrote:

[snip]

> The problem of Grass is that I need coordinates for that, my final image
> will be georeferenced afterwards but for the moment they don't have any
> geographical information so i can't use any GIS tools

OK, I understand.
If you can georeference afterwards, then you should have enough info to
georeference each image prior, then patch them together in GRASS, but that
does require a bit more work.
If you can't stitch in hugin without any change in pixel values, then you
may well have to resort to the above approach.

[Luís Henrique Camargo Quiroz]

Em 21/11/2012 20:47, alouest escreveu:

    Hi,

Well sorry as non-english speaker it's pretty hard to make it clear.

i have many Tiff files with temperature information and I know that they overlap since they are extracted from a thermal movie carried on a plane. So my aim is just to past the images together without any change to the value since they will be the base to some really accurate analysis.

It seems that nona as well change the value however  I will try the -l 1 option in enblend and see if it works.

    I don´t remember if you already told how you got your images. I mean: are your individual pictures a copy of the movie frames? Do you know some parameters of the lens used to make the movie?
    As Hugin uses the lens geometry (image distortions, etc) I seems sensible that nona could change yor values, as nona generates images projected on a sphere (for panoramas) or over a plane, for mosaics -- which I guess is your problem: a planar surface with a field of temperatures.  [post note: I just checked your first message and you told us about "a temperature raster mosaic"]. Have you seen http://hugin.sourceforge.net/tutorials/scans/en.shtml already?

    Did you create the control points by hand, or with cpfind or other automated methods? Your hot surface has enough distinctive features to select as controls points?
    I apologize if those questions are already answered in previous messages... I can´t remember it all ;)

The problem of Grass is that I need coordinates for that, my final image will be georeferenced afterwards but for the moment they don't have any geographical information so i can't use any GIS tools

Thanks again and if you have a magic option for nona to avoid the change of the value i would finish this crazy project!

    regards,

    Luís Henrique

Luís Henrique Camargo Quiroz - http://luishcq.br.tripod.com
my chant page - http://www.christusrex.org/www2/cantgreg

[JKEngineer]

Julien, 

Looking at your two samples, full.jpg and part.jpg, I see two issues.  One is the hot area you identified just below the seam.  The other, which you do not discuss, it the lower temperatures of the entire area above the seam.  This may be from the temperature or gray scale span that you displayed to capture the screen shot, but if not it represents a much more pervasive problem than just the hot area below the seam.  

Are the images that overlap at the seam consistent with each other?  That is, looking at the same geographic area in adjacent images, do you see the same temperatures?  

I did not follow the discussion earlier about using alpha channels, etc., but if I am not mistaken (I could be easily mistaken, I am not a Hugin expert), Hugin tries to even out the levels of a stitched pano.  I don't think you want that.  I don't know if you can completely disable some of the functions, like enblend or nona, but I think you can.  Bruno's suggestion for enblend -l 1 may address that.  

Can you work exclusively in grayscale?  If you select a temperature range that covers all of your images for display, save those as static images, either tiff or jpeg or other, and then stitch those, you may end up with what you want.  It will not have explicit temperature data, but the gray values will map to the temperature.  

JK

[Bruno Postle]

On Wed 21-Nov-2012 at 15:47 -0800, alouest wrote:
>
>Thanks again and if you have a magic option for nona to avoid the change of
>the value i would finish this crazy project!

Nona won't change any values unless you have vignetting or exposure
parameters set in your project files.

enblend blends photos together so this _will_ change values, you can
avoid this by having a hard seam - by setting the enblend -l 1
parameter.

--
Bruno

[alouest]

Thanks all for the answer.

The enblend -l1 is definitely the solution and works pretty well, it gives more gap but at least the temperature are consistent.

Nano doesn't change the value apparently but because the pixels shapes change the value appears different on my software but that's not an issue.

So I think I'm good.

So here we see that it's possible to work with FLIR thermal imagery without purchasing their ultra expensive stitching software which is a good news!

Thanks a lot for your help

So for summary of this discussion and to help people who would like to do the same here is the options that has been selected :

For the PTO

# hugin project file

#hugin_ptoversion 2

p f0 w20000 h29579 v54  E0 R1 S6623,10647,615,28015 n"TIFF_m c:LZW r:CROP"

m g1 i0 f0 m2 p0.00784314

# image lines

#-hugin  cropFactor=1

i w640 h480 f0 v1.98299759399113 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r27.8521414389429 p-32.3543915502492 y-5.94771868772334 TrX0 TrY0 TrZ0 j0 a0 b0 c0 d0 e0 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 Rt1 n"Rec-000842_50.tif"

....

# control points

c n0 N1 x68.1716594051952 y61.2351178588815 X96.5287897418657 Y225.914218938934 t0

....

#hugin_optimizeReferenceImage 0

#hugin_blender enblend

#hugin_remapper nona

#hugin_enblendOptions 

#hugin_enfuseOptions 

#hugin_hdrmergeOptions -m avg -c -c

#hugin_outputLDRBlended false

#hugin_outputLDRLayers false

#hugin_outputLDRExposureRemapped false

#hugin_outputLDRExposureLayers false

#hugin_outputLDRExposureBlended false

#hugin_outputLDRStacks false

#hugin_outputLDRExposureLayersFused false

#hugin_outputHDRBlended true

#hugin_outputHDRLayers true

#hugin_outputHDRStacks false

#hugin_outputLayersCompression LZW

#hugin_outputImageType tif

#hugin_outputImageTypeCompression LZW

#hugin_outputJPEGQuality 90

#hugin_outputImageTypeHDR tif

#hugin_outputImageTypeHDRCompression LZW

i created that in the Hugin GUI

Then I created a bat file with 

"c:\hugin\bin\nona.exe" -m TIFF_m -o 824 824.pto

"c:\hugin\bin\enblend.exe" -l 1 -o pano824.tif 8240000.tif 8240001.tif ...

[alouest]

Hey there, I fnished the first coverage, it looks pretty good, however my stripes have tendancy to turn at the end while they should go straight no matter which projection I use.

I was wondering if it could be because I use the same camera and lens in the settings for all the stripes.

I quote the hugin tutorial for the scanned images : "You need to stop Hugin from assuming that all the pictures were taken with the same camera, so you need to asign a different lens to each image. Do this by selecting one picture and hitting the New lens button. If you have more than two images, set New lens for all the images, such that each image has a different lens number."

How do I modify my PTO to include those information? 

THanks

[alouest]

Hello,

I've got one more problem.

Does Hugin handle the negative value?

I've got Tiff with negative value and it seems that Nona doesn't really like that, it keeps producing positive tiff which is not good at all for me.

Any idea how I could fix that?