DNG support

[dmg]

I was wondering, and perhaps this might be a very stupid idea, but,
would it be possible to do some of the workflow directly on DNG files?


dmg



--
Daniel M. German "Give a man a password,
he'll log in for a day.
Teach him to code,
Anonymous -> and he will hack his way in..."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo dAngelo]

Hi Daniel,

Post by dmg
I was wondering, and perhaps this might be a very stupid idea, but,
would it be possible to do some of the workflow directly on DNG files?

Is there any reason to do so (maybe except for chromatic abberation and vignetting correction, which you probably do in photoshop anyway)?

IMHO it will only complicate matters. Think about the interpolation step during remapping for different bayer patterns or other speciality chips, and the required demosaicing algorithm that can demosaic the spatially non-uniform Bayer pattern after remapping. I don't know an demosaicing algorithm that would handle this situation.

This is a big can of worms that is best treated separately ;-)

Theoretically, in the remapped, overlapping areas contain some irregular bayer pattern with more than one measurement per pixel, which would provide more information to a demosaicing algorithm, but this requires EXACT subpixel registration across the whole overlap, which is very unrealistic, given the way we shoot and process panoramas.

ciao
Pablo
______________________________________________________________________________
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Roger Howard]

Post by Pablo dAngelo
Hi Daniel,

Post by dmg
I was wondering, and perhaps this might be a very stupid idea, but,
would it be possible to do some of the workflow directly on DNG files?

Is there any reason to do so (maybe except for chromatic abberation and
vignetting correction, which you probably do in photoshop anyway)?
IMHO it will only complicate matters. Think about the interpolation step
during remapping for different bayer patterns or other speciality chips,
and the required demosaicing algorithm that can demosaic the spatially
non-uniform Bayer pattern after remapping. I don't know an demosaicing
algorithm that would handle this situation.
This is a big can of worms that is best treated separately ;-)
Theoretically, in the remapped, overlapping areas contain some irregular
bayer pattern with more than one measurement per pixel, which would
provide more information to a demosaicing algorithm, but this requires
EXACT subpixel registration across the whole overlap, which is very
unrealistic, given the way we shoot and process panoramas.

This assumes the major benefit of working in raw has anything to do with
demosaicing; it certainly doesn't for me. See below.

I've mentioned before on the NG list, and perhaps elsewhere - I can't see
supporting fully raw DNG files (as the discussion above seems to assume),
as we typically see from a simple repackaging of the camera raw files into
DNG containers. The issue with demosaicing alone would make this
effectively impossible (at least while preserving the Bayer pattern data).

However, there is another flavor of DNG, "linear" DNG, which would seem to
be quite practical, as this is post-demosaiced RGB data. This way we could
provide linear DNG to a stitcher, and then only after stitching would we
do the tonal/color corrections in the RAW processing. For me this would be
advantageous; I prefer doing color/tonal work *after* stitching anyway,
when I can take into account the entire panorama in my edits, rather than
before stitching where I have to match edits across multiple files , and
then do post-stitch correction.

Right now I simply try to get white balance correct and then process my
files at quite low contrast, then I stitch, and then go back and do final
color and tonal edits after stitching. By allowing a "raw" workflow (even
if demosaiced first by using linear DNG) I could stitch first, then do all
my color and tonal edits in one pass after stitching. Makes perfect sense
to me.

-Rh


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Hi all,

Post by Roger Howard

Post by Pablo dAngelo
Hi Daniel,

Post by dmg
I was wondering, and perhaps this might be a very stupid idea, but,
would it be possible to do some of the workflow directly on DNG files?

Is there any reason to do so (maybe except for chromatic abberation and
vignetting correction, which you probably do in photoshop anyway)?

This assumes the major benefit of working in raw has anything to do with
demosaicing; it certainly doesn't for me. See below.
However, there is another flavor of DNG, "linear" DNG, which would seem to
be quite practical, as this is post-demosaiced RGB data. This way we could
provide linear DNG to a stitcher, and then only after stitching would we
do the tonal/color corrections in the RAW processing.

Since then the DNG is probably just an ordinary tiff file with some more
meta information, there is not real theoretical advantage there.
The practical advantage is that RAW converters probably have more intuitive
tools for managing tonal/color corrections than photoshop, or other editors.

So the advantage of this workflow is actually to work around limitations is
raw converters, which cannot open normal linear 16 bit tif or png files, right?

Post by Roger Howard
Right now I simply try to get white balance correct and then process my
files at quite low contrast, then I stitch, and then go back and do final
color and tonal edits after stitching. By allowing a "raw" workflow (even
if demosaiced first by using linear DNG) I could stitch first, then do all
my color and tonal edits in one pass after stitching.

Actually, I believe most RAW converters apply the white balance before the
demosaicing, and just demosaicing the raw values with no white balance might
result in slightly different demosaicing, and might reduce quality slightly.
But I don't have hard facts for that, and probably depends on the converter
so it might not be true.

I guess a TIF to DNG converter is all that is needed to archive your goal,
which is to load the linear image into a RAW converter and tweak it there.

Then you could use the RAW converter to create linear 16 bit files, process
them with all available tools (hugin, panotools, enblend, smartblend etc.)
and convert the final result to a DNG file and load it into the "RAW
converter". Otherwise all programs in between will need to support DNG,
which probably isn't going to happen in the foreseeable future.

ciao
Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Roger Howard]

Post by Pablo d'Angelo
Since then the DNG is probably just an ordinary tiff file with some more
meta information, there is not real theoretical advantage there.
The practical advantage is that RAW converters probably have more intuitive
tools for managing tonal/color corrections than photoshop, or other editors.

Well I'm much more interesting in practical, versus theoretical,
advantages, so yes.

Post by Pablo d'Angelo
So the advantage of this workflow is actually to work around limitations is
raw converters, which cannot open normal linear 16 bit tif or png files, right?

Sure, if you want to make it sound like then our only challenge is to get
all our RAW converters to support a non-linear or linear TIFF based
workflow, and then to expect everyone to process our RAW files to linear
TIFF, then stitch, then reprocess again in a RAW converter. That's what
I'm hoping to avoid.

Post by Pablo d'Angelo

Post by Roger Howard
Right now I simply try to get white balance correct and then process my
files at quite low contrast, then I stitch, and then go back and do final
color and tonal edits after stitching. By allowing a "raw" workflow (even
if demosaiced first by using linear DNG) I could stitch first, then do all
my color and tonal edits in one pass after stitching.

Actually, I believe most RAW converters apply the white balance before the
demosaicing, and just demosaicing the raw values with no white balance might
result in slightly different demosaicing, and might reduce quality slightly.
But I don't have hard facts for that, and probably depends on the converter
so it might not be true.

Not in this case, no. With a "linear DNG" you still have linear (or rather
non-delinearized) color, without WB applied.

Post by Pablo d'Angelo
I guess a TIF to DNG converter is all that is needed to archive your goal,
which is to load the linear image into a RAW converter and tweak it there.

I disagree, because then I'll be replacing one step (RAW processing to
non-linear TIFF) with another (RAW processing to linear TIFF), not
improving or simplifying my workflow at all. As well, linear DNG is *not*
the same as a linearized TIFF.

I understand if you say no one wants to put in the effort; I know you guys
don't get paid for this, but I do disagree with your dismissal of the
concept.

Post by Pablo d'Angelo
Then you could use the RAW converter to create linear 16 bit files, process
them with all available tools (hugin, panotools, enblend, smartblend etc.)
and convert the final result to a DNG file and load it into the "RAW
converter". Otherwise all programs in between will need to support DNG,
which probably isn't going to happen in the foreseeable future.

So again, we're talking about level of effort, not whether it's a valid
concept. I only came into this thread to offer clarifications on what a
*valid* DNG stitching workflow would be, not to demand people make it for
me :)

I do think you should look into linear DNG for more information, as to
dismiss it as "just an ordinary tiff file with some more meta information"
is kind of an understatement. And furthermore, if it *was* that simple,
then I can't see why you'd be objecting to the level of effort involved,
as it would be trivial to support without requiring an extra step of
generating a linear TIFF.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

Post by Roger Howard

Post by Pablo d'Angelo
Since then the DNG is probably just an ordinary tiff file with some more
meta information, there is not real theoretical advantage there.
The practical advantage is that RAW converters probably have more intuitive
tools for managing tonal/color corrections than photoshop, or other editors.

Well I'm much more interesting in practical, versus theoretical,
advantages, so yes.

Post by Pablo d'Angelo
So the advantage of this workflow is actually to work around limitations is
raw converters, which cannot open normal linear 16 bit tif or png files, right?

Sure, if you want to make it sound like then our only challenge is to get
all our RAW converters to support a non-linear or linear TIFF based
workflow, and then to expect everyone to process our RAW files to linear
TIFF, then stitch, then reprocess again in a RAW converter. That's what
I'm hoping to avoid.

Basically yes, otherwise the challenge is to get all the other software
involved to work with DNG files.

Just for clarification, the workflow you propose is:

1. Raw conv to linear DNG
2. Stitching, editing to remove ghosts etc. save as linear DNG
(btw. does Photoshop support saving normal images as DNG files?)
3. open DNG file in RAW converter and modify colors.

Now, except for the the technical issue of saving image data in linear tiff
or linear DNG files, what is the difference for steps 2 and 3?

Post by Roger Howard

Post by Pablo d'Angelo
I guess a TIF to DNG converter is all that is needed to archive your goal,
which is to load the linear image into a RAW converter and tweak it there.

I disagree, because then I'll be replacing one step (RAW processing to
non-linear TIFF) with another (RAW processing to linear TIFF), not
improving or simplifying my workflow at all. As well, linear DNG is *not*
the same as a linearized TIFF.

But your goal was to edit the tonal range of a final pano within a raw
converter? Wouldn't be that the improvement for your workflow?
At the expense of doing one more file conversion (if the program to do so
was available?), which could probably be placed in a batch file.

Post by Roger Howard
I understand if you say no one wants to put in the effort; I know you guys
don't get paid for this, but I do disagree with your dismissal of the
concept.

This is one part of the reason. The other is that I still haven't understood
why DNG should be used as an normal image file format, and not as the
"digital negative", it is proclaimed by Adobe. In a way stitching can be
seen just as a way to glue two negatives together, but I believe it is a lot
more than that (think of HDR, or variable exposure panos).

Post by Roger Howard
I do think you should look into linear DNG for more information, as to
dismiss it as "just an ordinary tiff file with some more meta information"
is kind of an understatement.

Sorry for beeing ignorant without having read the DNG spec, I always thought
that it is a standard way to save the information stored in a propritary raw
file. Unfortunately I don't have the time to dig through the DNG spec right
now. What are the main differences between them, and an linear tiff with a
proper ICC profile?

Post by Roger Howard
And furthermore, if it *was* that simple,
then I can't see why you'd be objecting to the level of effort involved,
as it would be trivial to support without requiring an extra step of
generating a linear TIFF.

I guess it would not be too complex but requires a lot of work to do
everything correctly. I will happily accept patches for hugin to add linear
DNG import/export.

I hope this post doesn't sound to biased or from outer space, because I'm
really interested in a answer the question why or why not using DNG would be
a good idea. (If one exists at all;-)

ciao
Pablo

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD Smith]

Post by Pablo d'Angelo
Sorry for beeing ignorant without having read the DNG spec, I
always thought
that it is a standard way to save the information stored in a
propritary raw
file. Unfortunately I don't have the time to dig through the DNG spec right
now. What are the main differences between them, and an linear tiff with a
proper ICC profile?

Do DNG's contain raw un-Bayer-interpolated data, or demosaiced,
linear data, or optionally either? I would have presumed them to be
raw. I just took a quick look at the spec, and it seems the format
specifies "camera details" to allow any generic software to demosaic
the raw data themselves by using these "details" encoded in the file.

JD


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[r***@rogerroger.org]

Post by JD Smith

Post by Pablo d'Angelo
Sorry for beeing ignorant without having read the DNG spec, I
always thought
that it is a standard way to save the information stored in a
propritary raw
file. Unfortunately I don't have the time to dig through the DNG spec right
now. What are the main differences between them, and an linear tiff with a
proper ICC profile?

Do DNG's contain raw un-Bayer-interpolated data, or demosaiced,
linear data, or optionally either?

One or the other; most users prefer to use truly raw, un-demosaiced
image data, but there is also support for fully demosaiced linear
image data as well - though in fact it's a lot easier to support the
already de-mosaiced image data, obviously, since you don't have to
try to develop optimum interpolation for all the different styles of
mosaics.
-R


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD Smith]

Post by r***@rogerroger.org

Post by JD Smith

Post by Pablo d'Angelo
Sorry for beeing ignorant without having read the DNG spec, I always thought
that it is a standard way to save the information stored in a propritary raw
file. Unfortunately I don't have the time to dig through the DNG spec right
now. What are the main differences between them, and an linear tiff with a
proper ICC profile?

Do DNG's contain raw un-Bayer-interpolated data, or demosaiced,
linear data, or optionally either?

One or the other; most users prefer to use truly raw, un-demosaiced
image data, but there is also support for fully demosaiced linear
image data as well - though in fact it's a lot easier to support
the already de-mosaiced image data, obviously, since you don't have
to try to develop optimum interpolation for all the different
styles of mosaics.
-R

Aha, interesting, thanks. So in a pano workflow where the latter is
used (demosaiced, linear data), what advantage might DNGs offer over
16-bit linear TIFF data? I could imagine they might be more compact
on disk, saving only 12bits of linear data typically. Are there
other advantages? Since you need demosaiced data to operate on for
panoramic imaging operations, it seems only the linear demosaiced
flavor of DNG would be useful.

JD


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[r***@rogerroger.org]

Post by JD Smith

Post by r***@rogerroger.org

Post by JD Smith

Post by Pablo d'Angelo
Sorry for beeing ignorant without having read the DNG spec, I always thought
that it is a standard way to save the information stored in a propritary raw
file. Unfortunately I don't have the time to dig through the DNG spec right
now. What are the main differences between them, and an linear tiff with a
proper ICC profile?

Do DNG's contain raw un-Bayer-interpolated data, or demosaiced,
linear data, or optionally either?

One or the other; most users prefer to use truly raw, un-
demosaiced image data, but there is also support for fully
demosaiced linear image data as well - though in fact it's a lot
easier to support the already de-mosaiced image data, obviously,
since you don't have to try to develop optimum interpolation for
all the different styles of mosaics.
-R

Aha, interesting, thanks. So in a pano workflow where the latter
is used (demosaiced, linear data), what advantage might DNGs offer
over 16-bit linear TIFF data? I could imagine they might be more
compact on disk, saving only 12bits of linear data typically. Are
there other advantages? Since you need demosaiced data to operate
on for panoramic imaging operations, it seems only the linear
demosaiced flavor of DNG would be useful.

The advantage is RAW processing workflow - see previous messages in
this thread. I'd much prefer to apply tonal and color correction to
RAW data *after* stitching, where I can take into account the entire
panorama composition. I think those who question the utility (not
necessarily you JD, but in general) should ask why we ask for HDR
support in stitchers, and mightn't the arguments be similar here?

Today I apply WB and then process my RAW to non-linear, but very low-
contrast, 16bit TIFFs. Then I stitch. Then I bring the result into PS
for final contrast and color edits. As I would hope with some form of
DNG support, I would stitch DNG directly; then in one pass be able to
apply color and tone correction to the equirectangular.

Major benefit without any possible solution today? No, but it would
be a convenience, IMHO.

Finally, yes, I've acknowledged repeatedly that this support should
only focus on the linear, de-mosaiced DNG flavor, otherwise I'd be
asking for a huge investment in supporting demosaicing algorithms,
which are a moving target. No, just give us linear DNG support and
that'd be enough.

PS, no, storage savings for 12bit vs 16bit is no real benefit to me.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Daniel M. German]

rogerhoward twisted the bytes to say:

Roger> The advantage is RAW processing workflow - see previous messages in
Roger> this thread. I'd much prefer to apply tonal and color correction to
Roger> RAW data *after* stitching, where I can take into account the entire
Roger> panorama composition. I think those who question the utility (not
Roger> necessarily you JD, but in general) should ask why we ask for HDR
Roger> support in stitchers, and mightn't the arguments be similar here?

Roger> Today I apply WB and then process my RAW to non-linear, but very low-
Roger> contrast, 16bit TIFFs. Then I stitch. Then I bring the result into PS
Roger> for final contrast and color edits. As I would hope with some form of
Roger> DNG support, I would stitch DNG directly; then in one pass be able to
Roger> apply color and tone correction to the equirectangular.

Roger> Major benefit without any possible solution today? No, but it would
Roger> be a convenience, IMHO.

Roger> Finally, yes, I've acknowledged repeatedly that this support should
Roger> only focus on the linear, de-mosaiced DNG flavor, otherwise I'd be
Roger> asking for a huge investment in supporting demosaicing algorithms,
Roger> which are a moving target. No, just give us linear DNG support and
Roger> that'd be enough.

I think it is a good idea, but it will probably be problematic
nonetheless.

Should the output be a set of DNGs of the map image? Will that be
enough?

I think DNGs will need to be supported at all stages of the workflow,
including enblend.

dmg


Roger> PS, no, storage savings for 12bit vs 16bit is no real benefit to me.


--
Daniel M. German "Prose is intrinsically linear;
a good book carries the reader forward
The Economist -> on the crest of the words"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[JD Smith]

Post by Daniel M. German
I think it is a good idea, but it will probably be problematic
nonetheless.
Should the output be a set of DNGs of the map image? Will that be
enough?
I think DNGs will need to be supported at all stages of the workflow,
including enblend.

If storage size isn't an advantage, why not perform all operation in
linear TIFF, and then transcode the TIFF to a DNG at the end, before
using a RAW converter to fiddle the colors. From what I can tell, the
data would be exactly the same, and it wouldn't require any special
casing in any of the panorama tools.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Roger Howard]

Post by JD Smith
If storage size isn't an advantage, why not perform all operation in
linear TIFF, and then transcode the TIFF to a DNG at the end, before
using a RAW converter to fiddle the colors. From what I can tell, the
data would be exactly the same, and it wouldn't require any special
casing in any of the panorama tools.

Let's just say 25% storage savings isn't the kind of advantage I'd use to
justify asking for major new features.

Pardon my bluntness, but this is the kind of support that can really keep
users away. My response would be - if it's so easy then why not support it
directly and hide the dirty details from me (the user)? Or conversely, if
it's really not that interesting or not worth the effort in your calculus
I can take that.

Yeah, I can do this now, which is more or less what I'm doing. But that
does squat for other users, and isn't really thrilling for me to keep
hacking together ugly workflow kludges where more elegant support is
easily imagined.

If you guys don't see the value in supporting some flavor of raw image
data in the panoramic workflow I can handle that, just say so. I'll keep
doing what I'm doing. But I feel strongly that at some point one of the
panotools family will support "raw" workflow end to end; I can certainly
see the benefits to it (and am openly conceding the difficulties to be
fair, and also not demanding a thing since you guys are all doing more
than we can ask already!). Again, I didn't start this thread, just chimed
in with a compromise when a particular technical hurdle was mentioned. If
you don't want to put it on the roadmap that's fine.

Best -Rh


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Daniel M. German]

Roger> If you guys don't see the value in supporting some flavor of raw image
Roger> data in the panoramic workflow I can handle that, just say so. I'll keep

Roger,

I don't think it is an issue of not wanting to support it. I think it
is more an issue of "who has the time to program it". Would you
volunteer to write the support in nona or PTmender first? Then we can
start talking about its insertion in hugin.

Roger> doing what I'm doing. But I feel strongly that at some point
Roger> one of the panotools family will support "raw" workflow end to
Roger> end; I can certainly see the benefits to it (and am openly
Roger> conceding the difficulties to be fair, and also not demanding
Roger> a thing since you guys are all doing more than we can ask
Roger> already!). Again, I didn't start this thread, just chimed in
Roger> with a compromise when a particular technical hurdle was
Roger> mentioned. If you don't want to put it on the roadmap that's
Roger> fine.

Roger> Best -Rh


Roger>
--
Daniel M. German "To take photographs is to hold one's breath
when all faculties converge
in the face of fleeing reality.
It is at that moment that
mastering an image becomes a
Henri Cartier-Bresson -> great physical and intellectual joy."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Roger Howard]

Post by Daniel M. German
Roger> If you guys don't see the value in supporting some flavor of raw image
Roger> data in the panoramic workflow I can handle that, just say so. I'll keep
Roger,
I don't think it is an issue of not wanting to support it. I think it
is more an issue of "who has the time to program it". Would you
volunteer to write the support in nona or PTmender first? Then we can
start talking about its insertion in hugin.

I've repeatedly said I'm not demanding you guys do this; heck, it didn't
even start with me requesting it. I've just been trying to clarify what
would work (linear DNG) and why one might want to work this way. So again
coming back at me with "oh yeah, do you want to do it?" misses the point.
Once again, I fully appreciate your hard work on this project, and am not
demanding you implement DNG support, as I've said repeatedly throughout
this thread; I am simply describing 1) an approach, via linear DNG, that
handily avoids the demosaicing issues; and 2) why some users (including
myself) would love to see some form of raw-based stitching as preferable
to the current workflow (and I'm not speaking about Hugin here
specifically).

So again, if you don't have time, or don't this as value based on your
resources I'll fully understand that. That's a resource constraint issue I
can appreciate. If you're still not getting why someone would want this,
perhaps I can help clarify. But if you're response is to offer workarounds
(which are essentially what we all do already) or to suggest *I* should
develop it if I care so much, then I'm afraid we're getting nowhere! I'm
not here as a developer, plain and simple, but as an interested user. My
extremely limited contributions to this project will be restricted to just
what I'm offering here. I hope you can take some value from that. Or just
tell me to bug off, or that my suggestions make no sense, or you don't
like the color of my shoes...

-Rh


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Roger Howard]

I just want to apologize if I came off in any way as a demanding user. I
appreciate the work all of you have done. My interest in Hugin, and the
rest, is as an outsider, neither a developer or current user. There are
functional topics that grab my attention, such as RAW workflow, and I
hoped I could help clarify the two points I focused on - easy(er) methods
for supporting raw files, and the use cases for why this would even be
desirable. I didn't come in to make demands, or tell you what your
priorities are.

Good luck and keep up the great work,

Rh


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---