Editing raws in linear gamma 1.0

[Horshack]

Color management question. Considered the PC forum but the question may be more generic than to PS.

I want to edit raw images using a camera linear profile and in a color space that uses a gamma 1.0.

I believe I have it working but have a question about PS rendering.

I created a camera linear profile for my Z6 using the Adobe DNG Profile Editor. I removed the hue twists from that resulting profile using dcpTool.

I created a ProPhoto RGB Gamma 1.0 profile in PS via Edit -> Color Settings -> Working Spaces [RGB] (dropdown) -> Custom RGB, set Gamma 1.0, then saved via Working Spaces [RGB] (dropdown) -> Save RGB, restarted PS to see the new profiles.

Loaded a raw into ACR that's spot-metered to the middle gray WB target, selected my Z6 profile, then selected my custom ProPhotoRGB Gamma 1.0 as the encoding color space. When the image loads into PS the histogram is correct - it reflects both the linear camera profile and the absence of ProPhoto's 1/1.8 gamma tonal response curve applied to the image data. However, the rendition of the image in PS appears as if the image is being converted to 1/1.8 or 1/2.2, ie same tonal distribution as an sRGB 1/2.2. Here's an animated demonstration:

Raw image into ACR sRGB vs Linear Gamma 1.0 vs ... (Animation)

The animation has three slides:

1. ACR-loaded raw using linear camera profile with sRGB color space
2. ACR-loaded raw using linear camera profile with custom ProPhoto RGB w/1.0 gamma
3. Same as #2 but the image data reinterpreted as sRGB using Edit -> Assign Profile

#3 is how I expected PS to render the Gamma 1.0 image but I thought it would do so without having to assign the sRGB profile. As I said, it's as if PS is running the image data through a 1/2.2 conversion to display on the screen. Is this expected behavior, perhaps because my display is configured to use a 2.2 gamma system profile? But if that's the case, what prevents 2.2 gamma images from having the 2.2 gamma reapplied to them? The fact that the color-manged app knows the image is already encoded as 2.2 gamma?

 

[JimKasson]

Color management question. Considered the PC forum but the question may be more generic than to PS.

I want to edit raw images using a camera linear profile and in a color space that uses a gamma 1.0.

I believe I have it working but have a question about PS rendering.

I created a camera linear profile for my Z6 using the Adobe DNG Profile Editor. I removed the hue twists from that resulting profile using dcpTool.

I created a ProPhoto RGB Gamma 1.0 profile in PS via Edit -> Color Settings -> Working Spaces [RGB] (dropdown) -> Custom RGB, set Gamma 1.0, then saved via Working Spaces [RGB] (dropdown) -> Save RGB, restarted PS to see the new profiles.

Loaded a raw into ACR that's spot-metered to the middle gray WB target, selected my Z6 profile, then selected my custom ProPhotoRGB Gamma 1.0 as the encoding color space. When the image loads into PS the histogram is correct - it reflects both the linear camera profile and the absence of ProPhoto's 1/1.8 gamma tonal response curve applied to the image data. However, the rendition of the image in PS appears as if the image is being converted to 1/1.8 or 1/2.2, ie same tonal distribution as an sRGB 1/2.2. Here's an animated demonstration:

Raw image into ACR sRGB vs Linear Gamma 1.0 vs ... (Animation)

The animation has three slides:

1. ACR-loaded raw using linear camera profile with sRGB color space
2. ACR-loaded raw using linear camera profile with custom ProPhoto RGB w/1.0 gamma
3. Same as #2 but the image data reinterpreted as sRGB using Edit -> Assign Profile

#3 is how I expected PS to render the Gamma 1.0 image but I thought it would do so without having to assign the sRGB profile. As I said, it's as if PS is running the image data through a 1/2.2 conversion to display on the screen. Is this expected behavior, perhaps because my display is configured to use a 2.2 gamma system profile? But if that's the case, what prevents 2.2 gamma images from having the 2.2 gamma reapplied to them? The fact that the color-manged app knows the image is already encoded as 2.2 gamma?

I don't think I understand the issue. If all the colors in the image are within the gamut of the color spaces involved, Ps will display them as looking the same.

 

[Mark S Abeln]

The whole idea behind color management is that images look the same as physically possible despite the encoding and the display hardware.

I’ve used linear encoding before, and it is useful for precise color mixing. It’s also the best profile for downsampling images (but not upsampling!), and for sharpening, although for all these purposes I use 32 bit mode, which is linear.

--
http://therefractedlight.blogspot.com

 

[ggbutcher]

Color management question. Considered the PC forum but the question may be more generic than to PS.

I want to edit raw images using a camera linear profile and in a color space that uses a gamma 1.0.

I believe I have it working but have a question about PS rendering.

I created a camera linear profile for my Z6 using the Adobe DNG Profile Editor. I removed the hue twists from that resulting profile using dcpTool.

I created a ProPhoto RGB Gamma 1.0 profile in PS via Edit -> Color Settings -> Working Spaces [RGB] (dropdown) -> Custom RGB, set Gamma 1.0, then saved via Working Spaces [RGB] (dropdown) -> Save RGB, restarted PS to see the new profiles.

Loaded a raw into ACR that's spot-metered to the middle gray WB target, selected my Z6 profile, then selected my custom ProPhotoRGB Gamma 1.0 as the encoding color space. When the image loads into PS the histogram is correct - it reflects both the linear camera profile and the absence of ProPhoto's 1/1.8 gamma tonal response curve applied to the image data. However, the rendition of the image in PS appears as if the image is being converted to 1/1.8 or 1/2.2, ie same tonal distribution as an sRGB 1/2.2. Here's an animated demonstration:

Raw image into ACR sRGB vs Linear Gamma 1.0 vs ... (Animation)

The animation has three slides:

1. ACR-loaded raw using linear camera profile with sRGB color space
2. ACR-loaded raw using linear camera profile with custom ProPhoto RGB w/1.0 gamma
3. Same as #2 but the image data reinterpreted as sRGB using Edit -> Assign Profile

#3 is how I expected PS to render the Gamma 1.0 image but I thought it would do so without having to assign the sRGB profile. As I said, it's as if PS is running the image data through a 1/2.2 conversion to display on the screen. Is this expected behavior, perhaps because my display is configured to use a 2.2 gamma system profile? But if that's the case, what prevents 2.2 gamma images from having the 2.2 gamma reapplied to them? The fact that the color-manged app knows the image is already encoded as 2.2 gamma?

If you have a calibrated display profile in place, I think that would be where the "2.2" gamma would be introduced.

An exported image with an embedded profile should be in the color space and tone curve specified by the embedded profile. When another gomer loads that image into a color-managed viewer, that viewer will convert the image for display as follows:

JPEG profile -> linear XYZ -> display profile

That's how ICC transforms are done, through a colorspace designated as a "profile connection space", or intermediary between the source and destination profiles. The ICC profiles only know how to go back and forth with XYZ, which keeps them from having to know all the other profiles in existence. So, your 2.2 gamma JPEG will go to gamma 1.0 XYZ, then to gamma(whatever) display.

 

[Horshack]

Color management question. Considered the PC forum but the question may be more generic than to PS.

I want to edit raw images using a camera linear profile and in a color space that uses a gamma 1.0.

I believe I have it working but have a question about PS rendering.

I created a camera linear profile for my Z6 using the Adobe DNG Profile Editor. I removed the hue twists from that resulting profile using dcpTool.

I created a ProPhoto RGB Gamma 1.0 profile in PS via Edit -> Color Settings -> Working Spaces [RGB] (dropdown) -> Custom RGB, set Gamma 1.0, then saved via Working Spaces [RGB] (dropdown) -> Save RGB, restarted PS to see the new profiles.

Loaded a raw into ACR that's spot-metered to the middle gray WB target, selected my Z6 profile, then selected my custom ProPhotoRGB Gamma 1.0 as the encoding color space. When the image lmissing why that would be the case.oads into PS the histogram is correct - it reflects both the linear camera profile and the absence of ProPhoto's 1/1.8 gamma tonal response curve applied to the image data. However, the rendition of the image in PS appears as if the image is being converted to 1/1.8 or 1/2.2, ie same tonal distribution as an sRGB 1/2.2. Here's an animated demonstration:

Raw image into ACR sRGB vs Linear Gamma 1.0 vs ... (Animation)

The animation has three slides:

1. ACR-loaded raw using linear camera profile with sRGB color space
2. ACR-loaded raw using linear camera profile with custom ProPhoto RGB w/1.0 gamma
3. Same as #2 but the image data reinterpreted as sRGB using Edit -> Assign Profile

#3 is how I expected PS to render the Gamma 1.0 image but I thought it would do so without having to assign the sRGB profile. As I said, it's as if PS is running the image data through a 1/2.2 conversion to display on the screen. Is this expected behavior, perhaps because my display is configured to use a 2.2 gamma system profile? But if that's the case, what prevents 2.2 gamma images from having the 2.2 gamma reapplied to them? The fact that the color-manged app knows the image is already encoded as 2.2 gamma?

If you have a calibrated display profile in place, I think that would be where the "2.2" gamma would be introduced.

An exported image with an embedded profile should be in the color space and tone curve specified by the embedded profile. When another gomer loads that image into a color-managed viewer, that viewer will convert the image for display as follows:

JPEG profile -> linear XYZ -> display profile

That's how ICC transforms are done, through a colorspace designated as a "profile connection space", or intermediary between the source and destination profiles. The ICC profiles only know how to go back and forth with XYZ, which keeps them from having to know all the other profiles in existence. So, your 2.2 gamma JPEG will go to gamma 1.0 XYZ, then to gamma(whatever) display.

I was getting caught up in the fact the data in the working space is already gamma 1.0, not realizing that would just mean it should just bypass the gamma decoding step and go straight to converting to monitor gamma for display. What tripped me up is that the gamma 1.0 generated image data from ACR doesn't appear to be fully linear, which lead me to believe something else was at play with the display rendering. I still don't understand why the data isn't fully linear - it is for about 6 stops then isn't.

Here's a demonstration showing the RGB values as I adjust the ACR exposure slider by 1EV steps (slider should be linear):

Gamma 1.0 Histogram from -4EV to +5EV (Animation)

 

[ggbutcher]

Color management question. Considered the PC forum but the question may be more generic than to PS.

I want to edit raw images using a camera linear profile and in a color space that uses a gamma 1.0.

I believe I have it working but have a question about PS rendering.

I created a camera linear profile for my Z6 using the Adobe DNG Profile Editor. I removed the hue twists from that resulting profile using dcpTool.

I created a ProPhoto RGB Gamma 1.0 profile in PS via Edit -> Color Settings -> Working Spaces [RGB] (dropdown) -> Custom RGB, set Gamma 1.0, then saved via Working Spaces [RGB] (dropdown) -> Save RGB, restarted PS to see the new profiles.

Loaded a raw into ACR that's spot-metered to the middle gray WB target, selected my Z6 profile, then selected my custom ProPhotoRGB Gamma 1.0 as the encoding color space. When the image lmissing why that would be the case.oads into PS the histogram is correct - it reflects both the linear camera profile and the absence of ProPhoto's 1/1.8 gamma tonal response curve applied to the image data. However, the rendition of the image in PS appears as if the image is being converted to 1/1.8 or 1/2.2, ie same tonal distribution as an sRGB 1/2.2. Here's an animated demonstration:

Raw image into ACR sRGB vs Linear Gamma 1.0 vs ... (Animation)

The animation has three slides:

1. ACR-loaded raw using linear camera profile with sRGB color space
2. ACR-loaded raw using linear camera profile with custom ProPhoto RGB w/1.0 gamma
3. Same as #2 but the image data reinterpreted as sRGB using Edit -> Assign Profile

#3 is how I expected PS to render the Gamma 1.0 image but I thought it would do so without having to assign the sRGB profile. As I said, it's as if PS is running the image data through a 1/2.2 conversion to display on the screen. Is this expected behavior, perhaps because my display is configured to use a 2.2 gamma system profile? But if that's the case, what prevents 2.2 gamma images from having the 2.2 gamma reapplied to them? The fact that the color-manged app knows the image is already encoded as 2.2 gamma?

If you have a calibrated display profile in place, I think that would be where the "2.2" gamma would be introduced.

An exported image with an embedded profile should be in the color space and tone curve specified by the embedded profile. When another gomer loads that image into a color-managed viewer, that viewer will convert the image for display as follows:

JPEG profile -> linear XYZ -> display profile

That's how ICC transforms are done, through a colorspace designated as a "profile connection space", or intermediary between the source and destination profiles. The ICC profiles only know how to go back and forth with XYZ, which keeps them from having to know all the other profiles in existence. So, your 2.2 gamma JPEG will go to gamma 1.0 XYZ, then to gamma(whatever) display.

I was getting caught up in the fact the data in the working space is already gamma 1.0, not realizing that would just mean it should just bypass the gamma decoding step and go straight to converting to monitor gamma for display. What tripped me up is that the gamma 1.0 generated image data from ACR doesn't appear to be fully linear, which lead me to believe something else was at play with the display rendering. I still don't understand why the data isn't fully linear - it is for about 6 stops then isn't.

Here's a demonstration showing the RGB values as I adjust the ACR exposure slider by 1EV steps (slider should be linear):

Gamma 1.0 Histogram from -4EV to +5EV (Animation)

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

 

[Mark S Abeln]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

I'm pretty sure they do. You have to use Levels for linearity.

 

[ggbutcher]

Horshack, I have to date not recommended my hack raw processor, rawproc, to anyone, but I'm going to now for the following reason - it is hard to tease out behaviors in most of the other softwares. I wrote rawproc specifically for that reason, to be able to open a raw file and then stack the tools to process it one-by-one, seeing the incremental effect of each as I worked toward a pleasing rendition.

The most significant insight I've gained using rawproc is come from being able to regard the image at each step. In the early tools that's decidedly less-useful, but even looking at the display's attempt to render the raw measurements right after file-opening is telling in a broad-perspective sort of way. I've found the most useful step to look at is right after demosaic, before any tone curve is applied (well, sorta, the display pipe tries to transform whatever using the display profile, but that can be turned off).

Over time I've added various convenience things like a default toolchain, batch processing, etc., and with all that I use it exclusively for my photography. If you download it and have questions, you can ask here or at discuss.pixls.us.

https://github.com/butcherg/rawproc/releases/tag/1.3

 

[JimKasson]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

Lightroom 2012 Exposure control different from PS adjustment layer

Lightroom 2012 Exposure control different from PS adjustment layer

forum.luminous-landscape.com

 

[Horshack]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

https://forum.luminous-landscape.com/index.php?topic=77413.0

Thanks Jim, good stuff.

I've run a few experiments which seems to indicate the problem might not be limited to the exposure slider. I shot a bracketed sequence of -4EV through +4EV. Sampling a grey patch, ACR/PS goes non-linear around the same tone as the base shot w/exposure slider I've been working with. I then loaded those raws into RawTherapee without a camera profile and exported with the same ProPhoto RGB Gamma 1.0 profile I created for ACR - the exported TIFFs are all linear across the bracket. I then re-exported in RawTherapee but with my linear camera profile applied and they go non-linear at the same tonal range as ACR. I tried a few switches, including stripping the BaselineExposure field from the EXIF, which reduced the exposure but not the non-linearity. I have some more experiments planned.

 

[JimKasson]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

https://forum.luminous-landscape.com/index.php?topic=77413.0

Thanks Jim, good stuff.

I've run a few experiments which seems to indicate the problem might not be limited to the exposure slider. I shot a bracketed sequence of -4EV through +4EV. Sampling a grey patch, ACR/PS goes non-linear around the same tone as the base shot w/exposure slider I've been working with. I then loaded those raws into RawTherapee without a camera profile and exported with the same ProPhoto RGB Gamma 1.0 profile I created for ACR - the exported TIFFs are all linear across the bracket. I then re-exported in RawTherapee but with my linear camera profile applied and they go non-linear at the same tonal range as ACR. I tried a few switches, including stripping the BaselineExposure field from the EXIF, which reduced the exposure but not the non-linearity. I have some more experiments planned.

If you scroll down about halfway in the following post you can see Lr and C1 tone curves.

a7RII/Lr ASP, C1 generic auto 6000K color accuracy - the last word

This is the thirteenth in a series of posts on color reproduction. The series starts here. In the title, a7RII stands for the Sony alpha 7R Mark II. Lr stands for Lightroom. C1 stands for Capture 1. ASP stands for Adobe Standard Profile. Alpha Photo, a DPR contributor, performed the Capture one...

blog.kasson.com

 

[Horshack]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

https://forum.luminous-landscape.com/index.php?topic=77413.0

Thanks Jim, good stuff.

I've run a few experiments which seems to indicate the problem might not be limited to the exposure slider. I shot a bracketed sequence of -4EV through +4EV. Sampling a grey patch, ACR/PS goes non-linear around the same tone as the base shot w/exposure slider I've been working with. I then loaded those raws into RawTherapee without a camera profile and exported with the same ProPhoto RGB Gamma 1.0 profile I created for ACR - the exported TIFFs are all linear across the bracket. I then re-exported in RawTherapee but with my linear camera profile applied and they go non-linear at the same tonal range as ACR. I tried a few switches, including stripping the BaselineExposure field from the EXIF, which reduced the exposure but not the non-linearity. I have some more experiments planned.

If you scroll down about halfway in the following post you can see Lr and C1 tone curves.

https://blog.kasson.com/the-last-word/a7riilr-asp-c1-generic-auto-6000k-color-accuracy/

Are those with the standard camera profiles? Those have non-linear TRCs built into them. My DNG Profile Editor stripped that out in place of a linear curve.

 

[JimKasson]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

https://forum.luminous-landscape.com/index.php?topic=77413.0

Thanks Jim, good stuff.

I've run a few experiments which seems to indicate the problem might not be limited to the exposure slider. I shot a bracketed sequence of -4EV through +4EV. Sampling a grey patch, ACR/PS goes non-linear around the same tone as the base shot w/exposure slider I've been working with. I then loaded those raws into RawTherapee without a camera profile and exported with the same ProPhoto RGB Gamma 1.0 profile I created for ACR - the exported TIFFs are all linear across the bracket. I then re-exported in RawTherapee but with my linear camera profile applied and they go non-linear at the same tonal range as ACR. I tried a few switches, including stripping the BaselineExposure field from the EXIF, which reduced the exposure but not the non-linearity. I have some more experiments planned.

If you scroll down about halfway in the following post you can see Lr and C1 tone curves.

https://blog.kasson.com/the-last-word/a7riilr-asp-c1-generic-auto-6000k-color-accuracy/

Are those with the standard camera profiles?

Yes.

Those have non-linear TRCs built into them.

Right.

My DNG Profile Editor stripped that out in place of a linear curve.

Oops. I forgot that part. Sorry.

 

[JohnMoyer]

Horshack, I have to date not recommended my hack raw processor, rawproc, to anyone, but I'm going to now for the following reason - it is hard to tease out behaviors in most of the other softwares. I wrote rawproc specifically for that reason, to be able to open a raw file and then stack the tools to process it one-by-one, seeing the incremental effect of each as I worked toward a pleasing rendition.

The most significant insight I've gained using rawproc is come from being able to regard the image at each step. In the early tools that's decidedly less-useful, but even looking at the display's attempt to render the raw measurements right after file-opening is telling in a broad-perspective sort of way. I've found the most useful step to look at is right after demosaic, before any tone curve is applied (well, sorta, the display pipe tries to transform whatever using the display profile, but that can be turned off).

Over time I've added various convenience things like a default toolchain, batch processing, etc., and with all that I use it exclusively for my photography. If you download it and have questions, you can ask here or at discuss.pixls.us.

https://github.com/butcherg/rawproc/releases/tag/1.3

Thanks. I tried building it. It has been decades since I used automake. Do you have a quick answer for this error? I have been too lazy today to use the source.

<pre>

../../src/PicProcessorDemosaic.cpp: In constructor ‘DemosaicPanel:emosaicPanel(wxWindow*, PicProcessor*, wxString)’:

../../src/PicProcessorDemosaic.cpp:211:82: error: ‘DCBENHANCE’ was not declared in this scope

211 | Bind(wxEVT_CHECKBOX, &DemosaicPanel:aramChanged, this, DCBENHANCE);

| ^~~~~~~~~~

</pre>

 

[ggbutcher]

Horshack, I have to date not recommended my hack raw processor, rawproc, to anyone, but I'm going to now for the following reason - it is hard to tease out behaviors in most of the other softwares. I wrote rawproc specifically for that reason, to be able to open a raw file and then stack the tools to process it one-by-one, seeing the incremental effect of each as I worked toward a pleasing rendition.

The most significant insight I've gained using rawproc is come from being able to regard the image at each step. In the early tools that's decidedly less-useful, but even looking at the display's attempt to render the raw measurements right after file-opening is telling in a broad-perspective sort of way. I've found the most useful step to look at is right after demosaic, before any tone curve is applied (well, sorta, the display pipe tries to transform whatever using the display profile, but that can be turned off).

Over time I've added various convenience things like a default toolchain, batch processing, etc., and with all that I use it exclusively for my photography. If you download it and have questions, you can ask here or at discuss.pixls.us.

https://github.com/butcherg/rawproc/releases/tag/1.3

Thanks. I tried building it. It has been decades since I used automake. Do you have a quick answer for this error? I have been too lazy today to use the source.

<pre>

../../src/PicProcessorDemosaic.cpp: In constructor ‘DemosaicPanel:emosaicPanel(wxWindow*, PicProcessor*, wxString)’:

../../src/PicProcessorDemosaic.cpp:211:82: error: ‘DCBENHANCE’ was not declared in this scope

211 | Bind(wxEVT_CHECKBOX, &DemosaicPanel:aramChanged, this, DCBENHANCE);

| ^~~~~~~~~~

</pre>

Yep, that line is trapped by a conditional for librtprocess, which is the library of demosaic routines offered separately by the RawTherapee group. It's not in distros, so you need to download, compile, and install it so rawproc build can find it. Alternatively you can configure rawproc to ignore it with --disable-librtprocess, but then you won't have good demosaic routines, just the silly 'half' routine I wrote in about 15 minutes...

Edit: Actually, there are a few Linux distros that have it. However Debian/Ubuntu are not one of them...

 

[JohnMoyer]

@gbutcher

thanks

GitHub - CarVac/librtprocess: A project to make RawTherapee's processing algorithms more readily available.

A project to make RawTherapee's processing algorithms more readily available. - CarVac/librtprocess

github.com

 

[Horshack]

I've heard Adobe puts a nonlinear roll-off on their exposure tool.

Indeed:

https://forum.luminous-landscape.com/index.php?topic=77413.0

Thanks Jim, good stuff.

I've run a few experiments which seems to indicate the problem might not be limited to the exposure slider. I shot a bracketed sequence of -4EV through +4EV. Sampling a grey patch, ACR/PS goes non-linear around the same tone as the base shot w/exposure slider I've been working with. I then loaded those raws into RawTherapee without a camera profile and exported with the same ProPhoto RGB Gamma 1.0 profile I created for ACR - the exported TIFFs are all linear across the bracket. I then re-exported in RawTherapee but with my linear camera profile applied and they go non-linear at the same tonal range as ACR. I tried a few switches, including stripping the BaselineExposure field from the EXIF, which reduced the exposure but not the non-linearity. I have some more experiments planned.

cameraeIf you scroll down about halfway in the following post you can see Lr and C1 tone curves.liner high

https://blog.kasson.com/the-last-word/a7riilr-asp-c1-generic-auto-6000k-color-accuracy/

Are those with the standard camera profiles?

Yes.

Those have non-linear TRCs built into them.

Right.

My DNG Profile Editor stripped that out in place of a linear curve.

Oops. I forgot that part. Sorry.

I resolved the RT issue - I can now get it to generate fully linear output for my bracketed image set and also via its exposure slider.

ACR refuses to remain linear for the highest EV, either for the bracketed set or via the exposure slider. It appears to do highlight compression as a core function, irrespective of whether those highlights exist naturally in the file or if they're induced via exposure controls. It's also not related to the camera profile because it occurs even for images with no profile.

 

[JimKasson]

ACR refuses to remain linear for the highest EV, either for the bracketed set or via the exposure slider. It appears to do highlight compression as a core function, irrespective of whether those highlights exist naturally in the file or if they're induced via exposure controls. It's also not related to the camera profile because it occurs even for images with no profile.

That's good to know.

 

[Horshack]

Horshack, I have to date not recommended my hack raw processor, rawproc, to anyone, but I'm going to now for the following reason - it is hard to tease out behaviors in most of the other softwares. I wrote rawproc specifically for that reason, to be able to open a raw file and then stack the tools to process it one-by-one, seeing the incremental effect of each as I worked toward a pleasing rendition.

The most significant insight I've gained using rawproc is come from being able to regard the image at each step. In the early tools that's decidedly less-useful, but even looking at the display's attempt to render the raw measurements right after file-opening is telling in a broad-perspective sort of way. I've found the most useful step to look at is right after demosaic, before any tone curve is applied (well, sorta, the display pipe tries to transform whatever using the display profile, but that can be turned off).

Over time I've added various convenience things like a default toolchain, batch processing, etc., and with all that I use it exclusively for my photography. If you download it and have questions, you can ask here or at discuss.pixls.us.

https://github.com/butcherg/rawproc/releases/tag/1.3

Thanks, I'll definitely check this out. I'm able to get RawTherapee to behave like I want for now. Its processing pipeline is decently documented and of course the source is open if one needs to dig a little deeper.

I have a raw manipulation toolset if you ever need:

https://www.dpreview.com/forums/post/65037078

Which includes an automated image stacker for raws:

https://www.dpreview.com/forums/post/65044306

 

[sharkmelley]

ACR refuses to remain linear for the highest EV, either for the bracketed set or via the exposure slider. It appears to do highlight compression as a core function, irrespective of whether those highlights exist naturally in the file or if they're induced via exposure controls. It's also not related to the camera profile because it occurs even for images with no profile.

I did some similar experiments a few years ago. You may find that an earlier process version in ACR (Process Version 2, previously called Process Version 2010) will behave correctly when the Blacks, Brightness and Contrast sliders are set to zero and the "Linear" tone curve is selected.

Mark