Re: Might this idea work? scripting process

[dex Otaku]

Salut alouest,

On Thursday, 8 November 2012 14:01:32 UTC-6, alouest wrote:

'm using a sotware which can export RGB tiff and 32 bit tiff. I can produce panoramic with hugin of the RGB but not of the 32 bit tiff.

If I extract both RGB and 32 bit tiff, then I create my panorama from the RGB pictures and save the project file.

Would I be able to use all the settings (and control points, basically everything) used before and apply them to my 32 bit tiff that hugin see totally blank?

I tried quickly with nona but it crashed.

To summary could hugin or another tool could apply the settings from a working panoramic creation into empty tiff (they off course have the exact same extent).

Is that crazy or that could work?

To my knowledge, Hugin and its included tools only work with TIFF images that:

* use 16 bits per colour channel or less [no 32bpc TIFF, no floating point TIFF],

* are RGB or RGBA [no CMYK support],

* use only a single image layer [no multi-layers TIFF support],

* and must be <4GB in file size [a limitation of base-standard TIFF]

What are you using that creates 32-bit [I assume that's per colour channel] output?  HDR images from something?  

Is there a practical reason to maintain that bit depth as far in your processing chain as Hugin?  Chances are, even if you're going to be post-processing the images after stitching, 16 bits per channel will be sufficient.

My suggestion [which is probably your only option with Hugin, Nona, etc.]: reduce the bit depth of the images to 16bpc or less and use those with Hugin.  If you require >16 bit per channel image support, you may need to find other tools to use.

Cheers,

D

[alouest]

Thanks for your answer

I use FLIR thermal imagery, my TIFF are extracted from a video sequence recorded by plane by this thermal camera.

So basically my Tiff is displaying floating values such as temperature in one band.

I might be able to create a 16 bit rgb tiff and store the temperature in one of the band, the problem is that for the moment hugin doesn't accept it (it crashes).

I don't really know what is the kind of 16 bit tiff structure that hugin is expecting

Thanks

[Gnome Nomad]

On 11/09/2012 01:52 AM, dex Otaku wrote:
> Salut alouest,
>
> On Thursday, 8 November 2012 14:01:32 UTC-6, alouest wrote:
>
> 'm using a sotware which can export RGB tiff and 32 bit tiff. I can
> produce panoramic with hugin of the RGB but not of the 32 bit tiff.
> If I extract both RGB and 32 bit tiff, then I create my panorama
> from the RGB pictures and save the project file.
> Would I be able to use all the settings (and control points,
> basically everything) used before and apply them to my 32 bit tiff
> that hugin see totally blank?
> I tried quickly with nona but it crashed.
>
> To summary could hugin or another tool could apply the settings from
> a working panoramic creation into empty tiff (they off course have
> the exact same extent).
>
> Is that crazy or that could work?
>
>
> To my knowledge, Hugin and its included tools only work with TIFF images
> that:
> * use 16 bits per colour channel or less [no 32bpc TIFF, no floating
> point TIFF],
> * are RGB or RGBA [no CMYK support],
> * use only a single image layer [no multi-layers TIFF support],
> * and must be <4GB in file size [a limitation of base-standard TIFF]

Yes. I understand there's an effort to come up with a TIFF standard that
allows larger sizes.

> What are you using that creates 32-bit [I assume that's per colour
> channel] output? HDR images from something?

I don't know what the original poster means by it. Windows claims a
32-bit image format, but I think it's actually 8-bit RGB with 8-bit
alpha-transparency.

> Is there a practical reason to maintain that bit depth as far in your
> processing chain as Hugin? Chances are, even if you're going to be
> post-processing the images after stitching, 16 bits per channel will be
> sufficient.

I get better color when I stitch using 48-bit TIF (16-bit per channel).
I convert them from my camera's 48-bit RAW files. 48-bit is minimal HDR,
because 16-bits per channel gives a greater color gamut than can be
displayed or printed with existing technology.

> My suggestion [which is probably your only option with Hugin, Nona,
> etc.]: reduce the bit depth of the images to 16bpc or less and use those
> with Hugin. If you require >16 bit per channel image support, you may
> need to find other tools to use.

I know of one Hugin tool that doesn't work with 16-bit per channel
images: linefind. Unless that's been fixed in the new release?

> Cheers,
> D

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[JohnPW]

So GN,

(Sorry, I'm not sure I follow) You are using 48b tiffs as source images for Hugin to stitch panoramas?

What are the specs for acceptable input and output files for Hugin?

I just spent 40 minutes trying to find some kind of Hugin tech spec list and have now given up.( I do understand Hugin uses  chain of underlying programs.)

Just curious,

John

[Gnome Nomad]

Yes. My DSLR shoots 48-bit RAW files. I convert them to 16-bit TIFF
using RawTherapee. Hugin reads the resulting TIFFs just fine.

TIFF is an interesting format, because it's designed to be very
flexible. Everything from 2-bit (true B&W) on up. A very large selection
of compression algorithms (including JPG, IIRC). Layers. 256-bit alpha
transparency. All capabilities that I think predate this thing called
the Internet ...

Anyway, I have no idea what Hugin can read and write. Maybe developers
can clue us in?

[JohnPW]

OK,

I've done that as well with great results

I asked because I got the idea you were using unconverted 48 bit files.

John

[Gnome Nomad]

I convert them from 48-bit RAW to 48-bit TIFF. The conversion process is
necessary because a RAW file contains the actual data from the CCD. Each
"pixel" on a CCD actually consists of 3 separate cells, one cell for
each color. I think they're usually arranged in a triangular or
something similar pattern. But they're both 48-bit color formats.

I think the most effective noise reduction is done when working with the
RAW format, because the software can use the position information
provided for each individual color cell as part of figuring out what's
noise or not?