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.
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
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.
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 (Raw Processor Review, Part 1).
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.
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 :
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.
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.
+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.
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.
