DCamProf - a new camera profiling tool

[Iliah]

Well, for 1 patch it is possible only with the help of a database. Don't know if such databases are publicly available, and free; but OKUMURA YOSHIO made quite a study in R.I.T. on the topic.

UPD. Found one of his studies online http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.799&rep=rep1&type=pdf

[AlterEgo]

Well, for 1 patch it is possible only with the help of a database. Don't know if such databases are publicly available, and free; but OKUMURA YOSHIO made quite a study in R.I.T. on the topic.

UPD. Found one of his studies online http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.799&rep=rep1&type=pdf

"...The interesting figure of the table is the volume of a inkjet printer (Canon PIXUS iP8600) because the size is not different from the volume of the Pointerʼs color gamut. The result reminds us of an innovative printing technology in which eight dye inks of the printer reproduce almost all the surface real colors introduced by Pointer [Pointer 1980]..."

[AlterEgo]

one more unscientific test about dark patches, their measurements, glare on dark patches with glossy print, etc ... this IT8 target was the one measured and few saturated patches from it (actual shot) were used to build SSF profile which was then used in raw conversion of the this shot

[AlterEgo]

last unscientific experiment for this night, I switched to other targets

CC Passport (1 shot - not averaged, 1 light = illumination : H3200K+80A, flat fielded), SSF from matlab using all patches from that raw, measured illumination (argyll -H mode), measured target (average of 3 measurements of the same target, argyll -H mode)

single illuminant DCP profile for measured illumination and measured target

converting the same raw with ACR using this profle

http://s14.postimg.org/y9noh3y8x/ccpp_3.jpg  ->



.

.


so calculated SSF are getting better, no ?

[torger]

Highly correlated spectra should not hurt DCamProf profiling as it's designed to deal with such cases, but on the other hand it will not help much either. They're handled as averaging a bunch of patches into one, unless you reduce the chromaticity grouping distance to zero then it will try to correct for each patch (and result will not be good).

DCamProf currently makes no use of a neutral step wedge (it sees it just a bunch of highly correlated spectra), as it assumes the target shot is linear. Not sure yet if that's a good idea. Shots with glare issues are certainly not linear, but I've thought that those cannot be well corrected anyway so better require a glare-free shot. Even with a target shot made with proper lighting in a dark room maybe there can be some residual glare than needs correction though, or if the spectrometer measurement suffers from glare one needs to correct the other way around. Not sure though if a simple spline curve lightness correction is relevant.

Interesting to know that 2.5D LUTs are used in repro work too, and yes when the lightness adjustment is spectrally flat is should indeed work out fine. If you like DCamProf can make 2D LUTs too by relaxing the L dimension maximally (say -l 1000,0 to make-profile).

[torger]

I've decided to make CAT enabled per default to the next version, as I think most users will expect the look of StdA and D65 differ slightly just like in real life. CATs are far from perfect but from what I've read and some tests I've made it does seem that they are less bad than just doing relighting when it comes to modeling actual appearance.

If you do a D50 profile there will be no CAT of course as it's not needed, and you can still force "color consistent mode" (religthing instead of CAT) which is a good idea if you're making a profile for copy work, or if you just prefer that look. Color consistent means that the profile will make the images look like shot under D50 regardless of calibration illuminant.

[AlterEgo]

I've decided to make CAT enabled per default to the next version, as I think most users will expect the look of StdA and D65 differ slightly just like in real life. CATs are far from perfect but from what I've read and some tests I've made it does seem that they are less bad than just doing relighting when it comes to modeling actual appearance.

If you do a D50 profile there will be no CAT of course as it's not needed, and you can still force "color consistent mode" (religthing instead of CAT) which is a good idea if you're making a profile for copy work, or if you just prefer that look. Color consistent means that the profile will make the images look like shot under D50 regardless of calibration illuminant.

'd be nice to have a detailed help section on that in the blog.

[torger]

'd be nice to have a detailed help section on that in the blog.

Yep I'm adding a new fat section on CAT and relighting in the docs to explain the various aspects around their use.

[Iliah]

For normal profiles I use grey step wedge only to check linearity and diagnose flare and glare. This is an important check, and important warning. Flare can't be effectively eliminated based on a tight group of neutral patches as it changes across the target; but border pattern on SG targets combined with the pair composed of the black and the white patches in the middle allows to have a TPS (I actually use 2 TPSs, one additive, and one multiplicative) to compensate for flare.

Practical recommendation was to use polarizing filters to eliminate the effect, but now it is abandoned as proper target design that includes the interleaved black and white patch pattern and math do a better (much better in fact) job.

[GWGill]

what I 'd love to have is to use argyll chartread to measure a target and then use txt2ti3 to combine raw rgb data with just spectral data from chartread output... w/o using text editors, etc...

Normally that's all done using scanin. It creates the RGB values from the image and combines it with the reference file. How do you happen to have RGB values not created this way ?

yes, I understand the origin how txt2ti3 was intended to be used, but

I'm reluctant to clutter txt2ti3 with more file formats to recognize that it needs. It's quite complex and hard to test as it is.

PS: and if the target measurements were not in 10nm (but for example like -H mode in 3.33x increments), why it is necessary to strip intermediate measurements from the source file and output only SPEC_380, SPEC_390, etc ?

Sorry, I'm not following you. What tool, input is what ?

[Iliah]

If you are comparing to CC24 reference, yes, it is getting better; the two sources of error as I see it are still incorrect estimation of red response in the blue part of the spectrum (may be something to do with the pigments in the target you measured) and some vail.

[GWGill]

I haven't found any standard name for "relighting transform", some call it "color signal prediction", but in most contexts people say just "CAT", which is confusing as all CATs are designed to predict corresponding colors (that is which tristumulus value to use to produce the same appearance), not predict which tristimulus value the same object will have under a new illuminant. Only if you assume that color constancy is 100% perfect they will be the same, and the current established CATs do not.

I can't agree - there is no reason to assume that being able to spectrally accurately re-light a scene is what human mechanisms of color constancy are striving for.  They are evolved mechanisms that are useful to us, that bear the same resemblance to re-lighting as any 3-channel white balancing algorithms does.

[AlterEgo]

If you are comparing to CC24 reference, yes, it is getting better; the two sources of error as I see it are still incorrect estimation of red response in the blue part of the spectrum (may be something to do with the pigments in the target you measured) and some vail.

as a side note - making a target directly (not through SSF) is better, but with SSF you can can play around with extra options

here is when profile is built directly =



so

the two sources of error as I see it are still incorrect estimation of red response in the blue part of the spectrum (may be something to do with the pigments in the target you measured) and some vail.

I do have operator's errors indeed, still working out on how to shoot targets, but here (see above) I guess the matlab script and the algorithm of building SSF are to blame mostly, no ?

[Iliah]

I can't agree - there is no reason to assume that being able to spectrally accurately re-light a scene is what human mechanisms of color constancy are striving for.  They are evolved mechanisms that are useful to us, that bear the same resemblance to re-lighting as any 3-channel white balancing algorithms does.

The issue of "re-lightning" is mainly for Illum.A and D65 matrices that Adobe are using to estimate colour temperature and tint. Those matrices are not used anymore for calculation and presentation of colour. To estimate the CCT it is better to have spectral calculations when computing those matrices, not CAT.

[AlterEgo]

TPS

what is TPS ?

as proper target design that includes the interleaved black and white patch pattern and math do a better (much better in fact) job.

but then why not use an extra flat field (flare field) which is printed checkerboard ? and have 3 shots - target (averaged/bracketed), FF, CB

[GWGill]

>  haven't found any standard name for "relighting transform", some call it "color signal prediction", but in most contexts people say just "CAT"

Dr. Fairchild was using "spectral adaptation". I use sCAT as an abbreviation.

I don't think that's the same thing though.

As I understand it, "re-lighting" is creating a transform of XYZ/RGB values based on the change in values between spectral reflectance values viewed under two different illuminants.

Marks Fairchild's paper on spectral adaptation seems to be an approach to doing a white point change in spectral space, rather than tri-stimulus space. 

[ I confess that spurred by some of the discussions here, I contemplated a similar idea to that in Marks paper, based on the idea of taking the original illuminant or spectral emission values, dividing by the black body spectrum which has the source white point, and then multiplying by the black body spectrum which has the destination white point. This was based on the idea of a black body spectrum being the model of the "natural" spectral shape change with a change in color temperature. ]

[Iliah]

From comparing SSF vs. direct, seems SSF algorithm may need some further improvements; however it may be also something with the measurements, too. The direct transform looks not bad at all (on UK scale, same as "near excellent" in US).

[Iliah]

Flare needs to be estimated from the actual scene, as it is scene-dependent. TPS = thin plate spline.

[AlterEgo]

Normally that's all done using scanin. It creates the RGB values from the image and combines it with the reference file. How do you happen to have RGB values not created this way ?

I am using rawdigger to extract raw values and flatfield them... then I 'd like some automation to combine those with spectral data from chartread to be used further down the /potential/ workflow pipeline

I'm reluctant to clutter txt2ti3 with more file formats to recognize that it needs. It's quite complex and hard to test as it is.

but the issue is not with RD - the issue is that txt2ti3 treats its own (argyll) format differently !!! I have no issues to use txt2ti3 with RD and foreign formats... I want to use txt2ti3 with argyll chartread output... see the irony here ? the RD data is the same in both cases... you already recognize your own format - just make it possible to output the data which txt2ti3 currently does not output

Sorry, I'm not following you. What tool, input is what ?

chartread with -H outputs 3.3nm data... txt2ti3 when used with with such spectral data (mutated from chartead output into foreign format for the sole purpose of txt2ti3 being able to include spectral data in the output when combining  it with raw RGB) includes only 10nm steps... why no option to preserve 3.3x data ? I can certainly just use a text editor, etc... but again it will be easier to use less steps.

[AlterEgo]

Flare needs to be estimated from the actual scene, as it is scene-dependent.

but are we not estimating/correcting flare for the actual scene of shooting target for profile building - so that it will help with creating a profile too, no ?