DCamProf - a new camera profiling tool

[torger]

Just released 0.6.0 which now also can make ICC profiles in addition to DNG profiles (added make-icc, icc2json and json2icc commands). It's still limited for ICCs though as it can only make matrix-only ICCs (no LUT), and only for raw converters that feed linear data to the profile. That is no Capture One support yet, but RawTherapee and probably many other ICC-using raw converters out there should work.

[Bart_van_der_Wolf]

Just released 0.6.0 which now also can make ICC profiles in addition to DNG profiles (added make-icc, icc2json and json2icc commands). It's still limited for ICCs though as it can only make matrix-only ICCs (no LUT), and only for raw converters that feed linear data to the profile. That is no Capture One support yet, but RawTherapee and probably many other ICC-using raw converters out there should work.

Hi Anders,

Thanks. You did intend to take it a bit slower, catch a breath, and recuperate from the exhausting climb sofar, but I'm glad you didn't ...
Eagerly awaiting Capture One usable ICCs, but I'm patient (I know the next step is quite a bit more complex).

Cheers,
Bart

[AlterEgo]

Eagerly awaiting Capture One usable ICCs

matrix profiles are perfectly usable in C1 unless you want to use color editor, which requires LUT to be present there... tiff itself can be output from C1 instead of making it with dcraw (or similar)

[papa v2.0]

Hi everyone.
Interesting thread.
This may be of use to some.

Iain

[torger]

matrix profiles are perfectly usable in C1 unless you want to use color editor, which requires LUT to be present there... tiff itself can be output from C1 instead of making it with dcraw (or similar)

Capture One makes non-linear tiffs which DCamProf doesn't handle yet. DCamProf's matrix ICC doesn't have any shaper curves so input must be linear. I'll fix that eventually :-)

[AlterEgo]

Just released 0.6.0

to build with mingw I had to

1) procure arpa/inet.h - borrowed from matlab (as I have it already installed)

and

2) in profio.c

#include <pthread.h> - that fixes localtime_r ()


and borrowed the following code snippet from internet

static inline uint16_t
htons (x)
     uint16_t x;
{
#if BYTE_ORDER == BIG_ENDIAN
  return x;
#elif BYTE_ORDER == LITTLE_ENDIAN
  return __bswap_16 (x);
#else
# error "What kind of system is this?"
#endif
}

#define ntohs htons

static inline uint32_t
htonl (x)
     uint32_t x;
{
#if BYTE_ORDER == BIG_ENDIAN
  return x;
#elif BYTE_ORDER == LITTLE_ENDIAN
  return __bswap_32 (x);
#else
# error "What kind of system is this?"
#endif
}

#define ntohl htonl

[AlterEgo]

DCamProf's matrix ICC doesn't have any shaper curves so input must be linear. I'll fix that eventually :-)

but you can quickly put pure gamma trc tags, 1.8 is working for C1... instead of calculating some curve

[AlterEgo]

0.6.0 binaries for Windows build with mingw ( dcamprof.exe and libgomp_64-1.dll ) = https://app.box.com/s/6k6zw0suw3bkxrtqwmo6cl1pzrg2zp19

[torger]

Thanks for windows info, shall update to make easier to compile again to next release.

I guess the ntohl/ntohs etc should work if you include <winsock2.h> instead of <arpa/inet.h>? I'll make an ifdef for that.

[torger]

but you can quickly put pure gamma trc tags, 1.8 is working for C1... instead of calculating some curve

I think I need to look at the TIFFTAG_TRANSFERFUNCTION tag which since C1 6 (or 7?) is included in the exported TIFF. It's not a pure 1.8 curve.

[AlterEgo]

Thanks for windows info, shall update to make easier to compile again to next release.

I guess the ntohl/ntohs etc should work if you include <winsock2.h>?

removing code snippet and replacing with <winsock2.h> results in linker errors

 undefined reference to `__imp_ntohl'
 undefined reference to `__imp_ntohs'

so you need to add some extra libraries then

[AlterEgo]

I think I need to look at the TIFFTAG_TRANSFERFUNCTION tag which since C1 6 (or 7?) is included in the exported TIFF. It's not a pure 1.8 curve.

yes, that tag was mentioned somewhere here by some P1 employee, but gamma = 1.8 still works OK meanwhile - may be not for purists though...

[torger]

removing code snippet results in linker errors

 undefined reference to `__imp_ntohl'
 undefined reference to `__imp_ntohs'

so you need to add some extra libraries then

Uhh... I'll see, maybe I'll remove the swap dependencies to next version it's easy for me to do.

[Bart_van_der_Wolf]

I think I need to look at the TIFFTAG_TRANSFERFUNCTION tag which since C1 6 (or 7?) is included in the exported TIFF. It's not a pure 1.8 curve.

FWIW, attached is how the Green TRC of the default Capture One profile for the EOS 1DS Mark III profile looks. Definitely not a simple gamma, and the C parameter of a curve fit is closer to 1/1.942.... So maybe something like that can be found back in the TIFF's metadata tags if saved with Camera profile.

Cheers,
Bart

[AlterEgo]

here is for example rawdigger/makeinputicc argyll frontend (so w/o tiff generated by C1 - albeit you can perfectly convert C1 tiff to DNG and feed to the same workflow, just don't WB samples when exporting to CGATS file and set black level = 0 in RD) with g1.8 vs (where is which profile ?) C1 v8.2 with Sony A7 "Standard" profile... I am not advocating g = ~1.8, I am just saying that meanwhile  you can live with it.... PS: profile was built using printed IT8 target illuminated by halogen light not filtered up to D50 (I did not have filters handy) by the way...

[Alexey.Danilchenko]

removing code snippet and replacing with <winsock2.h> results in linker errors

 undefined reference to `__imp_ntohl'
 undefined reference to `__imp_ntohs'

so you need to add some extra libraries then

Winsock is a library, simple include does not make it. I guess a separate makefile for mingw is needed.

[AlterEgo]

Winsock is a library, simple include does not make it. I guess a separate makefile for mingw is needed.

including the code to define the functions for mingw build works OK I guess....

[AlterEgo]

Here's attached a few patches from canon pigment lucia ink on oba-free baryta paper, CC24 spectra, some real reflectance spectra from nordic nature (leaves, flowers etc), and finally some patches from IT8 Faust spectra provided by AlterEgo.

also QP202 spectral (with i1pro2 and with colormunki) = https://app.box.com/s/un6liz50nrkpn59aem0gnrg7395wbear

[torger]

FWIW, attached is how the Green TRC of the default Capture One profile for the EOS 1DS Mark III profile looks. Definitely not a simple gamma, and the C parameter of a curve fit is closer to 1/1.942.... So maybe something like that can be found back in the TIFF's metadata tags if saved with Camera profile.

I don't think the TRC curves of the LUT profiles say that much, if I've understood things correctly they are not even used at all in terms of camera profiling. As far as I know if you have an A2B0 LUT the *TRC and *XYZ tags are ignored, as there is both input curves and matrix in the LUT A2B0 tag itself.

And in that case the input curve may only be there to make a mapping trick to get better integer precision (ICCv2 is an old format integer math unfortunately) and the LUT itself may cancel out that curve and apply something new, which you can't see without putting data through the profile. In other words, it's not possible to use an ICC viewer and that way figure out which pre-processing C1 does. I think the TIFFTAG_TRANSFERFUNCTION in the exported profiling TIF is the thing to look for, looking into that now.

Those TRC curves also show an inverted curve, like you say 1/1.942 when a matrix profile actually needs ~1.8 to linearize, so they really doesn't make any sense to me.

The ICCv2 standard show two types of input profiles 1) XYZ+TRC tags (matrix plus shaper curves), 2) A2B0 only. The mix of both 1&2 is some non-standard stuff by Capture One as far as I understand, which may be because they are used both as camera profiles and can also be attached to a TIFF file just like sRGB.icm or AdobeRGB.icm.

If any ICC guru knows how it all fits together, please let me know...

[ErikKaffehr]

Hi Tim,

I tried to your advice, but this is a season to taste thing.

BTW, those mountain images were all with the Sonys. No P45+ image made it to the wall. I don't know why. I have just had it for something like 22 months, so that matters. Also, I didn't use it on the workshop, for different reasons.

I am going to look into your recommendations, they are much appreciated.

Best regards
Erik

From the excellent looking images I've seen of your work off the P45+, Erik, I've noticed they do come off as having a slight green (more like an ashen blueish green) bias with a light hand on saturation. Remember my suggestion of applying a luminance/saturation increase with Hue/Sat tool in Photoshop on your gallery exhibit image of the sunlit green knoll with the background mountains you linked to in the LuLa Coffee Corner forum?

For me adaptation working too long on a landscape with a magenta-ish blue sky (cobalt blue has a magenta element) requires constant retweaking of WB to get the right looking green. I do know from years of examining sunlit green plants that the sunlit portion of a non-waxy, midtone green leaf/grass does have a yellowish bias, but ACR/LR's exact hue that makes it look right requires very gradual adjusts due to the cyan portion of the green that can make shadows appear too cool which invokes the adaptive effect of seeing green highlights as warm or a thalo green.

To filter this cyan requires moving toward magenta which slightly warms up green highlights but with a much different hue. I would never let my custom DNG profile fix this because it made the greens look a slightly dull yellowish orange green. And I didn't like moving temp slider toward blue because it desaturates everything.

After a long WB edit with ACR4.4 profile I'ld walk away and come back to see I'ld made everything too green because I kept trying to get the cyan in the green tint slider to freshen up the green. So I went back to As Shot WB (returned tweaked 0 back to +6 to +10 toward magenta), selected the custom DNG profile, walked away, took a break, came back and it looked perfect. Hue changes applying the custom DNG profile is so subtle in warming up the greens that I never considered how much WB affects the overall perception of color cast. I think one has to consider color constancy in the mix of things rather than attributing it to metamerism.

I mean I had trouble getting the right green hue shooting Live Oak trees that I did a google image search and found WB and greens all over the map...

https://www.google.com/search?newwindow=1&hl=en&site=imghp&tbm=isch&source=hp&biw=1556&bih=941&q=live+oak+in+texas&oq=live+oak+in+texas&gs_l=img.3..0i8i30l2j0i24.3707.9093.0.9964.17.16.0.1.1.0.114.1335.15j1.16.0.msedr...0...1ac.1.64.img..0.17.1334.aZKWyeTORI4

None of them are correct looking.