Another camera profiling issue (DNGPE)

[Redcrown]

Much like torger in a recent thread, I've been doing lots of profile testing using the MacBeth colorchecker and the DNG Profile editor. Trying to learn more about "best practice" when shooting the chart.

It's easy to eliminate things like aperture, shutter speed, ISO, and lens as significant variables. Within reason, of course. High ISO or very long shutter speeds would create noise that can mess up the results.

That leaves 3 key variables:

1. Light source (daylight, tungsten, fluorescent, LED, etc.)
2. The white balance temp of the light source.
3. The exposure level of the chart image.

Most discussions focus on the light source as the only significant variable. However, my tests show me that the white balance temp and the exposure level also have significant impact on profiles. I've posted examples of the impact that exposure level has in other threads here and on dpReview, but those threads have not generated much feedback.

Here is an example of the difference white balance makes. I made two shots of the colorchecker in overcast daylight with my Canon 5D3. The shots were made 1 month apart. The exposures are identical (a LAB-L value of 96 on the white square). One has an ACR white balance of 5800 and one has 6250. That does not seem like much difference.

I generated single illuminant profiles from each shot using DNGPE with Adobe Standard as base profile. The following jpeg shows the difference when these two profiles are applied to the WB6250 shot used to make one of the profiles. The inner squares are the result of the WB5800 profile, the outer parts are the WB6250 profile.   

http://kellyphoto.smugmug.com/photos/i-mhKPDzk/0/O/i-mhKPDzk.jpg


To me, these differences are significant, and leave me a bit confused. I've reviewed Andrew Rodney's video several times where he shows no difference in daylight profiles made at different white balances. Since my test does not confirm that, I suspect operator error (mine, not Andrew's). So I'd appreciate a peer review.

For those willing to review my results here is a zip file. It contains the 2 DNG images and the 2 profiles made from those images. The DNG files are in "lossy" format to save download time, but I tested and saw no significant difference in profiles made from lossy and lossless inputs.

https://dl.dropboxusercontent.com/u/62166185/DngpeFiles.zip

[digitaldog]

https://forums.adobe.com/message/3179969

See post #9 from Schewe.

https://forums.adobe.com/message/3183090

See #11 from Eric.

[samueljohnchia]

I downloaded the zip folder and took a look at the DNG files. I think the cause for the differences is very simple. The eveness (or uneveness) of light illuminating the target is very different. The 5800K has quite a bit more illumination on the top portion of the target than the 6250K exposure. The surfaces of the patches are also not perfectly lambertian (diffusing), and it looks like some direct light is reflecting off the patches in the 5800K, making them lighter unevenly across individual patches. You can see it easily by comparing the cursor readout numbers for each patch, or by cropping both to the same size and layering one over the other and toggle the visibility. Since the original 5800K has more washed out (less saturated) patch colors, it follows that the DNGPE makes the correction for them to appear more saturated than the 6250K.

[Redcrown]

Samuel,

Thanks for taking the time to inspect my images and offering an analysis. Clearly I need to be more diligent in exposing the chart evenly.

My WB5800 chart looked OK to my eye, but close inspection with a colorpicker shows the error. When I fish around the edges of the chart I see a maximum of 9 percentage points difference in K values. I guess that's not good enough. My WB6250 image shows a 5% variance. Better, but maybe still not good enough.

So I'll start over with new shots (but that will have to wait a few days for freezing rain and drizzle to pass my area). I'm also learning it's bad practice to fill the frame so much with the chart. That is probably introducing slight lens vignetting.

Also, thanks for introducing the term "lambertian". Never heard that one before.

[Tim Lookingbill]

I examined your files as well & have to agree with Samuel.

Not sure why you have to remake a single illuminant daylight custom DNG profile lit by overcast light since the one I've made didn't make much difference over one created with a direct sunlight lit CCchart. There was a slight increase in saturation but only compared to remade daylight profiles using the same Raw target in LR4.4 converted DNG's along with the recent DNG PE Wizard which create slightly less saturated daylight over the PV2003 era versions.

Below is a screenshot of the overcast ccChart I used. I also found out it didn't make any difference whether I started out with Adobe Standard or ACR 4.4 base profiles. Neither affected tables or WB after running the Wizard. They both produced identical Lab numbers in each patch and dead to nuts neutral color cast correction in all gray patches from white to black.

It's when I start applying them to a wide range of individual images, usually landscapes with constantly changing light, do I see the differences between new & old DNG PE made profiles.

[samueljohnchia]

Hi Redcrown, no problem, it is fun trying to guess at camera profiling issues. This is one area that I have still not fully understood myself. When photographing colorcheckers, I like to keep the sun angle at 45 degrees incident to the chart, to minimise reflection issues. As long as a surface is not perfectly lambertian, this is best practice. I learnt that term whenI was conversing with a color scientist, trying to better understand camera profiling. Indeed, by keeping the chart small and in the center one avoids issues with vignetting throwing off the profiling process. It also helps to slightly defocus the lens to blur any details in the patches. Your exposure technique is excellent, holding the brightest white patch just below clipping. I also look out for any structures nearby which may reflect some additional tinted light from the sun, like a brightly painted wall or glassy surfaces - stay away from them, or re-position your chart.

Tim is quite right - I too have not seen too much difference between a single illuminant profile from a cloudy day (6000+K) and from direct noon sunlight on a totally clear day (5500+K). However, warm light at sunrise and sunset is something else, resulting in a profile that represents warm colors more accurately, but usually sacrificing some overall smoothness. You can see that in gradients of colors, like in the bokeh of an image. It is especially obvious when one hue gradates into another.

If the Adobe Standard and the other variant camera profiles for your camera use the same forward matrices, then it does not matter which base profile you choose to use. If they differ, then for the same white balance values in LR/ACR, you would see different results, and the DNGPE would also build different huesat tables. You can peer into all this using Sandy's DcpTool.

I am less sure about the usefulness of DNG camera profiles these days. For a long time I only had Canon 5D MkII cameras to experiment with, and profiling three different cameras resulted in a very close match to a synthetic color checker, and interestingly the profiles essentially did not differ at all. I feel that all the talk about cameras Adobe uses for profiling being vastly different from the ones we use, hence necessitating custom profiles is a more or less untrue. Last year I had a Sony A7R, which responded very poorly to DIY camera profiling with the colorchecker and DNGPE. My technique was excellent, and I was very careful. The DNGPE mapping was just not able to match all the patches of the colorchecker automatically, especially in the warm colors. I could certainly adjust the DNGPE silders manually to get a good match, but the resulting profile was even worse, with horrific hue jumps and shifts. All the DNGPE profiles was also noticeably less smooth than the Adobe Standard one. Matching all the patches of the colorchecker does not necessarily mean other colors have been mapped accurately, properly or in a pleasing way. But I noticed that when the photographed colorchecker matches up well with a synthetic one, the rest of the colors tend to look quite good too - but only if the DNGPE can get it right on its own, not with a user fiddling with the sliders manually. Some folks suggest to strip the profile of its huesattables, and use the forward matrices to transform the color, but I've never had good results with that also. That said, I'm not sure I like any of the Adobe Standard profiles, even though they are supposedly built using the best method I know of - with a monochromator. I'm not smart enough to know how to tweak the matrices to optimize color accuracy. That was a rabbit hole I went down into for too long.

[Redcrown]

Samuel,

It's ironic, I just started profiling again after a 2+ year absence because I bought a Sony RX10 (a high end P&S camera) for my wife. First attempts seemed strange. I was getting very high saturation and obvious hue shifts. More confusing to me, I was getting significantly different results depending on the exposure of the chart.

So I made some new chart shots with my old Canon 5D3, and again saw strange results. Variance depending on white balance and exposure levels. Now, thanks to your help, I realize both these recent attempts suffered from the operator error of uneven lighting.

Because of some sloppy record keeping, I can't tell which chart images I used to generate my old Canon 5D3 profiles I've been using for 2+ years. But I know all were made at lower exposures because back then I would just center the histogram. Looking back, that gave me a LAB-L value of the white patch at around 88 to 90.

The DNG Profile Editor is a program I love to hate. The documentation is woefully deficient on issues like proper exposure and lighting, the UI is confusing. So we have to rely on tips and tricks burried deep in forum threads on multiple sites.

In my early experience I didn't appreciate the importance of the base profile. I remember once I generated a profile, applied that profile to the chart image used to generate it, then simply did it again, and again, and again. Each time I got different results. Took hours and a thread on Adobe forums before Eric Chan pointed out that when you load a DNG image into DNGPE, it uses whatever profile is assigned to the image as the base profile! Each time I loaded the image, I got the profile from the previous time as the base. So I was stacking profile upon profile. Operator error, of course, but a pretty easy one to make.

It did stop raining briefly today, so I ran out and made some new shots. Still heavy overcast, but I went to a wide open area, put the chart about 5 feet off the ground on a vertical easel, stood 20 feet back to avoid casting body shadows, and made bracketed shots. I still have a 5% variance in LAB-L values when I colorpick around the edge of the chart.

And for Tim, I'm not trying to just add an overcast daylight profile. I've lost confidence in all my old profiles, so I'm starting from scratch and overcast is all I have to work with these days.

[samueljohnchia]

I saw in separate post you made, you discovered the way saturation changes with exposure of the CC. Excellent!

When evaluating the issue of saturation of the profile and hue shifts, one must not have any edits applied in ACR/LR. I use PV2010 and zero all the sliders.  So what you see is simply the profile at work. If there is additional contrast applied by the contrast slider or a curves adjustment, colors start flying all over the place. I have noticed similar issues with blues getting pushed too far, but usually for my landscape pictures I find yellows get pushed too much and shifted in hue towards green.

Eric is right about the base profile, but I think you misunderstood how it affects the DNGPE. If you rebuild your custom profiles in the DNGPE over and over again, you are not getting greater and greater shifting. The two forward matrix tables never change, only the HueSatDelta LUTs get recomputed. That result is not based on the previous profile at all. You are perfectly safe going at it over and over again. But where you place the four control points do affect the final result quite significantly, so that might be the cause of the differences you are seeing?

I find it extremely odd that you can get uneven illumination of a CC on a cloudy day. Just wondering, how old is your colorchecker? I see some scuffing on the black frame - was it carefully protected during periods of non-use? I had weird problems with camera profiling very early on because I was using a CC that was aged and tired.

[torger]

I think camera to camera variation should be very small so you should not need to make a profile per camera for that reason, however as far as I know Adobe's bundled profiles are not designed for showing accurate colors, but rather to show an "Adobe look". Maybe those cameras that have the "Neutral" profile, haven't analyzed myself but I doubt that it's very accurate. So if you want a workflow where the import looks neutral as a starting point you probably need to make your own profile.

I've only used DNGPE briefly but I've already my doubts that it actually produces neutral profiles, it may have some other optimization steps that it considers more important than matching the CC patch color.

Note that tone curve will affect color so if you want to test for accuracy you should have linear curve in your profile, unless DNG PE adapts its LUT for the tone curve, but I don't think so as the DNG spec is against that. That is color correction is made before the tone curve is applied.

If you don't have a linear curve color will change with exposure as colors will get in different places on the S-shaped tone curve. An example: considering an S-curve shape to get more contrast, an orange color with a high value of red and green and a low value of blue will tend to shift toward yellow, because the red and green component will be raised, while the blue one will be lowered. This is for an RGB curve, Adobe/DNG uses a slightly different variant but it's still not free from color shifts.

[Tim Lookingbill]

Torger, I was examining the results of CCchart profiling methods between ICC vs DNG in particular the Ben Goren link in your other thread you started and compared the results to my DNG profile CCchart for my camera and noticed something odd about the rendering of overall brightness appearance between all of the examples even though they all look pretty much alike. Here's the link to the Ben Goren "Exposure" for those interested...http://trumpetpower.com/photos/Exposure

There appears to be some kind of non-standard, non-uniform gradation characterization when increasing/normalizing Exposure or Brightness embedded within the slider tools or RPP's exposure normalization routines between imaging apps used to build the profile whether it's Ben Goren's ICC/RPP vs Adobe DNG rendition of overall brightness. This can have a huge effect on saturation appearance.

This is a very strange optical effect that can't be readily seen with side by side comparisons such as the Ben Goren example. That tutorial reminded me what I was noticing in overall brightness changes (with no clipping in ProPhotoRGB) when switching PV versions in images processed in PV2010 to PV2012 in LR. All of sudden the image got brighter overall but still retained its clarity/contrast where usually it would produce a flatness if the brightness was applied directly using the PV2010 sliders. It's almost like Adobe's sliders had redefined the effect of adding brightness and how it renders on screen.

It's more than a linear or non-linear issue when normalizing scenes for camera profiling because the very app that is utilizing these "normalization" tools does not take into account or connect the math under the hood to how the gradualness increase to brightness is rendered in the preview.

Note Ben Goren's example of the ICC/RPP results where the CCchart white patch is near clipping but the ACR 7 rendition has the white at 216RGB but both appear to have the same overall brightness appearance. There's no where to go in brightening the RPP version because you'ld clip anything near that L*96 white. You can't see this though in the preview! You can only see it in increased saturation in the midrange colors where saturation is most noticeable. That's the problem! Call it internal built in compression. Not sure, but I see it happening.

You'ld have to know the gradualness characteristic embedded in the behavior of the normalizing tools in these apps that attempt to mate or track luminance to hue/sat. IMO that's where the inaccuracies are created.

And now understand Andrew's point he made in the other thread that we do need to stop profiling cameras like they are printers. We need to know how to track luminance to hue/sat as it REALLY appears in front of the camera.

[torger]

I'm not sure I follow fully and I need to take a deeper look, the threads have stirred up so much stuff to look at and I have only that much time a day

Anyway, what I do know is that many raw converters, including latest Adobe, try to simulate film when it comes to overexposure, that is it gradually desaturates towards clipping. Older rendering engines had much more abrupt clipping. In RawTherapee you can control this aspect manually, I generally turn it off completely and control the rolloff manually with curves.

Anyway, this gradual desaturation can reach a bit down even into midtones in some cases if I remember correctly, it makes a mess for HDR merging (since the overexposed shots gets distorted colors).

If there's no clipping going on in the image there should be no such effect though. Normal raw conversion using the DNG color engine is quite well-defined, but still in order to get fully predictable color you must not apply a tone curve. A tone curve will lead to a pleasing look preferred over the linear of course, but while developing and comparing profiles one need to keep rendering linear.

Trying out the DNG profiles in RawTherapee is one alternative too if you see strange things happening in Lightroom, it doesn't do things "behind the back" of the photographer so it can be good for sanity checks.

[Tim Lookingbill]

A tone curve will lead to a pleasing look preferred over the linear of course, but while developing and comparing profiles one need to keep rendering linear.

My question is how does the appearance of rendering linear should appear on screen. Some sliders in some apps behave differently in gradualness as they near clipping. As I remember reading in another forum LR PV2012 invokes a built in highlight compression which explains why the Ben Goren's white patch viewed in ACR 7 is at 216RGB but yet the overall look of the image is just as bright as RPP's which has white near clipping. You can't make the RPP version any brighter using sliders without clipping.

Both of those renderings don't show exactly what those items would look like lit by bright noon day sunlight. They both look somewhat murky and dull as if a thin cloud passed over the sun. This is the gradualness characteristic differences I'm describing. Both apps still want to maintain a bit of clarity and contrast so as to retain the impression the scene is being lit by the sun but there appears to be some unexplainable dimness to the overall rendering. Ben says it's more accurate looking, I don't agree, but the DNG version doesn't either. It appears no one has a real idea on what accuracy is suppose to look like.

What I'm getting at is no one has actually defined an "accurate" appearance of how the sun reflects back to the sensor on real objects. Everyone is utilizing math to get to some starting point in the preview with some apps giving no headroom and some do by invoking highlight compression which affects saturation which should be tied to luminance increase

The descriptive word "pop" is an attempt to remove this dim veil but it seems to be poorly executed in the form of over saturation.

[AlterEgo]

My question is how does the appearance of rendering linear should appear on screen.

there were a number of synthetic DNG targets published where you can compare for example raw data (use rawdigger) with how your raw converter (ACR) works using its sampling tools, for example those :

https://app.box.com/s/d06td858jjde9bv1csgymv78t4jrqiew

https://app.box.com/s/n00yuroy77jysa7pzfd453jnduh6wlmu

[torger]

A real world scene has in general more dynamic range than a typical screen, which in turn has more than a print.

If we would render linear on a screen in an "absolute" sense it would look very dark and with clipped blacks, but we render perceptual and then it looks low contrast instead. To make a look that looks realistic an S-curve is applied, compressing highlights and shadows and increasing midtone contrast. However contrast increase distorts color somewhat (quite hard to detect though) and increases saturation.

The saturation increase is generally a desired effect to make the image "pop".

For purely reflective targets the screen should have high enough range to reproduce a correct contrast in linear mode, but I think the brain will adapt to the new viewing condition on screen and will still think it looks a bit dull. Screen brightness may not match the original scene brightness to start with, and you have the surroundings etc.

Anyway to evaluate color correctness you should render with linear curve and look at hue foremost, and relative saturations. The "duller" look you need to disregard from, the screen can't produce the same range as reality.

If I remember correctly there are some simplistic models of contrast appearance, but I think that current best practice is adjust tone curve to taste, and just accept the saturation increase. If you adjust contrast with just a luminance curve it will get a desaturated appearance, so there is no "correct" way to do it, just a limit of color science. Maybe the more elaborate color appearance model CIECAM02 has something about this, I'm not sure...

If you do reproduction work, copy paintings etc, there should be no contrast change if the resulting print should look the same as the original.

Lightroom is foremost designed for user-friendliness for casual users, and then this automatic desaturation with exposure slider is good, as well as the standard profiles which have some builtin "pop".

I guess that if we would shoot a purely reflective target, say a painting artwork in a studio, calibrate our screen to match the artwork whitepoint both in brightness and temperature, and then render the resulting image with linear curve and absolute colorimetric and view the screen beside the artwork it would look very alike. Next step away would be to have an own whitepoint on the screen, typically 6500K, and render relative colorimetric without blackpoint compensation, and so on.

However for generic photography we get a perceptual rendering on the screen, with a different brightness (often lower) than the original scene, and often the screen is unable to reproduce the the full dynamic range, so we get that dull look if we use a linear curve. It's still better as a reference for evaluate profile accuracy performance.

[Tim Lookingbill]

there were a number of synthetic DNG targets published where you can compare for example raw data (use rawdigger) with how your raw converter (ACR) works using its sampling tools, for example those :

https://app.box.com/s/d06td858jjde9bv1csgymv78t4jrqiew

https://app.box.com/s/n00yuroy77jysa7pzfd453jnduh6wlmu

It's not the Raw data I'm referring to with regard to how sliders act on linear data viewing a preview driven by a gamma encoded calibrated display with a static luminance intensity. Using numbers/data to determine this isn't enough to describe this gradualness behavior in the sliders which was my point when comparing Ben Goren's RPP white clipping vs ACR 7 highlight compression white patch when both produce generally the same preview with regard to overall luminance.

We don't get to see Ben physically brightening/normalizing these two processing demonstrations moving the sliders or doing Ben's math calculations for normalizing in RPP. We see the static finished image but don't note the white patches don't match but the rest of the scene does. Accuracy now gets thrown out the window if relying on the number data.

We have to rely on a calibrated display to make the image look "accurate" as we remember it or if doing repro work in the studio. That's the course we accept as photographers working in a color managed environment where the numbers no longer correlate to anything we see in the preview. What seems to be the fly in the ointment is the behavior of the sliders on the preview and how it influences our perception of what we think looks accurate.

[Tim Lookingbill]

The saturation increase is generally a desired effect to make the image "pop".

That "pop" look appears to me in discussions of this sort as a dismissive term to suggest it is not part of an accurate representation of the scene, to be relegated as merely a desired effect which I have to disagree. Subjective and objective are somewhat connected when reproducing what the photographer saw at the time of capture or else they wouldn't have been motivated to take the shot just as someone wanting to reproduce exactly a certain specific color relationship in a fine art painting such as cobalt blues & intense cyans. Objective measuring doesn't always guarantee the desired result.

The issue I'm seeing in these discussions is no one actually shows or describes exactly how direct sunlight affects the appearance of saturation in any given scene on whether it's really saturated or just a luminance increase. Most I've seen don't really know what they're looking at when they describe the color doesn't look right to them and deems that not to be accurate. Once they achieve what they think is accurate through stringent & controlled testing utilizing complex procedures ends up not looking accurate or pleasing at all.

Below is an example of a scene I shot of a Pyrex measuring cup in my kitchen under direct sunlight where ACR defaults render the scene pretty normal and correct looking, but not accurate. The second version is what I actually saw using the default ACR 4.4 profile & As Shot WB (5000K/+9). The third version is just ACR AutoWB (4800K/+13) which kind of made it look more neutral and less dingy looking and the histogram RGB's line up and overlap to confirm neutrality. But note the definition of the microwave oven to the left loses definition.

Also note the Pyrex logo which looks VERY accurate to the actual orangy red hue appears to have increased in saturation but it actually increased in luminance which aids in depicting the true natural characteristics of sunlight on objects of this type.

[Peter_DL]

If you rebuild your custom profiles in the DNGPE over and over again, you are not getting greater and greater shifting. The two forward matrix tables never change, only the HueSatDelta LUTs get recomputed. That result is not based on the previous profile at all. You are perfectly safe going at it over and over again.

Not sure about this one.

When the Base Profile already includes HueSatDelta maps, like with today’s Adobe Standard profiles or with a custom profile from a previous run of the Chart Wizard, there are essentially two options:

a.)  the HueSatDelta maps get zero’d out first, before the Chart Wizard inserts its hue/sat.-corrections.
b.)  the hue/sat.-corrections from the Chart Wizard are additive to the given content of the HueSatDelta table.

According the quotes from Eric Chan as given below,
and - as I read it - the second quote refers specifically to the HueSatDelta maps,
it is option b.)

Peter

--

>> When using the Chart Wizard feature of DNG PE, the color matrices are taken from the choice of the Base Profile (ColorMatrix* and ForwardMatrix* DNG tags), and the color tables (HueSatMap1 and HueSatMap2 DNG tags) are replaced by the ones calculated by the Chart Wizard.  If the Base Profile has a look table (LookTable DNG tag), it is removed.<<

>> DNG Profile Editor lets you define color edits (in the first tab) using a set of color control points. These control points in turn define a color lookup table used to perform the color correction when processing a (raw) image.
When you use a Base Profile, the resulting color table in the final profile is a combination of the base profile's color table, plus the color table defined by any edits that you've added in the first tab (using the Chart Wizard counts as adding edits to that first tab).

The reason you can get different and less smooth results if you apply the Chart Wizard iteratively is because you are applying lookup table after lookup table. The current color table-building method used by DNG PE has some limitations regarding smoothness of color profiles if two color control points are placed too closely (this can happen with the Chart Wizard, or if you specify two points manually that are close to each other). These problems can become more noticeable if you apply the DNG PE iteratively.<<

[mouse]

Not sure about this one.

When the Base Profile already includes HueSatDelta maps, like with today’s Adobe Standard profiles or with a custom profile from a previous run of the Chart Wizard, there are essentially two options:

a.)  the HueSatDelta maps get zero’d out first, before the Chart Wizard inserts its hue/sat.-corrections.
b.)  the hue/sat.-corrections from the Chart Wizard are additive to the given content of the HueSatDelta table.

According the quotes from Eric Chan as given below,
and - as I read it - the second quote refers specifically to the HueSatDelta maps,
it is option b.)

Peter

--

>> When using the Chart Wizard feature of DNG PE, the color matrices are taken from the choice of the Base Profile (ColorMatrix* and ForwardMatrix* DNG tags), and the color tables (HueSatMap1 and HueSatMap2 DNG tags) are replaced by the ones calculated by the Chart Wizard.  If the Base Profile has a look table (LookTable DNG tag), it is removed.<<

>> DNG Profile Editor lets you define color edits (in the first tab) using a set of color control points. These control points in turn define a color lookup table used to perform the color correction when processing a (raw) image.
When you use a Base Profile, the resulting color table in the final profile is a combination of the base profile's color table, plus the color table defined by any edits that you've added in the first tab (using the Chart Wizard counts as adding edits to that first tab).

Confusing; the way I read it Eric seems to contradict himself.

[Peter_DL]

the way I read it Eric seems to contradict himself.

Why?

>>the color tables (HueSatMap1 and HueSatMap2 DNG tags) are replaced by the ones calculated by the Chart Wizard.<<
and the second statement clarifies that their previous content is taken into account by this calculation,
so that >>the resulting color table ..is a combination of the base profile's color table, plus the ..edits that you've added ..using the Chart Wizard<<

 

[mouse]

Why?

>>the color tables (HueSatMap1 and HueSatMap2 DNG tags) are replaced by the ones calculated by the Chart Wizard.<<
and the second statement clarifies that their previous content is taken into account by this calculation,
so that >>the resulting color table ..is a combination of the base profile's color table, plus the ..edits that you've added ..using the Chart Wizard<<

In the first statement I read "replaced by" to mean replaced, not modified by application of the Chart Wizard.
The second statement seems to contradict (or perhaps clarify) this; indicating the effect of the edit is to modify the color table.

In any case it seems unlikely that repeated application of the Chart Wizard could negatively impact the profile.