Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: professorbalrog on September 03, 2015, 12:45:20 pm
-
Would any of you who are smarter than me using Argyll and DCamProf on a Mac be willing to help me out with it, or point me in the right direction? I'm not at all scared of command-line utilities but I feel like I have no idea how to even get these to compile correctly. I was able to get Argyll to run the scanin command based on the instructions I found here (and after moving the chart reference files to the bin folder):
http://www.trumpetpower.com/photos/Exposure#Normalizing_exposure
But that's about it. DCamProf's instructions say "It should also be relatively easy to build on Mac OS X". I have no idea what to do with that information :/ All I want to do is generate a profile that's roughly as accurate as what the X-rite software can create for use in ACR but one that I can use in Capture One instead (so, ICC right?). I don't need to build a custom target or anything crazy (yet) just the most basic of camera calibrations.
Help? Please?
-
I'll add a ditto. I gave up on that other DcamProf thread. Too much effort, too much noise. Been waiting to see if anyone is willing to commercialize it. Also been waiting for someone to show the benefits - side by side comparisons?
I've always been curious why there has been relatively no improvement in camera profiling in years. Xrite is still on version 1 after several years. Adobe DNGPE is also mostly unchanged since initial release. And no camera makers offer a product, which is strange.
I assume the market for camera profiling is just too small. Looks like there are only about 15 people in the original DcamProf thread. There may be a few hundred, maybe even a thousand others out there who are potential users/customers.
-
Would any of you who are smarter than me using Argyll and DCamProf on a Mac be willing to help me out with it, or point me in the right direction? I'm not at all scared of command-line utilities but I feel like I have no idea how to even get these to compile correctly.
ask for a build in the main topic = I share my builds for Windows : 0.9.4 build for Windows (mingw = dcamprof.exe + libgomp_64-1.dll + HTML & PDF manual / = copy of Torger's web page and the same converted to PDF /) : https://app.box.com/s/hxy4q0rzi59jhxdv4aqrefl5gd1p8xu1
somebody likewise can share for OSX
-
Too much effort
no pain no gain, no ?
-
I'll tell 'em you sent me. Thanks!
-
I've just released a tutorial of how to use DCamProf to make a camera profile:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html
I don't know if it can be called "DCamProf for dummies", as it's a quite comprehensive workflow, but it should make it easier to get into profiling than having only the reference documentation.
Concerning binaries I personally don't make or link them currently as I'm too lazy to maintain that. As seen there's some really helpful people in this forum though that makes builds.
When DCamProf reaches version 1.0 "general availability" I might make builds available directly on the home page. It's at version 0.9.5 now and I'm quite satisfied with the feature set, so I think it's really close to 1.0 now.
-
Awesome, thanks so much!! Really appreciate all the effort you've put into doing this. Looking forward to where you take it next
-
Would any of you who are smarter than me using Argyll and DCamProf on a Mac be willing to help me out with it, or point me in the right direction? I'm not at all scared of command-line utilities but I feel like I have no idea how to even get these to compile correctly. I was able to get Argyll to run the scanin command based on the instructions I found here (and after moving the chart reference files to the bin folder):
http://www.trumpetpower.com/photos/Exposure#Normalizing_exposure
But that's about it. DCamProf's instructions say "It should also be relatively easy to build on Mac OS X". I have no idea what to do with that information :/ All I want to do is generate a profile that's roughly as accurate as what the X-rite software can create for use in ACR but one that I can use in Capture One instead (so, ICC right?). I don't need to build a custom target or anything crazy (yet) just the most basic of camera calibrations.
Help? Please?
I've been in the same boat recently. Over on the Capture One forum they started a thread about C1's colors and using dcamprof for C1. I tried for the first time to use dcamprof (never heard of it before) to make a profile for C1 to be used with a Sony NEX-6. Fortunately, there is spectral data for a Nex-5 so I don't need a test target (I don't have any equipment to measure colors). My first attempts were quite promising and improved the C1 colors a lot. Unlike what you read in many forums the C1 colors for Sony are actually pretty bad. Everything's got a red/brown tint so much so that I don't like to use it. The colors from the out of camera jpegs are much better and closer to reality. I am not alone with this. See the thread at the C1 forum here: http://forum.phaseone.com/En/viewtopic.php?f=57&t=20609&sid=1f4cb522e0e7f561246906b1061f1fa4 (http://forum.phaseone.com/En/viewtopic.php?f=57&t=20609&sid=1f4cb522e0e7f561246906b1061f1fa4)
I asked questions there concerning dcamprof as this other 40+ page thread here in the forum and the instructions are simply inpenetrable for a newbee.
Now the bad thing is I can't get the profile I made work with real images. The colors are much better than anything C1 otherwise produces but the brightest parts get a red tint. Also the colors shift if I change brightness in C1. Has anyone any ideas what might have happened? This is the list of commands I used:
dcamprof make-target -c nex5.json -p cc24 target.ti3
dcamprof make-target -X -f linear_DSC04159_C11.tif -p target.ti3 new-target.ti3
dcamprof make-profile -c nex5.json new-target.ti3 profile.json
dcamprof tiff-tf -f linear_DSC04159_C11.tif auto_DSC04159_C11.tif tone-curve.json
dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json profile.json prelim-profile.icm
cp prelim-profile.icm /c/Users/michael/AppData/Local/CaptureOne/Color\ Profiles/
The tif files I used are from some random picture I took and exported from C1 as 16bit tiff, with embedded camera profile, the "no color correction" profile in C1 and with either linear or automatic tone curve (as indicated in the names above).
I'd be grateful if someone could tell me what I did wrong. If desired I could show examples or more verbose reports.
I'd really like to get correct colors from C1.
And considering building dcamprof: I use Windows with cygwin. There it is quite straightforward. You need to have libcms2 installed via cygwin's setup.exe first. Then you unpack the dcamporf source and remove -fopenmp in the Makefile just as the instructions say. Then simply make and you are done. Leaves a dcamprof.exe in the build directory. Move to /usr/local/bin/ or anything in your path, just standard Unix stuff.
Michael
-
no pain no gain, no ?
I see the pain, I don't see the gain. Maybe it's in that long thread somewhere?
Show me some images to compare. One converted with Adobe Standard, one with an Adobe DNGPE custom profile, maybe one with Xrite custom profile, and then one with DCamProf. Point out the differences and why one is better than another.
Maybe consider a service? I'll send you raw images of a 24 patch CC and $$. You send me profiles? Put a price on it.
-
Looking forward to seeing a side by side comparison with image samples between applying a DCamProf profile versus regular DNG profile method we've all been using with the CC chart Wizard or Xrite's CC Passport software.
Over 30K views on that long thread shows there's quite a few folks who would want to see this.
-
I see the pain, I don't see the gain. Maybe it's in that long thread somewhere?
it depends on your definition of the gain - for me it was just the ability to approximate SSF/CMF for my camera and use that so that I can build a sufficiently neutral (sufficiently for me) reproduction-type kind of profile - nothing fancy, film-like or exotic... now if I am not getting any color sufficiently right for my liking after that starting point so to say then I know whom to blame and no that's not Adobe's of PhaseOne's profiles :D ... so what kind of gain you were/are expecting ?
-
There are a few pictures in the tutorial document:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html
And actually there are a few in the DCamProf reference documentation too:
http://www.ludd.ltu.se/~torger/dcamprof.html#tone_curves
You need a good screen, preferably calibrated, to be able to see differences well.
This is free open-source software so I'm not really into selling anything at this point. Those that want improvement and control over their colors will find the software. I do have some motivational speak in the tutorial introduction though:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#why_own_profile
The difference between a custom camera profile and a bundled one is typically smaller than the difference between a custom printer profile and a manufacturer-provided. So one could say it's for "fine tasters" or "perfectionists" or "control freaks" or what you want to call us. I would say that it's "more pain than gain" for the majority of users, especially since camera profiling is a quite difficult task. It's much easier to make profiles for your printer or your screen.
It's very easy to show that Adobe Camera Raw have issues with color accuracy, just as Capture One. Those are the two reference converters I've looked at for DNG processing and ICC processing. It's not that they can't make profiles, it's just their design choice to apply strong looks. Raw converters today in a way simulate film photography and the profile is the film roll, complete with a contrast curve and a look. There is no raw converter today (at least among the big names) that do color the "scientific" way with a scene-referred colorimetric base profile and then do all the appearance modeling separate from the profile. To work with the current raw converters the profile must contain appearance modeling itself.
The question is then why would you want the manufacturer apply their look, when you can be in control of that yourself? I've been in contact with people that have big issues when they've changed camera brands because they can't really replicate the look they want any longer, as they became dependent on the look provided by their old brand. If you always do your own profiles that won't happen.
If you like to, DCamProf allows you to do your own subjective adjustments to the profile. This is the hardest part and does require that you have a decent eye for color, but it can be quite rewarding. The tutorial contains some guidelines of how to work.
I've used digital medium format a few years, and in that segment it's very clear how important well-designed profiles with refined looks are. Most users think it's all about their sensors, but really most MFD sensors are by today's measure mid range performance, but the profiles are really well-designed (and perhaps more importantly matching the taste of MFD users). I've been most impressed with Hasselblad which stay very close to a neutral realistic look, and that is how I make my own profiles using DCamProf.
DCamProf is mainly about making general-purpose profiles, that is one with a curve embedded. In that case there is no such thing as an objectively "better" profile, there are no established models for measuring that. It's all judged by eye. Sure I think my profile for my Hassy even exceeds Hassy's own, but that's because I've designed the profile along my taste. I'm sure there are users that prefer Hassy's look. If you have confidence in your own taste it can be very rewarding to make your own profile because then I'm quite sure you can exceed the quality of anything available at the market.
Still the differences will typically be subtle. If someone swaps the profile while I'm not looking on an image I haven't seen the original scene etc, I will probably not detect it. One part of having a custom profile is simply getting confidence in that you get sane color out of your camera.
When it comes to comparing various profiling software, in addition to looking at the image result you can simply look at the feature set and also disassemble the resulting profiles (for example by using DCamProf's dcp2json command). Few allows you to adjust contrast curve, few have an appropriate color appearance modeling to compensate for curve effects, few have flatfield correction and instead simply apply heavy smoothing or just ignore lightness axis, many have very coarse LUTs etc. The manufacturers don't use the consumer packages when they make profiles, they have their own in-house tools.
Comparing the results by eye only on unknown images is a little bit dangerous, as you don't know what you're looking at, you have no reference. For a particular image you may very well end up liking a matrix-only profile with a RGB curve on top the most. You should look at images you know, preferably ones you have very recently shot yourself, and you should have an idea of how you like colors to be reproduced.
I've written a guide of how to profile your screen, and then how to profile your printer. Then in February/March this year I was about to write the final article, that on how to profile your camera. Then I discovered that there actually were no software that could do it properly, so I had to write my own. I naively assumed it would be a quick hack job, but here I am six months and 20000 lines of code later.
-
I'd be grateful if someone could tell me what I did wrong. If desired I could show examples or more verbose reports.
I introduced some important fixes of the ICC LUT generation in 0.9.4 so if you didn't use the latest version, please re-run with the new.
Capture One is pretty messy to make a profile for, much more difficult than a DNG profile. What makes C1 difficult is the built-in pre-processing so the profile don't see the "raw" data.
The key to make a profile is that you need to have the RGB values the profile will be fed with, together with the XYZ reference values they correspond to. With DNG profiles the profile will see the "raw" data, which means that you can generate the RGB values from camera SSF. With Capture One you can't do that because they apply pre-processing.
I see what you try to do, the "dcamprof make-target -X -f linear_DSC04159_C11.tif -p target.ti3 new-target.ti3" does cancel out the curve preprocessing, but there is typically more, probably some pre-matrixing. This seems to differ between models, so maybe your model is without pre-matrixing, I don't know. The cameras I've tested in Capture One has some pretty heavy pre-matrixing which makes it impossible to make profiles from camera SSF. EDIT: the make-target -X .... command makes no sense in your workflow as we start with SSF, see post further down.
If one could find out the matrix (and any other additional pre-processing if any) one could revert that as well just as the curve, but DCamProf currently has no such functionality. It would require some more reverse-engineering work of C1. DCamProf can revert the curve so it can process color checker shots produced by C1, but you can't use SSFs, unfortunately. Unless your particular camera doesn't receive any pre-matrixing. The typical result if there is pre-matrixing is that your SSF profile will be over-saturated, colors can look sort of right anyway as whitepoint will be correct etc.
I suspect that the matrix embedded in many of the Lab-LUT ICC profiles C1 have actually is the pre-matrix, but I haven't verified if that is the case. Having a matrix in the profile makes no sense as only the LUT will be used, so I've figured that it's there for some sort of informational purpose. I've noted that many of the newer profiles don't have any matrix embedded, and when generating a new profile you don't need to include the matrix, so it's hard-coded. If the newer profiles don't apply any pre-matrixing or if they only do hard-coded I don't know. If the matrix is only hard-coded in C1 it will of course be very difficult for DCamProf to get it.
If anyone reading this knows anything about C1's pre-matrixing, please let us know. If it really is only a pre-matrix and it possible to figure out what it is, I'll gladly implement the feature in DCamProf. Reverse-engineering C1 is not my favorite task though, it's pretty frustrating spending a lot of time figuring out one specific software's inner workings just because there is no standard. The DNG pipeline is at least pretty well documented and has published open source reference code.
The problems you mention "the colors are much better than anything C1 otherwise produces but the brightest parts get a red tint. Also the colors shift if I change brightness in C1" indicate some other issue though, possibly a bug in the LUT creation. It would be interesting to further investigate that. If you haven't generated your ICC with the latest version, please generate it again, and if the problem remains I'd love to see the profile so I can debug the problem.
-
Sony NEX-6.
I just looked at the bundled Capture One Sony Nex-6 profile, it does not have any matrix elements in it, unlike for example P45+ profile (which I know has pretty strong pre-matrixing). If we're lucky this means that there is no pre-matrixing for Sony NEX-6, and thus reverting the curves would be all needed to make it work in your SSF workflow. If we're not lucky here is some hard-coded pre-matrixing or even worse some other non-linear pre-processing in addition to the curves which means we can't use SSF.
You can try make a profile without a curve first. If the colors seem to look right, the SSF workflow is hopefully working for this camera.
I'd recommend that you also try making a profile the traditional way. If your tint/shift issues disappear when making it the traditional way, there's probably some issue with matching actual camera raw values (as generated by the SSF processing) with the pre-processing C1 does. You're probably the first user that makes a SSF-based profile for C1, I haven't done it myself :).
If you don't have a CC24 target, you can download and process this shot in C1. Follow the work-flow described in the DCamProf reference doc. Use the CC24 target, as the CCSG target in this shot is full of glare.
http://www.imaging-resource.com/PRODS/sony-nex-6/NEX6hVFAI00100.ARW.HTM
-
If we assume that C1 doesn't do any more pre-processing than the curve so we could use SSF processing, then you should do like this:
* dcamprof make-target -c nex5.json -p cc24 target.ti3
now we have a target.ti3 that contains linear raw RGB values simulated from the SSF curves, using D50 illuminant and reflectance spectra from the CC24 target, and the corresponding XYZ reference values. This is all DCamProf needs to make a profile.
We don't need to do the linearization step since we get linear data directly when we do it from SSF rather than getting values from C1.
* dcamprof make-profile new-target.ti3 profile.json
Now we have a profile, that can be converted to both a DNG and ICC. The key to remember here is that in order for DCamProf to generate a profile it must have the true linear raw RGB values, and when we use SSF we get that directly.
From here you go on with the C1-specific stuff, described at http://www.ludd.ltu.se/~torger/dcamprof.html#workflow_icc_c1 :
* dcamprof tiff-tf -f linear_DSC04159_C11.tif auto_DSC04159_C11.tif tone-curve.json (extract the tone curve)
* dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json profile.json prelim-profile.icm (make preliminary profile)
* cp prelim-profile.icm /c/Users/michael/AppData/Local/CaptureOne/Color\ Profiles/
* run C1 and design the modifier curve, put it in modifier-curve.json
* dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json -t modifier-curve.json profile.json profile.icc (make final profile with modifier curve)
Your described workflow happens to work anyway because dcamprof make-profile -c nex5.json new-target.ti3 profile.json will overwrite the existing RGB values with new generated from the SSF (since "-c nex5.json" is provided), so the incorrect values generated in the dcamprof make-target -X -f linear_DSC04159_C11.tif -p target.ti3 new-target.ti3 are replaced. That step should only be performed when target.ti3's RGB values come from C1 directly (and are thus non-linear), not from SSF (which are linear).
-
Did some quick look at a number of C1 profiles. Some have a matrix embedded, some have not. The matrix is always the same. If we compare IQ260 (has matrix) and IQ280 (no matrix) which have roughly the same color response we can conclude that they use the same pre-processing. Did some quick tests by preprocessing with the matrix, no sane result. So I have no idea what that matrix is for.
-
Added a "for dummies" section :-), a way to make a perfectly okay profile without having to make any manual stuff, not even shooting anything if your camera is represented on Imaging Resource for example:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way
-
OK so emphasis on the dummy over here...I'm making progress here but when I try to run step 4 (as far as I've gotten) in the ICC profile instructions, i get this error:
dyld: Library not loaded: /opt/local/lib/liblcms2.2.dylib
Referenced from: /Applications/Argyll_V1.8.0/bin/dcamprof
Reason: image not found
Trace/BPT trap: 5
I exported from Capture one (following your directions) so I assume this step is necessary...I'm so close...I tried downloading little cms and executing the configure file but i guess that doesn't work? so close.....
-
OK so emphasis on the dummy over here...I'm making progress here but when I try to run step 4 (as far as I've gotten) in the ICC profile instructions, i get this error:
dyld: Library not loaded: /opt/local/lib/liblcms2.2.dylib
Referenced from: /Applications/Argyll_V1.8.0/bin/dcamprof
Reason: image not found
Trace/BPT trap: 5
I exported from Capture one (following your directions) so I assume this step is necessary...I'm so close...I tried downloading little cms and executing the configure file but i guess that doesn't work? so close.....
you probably better off asking the author of the OSX build (Iliah) in the main dcamprof topic here...
-
Added "the easy way" for Capture One users. The same workflow as in the reference doc, but with finished relax recipe and described with some more words:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way_c1
-
OK so emphasis on the dummy over here...I'm making progress here but when I try to run step 4 (as far as I've gotten) in the ICC profile instructions, i get this error:
dyld: Library not loaded: /opt/local/lib/liblcms2.2.dylib
Referenced from: /Applications/Argyll_V1.8.0/bin/dcamprof
Reason: image not found
Trace/BPT trap: 5
I exported from Capture one (following your directions) so I assume this step is necessary...I'm so close...I tried downloading little cms and executing the configure file but i guess that doesn't work? so close.....
Regarding all that, here is what is happening. Whoever built dcamprof had littlecms installed in /opt/local/.... That tells me that he used something like the Mac 'port' system (that lets you build all sorts of open source software for the odd OSX environment. LittleCMS naturally
installs itself in the more 'common' place of '/usr/local/....'
Simply running the 'configure' script isn't going to do much for you. It just runs a bunch of tests and configures the build/compile process. You still ahve to run the compiler which you CANT unless you have the free Apple Developer membership (which gives you access to the 'command line developer toolset' (ie. compiler & linker).
For *maximum* portability, the person who compiled dcamprof should have compiled it *statically* (ie. no dependencies on external libraries)
Be that as it may, here is a Dropbox link to the liblcms library that is missing...........
https://www.dropbox.com/s/hl9zdnqpoeq3uvf/liblcms2.2.dylib?dl=0
download it and then create a folder (if it doesn't already exist on your machine which it probably doesn't) /opt/local/lib
then copy the liblcms.2.2.dylib to that new folder. You will probably be asked to authorize (ie. your password) to do it.
After that, your copy of dcamprof should run.
I just read the beginning part of the thread so HERE IS WHAT YOU'RE LOOKING FOR
because I have no life, here is a just freshly compiled version (0.9.5) of dcamprof that is fully static (no external library dependencies) and compiled for Mac OSX (which doesn't support openmp so it will be a bit slower) (my machine runs 10.10 so don't ask me for others (maybe 10.9 is possible if there is beer involved :D )
https://www.dropbox.com/s/t86pvyrfl78512r/dcamprof-static?dl=0
-
because I have no life, here is a just freshly compiled version (0.9.5) of dcamprof that is fully static (no external library dependencies) and compiled for Mac OSX (which doesn't support openmp so it will be a bit slower) (my machine runs 10.10 so don't ask me for others (maybe 10.9 is possible if there is beer involved :D )
https://www.dropbox.com/s/t86pvyrfl78512r/dcamprof-static?dl=0
ha what do you think I was doing on a Friday night? Yeah...trying to make profiles. I actually was able to figure it out by using homebrew to install all the dependencies that were missing, I wish someone had mentioned that as an option because it's SUPER easy to get argyll and lcms up and running with homebrew. On the plus side, next time something like this comes around I'll have a half-idea what the hell I'm doing.
I'll be taking your compiled version to my poor work computer next week that has libraries from all this stuff in about 30 different folders. whoops. Thanks dude!!!
-
Added "the easy way" for Capture One users. The same workflow as in the reference doc, but with finished relax recipe and described with some more words:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way_c1
finally got everything running properly, thanks to this...
you're my hero. this just made my whole weekend!!!
-
Thanks a lot for your reply. So I wasn't completely off base with what I did. Good to know.
I introduced some important fixes of the ICC LUT generation in 0.9.4 so if you didn't use the latest version, please re-run with the new.
I did and the result is almost perfect. The hue shifting is gone, colors look perfect. I did both methods, from ssf and the target you suggested in one of the later replies. The results are almost identical. This what I did with the ssf:
../dcamprof make-target -c nex5.json -p cc24 target.ti3
../dcamprof make-profile target.ti3 profile.json
../dcamprof tiff-tf -f linear_DSC04159_C11.tif auto_DSC04159_C11.tif tone-curve.json
../dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json profile.json prelim-profile.icm
But here's the catch: When I use the prelim-profile there is still a problem at the low end in the shadows. The shadows are too bright and I can't fix them with the curve. If I try I get artifacts with colored seams in the dark areas and other strange behavior. I suppose there is still a linearity problem similar to what we had at the bright end. Do you have any idea? I've put the profile here: https://www.dropbox.com/s/06q08jya3yyk0o1/prelim-0.9.4a-profile.icm?dl=0 (https://www.dropbox.com/s/06q08jya3yyk0o1/prelim-0.9.4a-profile.icm?dl=0)
This is really promising and I hope this last problem can be ironed out. Thank you very much.
-
But here's the catch: When I use the prelim-profile there is still a problem at the low end in the shadows. The shadows are too bright and I can't fix them with the curve. If I try I get artifacts with colored seams in the dark areas and other strange behavior. I suppose there is still a linearity problem similar to what we had at the bright end. Do you have any idea?
Same here with the brightness in the shadows. The improvement in color is SO significant that this is trivial in comparison, but that's the only flaw I can see so far. Also it seems like C1's profiles allow you to make some pretty extreme adjustments to the levels without any serious stepping/posterization but with the custom profile it doesn't seem to tolerate huge adjustments. Again though, I am literally bouncing off the walls at how much better the color is with this method.
-
I did both methods, from ssf and the target you suggested in one of the later replies. The results are almost identical.
This indicates that there's indeed no pre-matrixing done for that camera model, so SSF is working. In my testing I've worked with P45+ files, and those are pre-matrixed, but perhaps it's a thing they only did with a few older models. Let's hope that.
-
I've put the profile here
I've looked at the profile and I can confirm that there is issues with low end shadows. I don't know what the reason is though. I need to replicate the workflow and debug step by step.
EDIT: just managed to replicate shadow issues with a very basic ICC workflow, so consider the too light shadows and other strange effects in that range a bug. You have to live with it for now. I'll start working on a fix, but it may be complicated so it may take a while. We'll see.
-
Found and fixed the bug, v0.9.6 is out now.
The shadow problem should be gone in that version.
The profile will still be less "stable" concerning extreme adjustments than the typical native C1 profile. I think this is because the C1 profiles make some gamut rolloff just to make the profile more robust, but does as as side effect reduce color accuracy for high saturation colors. DCamProf will try to reproduce colors as accurately as possible to the end of the gamut and then just hard-clip, and I think that is what may make it less robust.
Rolling off the gamut in the ICC LUT has been proven to be quite difficult, and I'm not sure yet if it's valuable. Please test and report back. If the C1 profiles is only behaving nicer on super-crazy settings like a white balance that make the image turn all blue and things like that, then I think DCamProf's LUTs can stay the way they are. But if posterization or other strange effects arise within the normal range of adjustments, then it should be fixed of course.
In my own photography I use DNG profiles and RawTherapee on Linux, so the ICC+C1 use case doesn't see much testing from myself, so I appreciate bug reporting.
-
Found and fixed the bug, v0.9.6 is out now.
The shadow problem should be gone in that version.
Unfortunately, it isn't. There is almost no difference. I tried it with the ssf in case that matters. Here is the profile again:
https://www.dropbox.com/s/s7sfujjobcbvp71/prelim-0.9.6-profile.icm?dl=0 (https://www.dropbox.com/s/s7sfujjobcbvp71/prelim-0.9.6-profile.icm?dl=0)
As it is the profile is unfortunately not usable yet. If you want I could upload pictures showing the effect.
-
Unfortunately, it isn't. There is almost no difference. I tried it with the ssf in case that matters. Here is the profile again:
https://www.dropbox.com/s/s7sfujjobcbvp71/prelim-0.9.6-profile.icm?dl=0 (https://www.dropbox.com/s/s7sfujjobcbvp71/prelim-0.9.6-profile.icm?dl=0)
As it is the profile is unfortunately not usable yet. If you want I could upload pictures showing the effect.
If you can upload your target.ti3 you run make-profile on it would be nice.
Can you try add -o standard to make-icc command line? It will disable the neutral tone reproduction operator (and affect color appearance negatively), but if the strange shadow stuff disappears I at least know it's related to the tone reproduction:
../dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json -o standard profile.json prelim-profile.icm
-
The profiles 0.9.4a and 0.9.6 are exactly the same, except the timestamp. Could you double-check that you're running dcamprof 0.9.6 and not the old version?
-
If you can upload your target.ti3 you run make-profile on it would be nice.
Here it is: https://www.dropbox.com/s/11bhqdqyqtp6152/target.ti3?dl=0 (https://www.dropbox.com/s/11bhqdqyqtp6152/target.ti3?dl=0)
Can you try add -o standard to make-icc command line? It will disable the neutral tone reproduction operator (and affect color appearance negatively), but if the strange shadow stuff disappears I at least know it's related to the tone reproduction:
../dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json -o standard profile.json prelim-profile.icm
No that has almost no influence. FWIW, 0.9.3 did not have this problem.
-
Here it is: https://www.dropbox.com/s/11bhqdqyqtp6152/target.ti3?dl=0 (https://www.dropbox.com/s/11bhqdqyqtp6152/target.ti3?dl=0)
No that has almost no influence. FWIW, 0.9.3 did not have this problem.
I tested to run you commands (although with tiffs coming from a P45+) with 0.9.5 - got shadow issues, and then 0.9.6, got no shadow issues. That is I get no problem. If I can't reproduce the problem, I can't debug it. I guess I need the other files too then so I can run the exact same commands with the exact same data. When it comes to fixing bugs it's more common than not that one ends up needing all data to reproduce the bug, so as a rule of thumb providing all input files is good.
0.9.3 had a completely different LUT generator, but it had some other issues.
I'll go to bed now, but will look in the morning, but I need the rest of the files to be able to debug further.
-
I tested to run you commands (although with tiffs coming from a P45+) with 0.9.5 - got shadow issues, and then 0.9.6, got no shadow issues. That is I get no problem. If I can't reproduce the problem, I can't debug it. I guess I need the other files too then so I can run the exact same commands with the exact same data. When it comes to fixing bugs it's more common than not that one ends up needing all data to reproduce the bug, so as a rule of thumb providing all input files is good.
Thanks a lot. Here's the data: https://www.dropbox.com/sh/pwx90uiyu40mbox/AACm9z2-_S0iRfvpPZhHuS9Ga?dl=0 (https://www.dropbox.com/sh/pwx90uiyu40mbox/AACm9z2-_S0iRfvpPZhHuS9Ga?dl=0) The doit.new is the script I used.
The DSC0963* files are just to illustrate what you end up with. The _C1 is stock Capture One export.
I'll go to bed now, but will look in the morning, but I need the rest of the files to be able to debug further.
So do I. see you tomorrow.
-
The DSC0963* files are just to illustrate what you end up with. The _C1 is stock Capture One export.
It would be great if you could lend me that test file with all those black shadows, I don't have many of those kind laying around.
-
Tested the workflow, I don't get the same result. I suspect that your 0.9.6 build actually is an older. Can you run dcamprof without parameters and see what the first line it outputs is? It should say "DCamProf v0.9.6 - a digital camera profiling tool."
I've attached the profile I get when running your script. Let us know if it works better.
-
my Dropbox link to a Mac OSX compiled version of dcamprof-static has been updated to v0.9.6
-
The guide seems to recommend filtered halogen lamps for the D50 illuminant and don't say much about studio strobes. Any reason not to use them for creating ICC profiles ?
-
The guide seems to recommend filtered halogen lamps for the D50 illuminant and don't say much about studio strobes. Any reason not to use them for creating ICC profiles ?
Studio strobes are good, very good spectrum. The light temperature can vary a bit shot to shot but I can't really figure out any case where that would be a real problem in practice.
Studio strobes often light up a lot around the target so you may possibly get more issues with flare. With flags I guess you could minimize the stray light though.
Had I been a studio pro I'd probably would have shown a flash example. I like continuous light as it's user friendly to set up, and you can then also have the scene available for viewing "by eye" to make comparisons between screen and real objects. It's also easy to measure the light spectrum as it's continuous light. I don't think I can measure a flash with my Colormunki.
In terms of profile quality though studio strobes should be just as good as halogen. The halogen I suggest for D50, the Solux on overdrive is also a bit controversial, some are suspicious about it's quality and have had bad results, so I know some people prefer flash over halogen. My results with the Solux have been excellent though so that's why I'm recommending it.
-
If a precise light temperature reading is important I could still make a spotread with our spectro when we shoot the chart, unless it's overkill ?
As for flare, we'll probably manage to deal with it using the right modifiers and checking the raw histograms.
Regarding those white and black patches I read an article suggesting synthetic ones be added to ti3 files. It features some other advices too, and made me wonder if they'd apply to Dcamprof as well ?
http://ninedegreesbelow.com/photography/well-behaved-camera-profile.html
-
Updated the http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way with an alternative to render a DCP which has a custom look with a an all-around look provided designed by me (added the same to the Capture One case).
I've designed the look with the intention for it to be subtle and generic. The warmup of greens and yellows is pretty typical (many commercial profiles I've looked at contains some sort of warmup), there's a subtle saturation increase there too (skin tone range excluded) which also is very typical.
If you think it adds any value or just messes things up, or you would like it to be a bit different is personal of course, but I think it's nice to have the subjective look feature represented in the basic use case too (which will be the only use case most users will do).
-
If a precise light temperature reading is important I could still make a spotread with our spectro when we shoot the chart, unless it's overkill ?
As for flare, we'll probably manage to deal with it using the right modifiers and checking the raw histograms.
Regarding those white and black patches I read an article suggesting synthetic ones be added to ti3 files. It features some other advices too, and made me wonder if they'd apply to Dcamprof as well ?
http://ninedegreesbelow.com/photography/well-behaved-camera-profile.html
A precise light temperature reading is not really important. If you shoot something way off from D50 there can be a value to have the spectrum, but if you shoot something close to D50 and want to make D50 colors you don't need to measure it.
I haven't read that article in detail, but you don't need synthetic white and black patches for DCamProf, it's been designed to handle those situations. Argyll is not really designed for camera profiles (it's more about scanner profiles when it comes to input profiles) which makes some quirks, that's one reason I made DCamProf. The manual edits Elle does in the article seems to be to trick Argyll into making decisions good for a camera profile rather than a scanner profile. DCamProf already makes those things "under the hood" as it was designed towards the camera case rather than the scanner case.
-
Tested the workflow, I don't get the same result. I suspect that your 0.9.6 build actually is an older. Can you run dcamprof without parameters and see what the first line it outputs is? It should say "DCamProf v0.9.6 - a digital camera profiling tool."
I've attached the profile I get when running your script. Let us know if it works better.
Thanks. I suspected something silly like this myself but I am definitely using 0.9.6. Numerical problems maybe? I am using Cygwin 32bit on win10. I noticed it takes quite some time with interpolation and smoothing so there might be something critical numerically. Anyway, I just ran everything again and put a log file in that dropbox directory (build.log).
Your profile is indeed different and with it I can sort of come up with a curve that provides dark output in the shadows. But it seems still strange there.
And you may use my picture. I've uploaded both raw and ooc jepg to the dropbox directory. Unfortunately, it is not really suited to judge the colors.
I am not sure how much time I can spend on this today so expect some sluggish response of mine.
-
Thanks. I suspected something silly like this myself but I am definitely using 0.9.6. Numerical problems maybe? I am using Cygwin 32bit on win10. I noticed it takes quite some time with interpolation and smoothing so there might be something critical numerically. Anyway, I just ran everything again and put a log file in that dropbox directory (build.log).
Your profile is indeed different and with it I can sort of come up with a curve that provides dark output in the shadows. But it seems still strange there.
And you may use my picture. I've uploaded both raw and ooc jepg to the dropbox directory. Unfortunately, it is not really suited to judge the colors.
I am not sure how much time I can spend on this today so expect some sluggish response of mine.
Thanks for the raw file. I definitely see problems in it also with the file I generated. What's special about that file is that it clips to black a lot, many cameras do that, but the one's I've used most in my testing (P45+, Hasselblad H4D-50, Canon 5D Mark II) don't to the same extent. There's still some problem with the elements in the LUT close to 0, which becomes clear on these type of pictures for these type of cameras. I'll be looking at that. Hopefully it's easy to fix this time around too... we'll see.
-
Yeah, 0.9.6 is working a lot better in the shadows, but still some weird clipping (that's what it looks like at least) in the areas close to 0. If you want another file to test with, I have a mark 3 file that's got a lot of black and dark areas that I've been using to try and get the curve handles right for the LUT. Let me know if you want to give it a spin, I'll PM it to you
-
Yeah, 0.9.6 is working a lot better in the shadows, but still some weird clipping (that's what it looks like at least) in the areas close to 0. If you want another file to test with, I have a mark 3 file that's got a lot of black and dark areas that I've been using to try and get the curve handles right for the LUT. Let me know if you want to give it a spin, I'll PM it to you
I don't think I need any more test file yet, the on I got from hk1020 was great. I know exactly what the problem is now. There's some noise in the shadows, and then the raw data is clipped at some black level, this creates "impossible" combinations, like no signal on green but some blue etc. This is just noise, but it gets mapped out of gamut and it gets crazy values. My LUT code did not take into account that there could be noise. The DNG profile LUT works in a different way so it's unaffected by this problem.
It's not so easily fixed though. The problem is about identifying which LUT positions that are "crazy" and then decide where to map those. There is such code already which is about mapping to nearest valid neighbor, but unfortunately the nearest valid can be a muuuch brighter value in this case, this is what causes noise clipped shadows to go haywire.
-
I think I have it working now... here's a profile
Did a release of the code, v0.9.7. I'm going to bed now, not sure how much time I can code next week. There's a quite large change to the ICC LUT generation code and I did not get much time to test (just wanted to get something out before sleep), so there's a risk it's still broken, but if so at least in a different way than before :-)
-
I think I have it working now... here's a profile
Did a release of the code, v0.9.7. I'm going to bed now, not sure how much time I can code next week. There's a quite large change to the ICC LUT generation code and I did not get much time to test (just wanted to get something out before sleep), so there's a risk it's still broken, but if so at least in a different way than before :-)
Thanks, I just tried it but didn't have time to do much. It sure looks better than anything before. Finding a proper curve is still something I need to do.
I also tried to build from source again but this time the program crashes. Tried to investigate but then my whole pc crashed. So more later.
-
Thanks, I just tried it but didn't have time to do much. It sure looks better than anything before. Finding a proper curve is still something I need to do.
I also tried to build from source again but this time the program crashes. Tried to investigate but then my whole pc crashed. So more later.
I've got news on the crash. The assert in icclut.c line 97 fails. It happens with this command:
dcamprof make-icc -n nex5 -f auto_DSC04159_C11.tif -t tone-curve.json profile.json prelim-profile.icm
...
Interpolating out of gamut entries...assertion "max1 != 0" failed: file "icclut.c", line 97, function: cam_similarity
./doit.new: line 8: 5488 Aborted (core dumped) ../dcamprof make-icc -n 'nex5' -f auto_DSC04159_C11.tif -t tone-curve.json profile.json prelim-profile.icm
However, this only happens on 32bit Cygwin. If I compile it on a 64bit Cygwin installation the program works. The difference between 32bit and 64bit gcc is the different default for the -mfpmath option, which controls usage of the 80bit registers (google it for details). On 64bit the default is -mfpmath=sse and on 32bit it is -mfpmath=387 If I add -mfpmath=387 to the makefile and compile it on 64bit the program crashes there as well. The strange thing is I can't use -mfpmath=sse on 32bit. I suspect this to be a current Cygwin bug as I have used -mfpmath=sse in the past although with gfortran only. Simply compiling a helloWorld.c with -fpmath=sse immediately produces an error:
vega> gcc -mfpmath=sse hello.c
hello.c:1:0: warning: SSE instruction set disabled, using 387 arithmetics
#include <stdio.h>
^
So I can't produce a working dcamprof for 32bit Cygiwn at the moment. Disabling the assert is no option, you end up with NaNs if you do.
Anyway, no need to send me a binary or anything, I found the mingw compiled one in the other dcamprof thread which works just fine. And so does the 64bit Cygwin one. The results printed to the console are almost identical.
I just thought you might be interested in this result as I believe it might point to some numerical sensitivities in the code.
More on the actual profile in another reply later.
-
I found the mingw compiled one in the other dcamprof thread which works just fine. And so does the 64bit Cygwin one. The results printed to the console are almost identical.
shouldn't they be all identical ? might be something worth looking into code-wise
-
Interpolating out of gamut entries...assertion "max1 != 0" failed: file "icclut.c", line 97, function: cam_similarity
Thanks for the report. Floating point stuff can be dodgy at times. In theory the results should always be the same, but sometimes some compiler math optimizations can cause slight differences to occur. Could be such a thing, or it's just some sort of bug. I'll look into it.
EDIT: tried checksumming the LUT data, there is some bug that causes varied results when running with OpenMP, but with OpenMP disabled I get the same result. This is a quite typical bug to have (concurrency bug), so if you have stability issues disabling OpenMP is a good first step. Another step is to disable optimization (remove -02 from makefile), if the Cygwin compiler has math optimization issues that can help solving the problem.
I'll fix the parallelism bug to the next release.
-
I'm doing some other stuff to the next release so it's a bit messy to make a quick release just now, but if you change
#pragma omp critical
{
if (r_ != 0 || g_ != 0 || b_ != 0) {
ig_offsets[3*ig_offsets_len+0] = r_;
ig_offsets[3*ig_offsets_len+1] = g_;
ig_offsets[3*ig_offsets_len+2] = b_;
ig_offsets_len++;
}
}
to
if (cam.v[0] > 0 || cam.v[1] > 0 || cam.v[2] > 0) {
#pragma omp critical
{
ig_offsets[3*ig_offsets_len+0] = r_;
ig_offsets[3*ig_offsets_len+1] = g_;
ig_offsets[3*ig_offsets_len+2] = b_;
ig_offsets_len++;
}
}
in icclut.c you should hopefully get rid of the immediate crash problem.
I've fixed the parallelism issue in my local code too, but it's non-critical. It just an array that ends up in different order from time to time which make the smoothing of out of gamut entries be mildly different. Fix for that will come in next release.
-
Thanks for the report. Floating point stuff can be dodgy at times. In theory the results should always be the same, but sometimes some compiler math optimizations can cause slight differences to occur. Could be such a thing, or it's just some sort of bug. I'll look into it.
EDIT: tried checksumming the LUT data, there is some bug that causes varied results when running with OpenMP, but with OpenMP disabled I get the same result. This is a quite typical bug to have (concurrency bug), so if you have stability issues disabling OpenMP is a good first step. Another step is to disable optimization (remove -02 from makefile), if the Cygwin compiler has math optimization issues that can help solving the problem.
I'll fix the parallelism bug to the next release.
Don't know yet but there is certainly a numerical problem. I've managed to compile dcamprof on 32bit Cygwin now. The options to add are -mfpmath=sse -march=native and that certainly indicates something is wrong. With -mfpmath=387 you get higher precision for most calculations so the non-zeroes you see in icclut with sse math might actually be spurious. Unfortunately, the effects of 387 math are rather more complicated and you might get less precision. Check the articles on the net. The sse math is gcc's default on 64bit installations, no matter if Cygwin, mingw or Linux.
And none of your suggested changes work: modified source, remove -O2, remove -fopenmp. Everything crashes.
-
I think that shall be moved to the main technical topic here, rather than stay in "for dummies" topic, no ?
-
I think that shall be moved to the main technical topic here, rather than stay in "for dummies" topic, no ?
Heh, yes when talking about source code it's no longer for dummies ;D
I don't manage to recreate the crash issue. Works well here, sse or 387. The modified source should have at least changed how the software crashes as it makes a specific test that the value is not zero first, and then the assert() on not being zero of the same value should not crash, unless there's some overwrite bug that sets it to zero again in-between the first check and the assert.
One should not need to worry about precision in this case, it's 64 bit floating point which is already big overkill. However if some calculation end up at zero so there's division by zero somewhere it can crash on some assert() somewhere. That's probably what happens in hk1020's crash, I can't reproduce it with my data though.
-
This one belongs to the dummies section ;)
"Export the target image again (or any other image) in the same way as before but this time with the standard film curve, "Film Standard" or "Auto". Let's call this curve.tif. DCamProf can now compare this file with the file with linear curve and that way figure out the shape of the embedded tone curve:
dcamprof tiff-tf -f cc24.tif curve.tif tone-curve.json"
If I apply the C1 standard curve to my ETTR linear pic (CC24.tiff unclipped), C1 reports clipped highlights (curve.tiff clipped). Should this be ignored, or shall I use a shot with a lower exposure ?
-
This one belongs to the dummies section ;)
"Export the target image again (or any other image) in the same way as before but this time with the standard film curve, "Film Standard" or "Auto". Let's call this curve.tif. DCamProf can now compare this file with the file with linear curve and that way figure out the shape of the embedded tone curve:
dcamprof tiff-tf -f cc24.tif curve.tif tone-curve.json"
If I apply the C1 standard curve to my ETTR linear pic (CC24.tiff unclipped), C1 reports clipped highlights (curve.tiff clipped). Should this be ignored, or shall I use a shot with a lower exposure ?
This can be ignored. For curve extraction tiff-tf doesn't look at the actual image contents, but just at the embedded "transfer function" which is a special tiff meta data tag.
-
This can be ignored. For curve extraction tiff-tf doesn't look at the actual image contents, but just at the embedded "transfer function" which is a special tiff meta data tag.
did you check how embedded "transfer function" (the data in that special tiff meta data tag) changes when you make .tiffs in C1 with different exposure corrections (in C1's UI) x different curves
-
Hello i want testing DCamProf ...but i dont have colorchecker passport
Where i can download colorchecker passport raw image for Single-illuminant profile ....before buy the colorchecker.
..thanks
Sorry for my poor English
-
Hello i want testing DCamProf ...but i dont have colorchecker passport
Where i can download colorchecker passport raw image for Single-illuminant profile ....before buy the colorchecker.
..thanks
Sorry for my poor English
1) DCamProf allows you to use any target, but then they all have their own challenges - some are too glossy, for some you can't rely on published data (like spectral or Lab, etc) and you need to measure it yourself... X-Rite Passport or ColorChecker Classic certainly on the best part of the spectrum... for some cameras you might find SSF/CMF so you can do w/o target, albeit target is always good to have test the profile (if you don't trust your eyes)
2) http://www.imaging-resource.com is a source of raw files with targets for almost all cameras (MF backs might be a notable exception)... but their illumination is not very ideal.. but still you can use to polish your process
-
did you check how embedded "transfer function" (the data in that special tiff meta data tag) changes when you make .tiffs in C1 with different exposure corrections (in C1's UI) x different curves
No I didn't observe that (I shall add to the docs to not change exposure for the curve extraction), but I'm not surprised. ACR does something similar just as in-camera JPEGs of my Canon (probably most other cameras too), to make a smoother "film-like" transition into clipping the curve is modulated to brighten and desaturate the highlights.
Hopefully / likely the curve modulation will be the same as long as we don't change the exposure correction between linear.tif and curve.tif
-
Hello i want testing DCamProf ...but i dont have colorchecker passport
Where i can download colorchecker passport raw image for Single-illuminant profile ....before buy the colorchecker.
..thanks
As a starter, follow the workflow described at (also tips about out imaging resource where you find CC24 shots):
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way
or if using Capture One:
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#the_easy_way_c1
-
Thanks... ;D
i follow this guide
http://www.juzaphoto.com/topic2.php?l=it&t=1473256
I use this command
dcraw -v -r 1 1 1 1 -o 0 -H 0 -T -W -g 1 1 StdA.nef
dcraw -v -r 1 1 1 1 -o 0 -H 0 -T -W -g 1 1 D50.nef
dcraw -v -r 1 1 1 1 -o 0 -H 0 -T -W -g 1 1 D65.nef
scanin -v -dipn StdA.tif ColorCheckerPassport.cht cc24_ref.cie
scanin -v -dipn D50.tif ColorCheckerPassport.cht cc24_ref.cie
scanin -v -dipn D65.tif ColorCheckerPassport.cht cc24_ref.cie
dcamprof make-profile -i StdA -w all 1.3,1,2,1.5,1 -l 0.1,0.1 StdA.ti3 StdA.json
dcamprof make-profile -i D50 -w all 1.3,1,2,1.5,1 -l 0.1,0.1 D50.ti3 D50.json
dcamprof make-profile -i D65 -w all 1.3,1,2,1.5,1 -l 0.1,0.1 D65.ti3 D65.json
dcamprof make-dcp -n "Nikon D610" -d "X-rite-StdA-D50" -t acr StdA.json D50.json X-D610-StdA-D50.dcp
dcamprof make-dcp -n "Nikon D610" -d "X-rite-D50-D65" -t acr D50.json D65.json X-D610-D50-D65.dcp
;D
-
The commands look fine. I haven't read the guide (I need google translate for that), but it seems to be made by someone experienced in the subject.
-
Thanks..but i have a problem with red... :'(
X-rite software
(http://i.imgur.com/wCMAlUS.jpg)
http://i.imgur.com/wCMAlUS.jpg
Dcamprof 0.97
(http://i.imgur.com/ir9mi2I.jpg)
http://i.imgur.com/ir9mi2I.jpg
The machine is red...not purple...Thanks ;)
-
It seems like you have not calibrated for daylight, I assume this is the StdA profile?
In my first edit I thought it could be the difference of CAT (disable it with -C to make-profile), but the difference is much larger than that. If you look at the colorchecker in the background, it looks pretty off alltogether in the dcamprof image. The effect looks similar to when you use a daylight profile in StdA light or the other way around. Are you sure you are using X-D610-StdA-D50.dcp and not the other? If you are there could be some issue with the illuminant tags in the profile, if you post the dcp file I can have a look. The first illuminant should be StdA and the second should be D50. If it's the other way around or wrong tags you can get this effect.
I suspect one of:
A) the wrong profile loaded (your D50-D65 rather than StdA-D50)
B) wrong illuminant tags
C) wrong order of illuminants
D) right order of illuminants, but wrong order of actual matrices/LUTs
If say StdA.ti3 would actually contain test data from daylight, then you could get this effect.
Normally color between different profile makers should look almost identical at first glance, only when really looking for differences one can see that they are there. When there is as large difference like here then there is most likely some problem in the profile-making process. There could be some bug in DCamProf illuminant tag transfer, I haven't tested that much as I generally provide the illuminants in the last make-dcp step, like this:
dcamprof make-dcp -n "Nikon D610" -d "X-rite-StdA-D50" -i StdA -I D50 -t acr StdA.json D50.json X-D610-StdA-D50.dcp
-
thank you for your patience.. ;)
I use this command
dcraw -v -o 0 -4 -r 1 1 1 1 -T StdA.nef
dcraw -v -o 0 -4 -r 1 1 1 1 -T D65.nef
scanin -v -dipn StdA.tif ColorChecker.cht cc24_ref.cie
scanin -v -dipn D65.tif ColorChecker.cht cc24_ref.cie
dcamprof make-profile -i StdA -w all 1.3,1,2,1.5,1 StdA.ti3 StdA.json
dcamprof make-profile -i D65 -w all 1.3,1,2,1.5,1 D65.ti3 D65.json
dcamprof make-dcp -n "Nikon D610" -d "X-rite-StdA-D65" -t acr StdA.json D65.json X-D610-StdA-D65.dcp
I upload my test raw files...
https://www.dropbox.com/s/0lkuvp8utmrz60v/Test.rar?dl=0
;D
-
Here's my result with your files:
http://torger.dyndns.org/macao.jpg
Here's with your profile in the archive:
http://torger.dyndns.org/macao-old.jpg
And here's my result with CAT disabled (mostly difference in red lightness):
http://torger.dyndns.org/macao-nocat.jpg
And here's a basic sanity check, no relaxation, only StdA, no CAT
http://torger.dyndns.org/macao-stda-max.jpg
The lightness varies quite much depending on various optimization settings and curve differences, but the hue is mostly the same on all. Let me know, is it too little yellow and too much magenta in the car paint?
Could you also compare the red patch on the color checker and say how similar it is to the car paint? From the image it seems like it's highly similar, almost the same.
I can see in the plots and the stats that it struggles to match the red patch in the color checker. Before LUT correction it's 8 DE off (it's quite much), but it becomes significantly better after LUT. You can run:
dcamprof make-profile -r dump1 -i StdA -w all 1.3,1,2,1.5,1 StdA.ti3 StdA.json
And then look at the patch matching images in the dump1 directory. The fm-patch-errors-DE-h.tif is before LUT sorted after hue, patch-errors-DE-h.tif is after LUT.
-
In the first problem image you showed, the front of the car looks more purple than the rear. This could be a clipping handling bug, which may have improved to 0.9.11.
In your original image, is the rear part of the car the correct color, or is it also too magenta?
EDIT: checked your profile in the archive and yes it has a clipping bug, green channel drops to 0 when the red color clips, making it more magenta. This does not happen on the profile I rendered.
You can try with the attached profile, it's rendered using your commands.
-
One warning: as far as I know X-Rite software makes a linear colorimetric profile and just applies a curve with no compensation. This makes reds become orange.
So in the first pair of images you posted I would expect that X-Rite's result is too orange.
Linear colorimetric (no curve):
(http://torger.dyndns.org/macao-linear.jpg)
Linear with Adobe's curve, without any compensation, note how red has become more orange (it's not a huge difference, it will depend a bit on your screen how easy it is to see)
(http://torger.dyndns.org/macao-curve.jpg)
Same curve, but now with DCamProf neutral tone reproduction operator
(http://torger.dyndns.org/macao-ntro.jpg)
-
Torger..thank you
0.9.11=very good
Mario ;)
-
Hi!
I am trying to learn dcamprof.
First off: WOW! What a piece of work! And what a detailed documentation! Many many thanks Torger!
Right now I try to glare-match a flat-fielded .ti3, using this command:
./dcamprof-v0.10.4 testchart-ff -L cc24-ff.ti3
but as a result I get something that looks like the manpage, no output. What am I missing?
edit:
The above was based on my reading of the documentation of the program itself,
http://www.ludd.ltu.se/~torger/dcamprof.html#glare_matching.
I see now that the profiling tutorial
http://www.ludd.ltu.se/~torger/photography/camera-profiling.html#step5_glare
uses a layout.json file:
dcamprof testchart-ff -L cc24-layout.json cc24-ff.ti3 cc24-ffgm.ti3
Where do I find that .json file, and how can I produce one for the ColorCheckerSG target? (I want to try to merge these 2 targets).
-
They are located in the data-examples folder.
-
Thank you, Frederic!
-
I am trying to create a profile based on a flat-fielded tif and .ti3. The syntax of the make-profile command is given as:
dcamprof make-profile [flags] <input-target.ti3> <output-profile.json
so I tried:
./dcamprof-v0.10.4 make-profile -i D50 -C cc24-layout.json cc24-ff.ti3
profile.json
As a result I get the manpage.
The strange thing is that I have earlier successfully created a profile using this command:
./dcamprof make-profile -g cc24-layout.json cc24-ff.ti3 profile.json
Why not now? it was another tif and .ti3, but the current one looks o.k., I attach a .zip.
Can anybody help?
-
Well I repeated with
./dcamprof make-profile -g cc24-layout.json cc24-ff.ti3 profile.json
and that worked. Obviously, dcamprof considered the glare to be too high for a profile without glare matching.
Relief!
-
Hi!
Could anybody advice how to create a layout.json file for the ColorChecker Passport? Looking at cc24-layout.json, I see some problems: It would have 3 different values for column count, row height, row width. How would the extra rows/patches (beyond the CC24) be called? And which patches would be identified as black and white? I assume the extremes in the neutral row at the bottom of the extra part?
Thank you for your help!
-
There is a cc24-layout.json in the "data-examples" folder. Anders says you should use it. If you are using or not, you will find the structure in there, don't you?
-
Hi sebbe,
thank you for your comment.
Yes I have tried to follow Anders' advice to model a .json layout file after the one for the cc24. The cc24-layout.json looks like this:
// Layout specification for X-Rite ColorChecker Classic
// Can be used for flat-field correction and glare modeling
{
"RowCount": 4,
"ColCount": 6,
"RelativeRowHeight": 1.0,
"RelativeColWidth": 1.0,
"HasColOffset": false,
"WhitePatches": [ "D01" ],
"BlackPatches": [ "D06" ],
"MiddleGrayPatches": [ "D04" ]
}
Hence my question: how handle a target which has 3 different values for ColCount (=row lenght, I assume), Relative RowHeight and RelativeColWidth. I assume row hight and column width describe the size of the patches, of which there are 3 different ones in the CC Passport.
Good light!
-
Hey Hening
I'm not very into creating my own testchart, and it looks like you did your own. Otherwise you just can take Anders version for the CC24.
I was looking into the documentation (http://www.ludd.ltu.se/~torger/dcamprof.html). There are two commands in dcamprof, that may help you in understanding the layout.json: make-testchart (http://www.ludd.ltu.se/~torger/dcamprof.html#make-testchart) and testchart-ff (http://www.ludd.ltu.se/~torger/dcamprof.html#testchart-ff). I didn't look more into it, maybe I'm wrong...
-
Hi sebbe,
no I have not made my own test chart. I just thought I could use the full Passport target rather than just the cc24 part. - I have looked at the make-testchart command, it does not answer my question, nor does testchart-ff, which I have used for flat-fielding. -
Well if Anders is satisfied with the cc24, so am I, I guess...
Good light!
-
Thanks for clarifying, it looks like I can't help you more.
But, what is the reason you want to use the whole part? They are just for a different use. One is for profiling, the other for whitebalance.
Anyway, there is no visible difference in using anything else instead of the cc24 in regard of profiling with dcamprof (e.g to the ColorChecker Digital SG with 140 fields). So you would not see a difference when using all the fields (with the whitebalance-part) or just the cc24-fields.
-
I just thought I could use the full Passport target rather than just the cc24 part
there is no gain for profiles from the 2nd page really... the _color_ patches are not (that) different = do not really bring any useful reference points
-
Hi sebbe,
no I have not made my own test chart. I just thought I could use the full Passport target rather than just the cc24 part. - I have looked at the make-testchart command, it does not answer my question, nor does testchart-ff, which I have used for flat-fielding. -
Well if Anders is satisfied with the cc24, so am I, I guess...
Good light!
The layout.json format currently does not support "complex" layouts like the ColorChecker Passport, so you'll have to satisfy with the cc24 part for now. I've made some simulations and really adding those extra won't make much of a difference as they are in a similar color range so I have not prioritized to support it.
If you want a real difference you should have a target which can do super-saturated colors like the CCSG, but it's very hard to shoot without significant glare issues.
A large amount of patches may be worthwhile if you do high end reproduction work, and then the patches should match the artwork you're copying, but if you make a profile for generic all-around use there's little gain to even go beyond the CC24.
What makes bundled profiles different between manufactures (Lightroom vs Capture One etc) is custom looks and optimization tradeoffs and how they apply the contrast curve, gamut compression etc. The actual target used doesn't have that large impact. DCamProf has it's "neutral tone reproduction operator" that is central to how its profiles looks, and with look operators you can apply some custom changes if you like.
One should worry more about making as well made shot as possible to reduce "measurement errors" rather than having lots of patches.
-
super-saturated colors like the CCSG
a theoretical question - what is the "physics" behind the direct relation between saturation and "glossiness" (for objects that reflect, not emit) ?
-
Thanks to all who replied. After what you all write, I feel really OK with the cc24. I tried to shoot the CCSG and the result was so miserable that dcamprof did not use a single patch for fusion to the combo.ti3. But I have a really good flat-fielded shot of the cc24, so I feel all set.
Thanks again!
-
Hi!
Hope you all had a merry Christmas!
I am confused about the make-icc command:
Which parameter am I to use with the -t flag if I want the neutral tone reproduction operator with the -o flag? As far as I can figure out, the -o without parameters would yield the neutral operator. But it pre-supposes that a non-linear curve is applied with the -t flag, but these are either acr or a custom .json file, so they will have their own curve. The -t without a parameter would mean 'no curve'. So -??
A happy new year!