RawTherapee restriction on user-chosen output profile

(Elle Stone) #1

In RawTherapee 5.2, I can pick a custom camera input profile as the camera input profile. But I can’t pick the same profile as the output profile.

My custom camera input profiles are also well-behaved RGB working space profiles. For many images I find it convenient to interpolate the raw file “as scene-referred as possible”, open the resulting image file with GIMP, and continue editing in the camera input profile color space.

In darktable, PhotoFlow, UFRaw, and presumably nufraw, there is no such restriction on the output profile.

Could this RawTherapee restriction on the user-chosen output profile please be lifted?

This is from “RawTherapee 5.2 stable, released on 2017-07-23” from Gentoo portage.

(Ingo Weyrich) #2

Rt allows you to select output profiles which meet one of the following conditions:

cmsGetDeviceClass() == cmsSigDisplayClass
cmsGetDeviceClass() == cmsSigOutputClass

For camera input profile there seems to be no check. Means you can cheat by making your profiles output profiles or display profiles instead of input profiles. Then you can copy them into the output folder and use them as camera input and output profile

(Elle Stone) #3

I’ve used the suggested “workaround” in the past with errant software that wanted to interfere with my choice regarding what profile to use. But could you “please please please pretty please” remove this restriction? Using a camera input profile as the output profile is not “cheating”! Sometimes it’s the best way to deal with specific editing problems. Having to resort to a “workaround” shouldn’t be necessary.

(Flössie) #4

We could remove that restriction if $USER == "elle" (instead of the “I know what I’m doing” thing)… :grin:


Today’s Bad Joke: And what restrictions might you have if $USER == "lui"?
Something especially for David Tschumperlé?

Have fun!
Claes in Lund, Sweden


if $USER_SAYS == "SVP" that counts for something. In any case, choice is good.

(Elle Stone) #7

Hmm, the above comment somewhat implies that the reason why the RawTherapee devs have made it impossible for users to select an input class profile as the user-chosen output profile is to protect the user from making a choice that will lead to wrong results for users who don’t know what they are doing.

In my opinion, writing code specifically to protect users from making mistakes based on a developers’ opinions about what users do and don’t understand is a road down which developers of image editing programs should not go.

But I suspect that the real reason for leaving input class profiles out of the list of allowed profile classes for saving an image to disk is that the RawTherapee devs didn’t realize there might be workflow reasons for outputting an interpolated image file that’s still in the camera input color space.

I like RawTherapee quite a lot - it has some amazing editing algorithms not available in other image editors. But normally I don’t use RawTherapee for actually interpolating raw files, because of one specific issue with the RT processing pipeline - there is a bounded ICC profile conversion - possibly to LAB, possibly to the RGB working space, maybe through both of these color spaces, that clips out-of-gamut colors in the interpolated raw file (https://ninedegreesbelow.com/photography/linux-raw-processor-review.html#radiometric).

When I do use RawTherapee for interpolating a raw file, my workaround for avoiding clipped colors is to use an sRGB profile from disk as the input and output profile - thus avoiding any clipped colors from the RT processing pipeline - and then assign the camera input profile after opening the interpolated file with GIMP-2.9.

In other words, personally it doesn’t affect my raw processing workflow at all, regardless of whether RT does or doesn’t allow saving an image to disk in a user-chosen input class ICC profile.

However, if the real reason for making it impossible for users to choose an input class profile for the output profile is to protect users from doing something the RT devs think is not in the best interest of users who don’t know what they are doing, then perhaps a similar constraint should be put on the user’s ability to select a custom camera input profile from disk. After all, an sRGB profile from disk is not an “input class” profile. Rather it’s a “display class” profile.

(Morgan Hardwood) #8

IIRC the restriction was put there to prevent a crash, probably related to CMYK profiles.

I prefer when the software lets the user choose what the user wants, so +1 to remove the filter if a crash can be prevented.

Could you upload some sample ICC profiles which can’t currently be selected?

(Ingo Weyrich) #9

That’s easy :slight_smile:

(Elle Stone) #10

Hi @Morgan_Hardwood - here is a (temporary) link to a sample camera input ICC profile that can’t currently be selected: https://ninedegreesbelow.com/files/sony98-am.icc

The relevant part of the profile is that it’s an RGB profle of the “input” class. When I made the profile I didn’t put in a proper copyright, but please consider it as CC0 if a copyright is needed.


@Elle @Morgan_Hardwood Where do you expect to select the ICC from ? There’s the Input profiles bundled with RT, which is not accessible to the Output profile combobox, and the system ICC profiles dir which is where RT get its output profiles. I don’t mind adding the “cmsSigInputClass” to the filter so you could select it, but looking into the bundled Input profiles would add too much profiles to that combo for 95% of the userbase I guess.

To prevent a crash, I’m only listing profiles with RGB channels, no CMYK profiles since we don’t handle that colorspace. Condition would then be :

  • Device class == Display OR Input OR Output
  • AND color space == RgbData

(Elle Stone) #12

In Linux, users and software can put ICC profiles in a variety of places. Personally I keep the profiles that I’m actually using in /usr/share/color/icc, which is where RT looks when the user is selecting an output ICC profile, same as when selecting an input ICC profile.

  1. Is there an interest of soft-proofing the output profile instead of the printer profile, i.e. Lab -> Output -> Monitor ?
  2. Does it make any sense to make a triple conversion Lab ->Output -> Printer -> Monitor soft-proofing ?

(Elle Stone) #14

If anyone wants access to the bundled ICC profiles for a given camera(s), the best thing for that user to do probably would be to copy the desired profie(s) to a folder where RT already looks. For some/many systems this probably does require being root or administrator. I can’t imagine anyone wanting to wade through all the bundled profiles every time they choose an output profile.


@Elle Filter removed in this changeset.

PS : Small correction : the profiles that are listed are already the bundled and personal ones…

(Elle Stone) #16

Thank you thank you!

(Alberto) #17

Yes, please. In particular I’d like to be able to see some indicators for out of gamut colours.

(Elle Stone) #18

+1 - if the user plans to do any additional editing in the output color space, and given that RT output currently is integer, it would be nice to see what colors might be clipped before actually saving the image to disk.

(Andrew) #19

Yes please. We had some discussion of this some weeks back here https://github.com/Beep6581/RawTherapee/issues/3054
and there was support at the time.

(Glenn Butcher) #20

Well, this is pretty much the idea behind rawproc, my raw processor hack. To your quest, I just did what I think you need by opening the NEF with input.raw.libraw.cameraprofile=Nikon_D7000_Sunlight.icc, then saved it to a JPEG with no additional processing and removing the sRGB profile from output.jpeg.cms.profile. Ta-da, even got the dialog, “No output profile specified, saving with working profile.”

Now, that this works in rawproc is due more to my ignorance than actually knowing how this is all supposed to work. But it makes sense to me, in that if there is no other colorspace transformation after a raw is opened with an assigned input profile, it should be saved with that profile as input for downstream work.