Bright pixels in dark areas of HDR Image
548 views
Skip to first unread message
ghnied...@t-online.de
Sep 4, 2013, 12:44:11 PM9/4/13
to pt...@googlegroups.com
For testing purposes I created an HDR image (not really a panorama) from 3 bracketed images taken with a full frame camera at an ISO setting of 1600 with 0 EV, +2 EV and -2 EV exposure variation. The result looks generally good, but there are bright individual pixels or small groups of adjacent pixels (up to 8 pixels) in the darker zones of the image. They are related to noise in the 0 EV and -2 EV images and can be suppressed by masking all underexposed zones in theses images. In the underexposed images the brighter pixels are only noticable when the overall brightness is drastically increased. Apparently PTGui includes pixels from underexposed parts of images slightly brighter than the (very dark) surroundings even when these parts are correctly exposed in an other image. Do I miss a control parameter which could reduce or suppress this effect? Is this an imperfection of the blending algorithm? Masking is cumbersome, there should be a better solution. Has anyone an idea?
Erik Krause
Sep 4, 2013, 1:50:51 PM9/4/13
to pt...@googlegroups.com
Am 04.09.2013 18:44, schrieb ghnied...@t-online.de:
> Apparently PTGui includes pixels from underexposed
> parts of images slightly brighter than the (very dark) surroundings even
> when these parts are correctly exposed in an other image. Do I miss a
> control parameter which could reduce or suppress this effect? Is this an
> imperfection of the blending algorithm? Masking is cumbersome, there should
> be a better solution. Has anyone an idea?
Only a wild Guess: Did you optimize the Camera response curve?
> Apparently PTGui includes pixels from underexposed
> parts of images slightly brighter than the (very dark) surroundings even
> when these parts are correctly exposed in an other image. Do I miss a
> control parameter which could reduce or suppress this effect? Is this an
> imperfection of the blending algorithm? Masking is cumbersome, there should
> be a better solution. Has anyone an idea?
If this doesn't help, could you make available the images? Please do not
add attachments to your posts; instead upload your files at a file
sharing site (for example http://ge.tt/ ) and include a link in your
message.
--
Erik Krause
http://www.erik-krause.de
PTGui Support
Sep 5, 2013, 3:53:51 AM9/5/13
to pt...@googlegroups.com
If there's siginficant noise present this can end up in the merged
image, but only if a pixels is underexposed in all brackets. Merging is
done pixel by pixel, PTGui doesn't look at surrounding pixels. Probably
the solution would be to add extra brackets with a longer exposure.
Noise reduction might also help of course. If you make your images
available I'd be happy to take a look.
Joost
> --
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui" group.
> To post to this group, send email to pt...@googlegroups.com
> To unsubscribe from this group, send email to
> ptgui+un...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
image, but only if a pixels is underexposed in all brackets. Merging is
done pixel by pixel, PTGui doesn't look at surrounding pixels. Probably
the solution would be to add extra brackets with a longer exposure.
Noise reduction might also help of course. If you make your images
available I'd be happy to take a look.
Joost
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui" group.
> To post to this group, send email to pt...@googlegroups.com
> To unsubscribe from this group, send email to
> ptgui+un...@googlegroups.com
> Please do not add attachments to your posts; instead upload your files
> at a file sharing site (for example http://ge.tt/ ) and include a link
> in your message.
> For more options, visit this group at http://groups.google.com/group/ptgui
> at a file sharing site (for example http://ge.tt/ ) and include a link
> in your message.
>
> ---
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
ghnied...@t-online.de
Sep 6, 2013, 10:46:47 AM9/6/13
to pt...@googlegroups.com
Initially I had not optimized the response curve. Now I have tried this. The result is slightly darker, but the bright pixels are at the same position with about the same brightness.
ghnied...@t-online.de
Sep 6, 2013, 12:18:39 PM9/6/13
to pt...@googlegroups.com
Thank you for the explanation how PTGui works.
My files are very large. The 3 original images were taken with a Sony Alpha 850 in RAW format, imported in Adobe Lightroom, corrected for lens errors and exported as 16 bit TIFF before they were loaded in PTGui. In order to reduce download times I make cropped images available at http://ge.tt/7pciHTr.
I don't think that the parts with bright pixels are underexposed in the image DSC03747. They certainly are in both other images.
You can see that I did not yet purchase PTGui. I first want to see what the software can do for me. Of course I prefer programs which make life as easy to me as possible. Noise reduction by lower ISO values would certainly be the best solution but require a tripod. To my opinion noise reduction by software should be done with the final image. My camera does not take more than 3 images in brackets with 2 EV difference. Therefore extra brackets would require changing the camera settings which would be very inconvenient with a large panorama.
Has nobody observed this effect before?
My files are very large. The 3 original images were taken with a Sony Alpha 850 in RAW format, imported in Adobe Lightroom, corrected for lens errors and exported as 16 bit TIFF before they were loaded in PTGui. In order to reduce download times I make cropped images available at http://ge.tt/7pciHTr.
I don't think that the parts with bright pixels are underexposed in the image DSC03747. They certainly are in both other images.
You can see that I did not yet purchase PTGui. I first want to see what the software can do for me. Of course I prefer programs which make life as easy to me as possible. Noise reduction by lower ISO values would certainly be the best solution but require a tripod. To my opinion noise reduction by software should be done with the final image. My camera does not take more than 3 images in brackets with 2 EV difference. Therefore extra brackets would require changing the camera settings which would be very inconvenient with a large panorama.
Has nobody observed this effect before?
Erik Krause
Sep 6, 2013, 2:45:29 PM9/6/13
to pt...@googlegroups.com
Am 06.09.2013 18:18, schrieb ghnied...@t-online.de:
> The 3 original images were taken with a Sony Alpha
> 850 in RAW format, imported in Adobe Lightroom, corrected for lens errors
> and exported as 16 bit TIFF before they were loaded in PTGui. In order to
> reduce download times I make cropped images available at
> http://ge.tt/7pciHTr.
Sorry, I can't find anything in the result image that isn't already in
> The 3 original images were taken with a Sony Alpha
> 850 in RAW format, imported in Adobe Lightroom, corrected for lens errors
> and exported as 16 bit TIFF before they were loaded in PTGui. In order to
> reduce download times I make cropped images available at
> http://ge.tt/7pciHTr.
the source images. The mostly red dots in your images are most likely
hot pixels. They are emphasized in the result by the merge to HDR
process. They are far less prominent if you use Exposure Fusion.
ghnied...@t-online.de
Sep 7, 2013, 5:59:47 AM9/7/13
to pt...@googlegroups.com
Hi Erik,
you are right, there is nothing in the output which is not already in the source images. The problem is, that PTGui copies information from underexposed parts of images into the output when the same parts exist properly exposed in another image. As I wrote above when I suppress this by masking underexposed parts of images the output is OK. But I don't want to do that manually, the software should do it for me. I think, when looking for the best one of 3 comparable pixels in the 3 source images the code takes the wrong one. There seems to be no knob which would allow me to change the criterion. It would certainly be the best if the algorithm would also take into account the sourrounding pixels. Exposure fusion might produce a less poor result, but all features of a software should work properly.
you are right, there is nothing in the output which is not already in the source images. The problem is, that PTGui copies information from underexposed parts of images into the output when the same parts exist properly exposed in another image. As I wrote above when I suppress this by masking underexposed parts of images the output is OK. But I don't want to do that manually, the software should do it for me. I think, when looking for the best one of 3 comparable pixels in the 3 source images the code takes the wrong one. There seems to be no knob which would allow me to change the criterion. It would certainly be the best if the algorithm would also take into account the sourrounding pixels. Exposure fusion might produce a less poor result, but all features of a software should work properly.
Erik Krause
Sep 7, 2013, 7:40:16 AM9/7/13
to pt...@googlegroups.com
Am 07.09.2013 11:59, schrieb ghnied...@t-online.de:
> you are right, there is nothing in the output which is not already in
> the source images. The problem is, that PTGui copies information
> from underexposed parts of images into the output when the same parts
> exist properly exposed in another image. As I wrote above when I
> suppress this by masking underexposed parts of images the output is
> OK. But I don't want to do that manually, the software should do it
> for me.
Then choose exposure fusion, it works that way.
> you are right, there is nothing in the output which is not already in
> the source images. The problem is, that PTGui copies information
> from underexposed parts of images into the output when the same parts
> exist properly exposed in another image. As I wrote above when I
> suppress this by masking underexposed parts of images the output is
> OK. But I don't want to do that manually, the software should do it
> for me.
> I think, when looking for the best one of 3 comparable pixels in the
> 3 source images the code takes the wrong one.
output, but the high dynamic range image in floating point space. In the
Source images only pixels below and above a certain value are discarded.
Any others are linearized (hence the importance of a response curve),
put in floating point space, exposure unified and averaged. Since the
hot pixels are equally bright in each image, the exposure correction
step brightens them.
Exposure fusion works like you expect: Only the best exposed pixels of
any image are used. This is done in multiple resolutions which are
blended again later in order to avoid hard edges.
> There seems to be no knob which would allow me to change the
> criterion. It would certainly be the best if the algorithm would also
> take into account the sourrounding pixels. Exposure fusion might
> produce a less poor result, but all features of a software should
> work properly.
be done in the raw conversion step, not in the HDR merge. There should
be several possibilities to do that, be it in camera, in software or
f.e. as dark frame subtraction afterwards.
ghnied...@t-online.de
Sep 7, 2013, 11:54:18 AM9/7/13
to pt...@googlegroups.com
Hi Erik,
Exposure Fusion does not show the annoying spots which appear in the HDR output - both in the HDR image and the tone mapped LDR image. But it does not produce HDR output. In some cases it might be better to do the tone mapping with a different program. At the moment I am not aiming at a nice picture but I am testing PTGui and I want to know how it deals with noisy input files. I like software which solves my problems and I do not like software which tells me that I myself should solve my problems. (I know, that this has limits. I am not expecting miracles.)
I do not agree with your opinion that the pixels are showing a problem of the sensor. I compared the lower right corner of a few dark images with high resolution. Brighter pixels are located at different positions and their density increases with the light intensity. Therefore I still believe that this is noise. But really this does not matter. I want to know, why they appear in the HDR output of PTGui. Their brightness is not high in the source images.
You say, in the HDR process pixels below and above a certain level are discarded. If these levels are chosen properly, only the best one is selected for each position - which I assumed to be the case. In PTGui the levels seem to be fixed, probably at values which are good for images with low noise level. Obviously they are not best with my images. I think that I could perhaps get rid of most spots if the levels could be adjusted by the user. And I do still believe that the result could even be better if the selection process would include the surroundings of each pixel which would finally be equivalent to the masking of dark parts which I did manually.
Helmut Niedermeyer
Exposure Fusion does not show the annoying spots which appear in the HDR output - both in the HDR image and the tone mapped LDR image. But it does not produce HDR output. In some cases it might be better to do the tone mapping with a different program. At the moment I am not aiming at a nice picture but I am testing PTGui and I want to know how it deals with noisy input files. I like software which solves my problems and I do not like software which tells me that I myself should solve my problems. (I know, that this has limits. I am not expecting miracles.)
I do not agree with your opinion that the pixels are showing a problem of the sensor. I compared the lower right corner of a few dark images with high resolution. Brighter pixels are located at different positions and their density increases with the light intensity. Therefore I still believe that this is noise. But really this does not matter. I want to know, why they appear in the HDR output of PTGui. Their brightness is not high in the source images.
You say, in the HDR process pixels below and above a certain level are discarded. If these levels are chosen properly, only the best one is selected for each position - which I assumed to be the case. In PTGui the levels seem to be fixed, probably at values which are good for images with low noise level. Obviously they are not best with my images. I think that I could perhaps get rid of most spots if the levels could be adjusted by the user. And I do still believe that the result could even be better if the selection process would include the surroundings of each pixel which would finally be equivalent to the masking of dark parts which I did manually.
Helmut Niedermeyer
Erik Krause
Sep 7, 2013, 12:52:26 PM9/7/13
to pt...@googlegroups.com
Am 07.09.2013 17:54, schrieb ghnied...@t-online.de:
> You say, in the HDR process pixels below and above a certain level are
> discarded. If these levels are chosen properly, only the best one is
> selected for each position - which I assumed to be the case. In PTGui the
> levels seem to be fixed, probably at values which are good for images with
> low noise level. Obviously they are not best with my images. I think that I
> could perhaps get rid of most spots if the levels could be adjusted by the
> user. And I do still believe that the result could even be better if the
> selection process would include the surroundings of each pixel which would
> finally be equivalent to the masking of dark parts which I did manually.
The only HDR program I know of, where it might be possible to do that
> You say, in the HDR process pixels below and above a certain level are
> discarded. If these levels are chosen properly, only the best one is
> selected for each position - which I assumed to be the case. In PTGui the
> levels seem to be fixed, probably at values which are good for images with
> low noise level. Obviously they are not best with my images. I think that I
> could perhaps get rid of most spots if the levels could be adjusted by the
> user. And I do still believe that the result could even be better if the
> selection process would include the surroundings of each pixel which would
> finally be equivalent to the masking of dark parts which I did manually.
are the FDR tools: http://www.fdrtools.com/front_e.php
I took your sample images to photomatix with even worse result using the
HDR process (photomatix has an exposure fusion process as well). SNS-HDR
processed them slightly better, but this one is exposure fusion based,
too (but it might give you these HDR look you apparently desire). I
personally process most of my bracketed images through SNS-HDR before
stitching.
The problem with your images is that there is no well exposed data for
the darker regions. Hence the programs brighten those regions and
emphasize the noise. Those pixels I mistook for hot pixels since they
don't follow the usual gaussian distribution of noisy pixels are far
brighter than the darker regions of the image. If you cut them you cut
significant amount of image information, especially since the lightest
image of your series is still underexposed. Expose properly, do a wider
bracketing, and those defects won't be over-emphasized. There are
solutions to do this, even for your camera:
http://wiki.panotools.org/Extended_bracketing_control
In an older post you write:
> To my opinion noise reduction by software should be done with the final image.
image data. After this the noise is already spread to originally
unaffected pixels due to bayer interpolation. This worsens once you do
HDR merging (as you currently experience) and it gets catastrophic after
panorama stitching, since noise patterns get warped and hence
non-uniform and virtually un-detectable. The noise reduction in ACR (or
Lightroom, which is the same engine) is very good, so why not use it?
PTGui is a panorama stitcher with some additional capabilities. It is a
very good panorama stitcher and HDR merging, RAW import etc. are
goodies, but not the core functionality. In case of HDR merging it's
even on the better side. But to repair defective images you need
different software.
PTGui Support
Sep 7, 2013, 4:16:40 PM9/7/13
to pt...@googlegroups.com
Hi Helmut,
The threshold from which PTGui starts taking pixels into account is set
at 30/255 if I remember correctly. A weighted average is done with the
other brackets, so a 'noise' pixel of brightness 31 will only get a low
priority, but if your best exposed pixel only has a brightness of 40
then the relative weight of the noise pixel in the merged result will
still be high, and it gets amplified by the EV+4 exposure offset. That's
what you are seeing here. If you look at the result you'll see red spots
only in the dark areas for which there is no good exposure information
(like the back of the chair). Adding longer exposures will improve the
result.
Making the noise threshold configurable might indeed much improve the
result in this case, but to be honest this is the first time I'm seeing
anyone seriously attempting to make an HDR from such noisy images
without properly exposed shadows. But I'll add this to the wish list.
Looking at surrounding pixels might seem an obvious improvement but this
would create new problems in high contrast areas (such as specular
highlights).
Of course there's always room for improvement; for now let's just
conclude that PTGui doesn't meet your expectations.
Kind regards,
New House Internet Services BV
Joost Nieuwenhuijse
-----------------------------------------------
PTGui - Photo Stitching Software
www.ptgui.com
For support see: http://www.ptgui.com/faq/
-----------------------------------------------
The threshold from which PTGui starts taking pixels into account is set
at 30/255 if I remember correctly. A weighted average is done with the
other brackets, so a 'noise' pixel of brightness 31 will only get a low
priority, but if your best exposed pixel only has a brightness of 40
then the relative weight of the noise pixel in the merged result will
still be high, and it gets amplified by the EV+4 exposure offset. That's
what you are seeing here. If you look at the result you'll see red spots
only in the dark areas for which there is no good exposure information
(like the back of the chair). Adding longer exposures will improve the
result.
Making the noise threshold configurable might indeed much improve the
result in this case, but to be honest this is the first time I'm seeing
anyone seriously attempting to make an HDR from such noisy images
without properly exposed shadows. But I'll add this to the wish list.
Looking at surrounding pixels might seem an obvious improvement but this
would create new problems in high contrast areas (such as specular
highlights).
Of course there's always room for improvement; for now let's just
conclude that PTGui doesn't meet your expectations.
Kind regards,
New House Internet Services BV
Joost Nieuwenhuijse
-----------------------------------------------
PTGui - Photo Stitching Software
www.ptgui.com
For support see: http://www.ptgui.com/faq/
-----------------------------------------------
ghnied...@t-online.de
Sep 8, 2013, 7:59:23 AM9/8/13
to pt...@googlegroups.com
Hi Erik,
thank you very much for your comments and your patience! I agree that I have to take the best images I can even if I use the best software available. PTGui is probably the best choice for me.
I do not completely agree with your opinion on software noise reduction. From the technical point of view you are certainly right. But because noise reduction is never a gain of information but always a loss, one has to find the best compromise between noise and details. However this is a question of taste and depends on the overall impression of the final image. I think one could reduce the noise of the source images to a moderate degree, then do the HDR process and then reduce the noise further if it seems necessary. If it seems, that the noise has been reduced too much in the source images, one would have to repeat the HDR process. Just for fun I will try it this way.
Best regards
Helmut Niedermeyer
thank you very much for your comments and your patience! I agree that I have to take the best images I can even if I use the best software available. PTGui is probably the best choice for me.
I do not completely agree with your opinion on software noise reduction. From the technical point of view you are certainly right. But because noise reduction is never a gain of information but always a loss, one has to find the best compromise between noise and details. However this is a question of taste and depends on the overall impression of the final image. I think one could reduce the noise of the source images to a moderate degree, then do the HDR process and then reduce the noise further if it seems necessary. If it seems, that the noise has been reduced too much in the source images, one would have to repeat the HDR process. Just for fun I will try it this way.
Best regards
Helmut Niedermeyer
ghnied...@t-online.de
Sep 8, 2013, 8:10:59 AM9/8/13
to pt...@googlegroups.com
Hi Joost,
my problem seems to be that, not being a professional, I want to get a professional result without professional effort. Most people probably do not want a perfect result or are willing to carry heavy equipment and spend much time. But I am sure that professionals do not always take perfect images home and are greatful if their software cures the faults. I think that I do now understand the problem and will find a way to live with it. Therefore I would not say that PTGui does not meet my expectations. I will probably purchase it and hope that it will further improve in the future.
Many thanks
Helmut Niedermeyer
my problem seems to be that, not being a professional, I want to get a professional result without professional effort. Most people probably do not want a perfect result or are willing to carry heavy equipment and spend much time. But I am sure that professionals do not always take perfect images home and are greatful if their software cures the faults. I think that I do now understand the problem and will find a way to live with it. Therefore I would not say that PTGui does not meet my expectations. I will probably purchase it and hope that it will further improve in the future.
Many thanks
Helmut Niedermeyer
Erik Krause
Sep 8, 2013, 10:47:39 AM9/8/13
to pt...@googlegroups.com
Am 08.09.2013 13:59, schrieb ghnied...@t-online.de:
>>From the technical point of view you are certainly right. But because noise
> reduction is never a gain of information but always a loss, one has to find
> the best compromise between noise and details.
My experience is that the noise reduction in ACR 7 or 8 / Lightroom 5 is
>>From the technical point of view you are certainly right. But because noise
> reduction is never a gain of information but always a loss, one has to find
> the best compromise between noise and details.
far superior to all noise reduction software which does it on the
converted images. Used cautiously I found no visible image degradation.
If you only remove the worst noise and leave some amount, you still can
use noise reduction more aggressively later on. Anyway it's better not
to remove all noise, since this causes banding in smooth gradients
(especially sky) in the jpeg compression step.
ghnied...@t-online.de
Sep 9, 2013, 10:11:05 AM9/9/13
to pt...@googlegroups.com
Hi Erik,
I thought of importing the HDR output of PTGui in 32 bit TIFF format into Lightroom (I have Lightroom 5) and doing the reduction of the intensity range and other polishing (also noise reduction) in Lightroom. Lightroom can import this format and do some operations on HDR images. I tried it with my test image and the result is - to my taste - better than the tone mapped output of PTGui, because I can decide, what should become brighter and what should become darker. A typical case of my image taking is a dark gorge with a bright sky. A few images of the Höllental-Klamm (near the Zugspitze, you might know it) caused me some frustration. First: a simple flat image does not reproduce the impression of being in a narrow gorge. I knew this and therefore I made a vertical panorama. At home it turned out that the sky was overexposed. Of course I could have known this before. In Lightroom one can improve the impression of overexposed parts slightly, but the result is still bad. If I had taken exposure brackets I could have recovered the sky. But the usual tone mapping algorithms do not only recover the sky, they reduce the dynamics of the whole image. In Lightroom I can mask the sky and reduce the lights in the masked area. I can even increase the contrast of the clouds. In this step I would also have worked on the noise, if necessary within masked areas. What do you think about this procedure?
Helmut Niedermeyer
I thought of importing the HDR output of PTGui in 32 bit TIFF format into Lightroom (I have Lightroom 5) and doing the reduction of the intensity range and other polishing (also noise reduction) in Lightroom. Lightroom can import this format and do some operations on HDR images. I tried it with my test image and the result is - to my taste - better than the tone mapped output of PTGui, because I can decide, what should become brighter and what should become darker. A typical case of my image taking is a dark gorge with a bright sky. A few images of the Höllental-Klamm (near the Zugspitze, you might know it) caused me some frustration. First: a simple flat image does not reproduce the impression of being in a narrow gorge. I knew this and therefore I made a vertical panorama. At home it turned out that the sky was overexposed. Of course I could have known this before. In Lightroom one can improve the impression of overexposed parts slightly, but the result is still bad. If I had taken exposure brackets I could have recovered the sky. But the usual tone mapping algorithms do not only recover the sky, they reduce the dynamics of the whole image. In Lightroom I can mask the sky and reduce the lights in the masked area. I can even increase the contrast of the clouds. In this step I would also have worked on the noise, if necessary within masked areas. What do you think about this procedure?
Helmut Niedermeyer
PTGui Support
Sep 10, 2013, 4:21:11 AM9/10/13
to pt...@googlegroups.com
I'm with Erik: noise reduction should be done before any other
processing. Noise reduction algorithms are designed to work with images
produced by camera sensors. Warping or merging to HDR modifies the noise.
But it should not be an issue anyway, as you probably would have taken
the photos at ISO 100 anyway.
And use a tripod when you start with HDR imaging. Handheld HDR is
possible but parallax may cause small misalignments between the brackets
which cannot be corrected.
Kind regards,
New House Internet Services BV
Joost Nieuwenhuijse
-----------------------------------------------
PTGui - Photo Stitching Software
www.ptgui.com
For support see: http://www.ptgui.com/faq/
-----------------------------------------------
processing. Noise reduction algorithms are designed to work with images
produced by camera sensors. Warping or merging to HDR modifies the noise.
But it should not be an issue anyway, as you probably would have taken
the photos at ISO 100 anyway.
And use a tripod when you start with HDR imaging. Handheld HDR is
possible but parallax may cause small misalignments between the brackets
which cannot be corrected.
Kind regards,
New House Internet Services BV
Joost Nieuwenhuijse
-----------------------------------------------
PTGui - Photo Stitching Software
www.ptgui.com
For support see: http://www.ptgui.com/faq/
-----------------------------------------------
On 09/09/2013 16:11, ghnied...@t-online.de wrote:
> Hi Erik,
>
> I thought of importing the HDR output of PTGui in 32 bit TIFF format
> into Lightroom (I have Lightroom 5) and doing the reduction of the
> intensity range and other polishing (also noise reduction) in Lightroom.
> Lightroom can import this format and do some operations on HDR images. I
> tried it with my test image and the result is - to my taste - better
> than the tone mapped output of PTGui, because I can decide, what should
> become brighter and what should become darker. A typical case of my
> image taking is a dark gorge with a bright sky. A few images of the
> H�llental-Klamm (near the Zugspitze, you might know it) caused me some
> Hi Erik,
>
> I thought of importing the HDR output of PTGui in 32 bit TIFF format
> into Lightroom (I have Lightroom 5) and doing the reduction of the
> intensity range and other polishing (also noise reduction) in Lightroom.
> Lightroom can import this format and do some operations on HDR images. I
> tried it with my test image and the result is - to my taste - better
> than the tone mapped output of PTGui, because I can decide, what should
> become brighter and what should become darker. A typical case of my
> image taking is a dark gorge with a bright sky. A few images of the
> frustration. First: a simple flat image does not reproduce the
> impression of being in a narrow gorge. I knew this and therefore I made
> a vertical panorama. At home it turned out that the sky was overexposed.
> Of course I could have known this before. In Lightroom one can improve
> the impression of overexposed parts slightly, but the result is still
> bad. If I had taken exposure brackets I could have recovered the sky.
> But the usual tone mapping algorithms do not only recover the sky, they
> reduce the dynamics of the whole image. In Lightroom I can mask the sky
> and reduce the lights in the masked area. I can even increase the
> contrast of the clouds. In this step I would also have worked on the
> noise, if necessary within masked areas. What do you think about this
> procedure?
>
> Helmut Niedermeyer
>
> Am Sonntag, 8. September 2013 16:47:39 UTC+2 schrieb Erik Krause:
>
> impression of being in a narrow gorge. I knew this and therefore I made
> a vertical panorama. At home it turned out that the sky was overexposed.
> Of course I could have known this before. In Lightroom one can improve
> the impression of overexposed parts slightly, but the result is still
> bad. If I had taken exposure brackets I could have recovered the sky.
> But the usual tone mapping algorithms do not only recover the sky, they
> reduce the dynamics of the whole image. In Lightroom I can mask the sky
> and reduce the lights in the masked area. I can even increase the
> contrast of the clouds. In this step I would also have worked on the
> noise, if necessary within masked areas. What do you think about this
> procedure?
>
> Helmut Niedermeyer
>
> Am Sonntag, 8. September 2013 16:47:39 UTC+2 schrieb Erik Krause:
>
> Am 08.09.2013 13:59, schrieb ghnied...@t-online.de <javascript:>:
> >>From the technical point of view you are certainly right. But
> because noise
> > reduction is never a gain of information but always a loss, one
> has to find
> > the best compromise between noise and details.
>
> My experience is that the noise reduction in ACR 7 or 8 / Lightroom
> 5 is
> far superior to all noise reduction software which does it on the
> converted images. Used cautiously I found no visible image degradation.
> If you only remove the worst noise and leave some amount, you still can
> use noise reduction more aggressively later on. Anyway it's better not
> to remove all noise, since this causes banding in smooth gradients
> (especially sky) in the jpeg compression step.
>
> --
> Erik Krause
> http://www.erik-krause.de
>
> >>From the technical point of view you are certainly right. But
> because noise
> > reduction is never a gain of information but always a loss, one
> has to find
> > the best compromise between noise and details.
>
> My experience is that the noise reduction in ACR 7 or 8 / Lightroom
> 5 is
> far superior to all noise reduction software which does it on the
> converted images. Used cautiously I found no visible image degradation.
> If you only remove the worst noise and leave some amount, you still can
> use noise reduction more aggressively later on. Anyway it's better not
> to remove all noise, since this causes banding in smooth gradients
> (especially sky) in the jpeg compression step.
>
> --
> Erik Krause
> http://www.erik-krause.de
>
Reply all
Reply to author
Forward
0 new messages