TIFF output is low contrast and soft

[rolkar]

This bug is found in release 0.54

http://www.dpreview.com/forums/post/56325395

[erikrk]

The default settings in ACR are +50 brightness and +25 contrast. LR probably does something similar. x3f_extract does no such enhancement. I wouldn't call this a bug. It's rather functioning as intended. Maybe a switch for contrast enhancement could be added.

On dom, 2015-08-16 at 12:12 -0700, Roland Karlsson wrote:

This bug is found in release 0.54

http://www.dpreview.com/forums/post/56325395

— Reply to this email directly or view it on GitHub.

[rolkar]

It does also look soft, i.e. unsharp. I am trying to evaluate if that is an illusion. Hmmmmm ... not sure about that.

[rolkar]

Tested to increase contrast and brightness in Photoshop. It was still too soft. But, it was perfectly possible to use smart sharpen to get the same result. Actually a bit better as the DNG file had a sharpening halo.

[erikrk]

ACR does sharpening by default too.

On dom, 2015-08-16 at 13:10 -0700, Roland Karlsson wrote:

Tested to increase contrast and brightness in Photoshop. It was still too soft. But, it was perfectly possible to use smart sharpen to get the same result. Actually a bit better as the DNG file had a sharpening halo.

— Reply to this email directly or view it on GitHub.

[rolkar]

On 2015-08-16 22:41, Erik Karlsson wrote:

ACR does sharpening by default too. This makes the 0 values for sharpness, contrast and brightness in SPP somewhat suspect.

[rolkar]

I think I know what is wrong. And, it is my fault.

I did change the setting for TIFF to sRGB, but I have not added any profile. So, the TIFF is probably read as it is linear. Then the bright parts are compressed. The image will then be very bright and also low contrast. Exactly what we see.

So, either we add a profile, or we code it linear. Linear sRGB is a quite exotic thing though :) Actually, I find no good references to any standardised linear RGB space. I saw some references to "Linear ISO RGB", but I could not find what it was. So ... I assume adding a profile is the only reasonable option.

That sharpening is necessary is another thing though. But, that is probably true. And that ACR applies sharpening is probably because Bayer CFA always needs sharpening.

[erikrk]

Really? Is there any software that by default reads TIFF files as linear? I think not. If that were the case, the result would be very bright.

I think it's simply that zero for sharpness, contrast and brightens in SPP isn't actually zero. All those three are above zero be default in ACR, and the result is relatively similar to that of SPP.

On mar, 2015-08-18 at 01:01 -0700, Roland Karlsson wrote:

I think I know what is wrong. And, it is my fault.

I did change the setting for TIFF to sRGB, but I have not added any profile. So, the TIFF is probably read as it is linear. Then the bright parts are compressed. The image will then be very bright and also low contrast. Exactly what we see.

So, either we add a profile, or we code it linear. Linear sRGB is a quite exotic thing though :) Actually, I find no good references to any standardised linear RGB space. I saw some references to "Linear ISO RGB", but I could not find what it was. So ... I assume adding a profile is the only reasonable option.

That sharpening is necessary is another thing though. But, that is probably true. And that ACR applies sharpening is probably because Bayer CFA always needs sharpening.

— Reply to this email directly or view it on GitHub.

[rolkar]

Really? Is there any software that by default reads TIFF files as linear? I think not. If that were the case, the result would be very bright.

You are right. Linear data is very dark. I know that from loading RAW data.

I think it's simply that zero for sharpness, contrast and brightens in SPP isn't actually zero. All those three are above zero be default in ACR, and the result is relatively similar to that of SPP.

OK - but this is very confusing.

Why is the RAW data so low contrast? Why is such strong contrast enhancement needed?

Are we doing something wrong when scaling the image before doing sRGB encoding?

[erikrk]

I don't think we're doing anything wrong. Since it's done by default in ACR, I assume that sharpening and contrast enhancement are normally done during raw processing. We're simply not doing that when we're generating TIFF output.

On mar, 2015-08-18 at 02:53 -0700, Roland Karlsson wrote:

Why is the RAW data so low contrast? Why is such strong contrast enhancement needed?

Are we doing something wrong when scaling the image before doing sRGB encoding?

[rolkar]

I don't think we're doing anything wrong. Since it's done by default in ACR, I assume that sharpening and contrast enhancement are normally done during raw processing. We're simply not doing that when we're generating TIFF output.

Ah! But I am thinking like this. Assume everything was linear (which it is not). Assume also that there is no fog in the picture and that the lens is clean. Then, what is caught on the sensor should be a linear copy of reality. Twice as bright should give twice as much "exposure" or twice as high numbers in the RAW data (at least after subtracting the black point).

So, if everything is linear from sensor to storage in computer, then no contrast enhancement would be necessary to maintain a reasonable contrast. The image would only be too dark or too bright, which can be fully fixed with the exposure control.

So, what is different here? It is the gamma coding! So, how can gamma coding make the image lower contrast? So that an increased contrast is needed?

My guess is that gamma coding is, in principle, broken, You can only gamma code the part of the image that fits into the final image. You cannot gamma encode the entire dynamic range of the image. That is meaningless, and cannot be correctly recovered when reading the file.

I am not sure that it is this that is the actual problem. But, it is quite obvious that it is a potential problem. What might happen is that a huge dynamic range, using the gamma encoding is, when unpacked, mapped to a much smaller dynamic range.

I have a hard time visualising what it means that a gamma encoded file is gamma encoded for a too large dynamic range. But, I can imagine that this kind of problems may arise.

Life would be much more easy if data were coded linear everywhere.

[erikrk]

The problem is that reality has a much greater dynamic range than a monitor or a print. When reality is comressed to the dynamic range of a monitor or a print, it thus looks very dull. Contrast enhancement is a way to create an illusion of high dynamic range by applying an S-curve that expands the midtones while compressing the shadows and the highlights.

Gamma encoding has nothing to do with this. It's just a way to store data. It's also 100% reversible apart from rounding errors.

On mar, 2015-08-18 at 03:31 -0700, Roland Karlsson wrote:

I don't think we're doing anything wrong. Since it's done by default in ACR, I assume that sharpening and contrast enhancement are normally done during raw processing. We're simply not doing that when we're generating TIFF output.

Ah! But I am thinking like this. Assume everything was linear (which it is not). Assume also that there is no fog in the picture and that the lens is clean. Then, what is caught on the sensor should be a linear copy of reality. Twice as bright should give twice as much "exposure" or twice as high numbers in the RAW data (at least after subtracting the black point).

So, if everything is linear from sensor to storage in computer, then no contrast enhancement would be necessary to maintain a reasonable contrast. The image would only be too dark or too bright, which can be fully fixed with the exposure control.

So, what is different here? It is the gamma coding! So, how can gamma coding make the image lower contrast? So that an increased contrast is needed?

My guess is that gamma coding is, in principle, broken, You can only gamma code the part of the image that fits into the final image. You cannot gamma encode the entire dynamic range of the image. That is meaningless, and cannot be correctly recovered when reading the file.

I am not sure that it is this that is the actual problem. But, it is quite obvious that it is a potential problem. What might happen is that a huge dynamic range, using the gamma encoding is, when unpacked, mapped to a much smaller dynamic range.

I have a hard time visualising what it means that a gamma encoded file is gamma encoded for a too large dynamic range. But, I can imagine that this kind of problems may arise.

Life would be much more easy if data were coded linear everywhere.

— Reply to this email directly or view it on GitHub.

[rolkar]

The problem is that reality has a much greater dynamic range than a monitor or a print. When reality is comressed to the dynamic range of a monitor or a print, it thus looks very dull. Contrast enhancement is a way to create an illusion of high dynamic range by applying an S-curve that expands the midtones while compressing the shadows and the highlights.

Gamma encoding has nothing to do with this. It's just a way to store data. It's also 100% reversible apart from rounding errors.

Actually, gamma encoding might be the problem.

Photoshop uses gamma encoding internally. The work space is sRGB or AdobeRGB.

And, Photoshop do not convert to linear before doing manipulations.

So - if the dynamic range before doing gamma coding was too large strange things may happen.

/Roland

[billt1970]

New Friends,

Not to jump in your technical discussion, but on one point I have some info that MAY be helpful.

Laurence taught me that in-camera X3F processing includes some sharpening adjustment. For everything up to the SD15, his first step in SPP is to put sharpening at -0.7; that, per Laurence, is actually ZERO sharpening adjustment. It is similar for the SD1/M, but not exactly the same, per Laurence. He taught me to go with -0.4 or -0.5 correction to ZERO for the SD1/M. I have no idea about the Quattro imager.

Hope that helps. If not, then feel free to ignore me!

Best Regards,

BT

From: Roland Karlsson [mailto:notifications@github.com] Sent: Tuesday, August 18, 2015 5:54 AM To: Kalpanika/x3f Subject: Re: [x3f] TIFF output is low contrast and soft (#74)

Really? Is there any software that by default reads TIFF files as linear? I think not. If that were the case, the result would be very bright.

You are right. Linear data is very dark. I know that from loading RAW data.

I think it's simply that zero for sharpness, contrast and brightens in SPP isn't actually zero. All those three are above zero be default in ACR, and the result is relatively similar to that of SPP.

OK - but this is very confusing.

Why is the RAW data so low contrast? Why is such strong contrast enhancement needed?

Are we doing something wrong when scaling the image before doing sRGB encoding?

— Reply to this email directly or view it on GitHub https://github.com/Kalpanika/x3f/issues/74#issuecomment-132149311 . https://github.com/notifications/beacon/ANElOKVshsQ0wwPqKZ3Vr5HrFghZIBOgks5oovgagaJpZM4Fsbke.gif

No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6125 / Virus Database: 4401/10457 - Release Date: 08/17/15

---

No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.6086 / Virus Database: 4401/10448 - Release Date: 08/16/15

[rolkar]

New Friends,

Not to jump in your technical discussion, but on one point I have some info that MAY be helpful.

Laurence taught me that in-camera X3F processing includes some sharpening adjustment. For everything up to the SD15, his first step in SPP is to put sharpening at -0.7; that, per Laurence, is actually ZERO sharpening adjustment. It is similar for the SD1/M, but not exactly the same, per Laurence. He taught me to go with -0.4 or -0.5 correction to ZERO for the SD1/M. I have no idea about the Quattro imager.

Hope that helps. If not, then feel free to ignore me!

Best Regards,

BT

Yes, that is correct. This value (-0.7 or whatever) has been discussed at DPReview a lot. And it is different for different cameras and SPP versions etc.

I am not sure that anyone REALLY knows what is zero sharpening, not even Laurence. All we know is that 0 is not zero.

I think we have sharpening under control though. We know that the image is softer than SPP shows.

It is the exposure and contrast settings that is a kind of mystery right now. It might have with gamma coding to do. Or not.

Anyhow, the TIFF data is by far to low contrast for some reason.

[erikrk]

Rescaling gamma encoded data should be harmless.

(ax)^g = a^g * x^g = bx^g

It always becomes a linear rescaling, just with a different factor.

On mar, 2015-08-18 at 06:35 -0700, Roland Karlsson wrote:

Actually, gamma encoding might be the problem.

Photoshop uses gamma encoding internally. The work space is sRGB or AdobeRGB.

And, Photoshop do not convert to linear before doing manipulations.

So - if the dynamic range before doing gamma coding was too large strange things may happen.

/Roland

[erikrk]

Maybe reality, linearly compressed to the dynamic range of a monitor, simply is that dull. Remember that film has an S-shaped response curve, so it has built-in contrast enhancement. Standard processing of data from digital cameras is probably adapted to coarsely emulate the properties of film.

On mar, 2015-08-18 at 06:35 -0700, Roland Karlsson wrote:

The problem is that reality has a much greater dynamic range than a monitor or a print. When reality is comressed to the dynamic range of a monitor or a print, it thus looks very dull. Contrast enhancement is a way to create an illusion of high dynamic range by applying an S-curve that expands the midtones while compressing the shadows and the highlights.

Gamma encoding has nothing to do with this. It's just a way to store data. It's also 100% reversible apart from rounding errors.

Actually, gamma encoding might be the problem.

Photoshop uses gamma encoding internally. The work space is sRGB or AdobeRGB.

And, Photoshop do not convert to linear before doing manipulations.

So - if the dynamic range before doing gamma coding was too large strange things may happen.

/Roland

— Reply to this email directly or view it on GitHub.