Forgot Password
Pentax Camera Forums Home
 

Reply
Show Printable Version Search this Thread
01-28-2021, 01:43 PM   #61
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by TonyW Quote
There is only one colour that falls outside sRGB that is the Cyan patch, but falls within Adobe RGB
Weird, when I enable to gamut warning in RT, on the X-rite RAW file photo from the Pentax K1, most of the color tiles have a warning. The cyan is clipped and this is an important one because it is in the middle of the Hue scale in the HSL correction tool of RT.

QuoteOriginally posted by TonyW Quote
Why are you quoting as fact what is purely a personal subjective opinion?
My subjective opinion that people move correction sliders manually to match color visually came from what I have found out of web searches. Even the Adobe DNG editor tutorial shows how to match colors between two camera by moving sliders and looking at color bars side by side to check visually if the colors are matching or not. There is also the PatchTool to make report of color differences between cameras, but making a report is not the same as producing text files containing corrections values to load in HSL tool of Raw Thearapee.

QuoteOriginally posted by TonyW Quote
At worst these are voodoo moves and totally unecessary at best you are just making work for yourself without any scientific or colorimetric information - do you have a spectrophotometer for instance to prove your theories?
I wouldn't say "proving" is appropriate, since I did the numerical work of sensitivity analysis of the H.S.L sliders (which can also be set by loading a text file containing the X Y correction values for H, S and L) and I've found that once the color saturation gets closer to 100%, the actual correction effect is not 1:1 anymore, the correction becomes compressed because saturation can't exceed 100%! I don't have any theory, I just tried to correction RAW file processing on H(H), S(H) and L(H) parameter to match in camera styles.

QuoteOriginally posted by TonyW Quote
Perceptual rendering intent is totally misleading as that particular intent is dependent on the makers view of what constitutes a 'pleasing' result. The correct rendering intent is one that produces the best or most pleasing visual result to you.
That's true. Although if I do a two point interpolation to find the right amount of H, S and L correction to my RAW development process, I have to make sure that I'm not using the camera JPEG processing in a zone where it is non linear.

QuoteOriginally posted by TonyW Quote
In another attempt to help you understand attached are the figures for the X-Rite colour checker. You will note that the values quoted are in sRGB values and more accurately L*a*b* values. Should you wish to plug these into your own version please use the Lab values as these are the correct values in any colour space you care to use sRGB, Adobe RGB and ProPhoto.
RT also has input for L*a*b corrections at the bottom of the exposure panel. I tried those but I felt more comfortable to use the HSL model, because it's easy to understand, L*a*b is more abstract.

QuoteOriginally posted by TonyW Quote
I am not trying to be harsh or super critical but genuinely trying to help your understanding
You provided some information to the topic and I checked it out. For example, from the table of X-rite values above, we can see that all colors are within sRGB, non of the RGB values are clamped to 0 of 255. The problem is that these color values are target values. But what happens if there is a color mismatch on the cyan, and the red component of Cyan tile tries to go below 0 during the color rendering process? Can I still use Cyan as a hue point assuming that there is a linear relationship between the applied S (saturation) correction value and the amount of shift happening on the output value of saturation?

Other difficulty: what happens on the S(H) curve between H=360 and H=5 if the red (H=5) is very saturated and the hue at H=357 (light pink) if very unsaturated?


Last edited by biz-engineer; 01-28-2021 at 01:52 PM.
01-28-2021, 02:34 PM   #62
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
QuoteOriginally posted by biz-engineer Quote
Weird, when I enable to gamut warning in RT, on the X-rite RAW file photo from the Pentax K1, most of the color tiles have a warning. The cyan is clipped and this is an important one because it is in the middle of the Hue scale in the HSL correction tool of RT.
You must be enabling gamut warning and be working in the wrong colour space or at least your editor does not do proper calculation prior to display. The Cyan is no more important than any other colour and forget about Hue scales. Set your colour space to ProPhoto or Adobe RGB the Cyan should not be clipped.

Please post a link or pm me a dropbox file to your K1 colour checker raw file

QuoteQuote:
My subjective opinion that people move correction sliders manually to match color visually came from what I have found out of web searches.
We all know that if its on the web it must be correct

QuoteQuote:
Even the Adobe DNG editor tutorial shows how to match colors between two camera by moving sliders and looking at color bars side by side to check visually if the colors are matching or not.
Yes a perfectly valid way to do this type of matching.
QuoteQuote:
There is also the PatchTool to make report of color differences between cameras, but making a report is not the same as producing text files containing corrections values to load in HSL tool of Raw Thearapee.
Do it by eye then in RT. Do not rely on there being an exact match between two different applications for the HSL figures
QuoteQuote:
I wouldn't say "proving" is appropriate, since I did the numerical work of sensitivity analysis of the H.S.L sliders (which can also be set by loading a text file containing the X Y correction values for H, S and L) and I've found that once the color saturation gets closer to 100%, the actual correction effect is not 1:1 anymore, the correction becomes compressed because saturation can't exceed 100%! I don't have any theory, I just tried to correction RAW file processing on H(H), S(H) and L(H) parameter to match in camera styles.
On the contrary proving is very important as the so called numerical work on the sensitivity analysis is based on the figures presented by one application while you seem to be floating between Pentax Adobe and RT
QuoteQuote:
RT also has input for L*a*b corrections at the bottom of the exposure panel. I tried those but I felt more comfortable to use the HSL model, because it's easy to understand, L*a*b is more abstract.
A colour scientist would most likely do all work in CIE Lab. One big advantage there is no variation in Lab values between colour spaces it is an exact description which seperates luminance from colour. The Lab value of 54, 80, 69 equals a bright red which translates to RGB values of 252, 1, 1 respectively. In Prophoto the RGB values are 176, 69, 26, and Adobe RGB = 216,6,6. There is no ambiguity in Lab the values of L*58 a*80 b*69 remains the same regardless of working space
QuoteQuote:
You provided some information to the topic and I checked it out. For example, from the table of X-rite values above, we can see that all colors are within sRGB, non of the RGB values are clamped to 0 of 255. ......
There is no point in "clamping" any value to either 0 or 255. Of course the colours must be within sRGB as any colour that is outside must be rendered to fall within the colour space that conversion is done using relative colorimetric rendering intent. As stated abobe the values will be very different in other RGB working spaces.

Last edited by TonyW; 01-28-2021 at 02:53 PM.
01-28-2021, 02:46 PM   #63
Pentaxian




Join Date: May 2015
Posts: 1,775
QuoteOriginally posted by biz-engineer Quote
Weird, when I enable to gamut warning in RT, on the X-rite RAW file photo from the Pentax K1, most of the color tiles have a warning. The cyan is clipped and this is an important one because it is in the middle of the Hue scale in the HSL correction tool of RT.
But what dcp are you using when processing the raws that are showing gamut warnings? The Pentax and Adobe dpc's (including the embedded ones) shift stuff around they aren't accurate but made to be pleasing. Your other edits, unless you go neutral pp3 in rt, can also push colours out of gamut.
01-29-2021, 01:19 AM   #64
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by house Quote
But what dcp are you using when processing the raws that are showing gamut warnings? The Pentax and Adobe dpc's (including the embedded ones) shift stuff around they aren't accurate but made to be pleasing. Your other edits, unless you go neutral pp3 in rt, can also push colours out of gamut.
My color management settings in RT: ProPhoto as working space, ProPhoto are output space, and sRGB as display space (smaller than my own display gamut).
Neutral RT preset + using the original .dcp provided with RT package , only the Cyan tile is OOG, no other gamut warnings on the 24 tiles checker.
When I change the camera profile to the .dcp created with X-Rite app, all other parameters stay the same, I get one more tile OOG on the checker.

---------- Post added 29-01-21 at 09:23 ----------

QuoteOriginally posted by TonyW Quote
Do it by eye then in RT.
Doing by eye is a valid approach because the human eye is better to detect subtle color differences than electronic devices, it require to have a monitor having a color gamut fully color all colors of the color checker, otherwise if the monitor clip one color the user may keep pushing a slider without seen any change on the display.

---------- Post added 29-01-21 at 09:25 ----------

QuoteOriginally posted by TonyW Quote
On the contrary proving is very important as the so called numerical work on the sensitivity analysis is based on the figures presented by one application while you seem to be floating between Pentax Adobe and RT
Each application has it's own HSL or CIE Lab computation, so yes using numerical values read out from two different software can create more issues. I try to read values only from RT itself.

---------- Post added 29-01-21 at 09:26 ----------

QuoteOriginally posted by TonyW Quote
A colour scientist would most likely do all work in CIE Lab. One big advantage there is no variation in Lab values between colour spaces it is an exact description which seperates luminance from colour. The Lab value of 54, 80, 69 equals a bright red which translates to RGB values of 252, 1, 1 respectively. In Prophoto the RGB values are 176, 69, 26, and Adobe RGB = 216,6,6. There is no ambiguity in Lab the values of L*58 a*80 b*69 remains the same regardless of working space
Thank you to this clarification. I had read that CIE Lab was unbounded, now I understand what it means, and the advantage of it !!!

---------- Post added 29-01-21 at 09:30 ----------

QuoteOriginally posted by TonyW Quote
There is no point in "clamping" any value to either 0 or 255. Of course the colours must be within sRGB as any colour that is outside must be rendered to fall within the colour space that conversion is done using relative colorimetric rendering intent. As stated abobe the values will be very different in other RGB working spaces.
That's right, I though about this later. I've used "perceptual" for my JPEG conversion, that was wrong, I should I used "relative colorimetric" to avoid non linear behaviour. Still, I have no control over the OOC Jpeg color rendering method used, I assume Pentax OOC Jpeg are rendered with perceptual, but I can't find evidence of this.

---------- Post added 29-01-21 at 09:40 ----------

QuoteOriginally posted by TonyW Quote
Please post a link or pm me a dropbox file to your K1 colour checker raw file
I'll prepare a package including file for working: exposure bracketed raws, OOC jpegs, and camera dcp

01-29-2021, 04:43 AM   #65
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
QuoteOriginally posted by biz-engineer Quote
My color management settings in RT: ProPhoto as working space, ProPhoto are output space, and sRGB as display space (smaller than my own display gamut).
Neutral RT preset + using the original .dcp provided with RT package , only the Cyan tile is OOG, no other gamut warnings on the 24 tiles checker.
When I change the camera profile to the .dcp created with X-Rite app, all other parameters stay the same, I get one more tile OOG on the checker.
Your colour management is totally out of whack so its no wonder you are finding OOG issues:

RT working space = ProPhoto is good as its the only colour space that can accomodate all of what your camera can capture.

RT output to ProPhoto is good for spawning 16 bit TIFF or to convert to a printer output space.

Do not use sRGB as a display space.

What good reason could you have to hobble your display capabilities? Use the Native space when calibrating to get the most your display is capable of

Are you suggesting that you are calibrating and profiling your screen to be a lower gamut than your monitor can display or is there some display setting in RT?

You need to be aware that raw editors cannot actually display colours relating to Prophoto. I will only comment about LR and ACR but they use a colour space similar to ProPhoto called Mellisa RGB. The difference is that Melissa uses a gamma of 1.00 whereas ProPhoto uses a gamma of 1.8. The colour space is only used for internal calculations as the display itself is based on sRGB TRC's

QuoteQuote:
That's right, I though about this later. I've used "perceptual" for my JPEG conversion, that was wrong, I should I used "relative colorimetric" to avoid non linear behaviour. Still, I have no control over the OOC Jpeg color rendering method used, I assume Pentax OOC Jpeg are rendered with perceptual, but I can't find evidence of this.
sRGB and Adobe RGB do not contain any perceptual matrix so you are forced down the relative colorimetric route even if your software offers the choice
01-29-2021, 04:52 AM   #66
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by TonyW Quote
Do not use sRGB as a display space
I know. I use my monitor own profile as display output profile. But I shortly replace monitor profile with sRGB because I wanted to check if the X-rite colors shot with K1 were OOG versus sRGB. And since the color gamut warning in RT compares to display profile, I temporarily replaced monitor profile by sRGB. On this part, I know what I'm doing, there's nothing wrong with this.

---------- Post added 29-01-21 at 12:57 ----------

QuoteOriginally posted by TonyW Quote
Are you suggesting that you are calibrating and profiling your screen to be a lower gamut than your monitor can display or is there some display setting in RT?
No. I just selected sRGB or aRGB or monitor profile to see what X-rtie patches light up OOG when I change output profile. My working color space prophoto is fine. In RT, the signal chain is that way: camera input space -> working space -> monitor space (for display) or output space (for exports or prints). So by selecting camera .dcp as input space, prophoto as working space, sRGB as output space (largest space) and monitor.icc OR sRGB or aRGB in display space, I can appreciate what color check tile goes OOG vs color space in the JPEG output.

---------- Post added 29-01-21 at 12:58 ----------

QuoteOriginally posted by TonyW Quote
The difference is that Melissa uses a gamma of 1.00 whereas ProPhoto uses a gamma of 1.8.
In RT, user can select gamma setting in RAW pre-processing options. In my case, default gamma = 1.0.

---------- Post added 29-01-21 at 13:03 ----------

QuoteOriginally posted by TonyW Quote
sRGB and Adobe RGB do not contain any perceptual matrix so you are forced down the relative colorimetric route even if your software offers the choice
In RT, rendering option is found in the output color space field and in display color space field. If I select "relative" in output color space setting, and the Pentax camera uses "perceptual" , there will be differences of color for colors not fitting within the JPEG sRGB color gamut. I made a mistake for my JPEGs of the X-rite checker, I chose sRGB in camera and sRGB perceptual in RT, I should have selected : aRGB in camera and aRGB relative colorimetric in RT.

Last edited by biz-engineer; 01-29-2021 at 05:13 AM.
01-29-2021, 05:47 AM   #67
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
Your K1 files do not show any overexposure in LR.

Attached:
The image should change from sRGB to Adobe RGB constantly OOG shown in Red. The OOG warnings are rather old and flaky and give no indication of the amount of OOG but at least demonstrates the issue is there. In the real world of printing you may find that the issue can safely be ignored most of the time


Using LR OOG display you will see there is some OOG in sRGB as expected but has disappeared when switching to Adobe RGB. Switching between relative and perceptual RI makes no visual difference these profiles are V2 which currently most suggest using as the V4 profiles can be tricky.

Suprisingly the colour checker did not show the Cyan OOG but other colours orange, yellows and reds - possibly the aim points have been changed a little from the original
Attached Images
 
01-29-2021, 09:24 AM - 1 Like   #68
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
I did try to PM you but it appears you have chosen not to accept PM's so:


I have had a quick look at the K1 DNG's and put them through RawTherapee, Lightroom and opened the camera JPEG. To the DNG images I applied the K1 vibrant profile (as this likely to show the most variation) and also selected the White point in RT and LR - to make sure we are starting from a known point. The SOOC JPEG K1 Vibrant I needed to adjust density down a little to match the RT and LR images. See attached:

IMO they are all close enough to be considered acceptable as a starting point for further editing, accepting that YMMV. Should you wish to tweak the profiles you can only reliably do this in something like Adobe DNG or Lumariver Profile editor or Argyl. This is purely a visual consideration unless you have the required tools to make real world measurements i.e. a spectrophotometer and an application such as Babel Colour and Patch tool.

Attached Images
View Picture EXIF
 Photo 

Last edited by TonyW; 01-29-2021 at 09:33 AM.
01-29-2021, 11:53 AM   #69
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by TonyW Quote
IMO they are all close enough to be considered acceptable as a starting point for further editing, accepting that YMMV. Should you wish to tweak the profiles you can only reliably do this in something like Adobe DNG or Lumariver Profile editor or Argyl. This is purely a visual consideration unless you have the required tools to make real world measurements i.e. a spectrophotometer and an application such as Babel Colour and Patch tool.
Thank you for taking the time to make a comparison using you .dcp files. It appears that RT applies some amount of general saturation be default, and that now explains why many tile of the color checker were OOG even if they shouldn't. On your most left image we can see that RT render colors more saturated compared to the two other LR and camera images, it is especially visible on the orange colored tiles. So, when I tried to match colors using RT, I started from a high level of saturation, + some perceptual rendering when exporting the JPEG with RT, which hijacked my HSL corrections.If you still have time, please take a look at saturation in RT.

In addition, more trouble can be added in RT: the way the tone curve is applied has multiple options. standard, weighted average, film like, luminance and perceptual. That means depending on the tone curve option color is affected. I suppose both LR and camera use the standard application of the tone curve, which applies the curve to all RGB channels the same way. However, the "auto-match" feature of RT selects the film-like option. Using perceptual (according to Rawpedia document) shouldn't affect colors at all. I probably didn't pay attention to that when I applied a tone curve.

Last edited by biz-engineer; 01-29-2021 at 12:01 PM.
01-29-2021, 12:25 PM   #70
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
QuoteOriginally posted by biz-engineer Quote
Thank you for taking the time to make a comparison using you .dcp files. It appears that RT applies some amount of general saturation be default, and that now explains why many tile of the color checker were OOG even if they shouldn't. On your most left image we can see that RT render colors more saturated compared to the two other LR and camera images, it is especially visible on the orange colored tiles. So, when I tried to match colors using RT, I started from a high level of saturation, + some perceptual rendering when exporting the JPEG with RT, which hijacked my HSL corrections.If you still have time, please take a look at saturation in RT.

In addition, more trouble can be added in RT: the way the tone curve is applied has multiple options. standard, weighted average, film like, luminance and perceptual. That means depending on the tone curve option color is affected. I suppose both LR and camera use the standard application of the tone curve, which applies the curve to all RGB channels the same way. However, the "auto-match" feature of RT selects the film-like option. Using perceptual (according to Rawpedia document) shouldn't affect colors at all. I probably didn't pay attention to that when I applied a tone curve.
No apparent changes in HSL.

The rendering intent is irrelevant - it does not change anything at all within your raw editor (using normal working/editing spaces) . Try looking at the output from your raw editor when set for sRGB or Adobe RGB, when you change from Relative Colorimetric to Perceptual or Absolute or Saturation what difference do you observe?

Raw editors output to a synthetic RGB working space which use matrix profiles. Only relative colorimetric rendering necessary to define the colour. The perceptual rendering intent is only useful when outputting from your working space to your output destination.
01-29-2021, 12:58 PM   #71
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by TonyW Quote
No apparent changes in HSL.
I think I finally get it. In RT, HSL values displayed on the left panel are related to the working color space. But the out of gamut warnings and the displayed image are related to the display color space.
So when my working color space was ProPhoto and I was trying to tune the HSL equalizer to get the same HSL values in the left panel of RT as in the camera JPEGs, I was trying to match two things that are only connected via the color space conversion (in RT) from ProPhoto RGB to the output color space (sRGB). So this explains why it's not possible to do a simple linear interpolation. But, now if I use sRGB as my working color space, the HSL values found on the left panel can be directly matched to a JPEG, although the effect of changes in the HSL equalizer will still be non linear. Is that it?
01-29-2021, 03:42 PM - 1 Like   #72
Site Supporter
Site Supporter




Join Date: Feb 2016
Posts: 696
QuoteOriginally posted by biz-engineer Quote
I think I finally get it. In RT, HSL values displayed on the left panel are related to the working color space. But the out of gamut warnings and the displayed image are related to the display color space.
Sorry but no you have not really got it at all.
I do not know the inner workings of RT, but if it works the way you describe above you should bin it immediately
I do not know what the HSL values in the left panel relate to but they should relate to your working space and the OOG warnings must relate to the output space otherwise they are of no value. Your display space may not be able to display all the colours in your image file but that should be a different OOG warning. In LR there are two OOG warnings one in Red showing OOG for the image in a particular paper profile and one in Blue when the image data exceeds the gamut of the monitor.

QuoteQuote:
So when my working color space was ProPhoto and I was trying to tune the HSL equalizer to get the same HSL values in the left panel of RT as in the camera JPEGs, I was trying to match two things that are only connected via the color space conversion (in RT) from ProPhoto RGB to the output color space (sRGB). So this explains why it's not possible to do a simple linear interpolation. But, now if I use sRGB as my working color space, the HSL values found on the left panel can be directly matched to a JPEG, although the effect of changes in the HSL equalizer will still be non linear. Is that it?
I really cannot comment on RT specifics as I just do not have enough hands on experience.

You are way way overthinking this subject and really not following colour managing at all, therefore just going around in circles when there is absolutely no need

This is a relatively simple thing to do with the outcome as good or better than the manufacturers guess what would be a pleasing image for Vibrant, Neutral etc. There is no Pentax, Nikon, Canon, Olympus colour science associated with JPEG's, just an individual or committee deciding on what colours look good for the various camera presets

Please stop trying to do any linear interpolation it just will not work, you need tools that you do not possess as explained earlier.

Bear in mind that you are just looking at a limited gamut colour checker shot under a particular lighting scenario so any profile or preset you choose to make will alter the 'look' of any image you decide to apply it to based on this limited colour set. What you should be doing is looking at a load of mixed real world images and seeing how your profile or preset perform. Then tweak colour as required to get an overall pleasing effect.

I attach one last example showing a three minute play with Adobe Profile Editor to visually match the look of the Pentax Vibrant profile in Rt. The RT image contained in the green box. I had RT open with the same DNG + Vibrant profile next to the Adobe profile editor. You will notice some rows of colours next to the circle you should see that the colour is split down the middle. The colours are what I selected from the colour checker to alter to match the RT version. The split and change of colour shows the original colour on the left with the alteration on the left just using Hue Sat and Luminance

This is not put forward as an exact match (that would be pointless IMO) and the dropping out of wide gamut to sRGB export has dulled things down a little, however it shows the possiblity to produce a new profile by tweaking an existing.


The unknown now is how would RT interpret an Adobe Profile editor profile - it may be not too great I forgot to save this one


This is of course just one way to do it and you may prefer to just make a set of presets using whatever tools at your disposal.
Attached Images
 

Last edited by TonyW; 01-29-2021 at 03:51 PM.
01-30-2021, 12:37 AM   #73
Pentaxian




Join Date: Feb 2015
Photos: Gallery | Albums
Posts: 8,478
Original Poster
QuoteOriginally posted by TonyW Quote
I do not know the inner workings of RT, but if it works the way you describe above you should bin it immediately
RT works, according to settings and description of what those settings do. For example, if soft proofing is enabled, then the out of gamut warning is relative to output. if soft proofing is disabled , the out of gamut warning is relative to display profile (and display profile can be set to other than display profile, e.g sRGB, aRGB, but it's not meant to be that way). HSL, CIE Lab on the left panel are relative to the Working space. Contrary to some other raw developper, Raw Therapee also has a number of options for the tone curve, which can be source of error if we don't check that the tone curve option is consistent when comparing two color profiles. More options also means more possibilities of making mistakes.

QuoteOriginally posted by TonyW Quote
This is a relatively simple thing to do with the outcome as good or better than the manufacturers guess what would be a pleasing image for Vibrant, Neutral etc. There is no Pentax, Nikon, Canon, Olympus colour science associated with JPEG's, just an individual or committee deciding on what colours look good for the various camera presets
I also think so. A group of people with proper color competence (not like me) went through a set of images (people, landscapes etc..) and decided about how color should be rendered, they created profiles accordingly and then stuck with it over the years. So it may be that the Pentax styles decided for the istD aren't that trendy anymore. In a way, it is great if someone can develop their own color profiles, but may also require so forehand knowledge on "color science".

QuoteOriginally posted by TonyW Quote
Please stop trying to do any linear interpolation it just will not work, you need tools that you do not possess as explained earlier.
Sure you are right. I oversimplified the topic, thinking I would match a color profile by a simple math. Reality is, it may be completely non-linear, if the "color science" committee decide to add a big punch to the turquoise blue but keep everything else flat, my interpolation will completely miss it. That's why this goes to 3D LUTs. And the eye is better than math a picking up color differences, evidence is that the human eye can detect color differences outside of sRGB or aRGB, so it was my mistake to believe that math from a color picker would be more precise than my eyes for color matching.
02-01-2021, 12:19 AM   #74
Pentaxian




Join Date: May 2015
Posts: 1,775
QuoteQuote:
On your most left image we can see that RT render colors more saturated compared to the two other LR and camera images,
Make sure to untick the look box in the rt colour profile. The look stuff is not meant to be accurate.
Reply

Bookmarks
  • Submit Thread to Facebook Facebook
  • Submit Thread to Twitter Twitter
  • Submit Thread to Digg Digg
Tags - Make this thread easier to find by adding keywords to it!
.dcp, .dcp color profile, adobe, camera, camera profile, checker, color, converter, correction, d50, dng, editor, effect, file, gamma, images, jpeg, monitor, pentax, photography, photoshop, post, profile, profiles, rawtherapee, rt, software, x-rite
Thread Tools Search this Thread
Search this Thread:

Advanced Search


Similar Threads
Thread Thread Starter Forum Replies Last Post
.dcp file compatibility between Lightroom and RawTherapee? BigMackCam Digital Processing, Software, and Printing 11 01-04-2020 02:51 PM
Converting Adobe dcp profiles to icc? BigMackCam Digital Processing, Software, and Printing 6 01-05-2019 11:28 AM
Pentax K-500 DCP/ICC profiles Trickortreat Pentax K-30 & K-50 0 12-27-2016 03:01 PM
Format of Camera Profile files (.dcp) Catscradle Digital Processing, Software, and Printing 7 02-02-2016 08:30 PM
Print profile vs display profile dtra Digital Processing, Software, and Printing 9 04-19-2011 04:33 PM



All times are GMT -7. The time now is 08:24 PM. | See also: NikonForums.com, CanonForums.com part of our network of photo forums!
  • Red (Default)
  • Green
  • Gray
  • Dark
  • Dark Yellow
  • Dark Blue
  • Old Red
  • Old Green
  • Old Gray
  • Dial-Up Style
Hello! It's great to see you back on the forum! Have you considered joining the community?
register
Creating a FREE ACCOUNT takes under a minute, removes ads, and lets you post! [Dismiss]
Top