RAW support with hugin ?

[Albert Szostkiewicz]

I saw similar topic from 4 years ago without any conclusion. Is where a reason why Hugin is not supporting RAW formats? Any plans for near future ?

[Luís Henrique Camargo Quiroz]

  Hi Albert,

  One point to consider, besides the existence of dedicated programs for dealing with RAW files, is: how shold Hugin "develop" the photos? Should it convert in a basic manner, without manipulating exposition, color balance, noise, for instance?

  It is better to leave all the possibilities of RAW file development to the specific programs for this purpose, so Hugin could concentrate on its goal: join different photos in order to compose a very good panorama!

  Don't you agree?

  regards,

  Luís Henrique

2018-07-03 4:03 GMT-03:00 Albert Szostkiewicz <tmd...@gmail.com>:

I saw similar topic from 4 years ago without any conclusion. Is where a reason why Hugin is not supporting RAW formats? Any plans for near future ?

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/93a8a4dd-732a-4040-801b-535b3aa33ddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[David W. Jones]

On July 4, 2018 3:09:00 AM HST, "Luís Henrique Camargo Quiroz" wrote:
> Hi Albert,
>
> One point to consider, besides the existence of dedicated programs for
>dealing with RAW files, is: how shold Hugin "develop" the photos?
>Should it
>convert in a basic manner, without manipulating exposition, color
>balance,
>noise, for instance?
> It is better to leave all the possibilities of RAW file development to
>the specific programs for this purpose, so Hugin could concentrate on
>its
>goal: join different photos in order to compose a very good panorama!
>
> Don't you agree?
>
> regards,
>
> Luís Henrique
>

>2018-07-03 4:03 GMT-03:00 Albert Szostkiewicz:
>
>> I saw similar topic from 4 years ago without any conclusion. Is where
>a
>> reason why Hugin is not supporting RAW formats? Any plans for near
>future ?

Hi, all!

I don't think adding support for RAW formats would do anything beneficial to Hugin.

My camera shoots 48-bit RAW files. I use Rawtherapee to convert them to 48-bit TIFF. There are thousands of settings combinations for conversion, even without touching what I consider "technical" settings like the different ways to demosaic an image. (RAW format isn't really an image format. It's a sensor-specific mosaic of values, not pixels, that have to be turned into pixel values.) Contrast, microcontrast, highlight/shadow recovery methods, noise reduction methods and settings, color balance, exposure curves, etc.

Lots of stuff. Even fairly "simple" RAW conversion tools like dcraw or ufraw do far more than I'd want to have wedged into Hugin.

Look into what Rawtherapee can do with RAW formats.

David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Jean-Luc Coulon (f5ibh)]

Hi,

Maybe a workaround (and which ease the process) would be to call rawtherapee (or any other raw converter – I use darktable), from inside Hugin. Something like the way Gimp opens raw files: you set a raw converter from the parameters, then when it detects a raw file, it opens it with the specified raw converter.

Jean-Luc

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/F5E7DDB8-1463-4813-8FB6-A2822201DAC9%40gmail.com.

[David W. Jones]

.

So when you add a bunch of RAW files to Hugin, it proceeds to popup a bunch of windows, one for each frame?

[Greg 'groggy' Lehey]

On Thursday, 5 July 2018 at 0:33:45 -1000, David W. Jones wrote:
>
> So when you add a bunch of RAW files to Hugin, it proceeds to popup
> a bunch of windows, one for each frame?

No. It displays a window "Could not decode (file name). Abort".

And I think that's correct.

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[David W. Jones]

On July 5, 2018 1:57:18 PM HST, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>On Thursday, 5 July 2018 at 0:33:45 -1000, David W. Jones wrote:
>>
>> So when you add a bunch of RAW files to Hugin, it proceeds to popup
>> a bunch of windows, one for each frame?
>
>No. It displays a window "Could not decode (file name). Abort".
>
>And I think that's correct.

I agree that's correct. I only mentioned it to point out how tedious and annoying it would be to have Hugin do that. I hate how Gimp does it, too. So my vote is to leave RAW processing to programs designed to do that, and use Hugin for what it does that they don't.

Not every program needs to do everything.

[bugbear]

David W. Jones wrote:
> On July 5, 2018 1:57:18 PM HST, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>> On Thursday, 5 July 2018 at 0:33:45 -1000, David W. Jones wrote:
>>>
>>> So when you add a bunch of RAW files to Hugin, it proceeds to popup
>>> a bunch of windows, one for each frame?
>>
>> No. It displays a window "Could not decode (file name). Abort".
>>
>> And I think that's correct.
>
> I agree that's correct. I only mentioned it to point out how tedious and annoying it would be to have Hugin do that. I hate how Gimp does it, too. So my vote is to leave RAW processing to programs designed to do that, and use Hugin for what it does that they don't.
>
> Not every program needs to do everything.

Would there be any merit in supporting some kind of "meta" extension, so that an external
program would be invoked to perform the conversion? All the complexity could be hidden
inside the script at the user's discretion.

BugBear

[David W. Jones]

On July 5, 2018 9:58:15 PM HST, bugbear wrote:
>David W. Jones wrote:

>> On July 5, 2018 1:57:18 PM HST, Greg 'groggy' Lehey wrote:
>>> On Thursday, 5 July 2018 at 0:33:45 -1000, David W. Jones wrote:
>>>>
>>>> So when you add a bunch of RAW files to Hugin, it proceeds to popup
>>>> a bunch of windows, one for each frame?
>>>
>>> No. It displays a window "Could not decode (file name). Abort".
>>>
>>> And I think that's correct.
>>
>> I agree that's correct. I only mentioned it to point out how tedious
>and annoying it would be to have Hugin do that. I hate how Gimp does
>it, too. So my vote is to leave RAW processing to programs designed to
>do that, and use Hugin for what it does that they don't.
>>
>> Not every program needs to do everything.
>
>Would there be any merit in supporting some kind of "meta" extension,
>so that an external
>program would be invoked to perform the conversion? All the complexity
>could be hidden
>inside the script at the user's discretion.

Hugin already supports some kind of external scripting, doesn't it? Python or something?

I'd still hate to have a barrage of prompts or interactive converter windows pop up. I'll still do my RAW processing separately.

[Gunter Königsmann]

Can rawtherapee Open multiple files in multiple tabs? Or can we talk the project team into adding that feature?

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/78B7AA0A-0DCC-4FC2-830D-65CEA3E24326%40gmail.com.

[David W. Jones]

On July 6, 2018 2:21:08 AM HST, "Gunter Königsmann" wrote:
>Can rawtherapee Open multiple files in multiple tabs? Or can we talk
>the
>project team into adding that feature?
>

>David W. Jones schrieb am Fr., 6. Juli 2018,

That's what Rawtherapee does by default when you select and open files from its file browser. You still have to make your settings, though, and have it apply them to convert the RAW images. You can make settings to be defaults for particular image types but you still have to trigger the actual conversion.

Opening a lot of images like that at once can be slow.

dcraw/ufraw might have command line options that could tell them to convert using specific settings, I've not used either of them much because I prefer to tailor images individually.

[Marcel Brouillet]

All the answers to this post assumed the raw processing is done before the stitching (which would work on TIFF/JPG… files). I totally agree on the objections.

However, does it make sense to combine raw files into a raw output, that can further be processed in rawtherapy ?

Distortions, stitching, etc could presumably be done on raw data arrays in an equal manner as they would be done on pixels. Not ? In practice, there could be a prior-conversion into jpeg with fixed (low-relevant) processing parameters, just to get the stitching parameters (PTO) and previsualisation, but the stitcher would work on RAW files. Would absolute data values for one shot not have the same reference as for a different shot, and consequently merging files has no sense ? I understood that precisely RAW format leave the normalizing to the processor, recording brute sensor data, so merging RAW files seems to have sense to me.

My question is just theoretic and blunt curiosity. I'm not spending, nor asking anyone to spend time on this. It seems like a huge work to rewrite a stitcher, especially ending up writing one for as many different raw formats as exist (re-using rawtherapy file-opening library, presumably). Does it make sense at all ?

(Brings me to the question to start with : why do people want RAW support in Hugin ? because they find the workflow a pain ? or for technical and image quality reasons ?)

Regards,

Marcel.

[bugbear]

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

[Marcel Brouillet]

It shows my ignorance on what is in the raw format and what tasks the raw processor does. This being out of scope (not hugin related) let's not clutter this list, but I'd appreciate a recommended reading to understand what I'm missing, if you have a good one.

Thanks you either way.

[Vladimir Nadvornik]

Hi,

when I think about it...

It might be possible to convert the mosaic data to independent channels
with transparency:

source:

RGRGRG
GBGBGB
RGRGRG

to:

RTRTRT
TTTTTT
RTRTRT

TGTGTG
GTGTGT
TGTGTG

TTTTTT
TBTBTB
TTTTTT


I don't see any principal problem with processing such images with nona
and enblend.
And if you do stack of multiple images shifted by 1 pixel, the result
could even have higher resolution than input.

Vladimir

[T. Modes]

Am Montag, 9. Juli 2018 16:02:06 UTC+2 schrieb nadv...@suse.cz:

It might be possible to convert the mosaic data to independent channels
with transparency:

source:

RGRGRG
GBGBGB
RGRGRG

to:

RTRTRT
TTTTTT
RTRTRT

TGTGTG
GTGTGT
TGTGTG

TTTTTT
TBTBTB
TTTTTT


I don't see any principal problem with processing such images with nona
and enblend.

 

If you do it this way each color will get different interpolation for each color (because different alpha channels) and this will results in color seams.

The next problem is that after remapping the Bayer pattern is destroyed. With the destroyed Bayer pattern it because impossible (or at least very difficult) for the RAW converter to demosaic the data now to get the final image.

(An alternative approach would be to demosaic the image data, then remap the data and then mosaic the data again to get the RAW again. But then you will loose resolution. So this is a no go.)

[Gunter Königsmann]

Also how should we handle bad pixels?

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/32144df2-94e0-4041-81f4-5fcd2222339e%40googlegroups.com.

[David W. Jones]

Here's a start at Wikipedia:

https://en.m.wikipedia.org/wiki/Raw_image_format

[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 and proper exposure merge is being applied. With Hugin I am forced to use 3rd party apps for conversion into TIFF or other format witch adds one more step of possible mistake.

As much as I wish to stay with Linux (which is my main operating system) and Hougin Open software, currently I am forced to run PtGui via wine to do my job as expected. It streamlines simple work that has to be done without requirement of 3rd party software in the process.

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/9430BC44-34A8-47CF-89CF-10DF83596828%40gmail.com.

[Greg 'groggy' Lehey]

On Tuesday, 10 July 2018 at 8:10:08 -0700, Albert Szostkiewicz wrote:
> 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 and proper
> exposure merge is being applied.

You can be sure that PTGui is simply converting the raw images to some
RGB format, possibly TIFF. It sounds like you're not being left much
choice in the matter.

> With Hugin I am forced to use 3rd party apps for conversion into
> TIFF or other format witch adds one more step of possible mistake.

And more control. Others may correct me, but I'd be surprised if
PTGui is performing the raw conversion itself. Probably it's invoking
a different program.

> As much as I wish to stay with Linux (which is my main operating
> system) and Hougin Open software, currently I am forced to run PtGui
> via wine to do my job as expected.

Note that the Unix (and thus Linux) way is to have multiple programs,
each able to perform one function and perform it well. It looks like
you're looking for the opposite.

> It streamlines simple work that has to be done without requirement
> of 3rd party software in the process.

It still requires mouse pushing. If you're looking for automatic raw
conversions, you can do that too with UFRaw, which has a batch mode.
Read in your images, run ufraw-batch on them to produce TIFF output
files, and you're ready to go.

Just checked https://www.ptgui.com/features.html: yes, PTGui uses
dcraw to convert the images. That's the same program that's behind
UFRaw. The difference with Linux is that you have a choice of raw
conversion tools, and that's one of the main reasons for using raw
images in the first place.

[Erik Krause]

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 and proper exposure merge is
> being applied. With Hugin I am forced to use 3rd party apps for conversion
> into TIFF or other format witch adds one more step of possible mistake.

raw data is by no means image data, it's the raw reading from the sensor
and it's awful. PTGui uses dcraw for conversion, which does a very basic
job. Using dcraw you loose almost all benefits of shooting raw including
correction of chromatic aberration, moiré, white balance, dead or hot
pixels, highlight restoration or noise reduction. You might well get
better images using jpeg straight from the camera. You don't get the
full dynamic range either, since dcraw clips all channels to the lowest
channel (thus avoiding a tint in clipped highlights). It is far better
to use a decent and dedicated raw converter.

--
Erik Krause
http://www.erik-krause.de

[Andreas Hirczy]

Greg 'groggy' Lehey <groo...@gmail.com> writes:

> On Tuesday, 10 July 2018 at 8:10:08 -0700, Albert Szostkiewicz wrote:
>> It streamlines simple work that has to be done without requirement
>> of 3rd party software in the process.
>
> It still requires mouse pushing. If you're looking for automatic raw
> conversions, you can do that too with UFRaw, which has a batch mode.
> Read in your images, run ufraw-batch on them to produce TIFF output
> files, and you're ready to go.

I used to use this for conversion:
----------------------------------------------
#!/bin/sh
# see <http://hugin.sourceforge.net/docs/manual/16bit_workflow_with_hugin.html>
# see <http://hugin.sourceforge.net/docs/manual/HDR_workflow_with_hugin.html>

for i in *.cr2; do
BASENAME=${i%.cr2}
dcraw -v -w -4 ${BASENAME}.cr2
convert -gamma 2.2 ${BASENAME}.ppm ${BASENAME}.tif && rm ${BASENAME}.ppm
exiftool -tagsfromfile ${BASENAME}.cr2 -overwrite_original_in_place -exif:all ${BASENAME}.tif
done
----------------------------------------------

Best regards,
Andreas
--
Andreas Hirczy <a...@itp.tugraz.at> https://itp.tugraz.at/~ahi/
Graz University of Technology phone: +43/316/873- 8190
Institute of Theoretical and Computational Physics fax: +43/316/873-10 8190
Petersgasse 16, A-8010 Graz mobile: +43/664/859 23 57

[David W. Jones]

Well, I think dcraw actually is a dedicated raw converter (it doesn't do anything else) and certainly seems to offer a lot of command line options (including dead or hot pixels, noise reduction, highlight clipping/no clipping/blending/reconstruction, etc):

http://www.cybercom.net/~dcoffin/dcraw/dcraw.1.html

By the way, a blown highlight in a RAW file is a hard max value, not a color value outside the limits of a particular color space the way it would be in a image file.

Still, I prefer a more interactive and visual process. Color, sharpening, contrast/microcontrast, noise reduction - all very much determined by how the image looks. Rawtherapee lets me come up with (say) base settings for a panorma's component images and apply them en masse, then tweak each image as needed, then batch convert.

[bugbear]

Greg 'groggy' Lehey wrote:

>
> Note that the Unix (and thus Linux) way is to have multiple programs,
> each able to perform one function and perform it well. It looks like
> you're looking for the opposite.

Agreed - making a monolith is not the Unix way.

But allowing programs to work together in a convenient
and efficient manner is very much the Unix way (c.f. pipelines!!).

I would be interested to have Hugin able
to INVOKE a separate program, with command line arguments,
as an importer, in the same way that it already does for
both control point detection and blending.

Unix being Unix, the "external" program could in fact
be a wrapper script, calling an actual program
with an arbitrary command and/or list of control/parameter files.

BugBear

[Marcel Brouillet]

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 the need to separate the colors ? Can't the stitching be done on the array of Bayer data ? Care has to be taken that red values be distorted and only put in red positions in the resulting array, before mixed with other red values from other distorted arrays. But then the resulting array is a giant RAW array, a panoramic RAW, that needs to be de-mosaic'ed, white-balanced, noise-reduced, etc... The advantage (quite certainly not worth the development, but theoretical) being that you handle the RAW processing on the entire pano, afterwards.

In other words, programmatic care has to be taken that « The next problem is that after remapping the Bayer pattern is destroyed » be avoided.

I foresee a possible objection, that raw values only have sense in relative values within a single shot, and that two shots do not share the same numeric conversion origins (i.e. measurement offset, inconsistent calibration of the A-to-N converter). Is that so ?

[Robert Krawitz]

On Wed, 11 Jul 2018 14:15:19 +1000, Greg 'groggy' Lehey wrote:
> On Tuesday, 10 July 2018 at 8:10:08 -0700, Albert Szostkiewicz wrote:
>> As much as I wish to stay with Linux (which is my main operating
>> system) and Hougin Open software, currently I am forced to run PtGui
>> via wine to do my job as expected.
>
> Note that the Unix (and thus Linux) way is to have multiple programs,
> each able to perform one function and perform it well. It looks like
> you're looking for the opposite.

The "UNIX/Linux way" also allows for scripts and other ways to combine
separate tools into one from the user perspective. If I have a
complex pipeline of operations I want to perform I don't have to
remember them and run them all by hand; I can use a script to do that
for me. And indeed if I look in /usr/bin, about 25% of the programs
there are in fact scripts -- programs that hide the fact that they are
actually multiple programs being combined.

>> It streamlines simple work that has to be done without requirement
>> of 3rd party software in the process.
>
> It still requires mouse pushing. If you're looking for automatic raw
> conversions, you can do that too with UFRaw, which has a batch mode.
> Read in your images, run ufraw-batch on them to produce TIFF output
> files, and you're ready to go.

One less step, though. Other than the work required (which may be
non-trivial, balanced against the fact that the Hugin developers have
other things they want to do, not to mention lives outside of Hugin),
there's no reason Hugin couldn't do the same thing.

> Just checked https://www.ptgui.com/features.html: yes, PTGui uses
> dcraw to convert the images. That's the same program that's behind
> UFRaw. The difference with Linux is that you have a choice of raw
> conversion tools, and that's one of the main reasons for using raw
> images in the first place.

False dichotomy; there's nothing preventing someone from using a
separate tool to convert the RAWs into TIFFs or JPEGs and invoking
PTGui on those.
--
Robert Krawitz <r...@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Erik Krause]

Am 11.07.2018 um 11:09 schrieb David W. Jones:
> Well, I think dcraw actually is a dedicated raw converter (it doesn't
> do anything else) and certainly seems to offer a lot of command line
> options (including dead or hot pixels, noise reduction, highlight
> clipping/no clipping/blending/reconstruction, etc):

dcraw excels as a raw file decoder. The conversion part is mediocre at
best. Most universal raw converters use the file decoding code of dcraw
but only few (that are known for inferior results) use the raw
conversion part.

--
Erik Krause

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

[Vladimir Nadvornik]

Hi,

I think this is exactly the problem. RAW converter replaces bad pixels
(overexposures, hotpixels, etc.) with some "guessed" values. This is ok
for single image, but when you have multiple image of the same area,
then there is a chance that another image has "real" values.

Currently Hugin does not have information about these "guessed" values.
There are some workarounds like using thresholds, but the results are
not optimal. Having this information directly from (integrated) raw
converter would work better.

Vladimir

[Frederic Da Vitoria]

2018-07-11 18:19 UTC+02:00, Vladimir Nadvornik <nadv...@suse.cz>:

> --
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> ---
> You received this message because you are subscribed to the Google Groups
> "hugin and other free panoramic software" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hugin-ptx+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hugin-ptx/ffad8a2f-1d6e-ccb9-7815-0e65041873a8%40suse.cz.

> For more options, visit https://groups.google.com/d/optout.

Would this be worth it? How often do you reach a few dozens bad pixels
in an image? Let's say 100 pixels (this seems a lot, I'd buy a new
camera long before) on a 10 MPx image, which means 1 pixel out of
100000. And those wouldn't be completely wrong, if the camera did a
correct job of "fixing" them.

--
Frederic Da Vitoria
(davitof)

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

[Vladimir Nadvornik]

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 the need to separate the colors ? Can't the
> stitching be done on the array of Bayer data ?

I was thinking about something similar to "Bayer drizzle" algorithm
(soory, right now I can't find any good explanationon fof it, the
information on google is rather fragmented)

The input is bayer data, output is normal RGB image.

> Care has to be taken that
> red values be distorted and only put in red positions in the resulting
> array, before mixed with other red values from other distorted arrays. But
> then the resulting array is a giant RAW array, a panoramic RAW, that needs
> to be de-mosaic'ed, white-balanced, noise-reduced, etc... The advantage
> (quite certainly not worth the development, but theoretical) being that you
> handle the RAW processing on the entire pano, afterwards.
>

> In other words, programmatic care has to be taken that « *The next problem
> is that after remapping the Bayer pattern is destroyed* » be avoided.

>
> I foresee a possible objection, that raw values only have sense in relative
> values within a single shot, and that two shots do not share the same
> numeric conversion origins (i.e. measurement offset, inconsistent
> calibration of the A-to-N converter). Is that so ?
>

I see no advantage in saving output as Bayer data. For example
Rawtherapee handles tif files almost the same as raws.


Vladimir

[Greg 'groggy' Lehey]

On Wednesday, 11 July 2018 at 8:29:20 -0400, Robert Krawitz wrote:
> On Wed, 11 Jul 2018 14:15:19 +1000, Greg 'groggy' Lehey wrote:
>> On Tuesday, 10 July 2018 at 8:10:08 -0700, Albert Szostkiewicz wrote:
>>> As much as I wish to stay with Linux (which is my main operating
>>> system) and Hougin Open software, currently I am forced to run PtGui
>>> via wine to do my job as expected.
>>

>> Note that the Unix (and thus Linux) way is to have multiple programs,
>> each able to perform one function and perform it well. It looks like
>> you're looking for the opposite.
>

> The "UNIX/Linux way" also allows for scripts and other ways to combine
> separate tools into one from the user perspective.

Yes, of course.

> If I have a complex pipeline of operations I want to perform I don't
> have to remember them and run them all by hand; I can use a script
> to do that for me.

Yes, that's exactly what I do. And also make(1), of course.

>>> It streamlines simple work that has to be done without requirement
>>> of 3rd party software in the process.
>>
>> It still requires mouse pushing. If you're looking for automatic raw
>> conversions, you can do that too with UFRaw, which has a batch mode.
>> Read in your images, run ufraw-batch on them to produce TIFF output
>> files, and you're ready to go.
>
> One less step, though.

That depends. We're looking at a single step. I have a script that
reads in files from the camera, only actually transferring files that
aren't already there. It would be trivial to augment it to put it
through something like dcraw, if I thought that mindless conversion of
images made sense.

> Other than the work required (which may be non-trivial, balanced
> against the fact that the Hugin developers have other things they
> want to do, not to mention lives outside of Hugin), there's no
> reason Hugin couldn't do the same thing.

In fact, I'm working in exactly the opposite direction, writing
scripts that automate more and more of what Hugin does. But yes,
possibly the option of starting a raw converter of your choice might
make sense.

>> Just checked https://www.ptgui.com/features.html: yes, PTGui uses
>> dcraw to convert the images. That's the same program that's behind
>> UFRaw. The difference with Linux is that you have a choice of raw
>> conversion tools, and that's one of the main reasons for using raw
>> images in the first place.
>
> False dichotomy; there's nothing preventing someone from using a
> separate tool to convert the RAWs into TIFFs or JPEGs and invoking
> PTGui on those.

Of course not, but that misses the point: the original poster wanted
PTGui just for the raw conversion functionality. If he uses a
standalone program to do the conversion, then he can use Hugin and
doesn't need PTGui.

[Albert Szostkiewicz]

wow, I did not expect such big and aggressive response :)

I did not meant to offend hugin hardcore fans :)

I know that PTGui is using dcraw, and there is nothing wrong with it. It is also not true that dcraw will strip all dynamic range data. You can check its possibilities here (https://www.cybercom.net/~dcoffin/dcraw/)

All I am asking is why not give such ability to Hugin? I don't think that would strip anyone from control. It would just add simple yet handy feature to Hugin.

My point being: I needed simple software that gives me good result, fast for my own simple task: create HDR panorama from raw photos (for my personal purposes, not at work). I was checking few softwares on the market like gigapano, ptgui, hugin and few others. Without knowing neither of them, I wanted to give a try to each one of software ans see which one will give me best results.

I ended up being torn apart between ptgui and hugin. While Hugin is a free package, I was forced to deal with conversions, transferring exif infos, dealing with color spaces during conversion and stitching was giving me unwanted artifacts which I have tried to fix with different tools and settings but after few hours i gave up. Ptgui on other is not available on linux so I had to run it via wine and it payed software so two strikes on beginning. But I was able to throw at him my raw photos directly and i got expected result without touching a single setting, no artifacts, just worked with single button, got expected dynamic range.

Simplicity when needed. Ended with paying for PTGui license.

Stitching HDR panoramas should be really 1-2-3 click, simple task. There is no brainier here (from Artistic point of view). 

In a large company I work for, they ended up writing own software to stitch HDR panos automatically (as we use them for work purposes)

I am Linux user, and I work in quite complicated software on everyday basics but If we could simplify and make some steps easier - why not?

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/170638c5-34f5-ca21-b638-e84225acebb0%40suse.cz.

[Erik Krause]

Am 12.07.2018 um 08:46 schrieb Albert Szostkiewicz:
> I know that PTGui is using dcraw, and there is nothing wrong with it. It is
> also not true that dcraw will strip all dynamic range data. You can check
> its possibilities here (https://www.cybercom.net/~dcoffin/dcraw/)

PTGui uses only a fraction of that possibilities. I'd never shoot raw
only for PTGui's raw import. It's not worth the hassle at all.

[Albert Szostkiewicz]

> PTGui uses only a fraction of that possibilities. I'd never shoot raw 
> only for PTGui's raw import. It's not worth the hassle at all.

What is your suggested workflow then ?

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/6fabeae8-3e6f-303c-bc0f-b999faf2b43d%40gmx.de.

[Erik Krause]

Am 12.07.2018 um 15:57 schrieb Albert Szostkiewicz:
> What is your suggested workflow then ?

Use a decent raw converter and convert to 16 bit TIFF.

[Robert Krawitz]

On Thu, 12 Jul 2018 06:57:26 -0700, Albert Szostkiewicz wrote:
>> PTGui uses only a fraction of that possibilities. I'd never shoot raw
>> only for PTGui's raw import. It's not worth the hassle at all.
>
> What is your suggested workflow then ?

To be clear, you're using PTGui not merely to develop the raw images,
but also to stitch/fuse them, correct?

> On Thu, Jul 12, 2018 at 12:18 AM Erik Krause <erik....@gmx.de> wrote:
>
>> Am 12.07.2018 um 08:46 schrieb Albert Szostkiewicz:
>> > I know that PTGui is using dcraw, and there is nothing wrong with it. It
>> is
>> > also not true that dcraw will strip all dynamic range data. You can check
>> > its possibilities here (https://www.cybercom.net/~dcoffin/dcraw/)
>>
>> PTGui uses only a fraction of that possibilities. I'd never shoot raw
>> only for PTGui's raw import. It's not worth the hassle at all.

--

[T. Modes]

Am Donnerstag, 12. Juli 2018 08:45:47 UTC+2 schrieb Groogle:

> Other than the work required (which may be non-trivial, balanced
> against the fact that the Hugin developers have other things they
> want to do, not to mention lives outside of Hugin), there's no
> reason Hugin couldn't do the same thing.

In fact, I'm working in exactly the opposite direction, writing
scripts that automate more and more of what Hugin does.  But yes,
possibly the option of starting a raw converter of your choice might
make sense.

Or you could use PTBatcherGUI, which has already a lot of automatic functions.

[Albert Szostkiewicz]

> Use a decent raw converter and convert to 16 bit TIFF.

Could you elaborate please? what is your choice of converter that is giving you best result ?

"decent converter" is not a suggestion.

Thanks.

> To be clear, you're using PTGui not merely to develop the raw images, 
> but also to stitch/fuse them, correct? 

correct! currently yes. If I was just about to convert raw images I would choose something like DCRAW or UFRAW that i have tested in the past.

Maybe Erik could suggest something better that he is using.

Currently I am using PTGui to stitch my hdrs but I would love to switch to Hugin if I could get at least similar results.

Cheers!

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/329d0fb1-58e0-819c-47b7-02797d67e9a4%40gmx.de.

[Erik Krause]

Am 12.07.2018 um 17:05 schrieb Albert Szostkiewicz:
> Could you elaborate please? what is your choice of converter that is giving
> you best result ?
> "decent converter" is not a suggestion.

I use Adobe Camera Raw, since I happen to own a Photoshop CS6 license.
Lightroom uses the same raw conversion engine, BTW. Before that I used
the raw converter that came with my EOS 5D, Digital Photo Professional,
but never went back. ACR is so much better, especially if you use third
party lenses.

I tested RawTherapee some years ago. The results where just fine but
back then it was less reliable. This might have changed. Other people
swear on DxO and find it superior to ACR, but I never tried that.

As for my workflow: I batch convert with ACR to 16bit TIFF, then batch
merge and tonemap (in case of bracketed shots) with SNS-HDR lite, then
stitch.

[Albert Szostkiewicz]

Ah yes, thx for reply.

I was looking at that as well. Adobe is using its own DNG converter

https://helpx.adobe.com/photoshop/using/adobe-dng-converter.html

I heard good things about it, but too bad for me that its only win/osx again and it is yet again another layer of conversion. That is why i was looking at UFRAW and DCRAW instead. Not sure if you have any test examples but I was unable to find any meaninful differences where dcraw or ufraw would destroy any raw data.

[T. Modes]

Am Freitag, 6. Juli 2018 09:58:20 UTC+2 schrieb bugbear:

Would there be any merit in supporting some kind of "meta" extension, so that an external
program would be invoked to perform the conversion? All the complexity could be hidden
inside the script at the user's discretion.

Okay, after this discussion I added a RAW import function: It uses dcraw or RawTherapee (both needs to be installed separately) to convert the RAW images to TIF and adds them automatically to the open project file. Maybe it needs some fine-tuning concerning the command line switches of the RAW converter.

I did only some basic testing that it works. RAW images does not belong to my workflow, so I have no deep experience in the RAW conversion process. Maybe one of the RAW shooter can improve it.

[Eesger]

Op zaterdag 14 juli 2018 19:49:19 UTC+2 schreef T. Modes:

Okay, after this discussion I added a RAW import function: It uses dcraw or RawTherapee (both needs to be installed separately) to convert the RAW images to TIF and adds them automatically to the open project file. Maybe it needs some fine-tuning concerning the command line switches of the RAW converter.

I did only some basic testing that it works. RAW images does not belong to my workflow, so I have no deep experience in the RAW conversion process. Maybe one of the RAW shooter can improve it.

I read this reply with great interest! Could you write down a compact how-to? (difference between using a standard JPG and with RAW/DNG8 image and how to install)

AD:

I found https://www.dechifro.org/dcraw/ 
Just place the 'dcraw.c' file (mentioned in the link above) in the right spot somewhere?

[Terry Duell]

Hello Eesger,

On Fri, 20 Dec 2019 00:39:20 +1100, Eesger <ees...@gmail.com> wrote:


> AD:
> I found https://www.dechifro.org/dcraw/
> Just place the 'dcraw.c' file (mentioned in the link above) in the right
> spot somewhere?
>

dcraw.c won't help, it is the source code.
You will need the compiled version to be installed, or install RawTherapee.

Cheers,
--
Regards,
Terry Duell

[T. Modes]

Am Donnerstag, 19. Dezember 2019 21:31:47 UTC+1 schrieb Tduell:

dcraw.c won't help, it is the source code.
You will need the compiled version to be installed, or install RawTherapee.

For Windows the compiled version of dcraw is called dcraw.exe. This one you will need.

Alternatively you can also install RawTherapee or Darktable from the corresponding sites.