Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: torger on May 22, 2017, 12:21:42 pm
-
I've just released a new software program for making camera profiles: Lumariver Profile Designer.
Presentation here: http://www.lumariver.com/#LumariverPD
Introduction video here: https://www.youtube.com/watch?v=UUt3jWs5vTk
User manual here: http://www.lumariver.com/lrpd-manual/
Download here: http://www.lumariver.com/#DownloadLumariverPD
It's the graphical user interface version of my command line tool "DCamProf". It's intended to be easy to use for casual users, but also provide the depth of manual tuning that DCamProf provides, now much easier to operate thanks to the GUI. Still it's unavoidable that the manual stuff is pretty technical, and to ease that aspect I've made a quite beefy user manual with reference docs and tutorials.
It's available for both MacOS and Windows, and comes in three editions. One "Basic" intended for casual users making DNG profiles for Lightroom etc, and one "Pro" for those that also wants to make ICC profiles (including those that works for Capture One) and wants more abilities to customize, and the unlimited "Repro" edition that adds mostly reproduction features like full 3D LUT and multi-target. All features are available in the version provided for download so you can test and toy with it, but you cannot save projects or export profiles unless you purchase a license.
-
was I first to buy 8) ?
-
was I first to buy 8) ?
Actually I was myself the first :-), I made a test buy to see that the Paypal config had worked out. But you were the fastest of the others, thank you :-)
-
First impressions - Straight out of the box it works a treat (at last DCP profiles with accurate rendition of reds), best 120 I've spent for years.
Btw
For operational queries do we create new topics, add on to this thread or email/pm?
Sent from my iPhone using Tapatalk
-
The official support channel for Lumariver software is listed somewhere on the web site, but of course the messages end up in my mailbox as this particular software is a one-man-show (not in developing tone reproduction and tuning defaults though, I've had great help from collaboration with photographers). Anyway, either way is okay. Since I'm only one person it's of course great if the manual is checked for answers first :)
(We had an own forum on the Lumariver site but it became mess to maintain, constantly attacked by hacking bots etc so I've put that on hold, so email is the only "official" channel currently, but I hang out at this forum too).
-
Thanks for confirming - just so this thread remains true to notifications about the software rather than getting bogged down with various arising queries I'll RTFM 1st and pm /new topic separately.
Cheers again for a good bit software (at a very decent price point).
Alex
-
Just looked at this and it's the first bit of software that I've ever needed to disable anti-virus software to install. (Win 7 with Avast).
You might like to look at that.
-
Just looked at this and it's the first bit of software that I've ever needed to disable anti-virus software to install. (Win 7 with Avast).
You might like to look at that.
Yes I'd like to fix that, but it seems to be very difficult :-/
There's a note about that on the web page. You shouldn't need to disable anti-virus (I think), normally it should just be Windows Smartscreen that complains "Windows Protected your PC", and then you press "more info...", see that the software indeed is sign by our company (Xarepo), and press "Run anyway". The problem is that nowadays it's not enough for Windows that the software is signed, it needs "reputation" which basically means many thousands of installs (I've heard), or you sell it through "Windows Store", which is the direction Microsoft is pushing. The app stores take a hefty 30% distribution fee so it's very good money for Microsoft/Google/Apple to make vendors sell that way. We'll probably go there in the end just like everyone else will, but for now it's still feasible to sell on the side.
(I've found out you can get some "free" reputation points by buying a very expensive signing certificate from Symantec, we're using a standard signing cert. I don't think the free points would have been enough though, but would probably lower the amount of world-wide installs required.)
There should be another way to get rid of the complaint; using "WACK", Windows Application Certification Kit, an analysis software that runs for 20-40 minutes and produces a test result which you then submit to Microsoft which then is supposed to make smartscreen stop complaining. I have put the software through that successfully (which is sort of messy as the installer "Inno Setup" I use doesn't seem to be compatible with the latest WACK so I actually have to sit and watch the whole test run and press buttons when the install software is started). But then actually getting the result file to Microsoft is pretty messy. I counted to 18 agreements that needs signing and their web page was pretty buggy. At that point I gave up, for the moment.
But yes, I'd really like to get rid of that warning if I just knew how... as this software is pretty niche I don't expect the automatic reputation quota to be filled any time soon. Most other small vendors examples I can come up with have already thousands of installs so they have already the reputation points needed, but I guess there is some way to fix it, I just haven't found out how. Searching the web it seems like Microsoft have changed the policy quite a lot over the last few years so the old guides no longer work. As their OS is hammered by viruses and various malware they have good reason to I guess....
-
I let Avast send a copy back for checking and it was returned later as no threat. Hopefully if everyone does that Avast will get the message it's no problem.
I've now added the program as an exception for av scanning and it now runs without any warnings.
-
Bravo Anders!
Congratulations,
kirk
-
Grattis!
I've tested the multitarget and the ICC-process for C1 so far. The manipulating of the tone curve is great. It's much easier than writing json files. :)
The multitarget function worked great when I started with the IT8.7 and added the CCSG to it. The other way around the program closed when I (or the program) render the result. When I'm on the 2nd target and save the ICC-profile the picture of the first target is showed after that. But with the grid and selection of the 2nd. All other functions seems to work nicely. On a few I'm still not sure what it does exactly (Headroom, LUT optimization with lightness, TRO Variant). Maybe some examples would be nice in the documentation later.
Is there a way to see the results of the ICC in terms of dE of each patch?
I'm heading to Gothenburg tomorrow. Therefore no much time to test more but I will enjoy your country for holidays instead. ;)
Thanks for the great tool.
Sebastian
-
Grattis!
I've tested the multitarget and the ICC-process for C1 so far. The manipulating of the tone curve is great. It's much easier than writing json files. :)
The multitarget function worked great when I started with the IT8.7 and added the CCSG to it. The other way around the program closed when I (or the program) render the result. When I'm on the 2nd target and save the ICC-profile the picture of the first target is showed after that. But with the grid and selection of the 2nd. All other functions seems to work nicely. On a few I'm still not sure what it does exactly (Headroom, LUT optimization with lightness, TRO Variant). Maybe some examples would be nice in the documentation later.
Is there a way to see the results of the ICC in terms of dE of each patch?
I'm heading to Gothenburg tomorrow. Therefore no much time to test more but I will enjoy your country for holidays instead. ;)
Thanks for the great tool.
Sebastian
If the program closed then it crashed due to some bug. The multi-target aspect is a bit less tested than the other features, I've tested it with a quite simple workflow and obviously based on your report it doesn't cover all cases :-\. I'll dig more into that and iron out the bugs, thanks for reporting.
The Headroom and LUT optimization stuff is described with text in the manual, but I guess it would help with some images.
The headroom especially may be a bit tricky to understand, although the basic principle is simple: if you have a 3D LUT it matters how bright target patches are as you can apply a different correction on a dark patch as on a light patch even if they have the same hue and saturation, and the headroom defines which range the 3D LUT works in. The default is "from image", which is what most will be using most of the time, and it means that the LUT covers the same brigthness range the target in the image covers. This means that if you have a very dark target chart the 3D LUT will only cover dark colors. The idea is however that you expose the target with the same exposure you would use for real images, in a reproduction setup you usually shoot the target in the same space as where you will shoot the actual artwork or objects for reproduction. If you set it to "from reference", the brightness range is specified by the measured reference values, and custom you can set it to any value you want and optionally make the profile scale to match. Those two settings I expect to be used more rarely, but could have an application for like scanners and similar when you want the profile to correct also the exposure.
The "LUT optimization with lightness" preset simply means that the LUT actually considers lightness and corrects it, which is disabled per default for general-purpose, and enabled for reproduction. While in reproduction it is often important that the lightness of colors is correct too, correcting lightness for a general-purpose profile is generally not a good idea. This is not only because lightness correction requires flatfield correction or perfectly even light to make sense, but because you may then make transition into clipping look less nice (which is not a problem for reproduction when you typically don't clip stuff and use no tone curve) and while errors in lightness is easy to spot in an A/B swap comparison, lightness errors are not disturbing when an image is viewed alone, unlike those in chroma/hue.
That said you can do interesting stuff with lightness manipulation in the color adjustments editor, for example by modulating lightness of nearby hues you can introduce "color separation" (for example making yellows lighter than reality and greens darker and then cyan-blues lighter again etc). If doing so it may be wise to fade out the manipulations towards the whitepoint to make the transition to clipping look nice. (Color separation can be enhanced with other methods too, the general principle is to introduce small controlled errors, so the profile still "feels accurate"... the camera color filters also have quite strong effect on that as you really can't make very strong manipulations for nearby colors or you hurt smoothness, so the camera response shines through quite a bit in that aspect.)
To see the colorimetric matching result you need to enable manual optimization mode, and open the Tune LUT dialog. You can use the presets in there so you don't really need to make a manual optimization. I may adjust that in a future version especially for the repro mode as it's not entirely logical that you have to enable "manual" even if you don't intend to do it manually. When designing it originally I was thinking that if you want to know how well it matched, you probably want to make manual adjustments too, and if you do automatic you probably don't really want to look at the colorimetric result but rather just evaluate the profile by eye.
-
I'll test the multi-target "crash" later on another computer. Sometimes things crashes because of the system not the program. ;)
Thanks for the details about headroom. I do understand the differences now.
The intention to optimize after checking make sense. I'll have a look into it later.
If the program closed then it crashed due to some bug. The multi-target aspect is a bit less tested than the other features, I've tested it with a quite simple workflow and obviously based on your report it doesn't cover all cases :-\. I'll dig more into that and iron out the bugs, thanks for reporting.
The Headroom and LUT optimization stuff is described with text in the manual, but I guess it would help with some images.
The headroom especially may be a bit tricky to understand, although the basic principle is simple: if you have a 3D LUT it matters how bright target patches are as you can apply a different correction on a dark patch as on a light patch even if they have the same hue and saturation, and the headroom defines which range the 3D LUT works in. The default is "from image", which is what most will be using most of the time, and it means that the LUT covers the same brigthness range the target in the image covers. This means that if you have a very dark target chart the 3D LUT will only cover dark colors. The idea is however that you expose the target with the same exposure you would use for real images, in a reproduction setup you usually shoot the target in the same space as where you will shoot the actual artwork or objects for reproduction. If you set it to "from reference", the brightness range is specified by the measured reference values, and custom you can set it to any value you want and optionally make the profile scale to match. Those two settings I expect to be used more rarely, but could have an application for like scanners and similar when you want the profile to correct also the exposure.
To see the colorimetric matching result you need to enable manual optimization mode, and open the Tune LUT dialog. You can use the presets in there so you don't really need to make a manual optimization. I may adjust that in a future version especially for the repro mode as it's not entirely logical that you have to enable "manual" even if you don't intend to do it manually. When designing it originally I was thinking that if you want to know how well it matched, you probably want to make manual adjustments too, and if you do automatic you probably don't really want to look at the colorimetric result but rather just evaluate the profile by eye.
-
Will Lumariver support HUTCHCOLOR precision scanner
target in the future?
I know it look like a rectangular one.
But it's not. So many patches is not used, it become an
odd shape to customize.
Here is an reference file.
http://www.hutchcolor.com/HCT_data_files/F35T/6840-6869.txt.zip (http://www.hutchcolor.com/HCT_data_files/F35T/6840-6869.txt.zip)
-------------------------------------------------------------------
HCT
Reference File 6840-6869 AVERAGED
BEGIN_CODE
MONTH 20
DAY 06
YEAR 24
MEDIA_MANUFACTURER FUJI
MEDIA_CODE RVP
MEDIA_TYPE TRANSMISSION
MEDIA_SIZE 6x7
END_CODE
BEGIN_LAYOUT
ROWS_ALPHA 22
COLUMNS_NUMERIC 29
PATCHES_ACTIVE 528
END_LAYOUT
BEGIN_DATA_FORMAT
SAMPLE_ID XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB_B
END_DATA_FORMAT
BEGIN_DATA
A01 72.926 74.195 56.488 89.014 2.908 4.803
A15 0.058 0.055 0.036 0.498 0.192 0.181
A16 74.227 75.421 57.304 89.59 3.119 4.951
A29 74.042 75.229 57.173 89.5 3.126 4.931
B01 0.053 0.05 0.033 0.453 0.169 0.167
B02 17.983 7.995 18.043 33.97 70.279 -34.326
B03 24.635 12.574 25.141 42.109 66.786 -34.376
B04 31.93 18.82 31.697 50.466 59.408 -30.772
B05 41.545 28.829 38.992 60.61 47.389 -23.672
B06 55.88 46.927 47.851 74.124 28.365 -11.378
B07 75.177 76.355 57.658 90.023 3.197 5.335
B08 66.187 67.596 19.039 85.803 2.26 52.867
B09 48.128 40.01 21.6 69.457 28.238 19.442
B10 34.963 23.583 20.257 55.657 47.655 -1.65
B11 25.796 14.399 17.933 44.792 60.123 -15.403
B12 18.416 8.657 14.043 35.311 66.764 -22.346
B13 10.859 4.385 7.662 24.903 65.146 -20.03
B14 64.7 59.486 52.741 81.548 17.255 -4.079
B15 64.912 61.519 53.959 82.648 12.987 -3.5
B16 61.877 62 55.071 82.905 4.937 -4.24
B17 65.56 69.37 57.77 86.685 -2.946 -0.535
B18 66.918 71.471 58.498 87.713 -4.356 0.493
B19 65.921 70.721 55.977 87.349 -4.998 2.466
B20 62.873 68.148 41.602 86.079 -6.426 16.834
B21 66.494 70.111 37.246 87.051 -2.44 24.27
B22 69.171 70.918 32.863 87.444 1.716 31.22
B23 65.259 63.39 36.458 83.644 9.488 19.494
B24 59.126 53.537 37.492 78.183 18.811 8.654
B25 62.613 56.66 50.104 79.981 19.255 -3.86
B26 73.961 75.769 58.079 89.752 1.874 4.435
B27 74.642 75.887 57.601 89.806 3.038 5.019
B28 72.833 74.183 55.904 89.008 2.738 5.403
B29 0.048 0.046 0.028 0.411 0.169 0.19
C01 23.334 24.583 16.458 56.66 -1.619 8.446
C02 15.235 6.936 18.912 31.656 64.879 -40.22
C03 20.823 11.355 26.56 40.164 57.868 -40.218
C04 26.967 17.697 33.623 49.11 46.281 -35.999
C05 35.447 28.637 41.563 60.434 28.654 -27.328
C06 48.112 48.136 50.876 74.896 4.746 -13.493
C07 60.661 67.023 57.524 85.513 -9.138 -2.304
C08 53.652 60.739 27.288 82.234 -12.197 31.096
C09 40.976 41.846 27.69 70.738 1.947 10.615
C10 29.922 23.814 25.485 55.881 28.602 -11.219
C11 22.221 13.779 22.023 43.901 48.3 -25.466
C12 16.039 7.856 16.861 33.671 60.839 -32.139
C13 9.547 3.825 8.837 23.077 62.845 -27.593
C14 48.243 36.754 43.594 67.077 38.821 -18.429
C15 44.372 38.296 46.222 68.213 22.964 -19.657
C16 34.195 33.88 46.359 64.839 5.382 -25.636
C17 43.163 48.855 52.685 75.346 -11.304 -14.712
C18 53.361 61.66 56.79 82.728 -15.076 -6.347
C19 47.642 56.901 34.932 80.119 -19.057 15.57
C20 44.417 53.199 19.006 77.989 -18.993 39.467
C21 54.677 60.211 17.088 81.95 -8.36 50.566
C22 64.682 65.329 12.916 84.652 3.852 65.771
C23 49.253 42.255 13.451 71.036 24.514 40.828
C24 38.979 29.023 12.855 60.794 38.682 24.814
C25 41.867 30.993 26.331 62.493 40.271 -1.311
C26 66.812 68.33 56.811 86.169 2.059 -0.437
C27 69.579 71.544 55.137 87.748 1.283 4.037
C28 67.216 69.643 40.963 86.82 0.144 18.931
C29 22.277 23.425 15.116 55.489 -1.408 9.694
D02 8.521 3.993 18.674 23.646 51.815 -53.515
D03 12.284 7.484 26.261 32.879 40.885 -52.264
D04 16.764 12.931 33.328 42.647 26.244 -46.709
D05 23.52 23.003 41.329 55.06 6.071 -36.299
D06 33.752 40.35 50.19 69.703 -17.071 -21.677
D07 46.642 56.381 55.673 79.827 -20.572 -10.185
D08 40.365 51.046 30.629 76.702 -25.579 16.136
D09 28.287 35.763 30.508 66.314 -22.666 -1.582
D10 19.085 19.07 27.555 50.748 3.598 -23.627
D11 13.212 9.775 23.459 37.425 27.447 -39.37
D12 8.921 4.72 17.691 25.91 45.444 -47.421
D13 4.858 1.848 9.027 14.661 52.475 -42.777
D14 36.538 23.328 35.477 55.398 54.052 -27.835
D15 28.059 21.291 37.839 53.242 32.802 -34.829
D16 16.243 15.39 36.926 46.144 8.22 -45.818
D17 26.217 32.642 47.6 63.849 -20.32 -28.804
D18 38.012 49.197 54.25 75.571 -28.102 -16.016
D19 30.687 42.741 24.733 71.374 -35.27 16.817
D20 27.598 38.18 9.643 68.149 -33.224 47.313
D21 44.76 51.003 8.999 76.676 -12.35 64.241
D22 62.358 61.498 7.171 82.645 7.197 81.501
D23 40.817 31.66 5.925 63.05 34.674 53.183
D24 26.885 16.538 4.71 47.668 52.207 32.785
D25 29.215 17.965 15.06 49.449 53.705 -0.579
D26 59.213 56.388 47.979 79.827 11.926 -1.695
D27 56.804 57.993 41.966 80.73 2.197 7.147
D28 55.115 57.9 37.416 80.676 -1.776 13.048
.
.
.
.
S02 0.106 0.073 0.398 0.661 1.445 -6.369
S03 0.375 0.751 0.898 6.783 -14.101 -5.039
S04 1.074 2.861 1.419 19.474 -41.269 9.546
S05 2.265 6.38 1.933 30.342 -56.584 22.679
S06 3.905 10.346 2.308 38.455 -63.019 33.187
S07 7.822 16.298 2.91 47.361 -56.668 43.665
S08 6.797 12.732 0.8 42.357 -44.989 57.967
S09 3.136 7.536 0.606 32.995 -51.59 45.456
S10 1.829 4.7 0.458 25.857 -47.083 35.93
S11 0.78 1.93 0.251 15.111 -33.639 21.318
S12 0.223 0.463 0.099 4.185 -9.02 5.34
S13 0.041 0.039 0.023 0.352 0.146 0.181
S14 1.73 1.293 2.084 11.213 13.549 -11.733
S15 1.319 1.1 2.133 9.779 8.411 -14.663
S16 0.731 0.787 2.209 7.107 -1.115 -19.951
S17 1.309 2.08 2.903 15.886 -18.212 -10.53
S18 1.746 3.129 3.261 20.534 -26.244 -5.099
S19 1.553 2.911 2.241 19.668 -27.528 1.408
S20 1.285 2.463 0.84 17.729 -26.911 14.83
S21 2.369 3.174 0.806 20.702 -12.927 20.564
S22 3.002 3.467 0.765 21.801 -5.718 23.172
S23 2.331 2.394 0.639 17.409 0.478 17.952
S24 1.333 1.001 0.406 8.977 12.255 7.807
S25 1.506 1.141 1.295 10.097 12.422 -5.043
S26 0.468 0.587 0.565 5.3 -3.953 -1.525
S27 0.407 0.541 0.447 4.89 -4.651 -0.005
S28 0.378 0.519 0.416 4.688 -4.949 0.231
T01 23.592 24.733 16.06 56.798 -1.115 9.632
T14 1.717 1.533 1.94 12.806 6.373 -7.619
T15 1.443 1.404 1.988 11.965 2.62 -9.521
T16 0.977 1.158 2.04 10.229 -4.916 -13.012
T17 1.429 2.098 2.413 15.978 -15.079 -6.457
T18 1.72 2.74 2.606 18.949 -20.06 -2.931
T19 1.608 2.612 2.024 18.4 -20.608 1.227
T20 1.439 2.384 1.094 17.365 -20.774 10.216
T21 2.092 2.745 1.043 18.964 -11.368 13.725
T22 2.434 2.892 1.011 19.58 -6.767 15.269
T23 2.079 2.29 0.92 16.919 -2.804 12.103
T24 1.43 1.291 0.711 11.189 5.551 5.884
T25 1.577 1.425 1.427 12.1 5.7 -3.238
T26 0.238 0.339 0.32 3.062 -3.576 -0.758
T27 0.198 0.264 0.225 2.388 -2.308 -0.138
T28 0.163 0.197 0.153 1.78 -1.095 0.173
T29 74.51 75.741 57.715 89.738 3.058 4.784
U01 0.054 0.052 0.03 0.471 0.136 0.247
U14 1.597 1.738 1.673 14.033 -2.028 -2.741
U15 1.505 1.69 1.66 13.756 -3.365 -3.075
U16 1.289 1.59 1.71 13.152 -7.046 -4.64
U17 1.491 1.996 1.801 15.45 -11.042 -1.652
U18 1.592 2.189 1.867 16.431 -12.524 -0.625
U19 1.558 2.148 1.706 16.225 -12.574 0.695
U20 1.467 2.038 1.311 15.666 -12.679 4.337
U21 1.704 2.163 1.282 16.297 -9.045 5.812
U22 1.789 2.185 1.25 16.407 -7.387 6.411
U23 1.712 2.038 1.234 15.662 -6.117 5.34
U24 1.464 1.615 1.125 13.302 -2.567 2.757
U25 1.546 1.701 1.483 13.806 -2.487 -0.972
U26 0.079 0.095 0.092 0.859 -0.532 -0.245
U27 0.075 0.093 0.065 0.842 -0.596 0.221
U28 0.08 0.099 0.052 0.896 -0.646 0.562
U29 0.041 0.04 0.022 0.357 0.121 0.195
V01 73.97 75.297 57.131 89.532 2.839 5.03
V14 23.404 24.644 16.169 56.698 -1.564 9.2
V15 74.869 76.081 57.748 89.897 3.113 5.023
V26 0.052 0.051 0.038 0.465 0.087 0.084
V27 0.043 0.041 0.026 0.366 0.141 0.139
V28 0.042 0.04 0.024 0.36 0.133 0.172
V29 0.043 0.04 0.024 0.366 0.14 0.182
END_DATA
-
It's a bit unfortunate that many targets for no reason just aren't simple grids :-\. Grid targets can be matched with the custom target function. There is the free-form target function too, but it's only feasible to use for a few spot colors not a whole target.
Anyway I can add more targets. In fact the next patch release will contain CMP DT-8 http://www.cmp-color.fr/DT8.html as I've got all the data I need from its author.
To add a target in the drop-down list of standard targets I require
- the target should be possible to purchase, or as an exception be a legacy target that many still use
- a reference file with full spectrum, unless it's a multi-media scanner target (which you buy with reference file) then just any reference file will do
- a target photo (raw)
- the target dimensions so I can design the grid properly (a flat image is enough, or the target photo if shot flat)
Although LRPD doesn't need full spectrum in the reference files I have as a quality requirement that any target that is embedded in the program should have full spectrum reference files. I make an exception for scanner targets as they are always delivered with their own reference files anyway, and there are usually many different versions of them (different films etc).
What's missing with the HCT is a flat straight on target photo. If you have one that you can send to me I can add it.
-
I'll test the multi-target "crash" later on another computer. Sometimes things crashes because of the system not the program. ;)
I've now confirmed and fixed the one where the wrong target image showed up (next patch release), haven't succeed triggering the other yet but I'll probably do after some fooling around :)
-
I've included scanned file and reference data.
Thank you.
What's missing with the HCT is a flat straight on target photo. If you have one that you can send to me I can add it.
-
I've now confirmed and fixed the one where the wrong target image showed up (next patch release), haven't succeed triggering the other yet but I'll probably do after some fooling around :)
Great. the crash is not repeatable on the 2nd computer. Therefore, don't look deeper there.
But loading a saved project does bring the message: Invalid JSON data in file "xxx.lrpd". Maybe something to do with the multitarget?
Beside: I love to load a custom tif over profile comparison and see how all changes are directly visible on that picture. Great idea especially when I go into a look.
-
I've included scanned file and reference data.
Thank you.
Great, I'll include that target too in the next patch release.
-
Great. the crash is not repeatable on the 2nd computer. Therefore, don't look deeper there.
But loading a saved project does bring the message: Invalid JSON data in file "xxx.lrpd". Maybe something to do with the multitarget?
Could you send me the .lrpd file that complains on invalid json data? You could pm me or send an email to not clutter the thread too much.
-
so far 3 main disappointments
1) inability to use SSF data instead of raw files with targets
2) inability to use CGATS data (for example prepared with RawDigger or elsewhere) instead of raw files with targets
3) inability to take over dcamprof prepared data at some stage to continue further in LPD
-
so far 3 main disappointments
1) inability to use SSF data instead of raw files with targets
2) inability to use CGATS data (for example prepared with RawDigger or elsewhere) instead of raw files with targets
I have not tried it yet (still cannot get enough time to give it a go) but if that is so it's quite disappointing. Would add my vote to have these two added
-
so far 3 main disappointments
1) inability to use SSF data instead of raw files with targets
2) inability to use CGATS data (for example prepared with RawDigger or elsewhere) instead of raw files with targets
3) inability to take over dcamprof prepared data at some stage to continue further in LPD
SSF data is not supported at this time, as there are extremely few users, the problem being that it's very expensive or advanced DYI/ebay project to actually shoot SSF. I think SSF is better suited in DCamProf which is more academic/research, while Lumariver Profile Designer is more commercial. That said I may add SSF later "just for fun".
Again the reason I don't have DCamProf import is that Lumariver Profile Designer is intended as a commercial stand-alone product, while DCamProf is more slanted towards academic/research. I don't see many users will use them both simultaneously.
CGATS can be imported as custom reference file, it's a central feature. What you can't do though, which I assume is the feature you want, is importing a finished measurement (the raw values too, not just reference XYZ/Lab/spectra) made with Argyll scanin or RawDigger. The reason this is not the case is because Lumariver Profile Designer has the scan functionality built-in.
These features may very well end up in the software eventually, but there will for LRPD more than for DCamProf be a focus on features with more commercial value. Users want all sorts of features, and I'd love to satisfy everyone, but I can't spend hours and hours on features that only one or two users will find useful. With DCamProf I could do that if I found an academic interest in it (in the end I knew of only two people that actually did SSF profiles, it's you and Alexey, and then myself for making theoretical research on the effect of color filter shapes...), but here there will be decisions made more on a commercial basis.
But in any case, two votes registered for these features :-)
-
SSF data is not supported at this time, as there are extremely few users, the problem being that it's very expensive or advanced DYI/ebay project to actually shoot SSF. I think SSF is better suited in DCamProf which is more academic/research, while Lumariver Profile Designer is more commercial. That said I may add SSF later "just for fun".
Again the reason I don't have DCamProf import is that Lumariver Profile Designer is intended as a commercial stand-alone product, while DCamProf is more slanted towards academic/research. I don't see many users will use them both simultaneously.
why not ? what I ideally want is a something like color editor in C1 where I can prepare the data as I want (just like I can bring camera profile compatible with C1 into C1 itself) and then I fancy to do some LUT tweaking while having more or less real time visual feedback (and numbers too on the same screen) even looking @ the actual photo of something ...
CGATS can be imported as custom reference file, it's a central feature. What you can't do though, which I assume is the feature you want, is importing a finished measurement (the raw values too, not just reference XYZ/Lab/spectra) made with Argyll scanin or RawDigger. The reason this is not the case is because Lumariver Profile Designer has the scan functionality built-in.
yes, I am talking about raw data in CGATS because I might want to do a lot of averaging and other manipulations, etc - so I can use other existing tools for that - but I still want to be able to take in such CGATS file...
These features may very well end up in the software eventually, but there will for LRPD more than for DCamProf be a focus on features with more commercial value. Users want all sorts of features, and I'd love to satisfy everyone, but I can't spend hours and hours on features that only one or two users will find useful. With DCamProf I could do that if I found an academic interest in it (in the end I knew of only two people that actually did SSF profiles, it's you and Alexey, and then myself for making theoretical research on the effect of color filter shapes...), but here there will be decisions made more on a commercial basis.
But in any case, two votes registered for these features :-)
with GUI products the main pain for a single parent developer is ... GUI itself ... not things like opening couple of text files (SSF and raw data CGATS)... I mean you for sure use the ~~~same codebase to do actual relevant calculations between dcamprof and LPD... $0.02 from the crowd
PS: it is not something that needs to be done ASAP - there are other errors to fix first, but like with rawdigger top tier edition I think top tier edition of LPD shall have such options still... may be for v2.0 (unless the code hopefully allows to plug these sooner)
-
Could you send me the .lrpd file that complains on invalid json data? You could pm me or send an email to not clutter the thread too much.
Find and fixed that bug, was due to that vsnprintf() is not C99 compliant on Windows :-\ . Hopefully I will make a patch release this weekend to fix that. I want to fix it quickly because it basically means that you can't save multi-target projects on Windows (works on Mac as it's better at being C99 compliant) unless your filenames are short :), so it's a serious issue.
-
with GUI products the main pain for a single parent developer is ... GUI itself ... not things like opening couple of text files (SSF and raw data CGATS)... I mean you for sure use the ~~~same codebase to do actual relevant calculations between dcamprof and LPD... $0.02 from the crowd
I'll look into it at some point. But it's not as easy as it seems, almost everything affects the GUI in some way, it's not like adding it to a command line tool.
-
I'll look into it at some point. But it's not as easy as it seems, almost everything affects the GUI in some way, it's not like adding it to a command line tool.
at least with the raw data CGATS' one can do the following = once GUI detects that you picked a text CGATS one, generate some dummy DNG file based on raw channel data from it and open it (DNG) in GUI to proceed to work as normal, as if that DNG was from the camera... quick and dirty plug
-
Find and fixed that bug, was due to that vsnprintf() is not C99 compliant on Windows :-\ . Hopefully I will make a patch release this weekend to fix that. I want to fix it quickly because it basically means that you can't save multi-target projects on Windows (works on Mac as it's better at being C99 compliant) unless your filenames are short :), so it's a serious issue.
Released version 1.0.1:
New: Added CMP Digital Target 8, glossy and matte versions.
New: Added HutchColor HCT target.
New: Command-W on MacOS will close project window.
Fixed: wrong sub-target image shown in some situations.
Fixed: crash when opening huge TIFF files.
Fixed: broken file format on save (usually when using multi-target), windows-only bug.
-
@ post # 22:
> (in the end I knew of only two people that actually did SSF profiles,
+1 ;-)
That is for the Canon 5D2, where SSF Data are available.
So obviously, the gui version does not entirely replace the command line tool. Good that one has learned at least a little command line... :-)
-
Hi - this looks fantastic!
I just bought into the Hasselblad X1D system and their color profiles I find are already very good (compared to other camera manufactures anyway). Having said that, for many years for my last few camera/lens systems, I have prepared camera profiles for different lighting conditions with the Colorchecker Passport. That experience has already convinced me that camera profiles will meaningfully improve even Hasselblad's (apparently dual illuminate tungsten/daylight) hardwired profile even without yet testing that hypothesis (never mind the effects of polarizers, neutral density filters, day, night, shade and different lenses which I also profile). Several questions:
1. What is the best target, quality-wise, to profile with Lumariver currently? HutchColor, Passport, Digital SG, another?
2. Would your recommendation be the same for landscape shooters? (Sunlight and shade are many of our primary lighting conditions).
As a number of us will be, I am willing and actually want to spend up to a week or so to create profiles for my new camera under different lighting/lens/filter conditions. In my view, these profiles are one of the best camera investments to be made in photography since God created the lens. A printer or computer might win out too ... a close call.
-
@ post # 22:
> (in the end I knew of only two people that actually did SSF profiles,
+1 ;-)
That is for the Canon 5D2, where SSF Data are available.
So obviously, the gui version does not entirely replace the command line tool. Good that one has learned at least a little command line... :-)
I'm going to do a "middle way", the next patch release will have an extra "Custom Target with Raw Values". You will still need to load a target image (where the profile is applied, camera model and baseline exposure is taken if DNG), but the image doesn't need to contain a target. That way you can import CGATS with pre-scanned values, and you can use DCamProf to make CGATS with raw values derived from SSF, or scan with RawDigger if you prefer that. With the ability to load pre-scanned values I think it's overkill to make SSF support directly inside.
-
Hi - this looks fantastic!
I just bought into the Hasselblad X1D system and their color profiles I find are already very good (compared to other camera manufactures anyway). Having said that, for many years for my last few camera/lens systems, I have prepared camera profiles for different lighting conditions with the Colorchecker Passport. That experience has already convinced me that camera profiles will meaningfully improve even Hasselblad's (apparently dual illuminate tungsten/daylight) hardwired profile even without yet testing that hypothesis (never mind the effects of polarizers, neutral density filters, day, night, shade and different lenses which I also profile). Several questions:
1. What is the best target, quality-wise, to profile with Lumariver currently? HutchColor, Passport, Digital SG, another?
2. Would your recommendation be the same for landscape shooters? (Sunlight and shade are many of our primary lighting conditions).
As a number of us will be, I am willing and actually want to spend up to a week or so to create profiles for my new camera under different lighting/lens/filter conditions. In my view, these profiles are one of the best camera investments to be made in photography since God created the lens. A printer or computer might win out too ... a close call.
For reflective targets my current opinion is that the X-Rite targets have the best quality, good finish and smooth varied spectral shapes. The Digital SG is very good, but semi-glossy and just as any glossy target I wouldn't recommend shooting it in anything but excellent setups where every precaution is made to minimize glare. The colorchecker passport or classic 24 is a good matte target, and as it's matte is more robust for non-optimal target shots.
A general recommendation is that if you're making reproduction profiles you should have a target with broad coverage, like the Digital SG or maybe even one of the huge targets (those generally have less than perfect spectral qualities though), while for general-purpose when you''re more likely to hand-tune and adjust looks a smaller target like the CC24 is better suited.
If you're making a scanner profile (which you aren't) using scanner-specific targets made of the same media as the media that will be scanned is the way to go.
Shooting target outdoors -- matte targets for sure as glare will be a problem, and concerning matte targets it's really hard to improve on the CC24.
Note that for Hasselblad there is a small quirk, as Lightroom is using proprietary Phocus profiles (AFAIK) rather than DNG profiles there are no "Adobe Standard" profiles to get the ACR Matrices from, so you can't use that feature with Hassy. It's not a big deal, the only thing it means is that you might get a small WB shift when switching between embedded profiles and your own custom profiles when the WB isn't "As Shot".
-
Pls apologize for this very basic question.
Is there any real benefit in using well designed profiles vs fine tone/color tuning in LR/CO (or others) starting from the canned profiles? I have already purchased the Lumariver Profile Designer and I am trying to get the best out of it.
TIA
Ario
-
Pls apologize for this very basic question.
Is there any real benefit in using well designed profiles vs fine tone/color tuning in LR/CO (or others) starting from the canned profiles? I have already purchased the Lumariver Profile Designer and I am trying to get the best out of it.
I think there are many more or less subtle benefits that adds up. I think most photographers are quite hard to convince of the meaning of profiling your camera, and that's why camera profiling has stayed a niche mostly related to reproduction work. There's this idea that no matter which colors the camera start out with you can with post-processing adjustments in the raw converter get the colors to where you want, combined with that many do so heavy post-processing that there's not much left of the original color.
I don't think that it's that easy, the original color will shine through in one way or another. But even if you don't think it does there's the argument that why not start off with something you like, and something that's not way different between cameras and raw converters. Quite useful if you have more than one camera to be able to match them so you can carry your own look between different cameras more easily. I still see today that many switch from say LR to CO because of the colors, and well, you can fix that with a profile, you don't need to change raw converter... And why not start off with something that's actually neutral and realistic so you have a sane baseline. To me that's very important, I don't want a distorted starting point which someone else have designed, I actually want to know how my post-processing modify colors. I just don't get it why a modern camera shouldn't produce natural colors (and those working with product, architecture and other color-critical applications often say the same).
Say 10 years ago, camera sensor color filters responses differed a lot more than they do today. The hardware was often more saturated natively (with limited signal-to-noise ratio that was a wise design choice) and harder for a profile to control. Today camera hardware is more similar and matters less while profiles can control more of the final outcome. Knowing that you have the tools to control the color regardless of camera brand or model or raw converter at least I think is valuable.
Others may like it that their brand makes the look, a view not the least common in medium format community where there's a lot of prestige in the way colors are rendered and it's almost an insult if you claim you can improve on that :). There's string quite strong mythology around colors of certain brands. But actually, it's not so much about improving a look, it's about being in control of the color and make profiles that are aligned with your own taste, rather than adapting the taste to someone else. That said, it's not easy to make any crazy look with Lumariver Profile Designer, it's anchored in neutrality and realism and you work from there. So it helps if one at least has some interest in maintaining some of that.
To all this you can say -- "I don't care, I'm happy with canned looks the manufacturers and raw converters provide", and many do, and I'm fine with that. I'm not trying to convince everyone.
I see quite different approaches using Lumariver Profile Designer too. You have one group that runs the auto mode and are happy with the default neutral & realistic profile it produces, and you have another group that spends hours and hours fine-tuning and creating their look of their own, and come up with things that are very different from how I design my profiles, and I love to see that the software is not locking in people in "my" preferred look either. For those that spend time with the software and tuning profiles for different cameras there's the added benefit that you gain a feel and understanding of how colors work, what you like and not, how cameras differ (they do a little still) etc.
So there's some sort of answer. If my company actually had any marketing people they would have stopped this project before it started :) , there really isn't a one-liner slogan that everyone will understand and appreciate. Or maybe there is... if so I haven't figured it out.
-
I'm going to do a "middle way", the next patch release will have an extra "Custom Target with Raw Values". You will still need to load a target image (where the profile is applied, camera model and baseline exposure is taken if DNG), but the image doesn't need to contain a target. That way you can import CGATS with pre-scanned values, and you can use DCamProf to make CGATS with raw values derived from SSF, or scan with RawDigger if you prefer that. With the ability to load pre-scanned values I think it's overkill to make SSF support directly inside.
does it mean that I can use dcamprof to generate some artificial target using SSF data ("dcamprof make-target") and then load this file ("The file format is Argyll’s .ti3, with some DCamProf extensions. ") ? if so a nice point to take over dcamprof under the circumstances ...
-
baseline exposure is taken if DNG
do you override this with the control in GUI or the value dialied in GUI is added to the value from DNG ?
-
for DCP (two tabs for targets/illuminants) can we have in each tab a button saying something like "copy all settings from the other tab" ?
-
I try to build a profile for DXO optics pro.
From the menu, I choose "export image for ICC profile" and "export as realistic color rendering"
Here is what I got.
Obviously, it's not linear.
How do I extract the curve? Any tools?
-
does it mean that I can use dcamprof to generate some artificial target using SSF data ("dcamprof make-target") and then load this file ("The file format is Argyll’s .ti3, with some DCamProf extensions. ") ? if so a nice point to take over dcamprof under the circumstances ...
Yes, that will work, actually using that as a test case. I'll try to release it quite soon.
-
I try to build a profile for DXO optics pro.
From the menu, I choose "export image for ICC profile" and "export as realistic color rendering"
Here is what I got.
Obviously, it's not linear.
How do I extract the curve? Any tools?
The way I make DxO Optics profiles is to export "Linear RAW" instead of "realistic color rendering" so you get a linear image. Actually I'm not sure what the "realistic color rendering" mode does. Looking at the image it seems like it has done a normal rendering with its own ICC profiles and exported it to a TIFF with AdobeRGB profile. That could suit a really old-school workflow when you add an extra ICC profile on top of the normal export. However the best way for Lumariver Profile Designer would be to use the export "Linear RAW" so it gets to work directly on the camera's (white balanced) raw data.
LRPD will in any case auto-detect the embedded AdobeRGB profile and from that understand how to linearize the data, so it should be possible to make an ICC profile from that image too, not sure how you apply it later though (I have only tried the Linear RAW mode). You can open the tone curve dialog and change the template to "Target TF" to see what transfer function that has been detected.
Note that the CCSG shots from Imaging Resource like you seem to be using here normally suffers quite a lot of glare, so often it helps using the (experimental) glare compensation checkbox when using these shots.
-
SSF data is not supported at this time, as there are extremely few users, the problem being that it's very expensive or advanced DYI/ebay project to actually shoot SSF.
I am sorry but that is wrong on both counts. For a good quality profile with the card you need spectrophotometer to measure your particular instance of the card (using reference values is a dead approach - there are substantial variations and even the same card will vary over time). The cost of monochromator approach is actually comparable with a new CC SG card - it is a bit higher but gives you non comparable advantage of measuring sensor once as opposed faffing about with shoting targets correctly under different lighting and dealing with all that target shooting involves. Add to that the price of spectrophotometer for the target measuring and the price for spectral sensitivity curves approach will look more than favourable. Not to say it will produce more consistent results with less efforts.
The whole point of my and Iliah project was to show how easy it is and give away free tools to use to make it even easier to construct.
I also would point out that there are commercial products out there that allegedly allow you to take spectral curves from the cameras as well so it this is not limited just to DIYers like me.
-
I am sotty but that is wrong on both counts. The cost us actually comparable with a new CC SG card - it is a bit higher but gives you non comparable advantage of measuring sensor once as opposed faffing about with shoting targets correctly under different lighting and dealing with all that target shooting involves.
The whole point of my and Iliah project was to show how easy it is and give away free tools to use to make it even easier to construct
Is there a link to this project? Could be nice to have in this thread.
Anyway, with the upcoming patch release you will be able to load custom targets with raw values, so you can load CGATS-like files with raw values prepared in DCamProf or other software, with or without SSF. There will be no direct support for SSF in LRPD at this time though, that is you need to prepare a CGATS file in some other software. It's not unlikely that it will appear eventually though, just because I can. I have nothing against SSF, but I just don't see many using it. If it requires an ebay purchase of rare equipment it's not going to be any volumes.
-
do you override this with the control in GUI or the value dialied in GUI is added to the value from DNG ?
In the GUI it's the baseline exposure offset that is set, and thus added to the value in the DNG.
For the custom raw value files I've now decided to disregard from the baseline exposure in the DNG though, so the values provided are the values used regardless what the DNG baseline exposure in the image is. It only matters for 3D LUTs in any case...
-
Is there a link to this project? Could be nice to have in this thread.
https://www.dpreview.com/forums/thread/4144719
but you need to hunt down cheap used integrating sphere and monochromator @ ebay... otherwise they cost a lot... some people DIY integrating spheres, coating them with ~barium sulfate inside
-
https://www.dpreview.com/forums/thread/4144719
but you need to hunt down cheap used integrating sphere and monochromator @ ebay... otherwise they cost a lot... some people DIY integrating spheres, coating them with ~barium sulfate inside
My current view on SSF is that it's good for research, testing targets, how large impact different color filter shapes has etc, but that it seems to often suffer from quite large measurement errors. To the profiler SSF always looks like "perfect", there's never glare or uneven light or those kind of non-linear measurement errors. When shooting targets the profiler gets to see the measurement errors, with SSF there are no errors as seen by the profiler -- but is the SSF provided actually matching the camera's real SSF or is it differing substantially due to measurement error when making the SSF? I have no gear to measure SSF myself, so I have just tested the stuff found on the net from some academic projects, and for my old 5DMk2 I say that shooting targets leads to a more accurate profile than using those SSF, even if you have moderate measurement errors on the target. But the theory is if you have proper accurate SSF, they should be great... I just don't know how easy it is to get accurate SSF measurements...
-
I just don't know how easy it is to get accurate SSF measurements...
neither is to get a proper shot of a target ...
-
neither is to get a proper shot of a target ...
Indeed, but in that case you get, with some practice, a good indicator of the quality. You can generally see on the matrix result if the shot suffers from large measurement errors, huge lightness errors along the neutral axis especially on the black patch, or over-saturation = glare. With a badly measured SSF the profiler still sees a "perfect camera" (but the wrong camera) so you get no indication of measurement error in the matrix or LUT calculations, you just have your eyes to decide if the final rendered image seems to produce sane result.
Target measurement errors usually leads to some saturation errors, hues are still correct. Lightness is generally not compensated for, unless you do reproduction, so the typical workflow is very robust against that. As cameras make a pretty good matrix-only match these days, the result gravitate to something linear and sane in the relax stage, further enhancing robustness.
SSF measurement errors however, I think has a tendency to also produce hue matching errors (which I think is a worse problem), but maybe I'm wrong? Although I have made many theoretical experiments with SSF I actually don't have the experience from making SSF measurements, so I stay humble about the subject.
-
Attention DxO Optics Pro users:
I've noticed that LRPD gets fooled by that the linear RAW tiffs still have an ICC profile embedded and then messes up the transfer function. I will fix that to the next patch release. However you can work around it currently by removing the ICC profile from the linear TIFF before loading it into LRPD, using exiftool like this:
exiftool -icc_profile:all= linear.tif
and then load it into LRPD and make your profile.
I've also noted that it seems that the "File -> Export Image for ICC Profile" option is only available in the Windows version of DxO Optics, don't know why. The mac version can load profiles still, but not export for profiling, so for that it seems like you need a Windows box, or complain to DxO so they fix the mac version.
-
Crashes when selecting all the following:
1) ICC
2) Neutral: from white patch
3)LUT Optimization: None
4) Curve:Linear
5) TRO:Neutral
6) Base Look:None
It seems that whatever the options are selecting ICC \Repro crashes under Win7 64.
-
OK, the demo does not allow to export profile, but how can I try applying it?
-
OK, the demo does not allow to export profile, but how can I try applying it?
You can use the Profile Comparison tab and load custom non-target images there.
-
You can use the Profile Comparison tab and load custom non-target images there.
Using a DataColor chekr24 the skin tone is too redas in common profiling. Could you be so kind and quote your reference data for SpderCC24 or point to the source of it? I might send you mine if you need it.
-
Crashes when selecting all the following:
...
Tried the same with v1.0.1 on Win without issues, but it could be related to target or target image rather than those settings. You could use File -> Archive one step away from crashing and PM me a link to have a look. Or sit around and wait for v1.0.2 which I'm working on currently, it fixes some crash things.
-
Tried the same with v1.0.1 on Win without issues, but it could be related to target or target image rather than those settings. You could use File -> Archive one step away from crashing and PM me a link to have a look. Or sit around and wait for v1.0.2 which I'm working on currently, it fixes some crash things.
BTW you should provide a WB colorpickerfor test images when testing a profile since the embedded WB in DNG or RAW might be wrong.
-
Using a DataColor chekr24 the skin tone is too redas in common profiling. Could you be so kind and quote your reference data for SpderCC24 or point to the source of it? I might send you mine if you need it.
It's data coming from scyth. You can manually adjust the skintone patch in the customize colors dialog if you think the reference is wrong. Otherwise if it's just very slightly too red it can be due to approximations in the colorimetric step, which you can control in the optimization tab. Or if that's correct it may simply be that "too red" is caused by a mismatch between the tone reproduction operator and your taste, if so you could try for example the RGB-Lum or a mixed variant which is less hue accurate and makes skintones more yellow.
-
So for ICC profiles there is only TIFF shots support?
-
BTW you should provide a WB colorpickerfor test images when testing a profile since the embedded WB in DNG or RAW might be wrong.
There is one...
-
It's data coming from scyth. You can manually adjust the skintone patch in the customize colors dialog if you think the reference is wrong. Otherwise if it's just very slightly too red it can be due to approximations in the colorimetric step, which you can control in the optimization tab. Or if that's correct it may simply be that "too red" is caused by a mismatch between the tone reproduction operator and your taste, if so you could try for example the RGB-Lum or a mixed variant which is less hue accurate and makes skintones more yellow.
The customize color tab's contorl Hue provides only in effect a Tint control - a magenta\pink axis/
-
So for ICC profiles there is only TIFF shots support?
Yes, you export to TIFF for profiling from the raw converter. That TIFF can be pretty much a straight dump of the raw data, it depends on how the raw converter does it. In any case you need some sort of profiling export from the raw converter, as to make an ICC profile the profile maker must know which pre-processing is applied before the profile, it's not standardized as for ICC.
-
The customize color tab's contorl Hue provides only in effect a Tint control - a magenta\pink axis/
It's all three axes (the "tint" is the hue axis), you can make modification in a gamut sphere around the anchor color, just not that many DE. If the patch is several DEs off then there is something really wrong though.
-
It's all three axes (the "tint" is the hue axis), you can make modification in a gamut sphere around the anchor color, just not that many DE. If the patch is several DEs off then there is something really wrong though.
I am sorry, but Hue is warm\cool (sun\sky or b Lab axis) plus tint magenta\green (wet\dry or a Lab axis). Saturation and Lightness caanot make up the b part of the Hue.
-
I simply using an ISIS XL and x-rite software to build my own Epson printer profiles - sorry for being daft, but which version should I be using, and is there any way to carry on using the Isis automated reading with Lumariver?
(great name btw!)
-
I simply using an ISIS XL and x-rite software to build my own Epson printer profiles - sorry for being daft, but which version should I be using, and is there any way to carry on using the Isis automated reading with Lumariver?
Lumariver Profile Designer is for input profiles for cameras and scanners, that is you can't make printer profiles with it :-\
-
I am sorry, but Hue is warm\cool (sun\sky or b Lab axis) plus tint magenta\green (wet\dry or a Lab axis). Saturation and Lightness caanot make up the b part of the Hue.
Hmmm... I see your point. Maybe I should change to Jab before people start getting used to JCh. It will be an incompatible behavior change, but I don't think many have started using those adjustments yet. I'll think about it. Or I simply add A/B sliders on top, it may make it more user friendly overall. Here's an example showing both sliders side by side:
http://bl.ocks.org/connorgr/0a299fe77d5c7feccd22e02f2ac5d69b
C/h affects a/b simultaneously. The shape of the local volume you can move around with the sliders will differ though, Jab will be more uniform in all directions, while JCh is more pie-shaped, and with the sliderlimited range on h you can't move effectively near the neutral axis, so I guess it's anyhow a good idea to have ab sliders.
In all, early adopters may need to be prepared that the software is moving a little bit here in the start before everything settles...
The fun thing with a lot of interest is that there is a lot of interest. The drawback is that I'm getting this backlog that grows faster than I'm reducing it... time to scrap my weekend plans...
-
Done some more thinking and there will be some A+B stuff added, maybe not all at once though. Chroma+hue can technically address all positions A+B can, but when you have the range limited to locally around an anchor color that's not the case. Still adjusting chroma isolated from the other dimensions are important and hue+chroma is considered by many as a more user-friendly color addressing, so A+B won't replace the current, there will be some sort of additional control...
-
My current view on SSF is that it's good for research, testing targets, how large impact different color filter shapes has etc, but that it seems to often suffer from quite large measurement errors.
Really? I would have said the same about targets. Why would there be even a commercial products (albeit with strange approach and costing a fortune) to take sensor spectral sensitivity curves?
To the profiler SSF always looks like "perfect", there's never glare or uneven light or those kind of non-linear measurement errors. When shooting targets the profiler gets to see the measurement errors, with SSF there are no errors as seen by the profiler -- but is the SSF provided actually matching the camera's real SSF or is it differing substantially due to measurement error when making the SSF?
What errors would those be? I take it you have not spend long actually looking how we do the measurements and what is involved.
The monochromators are easily calibrated and unlike targets do not have a habits of changing too much over time. Integrating spheres taking care of the uneven lighting. Measuring spectrum simultaneously with taking shot at each wavelength takes care of the light source fluctuations and allows to even out the response to equal-energy source. Moreover the spectrum measurements and monochromator in pair allow verifying each other. The spactral measurement that I have done with Hamamatsu sensor are a lot more prcise and stable than i1Pro (not to say they caprured with more resolution and less noise on a borad that cost less than 100$ to build). With this approach you can take measuerments of spectral curves with any light really - even tungsten halogen (xenon works best though and Iliah is looking at high power LEDs).
I have no gear to measure SSF myself, so I have just tested the stuff found on the net from some academic projects, and for my old 5DMk2 I say that shooting targets leads to a more accurate profile than using those SSF, even if you have moderate measurement errors on the target. But the theory is if you have proper accurate SSF, they should be great... I just don't know how easy it is to get accurate SSF measurements...
Do you know how those were obtained? Have you factored in the lens and the fact that your very 5Dm2 may have slightly different curves?
My experience is dramatically different from yours - the very first spectral curves I took manually using just monochromator and sphere and adjusting the light source intensity crudely gave me much better matrix profile that I never succeeded building with targets.
-
I'm glad SSF is working out for you, and it's a super-cool DIY project (I'm a bit interested in doing it myself!), and you will be able to use the measurements in the upcoming patch release, although I don't see that big value using LRPD when making matrix-only profiles and already used to programming and command line tools -- then just use DCamProf instead. It's not like SSF matrix-only users is going to be a big customer group...
Measurement errors I'm concerned about would be sensitivity at a specific wavelength (too high or low), not that the wavelength in the monochromator would be off. That it is transmissive light is an advantage though. Flare can be an issue, but not glare.
I once asked Hasselblad's Ove B if they were using SSF for making their profiles. They don't. The thing is that making a great general-purpose profile is not so much about target or measurement method if you just have decent precision, the rest is about tone operators, highlight handling, gamut handling, possibly manual tuning of individual colors etc.
Even if you have 100% precision in the measurement, the camera can't make a 100% match, and then the profiler needs to make an approximation. It makes a good job automatically, but if you're really picky you may want to adjust those approximations by eye individually, which LRPD allows. And as soon as you are doing manual adjustments by eye, that 100% exactness in measurement no longer matters.
-
Sorry to pollute the thread but if you are successfully running the v1.0.1 version of the tool under Yosemite (OSX 10.10), pls give a shout out. It looks like there may be a Mac OSX 'codesigning' problem w/ v1.0.1.
-
Sorry to pollute the thread but if you are successfully running the v1.0.1 version of the tool under Yosemite (OSX 10.10), pls give a shout out. It looks like there may be a Mac OSX 'codesigning' problem w/ v1.0.1.
I think the link you sent me in PM points to the problem, a technical build/compile issue with the third party-library libarchive (used by LRPD to archive projects). It will work on 10.11 and 10.12 (which I'm running myself), but the software won't start on 10.10. I'll look into the issue as soon as I get time. Meanwhile a work-around is to update to the latest MacOS.
-
I think you may end up having to manually compile (and set the min version) of the libarchive stuff, unless you can convince 'brew' to change it's default min_version at install time or force a rebuild.
updating OSX is a big deal for me and not desirable.
I"m not scared by command-line ;)
-
I'm glad SSF is working out for you, and it's a super-cool DIY project (I'm a bit interested in doing it myself!), and you will be able to use the measurements in the upcoming patch release, although I don't see that big value using LRPD when making matrix-only profiles and already used to programming and command line tools -- then just use DCamProf instead. It's not like SSF matrix-only users is going to be a big customer group...
And why are you making the assumption that it is usable for matrix only? Iliah was building camera profiles using monochromator approach for quite some time.
Measurement errors I'm concerned about would be sensitivity at a specific wavelength (too high or low), not that the wavelength in the monochromator would be off. That it is transmissive light is an advantage though. Flare can be an issue, but not glare.
I am sorry but that sounds a bit nonsensical. I did explain how sensitivity is measured and adjusted at each stage.
I once asked Hasselblad's Ove B if they were using SSF for making their profiles. They don't. The thing is that making a great general-purpose profile is not so much about target or measurement method if you just have decent precision, the rest is about tone operators, highlight handling, gamut handling, possibly manual tuning of individual colors etc.
I would not base my opinion on one company that has little to show for their colour reproduction know-hows. I'd start with Kodak, Hunt books and perhaps talking to former Kodak engineers regarding processes involved etc.
Even if you have 100% precision in the measurement, the camera can't make a 100% match, and then the profiler needs to make an approximation. It makes a good job automatically, but if you're really picky you may want to adjust those approximations by eye individually, which LRPD allows. And as soon as you are doing manual adjustments by eye, that 100% exactness in measurement no longer matters.
Nobody prevented a check to see how practical measured SSFs are. You need at least illuminant and lens spectral curves to make realistic use of them.
I sense that this is a dead end discussion - I am not going to pollute this thread anymore. I wish you all the luck with the product even though I am not going to use it.
-
...
ну вот на пустом месте же...
-
Hey Alexey, relax ;)
I guess I missed this part "Measuring spectrum simultaneously with taking shot at each wavelength takes care of the light source fluctuations and allows to even out the response to equal-energy source.", that of course greatly reduces measurements errors. Sorry. Don't need to be mad. I'm already very impressed by your achievement and glad that you share experience and source code so others can try it out.
I wouldn't consider Hasselblad to have little to show about color know-how. The medium format companies live and die by the color reproduction. Not all love it of course, as tastes differ (there's a reason I've made a profile maker...). Phase One doesn't use SSF either (AFAIK), but targets, their look and hand edits (not sure about their repro profiles though). There are just different methods. What I was trying to say is that even if SSF is a superior measurement method, which it surely is when done right, it's not a guarantee for superior profiles as there's so many more aspects to it. And likewise, a profile made from a reasonable good target measurement won't automatically be inferior to one based on SSF.
Good measurements always help though.
And even if you say you won't use the software now, and as said I think if you favor matrix-only profiles DCamProf is probably doing all you need already, I did register your vote on SSF features a couple of pages back in this thread and that was a reason that I'm actually adding in CGATS raw value reading to the next LRPD patch release, so I do hope you give it a look anyway when you get time, could be fun. I try to listen to my users. Daicehawk just got my eyes opened for the value of AB chromaticity adjustments, but again not without a little debate... every feature requires quite some effort to implement so I need to test the arguments a bit.
-
I think you may end up having to manually compile (and set the min version) of the libarchive stuff, unless you can convince 'brew' to change it's default min_version at install time or force a rebuild.
Yeah I'll have a look. Building libarchive myself should not too much of a mess, I'm more worried that it's the same problem with the OpenMP lib (also brew). I have like a mountain of things to do to the next patch release. Or actually not too many things, but I'm a bit stressed by all input coming at the same time, but then again I put myself into this situation so I guess I get what I deserve... :)
-
understood. no worry/rush.
-
ну вот на пустом месте же...
??? Не на пустом
-
Hey Alexey, relax ;)
"I have never been so relaxed in all my life..." ((c) "How to steal a million")
Just to say that I am never mad - but it is unfortunate when merits of several approaches are discussed without fully understanding what is involved in both.
I am ok with dcamprof and understand your target audience and reasons for new tool so don't worry about me ;). The tool I am writing for spectral sensitivity curves automation may have a component to build simple profiles for given conditions (probably using external tools like ArgyllCMS or dcamprof) - but it is a bit early to say.
-
when merits of several approaches are discussed without fully understanding what is involved in both.
a lot of useful discussions start exactly like this 8)
-
a lot of useful discussions start exactly like this 8)
To me discussions start with questions.
-
Yeah I'll have a look. Building libarchive myself should not too much of a mess, I'm more worried that it's the same problem with the OpenMP lib (also brew). I have like a mountain of things to do to the next patch release. Or actually not too many things, but I'm a bit stressed by all input coming at the same time, but then again I put myself into this situation so I guess I get what I deserve... :)
Not sure if it helps but for cross compilation on Mac I opted for getting the llvm with OpenMP support (from llvm site) and converting it to toolchain. Then I used XCode for building project and added omp dlls to the path in execurable folder with name of that folder in xml resource. That works just fine and has no dependencies on external non standard libraries.
-
Not sure if it helps but for cross compilation on Mac I opted for getting the llvm with OpenMP support (from llvm site) and converting it to toolchain. Then I used XCode for building project and added omp dlls to the path in execurable folder with name of that folder in xml resource. That works just fine and has no dependencies on external non standard libraries.
Thanks, I have no external dependencies, but have some libs built by brew, which may not be that good... I'll look into that.
-
Hey, about this CGATS. What is the patch order of a simple rectangular target? I know LGOROWLENGTH is a sort of "defacto" standard to specify the number of rows (despite its name sounds like column count).
But are the patches then listed in row by row from left to right, or column by column left to right. I seem to come across both cases, and I wonder which one that I should consider "standard".
I try to make up my mind from what seems most common, but I'm still a bit unsure... I got an issue report that LRPD is arranging custom grids from CGATS in the wrong order so I'm trying to get this right once for all...
My current best guess is that it should be column by column left to right, but I see contradicting info too.
-
My current best guess is that it should be column by column left to right, but I see contradicting info too.
Well, I made up my mind, I'll do it like PatchTool does -- row count decided by LGOROWLENGTH, column by column left to right.
(There's a bunch of smartness if LGOROWLENGTH is missing or applying custom reference to existing grids, this layout is just for the default custom grids.)
-
Thanks Anders for making this available. I have checked a number of my photos in different lighting conditions and with editing. I have for a while used the Camera Standard profile with both Canon 5DSR and Nikon D810 and although there were cases especially in morning light where I could the colors were not quite true, I liked the profile. I also purchased at some point profiles for the 5DSR from Huelight and only checked some photos and did not see much difference so did not adopt them as standard. Now with the profiles generated by Lumariver Profile Designer (LPD), I see in some pictures little difference between the Camera Standard profile and in others quite a big difference. Typically in green colors and early morning light or late in the day. Greens come out much better and clear and also the shadow details are better than the Camera Standard profile. When I check these pictures with the Huelight profiles there is much more a similar rendering of the green colors and shadow detail, but for what I have checked so far the green colors come out better with LPD. So for what I have checked so far I think it is a winner. I will continue to check on a picture by picture basis and if happy, I will adopt as my standard profile on import into Lightroom. So thanks again for your great work :)
-
Is there any consideration of a Linux version since dcamprof and Qt are so Linux friendly?
-
Is there any consideration of a Linux version since dcamprof and Qt are so Linux friendly?
Actually I run LRPD on Linux myself and Linux is my main development platform. In my telecom/datacom career Linux is very common while Mac/Windows not so much so I'm a bit of a beginner on those platforms development-wise (as you've noted regarding 10.10 compatiblity, but I'm working on it ;) ). I figured that commercial interest would be very low on Linux though so I haven't bothered making a release build, but it would probably not be too much of work to do it, so I may actually do one when stuff calms down a bit.
-
Thanks Anders for making this available. I have checked a number of my photos in different lighting conditions and with editing. I have for a while used the Camera Standard profile with both Canon 5DSR and Nikon D810 and although there were cases especially in morning light where I could the colors were not quite true, I liked the profile. I also purchased at some point profiles for the 5DSR from Huelight and only checked some photos and did not see much difference so did not adopt them as standard. Now with the profiles generated by Lumariver Profile Designer (LPD), I see in some pictures little difference between the Camera Standard profile and in others quite a big difference. Typically in green colors and early morning light or late in the day. Greens come out much better and clear and also the shadow details are better than the Camera Standard profile. When I check these pictures with the Huelight profiles there is much more a similar rendering of the green colors and shadow detail, but for what I have checked so far the green colors come out better with LPD. So for what I have checked so far I think it is a winner. I will continue to check on a picture by picture basis and if happy, I will adopt as my standard profile on import into Lightroom. So thanks again for your great work :)
Nice to hear. I hope the long term tests turns out well. If you have some specific problem with the profile it's generally tunable so if you do get some problem in the long-term evaluation let me know and maybe I can help out.
-
I've now just uploaded patch release v1.0.2, it contains the following:
New: Added “Custom Target (Raw Values)” which makes it possible to import CGATS files complete with raw values.
Fixed: hard-coded workaround to handle DxO Optics confusing profiling export images.
Fixed: adjusted CMP Digital Target 8 layout according to the manufacturer’s comments.
Fixed: now starts on older MacOS versions as advertised.
Fixed: now finds license key for unicode user names on Windows.
Fixed: minor issues around glare detection.
Improved: better auto-layout of custom targets.
Improved: better handling of manual lut/matrix/target adjustments when adding, changing and removing targets in multi-target mode.
Improved: support more ICC profile types when extracting curves.
Docs: added section about DxO OpticsPro.
The custom target raw values (repro only) allows for importing files you've prepared with raw values from third-party software, so for example you could prepare a .ti3 file using SSF in DCamProf. In this mode you still need to load a target image, but it doesn't need to contain a target.
I've hard-coded DxO OpticsPro handling to Linear RAW. In theory LRPD calculates the transfer function from the provided TIFF file and should not really need converter-specific patches, but DxO has unfortunately made that impossible by providing no information, or rather misleading information in the TIFFs... anyway, now it's much simpler to make DxO icc profiles than before.
I decided to postpone the AB chromaticity adjustment features to a later release. I've thought through the design though and it will be an addition rather than replacement of the current Hue-Chroma chromaticity functionality, meaning that it's not going to break compatibility and thus ok to postpone a bit.
-
thank you !
-
I bet somebody needs some sleep. :P
I've now just uploaded patch release v1.0.2, it contains the following:
New: Added “Custom Target (Raw Values)” which makes it possible to import CGATS files complete with raw values.
Fixed: hard-coded workaround to handle DxO Optics confusing profiling export images.
Fixed: adjusted CMP Digital Target 8 layout according to the manufacturer’s comments.
Fixed: now starts on older MacOS versions as advertised.
Fixed: now finds license key for unicode user names on Windows.
Fixed: minor issues around glare detection.
Improved: better auto-layout of custom targets.
Improved: better handling of manual lut/matrix/target adjustments when adding, changing and removing targets in multi-target mode.
Improved: support more ICC profile types when extracting curves.
Docs: added section about DxO OpticsPro.
The custom target raw values (repro only) allows for importing files you've prepared with raw values from third-party software, so for example you could prepare a .ti3 file using SSF in DCamProf. In this mode you still need to load a target image, but it doesn't need to contain a target.
I've hard-coded DxO OpticsPro handling to Linear RAW. In theory LRPD calculates the transfer function from the provided TIFF file and should not really need converter-specific patches, but DxO has unfortunately made that impossible by providing no information, or rather misleading information in the TIFFs... anyway, now it's much simpler to make DxO icc profiles than before.
I decided to postpone the AB chromaticity adjustment features to a later release. I've thought through the design though and it will be an addition rather than replacement of the current Hue-Chroma chromaticity functionality, meaning that it's not going to break compatibility and thus ok to postpone a bit.
-
release v1.0.2
about "Baseline Exposure Offset" control (which is not available in dcp:reproduction mode, btw) - may be it makes sense to show "Baselines Exposure" too, so that users will see the resulting total value... a problem with dual different DNG files will be when both have different values for it (theoretically it is possible)
-
about "Baseline Exposure Offset" control (which is not available in dcp:reproduction mode, btw) - may be it makes sense to show "Baselines Exposure" too, so that users will see the resulting total value... a problem with dual different DNG files will be when both have different values for it (theoretically it is possible)
Yes it's a good idea, and you can already see that in the Profile Comparison tab beside the exposure control on additional images you load. I maybe should show it on the tone curve tab too.
Baseline exposure offset is not shown in the slimmed reproduction mode as it's not really necessary to control in that workflow. I'm a bit rusty on the details as I made the new 3D LUT algorithms back in January-March, but if I remember correctly BEO is handled automatically as a part of linearization of the 3D LUT.
-
to facilitate people experimenting I am uploading several cgats files with camera raw data for Sony A7R2 camera for "....“Custom Target (Raw Values)” which makes it possible to import CGATS files complete with raw values..."
Attached are files for ColorChecker 24 target (StdA + D65 for dual illuminant "dcp" profiles and D50 for "icc/icm" profiles)
So you don't need to shoot your own target
-
to facilitate people experimenting I am uploading several cgats files with camera raw data for Sony A7R2 camera for "....“Custom Target (Raw Values)” which makes it possible to import CGATS files complete with raw values..."
Attached are files for ColorChecker SG target (StdA + D65 for dual illuminant "dcp" profiles and D50 for "icc/icm" profiles)
So you don't need to shoot your own target
-
So you don't need to shoot your own target
What's the point of using someone else's shots for profiling one's own camera? The whole idea of profiling your own camera is to account for specifics of your camera sensor and profile that. Generic profiles should probably be averaged across a few camera/sensor samples.
-
What's the point
just for experiments as noted at the beginning of the text ...
-
Does anyone know about how much cameras of the same model vary sample to sample, concerning color response (eg SSF shapes)? My guess would be that the variation is pretty small. It would be good if it's large enough to be noticable though, as that would be yet an argument to make your own profiles :)
-
Does anyone know about how much cameras of the same model vary sample to sample, concerning color response (eg SSF shapes)? My guess would be that the variation is pretty small. It would be good if it's large enough to be noticable though, as that would be yet an argument to make your own profiles :)
The sensor is the not the only component here. I fact there are a few - silicon sensitivity and structure (some variations can cause respinse variations and appear as wave pattern on spectral sensitivity curves). The CFA can vary from batch to batch. From what I tried however the most variable part is usually IR cut filters (cut off areas, ramp and transmittance over visible range).
-
Does anyone know about how much cameras of the same model vary sample to sample, concerning color response (eg SSF shapes)?
I guess changing lenses shall probably inflict more changes than sample to sample / batch to batch variations in what lies on top of silicone starting from CFA, microlenses and all the way to IR/UV cut and AA (of whatever is simulating AA in terms of light path length) layers
-
From what I tried however the most variable part is usually IR cut filters
that is certainly very probable with a niche manufacturer that makes cameras in smaller batches ... now somebody must entice lensrentals to do tests as they access to a lot of damaged gear or outlets that are in business of removing CFA to make monochrome cameras or modifying cameras for IR photography...
-
A quick question on making C1 repro profiles in LRPD, please.
The manual (and indeed Phase One themselves) mandates using the Linear Scientific curve when making repro profiles. As far as I am aware, this specific curve is only available in the very specialised and hugely expensive Cultural Heritage version of the C1 software.
Is there any way of accessing this curve in the C1 Pro version, which otherwise only appears to include the standard Linear Response curve which has a (small) roll-off in the highlights? Or any other means of achieving the same effect?
Many thanks.
-
I guess changing lenses shall probably inflict more changes than sample to sample / batch to batch variations in what lies on top of silicone starting from CFA, microlenses and all the way to IR/UV cut and AA (of whatever is simulating AA in terms of light path length) layers
This is in accordance with my experience. On a real world image shot with my earlier a7r1 I see practically no difference if I display it through a profile built for the a7r2. Whereas I see a striking difference between lenses compared to a test target.
-
I've noted that some folks is pirating the software, some guy has made a crack and all... >:( we'll I guess this means that people actually want to use it. I'm not sure how I'm going to react to it. I've never really bothered making a hard-to-crack license protection as most photographers are honest people and niche software is usually not that interesting for crackers. Obviously this is not niche enough :-\
I'm not keen on using license servers like for example BasICColor, but I'm not really fond of people pirating the software either. There's DCamProf for those that don't want to pay.
-
A quick question on making C1 repro profiles in LRPD, please.
The manual (and indeed Phase One themselves) mandates using the Linear Scientific curve when making repro profiles. As far as I am aware, this specific curve is only available in the very specialised and hugely expensive Cultural Heritage version of the C1 software.
Is there any way of accessing this curve in the C1 Pro version, which otherwise only appears to include the standard Linear Response curve which has a (small) roll-off in the highlights? Or any other means of achieving the same effect?
I'm no expert considering C1 hacks (how to access various curves inside C1), but LRPD will in repro mode compensate for the slightly non-linear "Linear Response" curve, so it shouldn't be an issue except possibly very close to highlight clipping.
-
The manual (and indeed Phase One themselves) mandates using the Linear Scientific curve when making repro profiles. As far as I am aware, this specific curve is only available in the very specialised and hugely expensive Cultural Heritage version of the C1 software.
just rename the .fcrv file from a different camera - they are present in regular distribution too ... the difference is that a regular .fcrv curve file has some flag inside (byte or two) for C1 code to deal with data near clipping, roll it nicely ... and linear scientific does not
-
> I've noted that some folks is pirating the software
This is really mean!
-
@torger, @scyth
Thank you both. I've found and renamed what is hopefully a suitable Lin Scientific .frcv file, so will experiment with that and see how it goes.
I bought a license for the repro edition at the weekend - I could probably have got by with the command line version, but LRPD was a lot less hassle, and also as a 'thank you' for all your efforts and hard work. My very preliminary and limited tests so far suggest that LRPD repro ICC profiles are at least on a par with the trial profiles that I produced with BasICColor Input 5 when that was released last year.
It's very disappointing to hear you're suffering from piracy already - hopefully most of the culprits are people who just want to play with it and/or wouldn't have paid for it anyway, so that you don't lose too much in sales. Good luck.
-
It's very disappointing to hear you're suffering from piracy already
from the practical standpoint - those who don't buy won't buy ... there is no point to suffer... it is not like a $1 app from an appstore
-
from the practical standpoint - those who don't buy won't buy ... there is no point to suffer... it is not like a $1 app from an appstore
Yes the cyber-criminals from the countries that make the cracks is sort of not the problem, they won't buy any software anyway. It's just sad to see programming talent being wasted on cracking, viruses and hacking elections rather than contributing to society by making creative useful software.
It can become a problem for me though if cracked software spread to developed countries and the half-honest folks that can afford just choose the cracked version instead. It's a problem even here in Sweden, I know people that have a really good income but still pirate movies and software like crazy just because it's easy and relatively risk-free and they just don't see the point to pay for things they can get for free, through the help of some cracker. I'm quite offended by that behavior. If kids do it, okay, but I know grown-ups that do it...
Pretty pissed right now, but you're right, I can't do much about it and it's better to just ignore it, for my temper at least. It's a sport to the crackers, to me it's just boring waste of time in a game I will lose anyway, and I don't want to make the software a license-server-dongle-whatever pain to use for my paying customers.
-
and hacking elections rather than contributing to society
as a side note - showing how clintonites conspired against bernie was a service to society regardless ;D ...
-
Any piracy must be doubly frustrating when you've priced and licensed the software so reasonably in the first place, and when the alternative command line version is still freely available. But thank you for not imposing an arduous copy protection system on your legitimate users; as has been said before, copy protection merely serves to keep honest users honest, and does little to deter the dishonest ones.
-
some guy has made a crack
JFYI - the key generation was already reverse-engineered today ... no need for crack anymore ...
-
from the practical standpoint - those who don't buy won't buy ... there is no point to suffer... it is not like a $1 app from an appstore
Pirating is a bit more nuanced than that - it's not black and white. The reality is that some people will buy anyway, some will never buy, and some people will buy if they have to. The latter is not a fixed number, it depends on the desirability of the SW, the price and the availability of pirate versions.
Niche software can be particularly vulnerable, since technically it can be just as hard & expensive to develop as mainstream software, but has a much smaller potential market, resulting in a relatively high price compared to "normal" software. The high price confronts peoples normal judgement of fair value, creating a larger pool of people who will pirate it if they can.
Copy Protection is a pain for everyone involved, but it is not necessarily always a waste of time from the creators point of view, particularly for niche software if they use a unique scheme, since skilled crackers are less likely to want to waste time on it. It has to be non-trivial though, something that will take more than a day to figure out in IDA.
Here's an additional thought I've had about pirated software :- its availability reduces the value of the software to those who have paid for it - it justifies the feeling that they may have been foolish in buying it. So attempting to maintain exclusivity by having an effective CP scheme may be a means of increasing the buyers satisfaction in purchasing your SW. :-)
-
Pirating is a bit more nuanced than that - it's not black and white. The reality is that some people will buy anyway, some will never buy, and some people will buy if they have to. The latter is not a fixed number, it depends on the desirability of the SW, the price and the availability of pirate versions.
Niche software can be particularly vulnerable, since technically it can be just as hard & expensive to develop as mainstream software, but has a much smaller potential market, resulting in a relatively high price compared to "normal" software. The high price confronts peoples normal judgement of fair value, creating a larger pool of people who will pirate it if they can.
Copy Protection is a pain for everyone involved, but it is not necessarily always a waste of time from the creators point of view, particularly for niche software if they use a unique scheme, since skilled crackers are less likely to want to waste time on it. It has to be non-trivial though, something that will take more than a day to figure out in IDA.
Here's an additional thought I've had about pirated software :- its availability reduces the value of the software to those who have paid for it - it justifies the feeling that they may have been foolish in buying it. So attempting to maintain exclusivity by having an effective CP scheme may be a means of increasing the buyers satisfaction in purchasing your SW. :-)
Thanks for your thoughts. I know I probably have to do something and just not stand and watch as people steal my income. I too realize that this type of software is the one that is most hurting of piracy due to price range (not too low, not too high) and that it's niche. I'm right now so f**king pissed I'm considering pulling the software all-together, but of course I have the responsibility to my paying customers. Priority one is to not make them suffer. I knew this could happen and I didn't think I would be so angry, but I really am. It's the exact same feeling as someone has stolen my property.
The problem is that making a copy protection worth its name is several weeks of full-time job. I did this about 12 years ago for my employee at the time and it was a real mess, and the methods since then needs upgrading for sure so I have a lot of reading to do. I don't have that much coding now, so it means post-poning features I had in mind in future updates possibly for months, just because going to war with crackers and make less honest people feel like "not being stupid to pay for something they can rip for free" -- and I know more people than you'd like have that kind of mindset, all this is really making me angry.
We'll, I'll try to leave this behind me and focus on questions and development related to profiling... I'm not making anyone happy by whining, except for that it felt a bit better for myself for a moment ;).
-
Sad to hear about the piracy. I bought the software because I like to have a GUI and also to honour your work on DCamProf. Lumariver profiles are competitive to basICColor Input 5 profiles (which I own too). On top of that you can modify the profile in nearly any way. And all that for the third of the price. This is really a bargain.
As there is no big market for your product I don't think your software will have a lot of seeders. And therefore it may be cracked now but not shared anymore after a few weeks.
Maybe you should just put some comments on the biggest torrent/download sites with hints to dangerous virus inside the crack. Or write the truth in the same way you did it here. Both strategies may slow/reduce the sharing of the crack.
On the other hand I don't think that much people would use the crack. Creating a profile isn't that simple and users of profiling software are aware of the work behind such a program. Thats why I'm sure they are also willing to pay for it.
Did you made some marketing for the program on other sites/forums? Or did you asked lula for a review/interview? DCamProf created a lot of hits on their site and this would be a nice way to say thank you. This will not help with the piracy but you'll may get some more sellings.
I hope the best for you and thanks for your products.
Sebbe
-
The problem is that making a copy protection worth its name is several weeks of full-time job.
you actually want to consider doing this, because Lumariver HDR is going to be next... I just read the question about it in the same thread over there... btw, ~$15 FastRawViewer is absent from that place... just saying
-
Just bought it. I respect the efforts of all software designers.
-
Or did you asked lula for a review/interview?
do you really need to ask ? I'd assume you can simply write a good article and submit it ... that shall indeed increase the bottom line too
-
The problem is that making a copy protection worth its name is several weeks of full-time job.
Yep - it feels like a complete waste of development effort - effort that would be better spent on improving your software. About all I can say is that there is some satisfaction in devising things to slow the crackers down, and hopefully get them to give it up as being not worth the effort.
-
the most cheap way to slow enemy down is
1) publicly available binaries (for trial) have certain functionality simply not compiled in ( = not if, but #IF ) and certain other functionality hardcoded inside ( again the same way - so you can't change couple of bytes to bypass )
2) fully functional binaries are downloaded after purchase only - you email buyer a link, then remove it ... and again different versions have different code compiled in binaries (not if checks in code)
-
Thought about it a bit, and I'm probably not going to do anything about it, not yet at least. I want to concentrate on delivering value, not this b*llsh*t especially as my time is very limited and this is a one-man project. I'm actually in the midst of working with the next patch release, which ironically contains fixes for handling Russian file names on the Windows platform... the interest from eastern countries is very high, but the sales are few (not zero though!)... I wonder why...? ;)
Typical pirates generally don't buy anything ever, period. Even if it was €1, and they don't care if it's a struggling niche product from one hard-working individual or a well-established global hit from a huge company. If they can't get it for free they just don't get it, so technically you don't lose money on them, they're just a bunch of annoying ***holes, especially when they ask for support or demand some feature, or just generally say your software sucks and isn't worth the money (but still use it, just to rub it in). Serious higher end users, those that need the Pro and/or Repro editions is not the problem. Working photographers generally knows all about getting their own work pirated. I'm confident they will buy, and most customers so far are pro photographers or very serious amateurs. Many medium format users.
Where I expect to lose money is among more casual users that really only need the Basic version, but rather than paying €30 for that gets an illegal copy of the Repro for free. How many will those be? 5%, 10%, 30%, 50%? It's too early to estimate. If it's say 5-10% of actual losses it's very hard from a business standpoint to motivate counter-measures. It would be one thing if I would actually enjoy making them, but I certainly don't.
On the other hand it's for the Basic version there could be actual volume which could make this project profitable, that would be nice and it would be good for everyone. If it starts making real money I can work more on it, and I really want to. The Pro/Repro users is the core group, what makes this worthwhile and important for the quality of the project, but I need an unrealistic amount of them to actually cover development cost. There's a reason BasICColor is €500+VAT and ColorPony is $1000, and there's a bunch of half-dead or fully dead historical profilers. If you rely on pro users alone, the volumes will be very low and you thus need steep pricing.
So it's not a clear-cut case...
-
and ColorPony
how did I manage never ever hear about them :o
-
On the other hand it's for the Basic version there could be actual volume which could make this project profitable
which again seems to be the case with FRV ( plus aggressive marketing, constant free trials and low cost... the authors do not really care about what is happening in the MOTHERLAND /literally/... you can't beat it anyways so no need to worry ) ... while RD version 2 is still a pipe dream
-
Just bought it. I respect the efforts of all software designers.
Thank you sir! ;D I have had some licenses sold for DCamProf users that really isn't into having a GUI but just wanted some way to sponsor, and getting an LRPD license is a good way. I appreciate it very much. I don't like to beg though, I flash the Lumariver GUI on the DCamProf web pages now, I thought that would be enough :).
-
I purchased a repro license a few days ago and like the profiles coming out of LRPD better than X-rites or Adobe's software. Thanks for your hard work.
Would be nice to be able to enter the illuminant temperature manually because my strobes are at 4700k but the lowest I can select is D50.
-
I purchased a repro license a few days ago and like the profiles coming out of LRPD better than X-rites or Adobe's software. Thanks for your hard work.
Would be nice to be able to enter the illuminant temperature manually because my strobes are at 4700k but the lowest I can select is D50.
for dcp profiles the codes that can be used are :
0 = Unknown
1 = Daylight
2 = Fluorescent
3 = Tungsten (incandescent light)
4 = Flash
9 = Fine weather
10 = Cloudy weather
11 = Shade
12 = Daylight fluorescent (D 5700 - 7100K)
13 = Day white fluorescent (N 4600 - 5400K)
14 = Cool white fluorescent (W 3900 - 4500K)
15 = White fluorescent (WW 3200 - 3700K)
17 = Standard light A
18 = Standard light B
19 = Standard light C
20 = D55
21 = D65
22 = D75
23 = D50
24 = ISO studio tungsten
255 = Other light source
unless somebody corrects me
xenon strobe shall be OK to be coded as D50 for a general purpose profile
-
I've been meaning to buy this simply because the underlying documentation is far better than anything else I've run across and I respect the work that has been done to create it. I'm happy, and facile enough, with the command line stuff but buying the gui product seems the least I can do given that value I've already reaped.
-
I've been meaning to buy this simply because the underlying documentation is far better than anything else I've run across and I respect the work that has been done to create it. I'm happy, and facile enough, with the command line stuff but buying the gui product seems the least I can do given that value I've already reaped.
one of my motives too ... plus the fact that author is available for interaction on the forum (and dudes from BasiCColor - not ... so minus to their karma)
-
one of my motives too ... plus the fact that author is available for interaction on the forum (and dudes from BasiCColor - not ... so minus to their karma)
If you write BasICColor an e-mail one of the developers reply nicely and they give you their phone number as well. But maybe it's because my native language is the same as theirs. :)
The big things + of lumariver over dcamprof are the GUI for curve editing and the look editing. I tried that with dcamprof but it was too much try and error workflow. After two years getting nuts with profiles I have now a nice starting point for my processing. If there is more time I will even create some base-styles and save them as profiles (e.g. "saturated midtones except for skin colors").
-
Would be nice to be able to enter the illuminant temperature manually because my strobes are at 4700k but the lowest I can select is D50.
You can by selecting the "Illuminant: Black-body" and then enter the temperature in the separate field.
-
You can by selecting the "Illuminant: Black-body" and then enter the temperature in the separate field.
Great, I will give that a try. Thanks
-
After some delay, v1.0.3 has been released:
New: now possible to adjust hues with a+b sliders in addition to
hue+chroma, for additional control of chromaticity, especially near
the neutral axis.
New: Jab adjustment patch in the look adjustment editor as an
alternative to the default JCh adjustment. Again for better control
around the neutral axis.
Fixed: apply any custom target adjustments before finding out whitest
patch rather than after.
Fixed: accept longer patch names to better support SpectraShop CGATS
files.
Fixed: matrix calculate button was in some situations incorrectly
disabled with white patch auto setting.
Fixed: now full unicode support in all filenames on Windows.
Fixed: portable filenames in the .zip archives (so Mac archives work
on Windows and vice-versa even if non-ASCII filenames are used).
Fixed: when DCP tone curves are imported they are now interpolated
using cubic spline, as said in the DNG specification 1.4.0.0
(before it was linear).
Fixed: locked GUI on MacOS when opening project files from the Finder.
Fixed: glare matching setting didn’t stick.
Fixed: crash with custom grids due to automatic flatfield correction
was falsely triggered.
Fixed: crash when using CMP Digital Target 8.
Fixed: uninitialized data access on toolbox tab change leading to
crashes in some occassions.
As you see mostly fixes, but I finally added the Jab controls for color adjustments as suggested by "daicehawk" a while back. The main advantage with Jab is better control near the neutral axis, but some users prefer Jab over JCh also further away from neutral. Note that if you make DNG profiles the ability to tune the neutrals are limited in practice as the DCP format doesn't allow colorizing neutrals. If you're really hardcore I guess you could disable all neutrals on the target except one and tune that, and that way shift the fixed neutral.
-
Did you finish all the big fixes now and have time to consider small UI-like requests ?
-
Did you finish all the big fixes now and have time to consider small UI-like requests ?
I'm sort of considering summer vacation ;), but sure something needs to be in the next release too. Most efforts will for a while probably go to user support (which generally includes fixing some bugs still left) and tuning the repro workflow in collaboration with art repro professionals, while enjoying the short Swedish summer.
-
I'm sort of considering summer vacation ;)
sorry to rain on your parade - but people are already up in arms after your new licensing code ...
-
sorry to rain on your parade - but people are already up in arms after your new licensing code ...
Heh, of course they are, why would they stop now? It's a game to them. I guess we have to let them play...
-
Many thanks for this. So happy to be able to use my Color Checker with Capture One as fully as I'd like.
Purchased.
-
Is it possible add a function to import external 3d-lut and convert it to DNG profile with Lumariver?
-
Is it possible add a function to import external 3d-lut and convert it to DNG profile with Lumariver?
I assume it would be added as a looktable only, that is on top of the base profile, and the import format would be say ".cube". That could be done, but note that a DNG LUT can colorize the neutral axis so it may not be possible to apply all changes the imported LUT does.
What is the desired workflow / use case?
-
Useful Digital Transitions/Phase One guide to creating repro profiles for Capture One:
https://dtdch.com/wp-content/uploads/2017/04/Public-Color-Guide-DTDCH-v2.pdf
Malcolm
-
What is the desired workflow / use case?
one might assume to use tools like www.3dlutcreator.com (with quite developed UI) and then just save time by moving that into dcp profile to get similar output directly from ACR/LR w/o going to PS or so
-
What is the desired workflow / use case?
- dE-values/result documentation/export after each step (optimization, tone curve, look or at least at the end). that way I can easily see what impact a change has. At the moment LUT optimization, TRO-variant, gamut compression, base look are some kind of a black boxes.
- load and save of "edit look adjustements"
- show target grid (with the reference values) are visible on all slides and not only on "target".
-
Useful Digital Transitions/Phase One guide to creating repro profiles for Capture One:
https://dtdch.com/wp-content/uploads/2017/04/Public-Color-Guide-DTDCH-v2.pdf
Malcolm
Thanks!
-
I'm right now so f**king pissed I'm considering pulling the software all-together, but of course I have the responsibility to my paying customers.
I understand your disappointment. What about adding new features/improvements to the software making every pirated version obsolete?. They would serve in the same way as the console version: to let people know what the software can do and generate an interest on the "full"/upgraded version.
You'd need to manage the upgrade policy with present paying customers, so as introducing a better protection on the new released versions.
Regards
Enviado desde mi ALE-L21 mediante Tapatalk
-
I understand your disappointment. What about adding new features/improvements to the software making every pirated version obsolete?. They would serve in the same way as the console version: to let people know what the software can do and generate an interest on the "full"/upgraded version.
You'd need to manage the upgrade policy with present paying customers, so as introducing a better protection on the new released versions.
Regards
Enviado desde mi ALE-L21 mediante Tapatalk
I can only repeat the suggestion - do not make fully enabled code to be available for download - compile binaries on demand, email the links ...
-
I've recently bought the basic version and, so far, am very happy with it and looking forward to trying out some of the options to build different profiles.
One aspect does slightly frustrate me is the model/pricing strategy.
Whilst the basic version is a good price, the pro version is a rather big jump in price for casual users of CO like myself. I understand that the repro version can command a serious premium.
From Guillermo's suggestion;
What about adding new features/improvements to the software making every pirated version obsolete?.
How about an amateur version that can build both DCP & ICC profiles without all the advanced options (at a slightly high price than the current basic version, say 45euros) and a Pro version for advanced users. Less versions to worry about and maybe a bigger market for the cheaper version.
Also some upgrade pricing between versions wouldn't go amiss either.
-
... Whilst the basic version is a good price, the pro version is a rather big jump in price for casual users of CO like myself. I understand that the repro version can command a serious premium.
...
Basicaly the same question:
On one side I'm happy that CO is considered pro and Lightroom not, but on the other side it is a big difference.
-
Just bought the Repro :)
-
Just bought the Repro :)
Same here.
Cheers,
Bart
-
Basicaly the same question:
On one side I'm happy that CO is considered pro and Lightroom not, but on the other side it is a big difference.
I do not see it as a Pro / non-Pro thing, but rather that e.g. ICC based profiles are more of a challenge due to the different ways that different Raw converters treat them. DNG profiles are more strict/uniform in their requirements, which can also be a benefit for those who live in the Adobe ecosphere.
The price difference probably also has something to do with potential target audience size (and possibly support requirements, something that's no mean feat for a one-man operation).
Cheers,
Bart
-
I do not see it as a Pro / non-Pro thing, but rather that e.g. ICC based profiles are more of a challenge due to the different ways that different Raw converters treat them. DNG profiles are more strict/uniform in their requirements, which can also be a benefit for those who live in the Adobe ecosphere.
The price difference probably also has something to do with potential target audience size (and possibly support requirements, something that's no mean feat for a one-man operation).
Cheers,
Bart
The pro gives extra options too, that are rather interesting.
-
Hi
As a Capture One user, a question:
If I read the info here and the manual correctly the new ICC profile (as done using the "normal" Capture One instructions), will make a "pleasing" neutral "look", but keeps the tone curves from Capture One.
Will that be a drastic other look or quite similar, but with "correcter" colours?
-
Regarding pricing, nearly all C1 users I've had contact with are pro users or very high level non-professionals, and C1 is not a cheap raw converter so the volumes are lower and pricing higher, and there's also more user support as users this segment more often have an interest in making advanced tuning. Lots of medium format users or very high end 135 cameras. The DCP space is more volume, more casual and less professional, and thus I made a specific product for that. It's the Basic edition that's intended to be the odd one out, not the others. I see it as a big jump down rather than a big jump up :-). Sure I'd love to sell tens of thousands of this and just need to charge €10, but profiling is niche software which quite few use, it's a connoisseur thing, and the relative low volume leads to steeper pricing (LRPD isn't the most expensive profiler out there...). Otherwise you can just as well give it away for free like DCamProf or Adobe DNG Profile Editor.
That said I might still consider a Basic/ICC version later on if the interest is proven to be large but I haven't seen much of that so far.
-
Hi
As a Capture One user, a question:
If I read the info here and the manual correctly the new ICC profile (as done using the "normal" Capture One instructions), will make a "pleasing" neutral "look", but keeps the tone curves from Capture One.
Will that be a drastic other look or quite similar, but with "correcter" colours?
What some users think is an almost undetectable difference others think is a drastic difference, so it's a bit hard to say. It depends on subject material, the more colorful like flowers etc the easier it is to spot differences, otherwise the differences are quite subtle. I'd say that for most subject material it's quite similar but with more realistic color reproduction. It does depend a bit on camera model too as C1 doesn't have the exact same look for all models, but often makes overly warm looks (if you prefer more realistic reproduction), while LRPD default is more neutral.
-
Regarding pricing, nearly all C1 users I've had contact with are pro users or very high level non-professionals,
It's hardly got much publicity yet so you're selling to the CM enthusiasts who've followed your other high end ventures. Sell at a high price and users will demand a lot of support.
CO doesn't have to be expensive. People like myself who bought CO early on can still follow a relatively cheap upgrade path to keep current. It's cost me less than LR overall to stay on the latest version.
That said I might still consider a Basic/ICC version later on if the interest is proven to be large but I haven't seen much of that so far.
The people you need to listen to are potential customers, they're the ones that will generate new income. Not the nit picking obsessives who want every possible option they've ever heard of, but 99% of people won't understand/want/need.
-
It's hardly got much publicity yet so you're selling to the CM enthusiasts who've followed your other high end ventures. Sell at a high price and users will demand a lot of support.
CO doesn't have to be expensive. People like myself who bought CO early on can still follow a relatively cheap upgrade path to keep current. It's cost me less than LR overall to stay on the latest version.
The people you need to listen to are potential customers, they're the ones that will generate new income. Not the nit picking obsessives who want every possible option they've ever heard of, but 99% of people won't understand/want/need.
Good points. I'll think about it. It won't change in near-time though, it's early days and everything needs some time to set. Price vs expected support thing is not really matching, just try making a mobile app and you'll see ;)
-
Price vs expected support thing is not really matching,
Support is often proportional to the number of features available.
Make a basic version for dcp and icc WITHOUT all the high end options and you'll cut down your potential support issues.
-
Regarding pricing, nearly all C1 users I've had contact with are pro users or very high level non-professionals, and C1 is not a cheap raw converter so the volumes are lower and pricing higher, and there's also more user support as users this segment more often have an interest in making advanced tuning. Lots of medium format users or very high end 135 cameras. The DCP space is more volume, more casual and less professional, and thus I made a specific product for that. It's the Basic edition that's intended to be the odd one out, not the others. I see it as a big jump down rather than a big jump up :-). Sure I'd love to sell tens of thousands of this and just need to charge €10, but profiling is niche software which quite few use, it's a connoisseur thing, and the relative low volume leads to steeper pricing (LRPD isn't the most expensive profiler out there...). Otherwise you can just as well give it away for free like DCamProf or Adobe DNG Profile Editor.
That said I might still consider a Basic/ICC version later on if the interest is proven to be large but I haven't seen much of that so far.
The prices for lumariver are fine. It reflect the work Anders put into dcamprof, the GUI for lumariver and the very detailed documentation of the process itself. On the other hand, if you're about profiling photography is at least a serious hobby for you. This means you put hundreds of hours a year into it and hundreds of dollars a year too. This program adds more creativity to my process and it gives me a better starting point for my processing which leads to less time "boring" processing. Therefore I have more fun with my hobby. In my oppinion a very good thing. :) And if I'm looking after the money I spend into this hobby (camreas, lenses, travels, software, accessories like flashes/tripods, cleaning, services, ...) the price of a repro-version is certainly below 1% of the money spent over the last 10 years.
-
Support is often proportional to the number of features available.
Make a basic version for dcp and icc WITHOUT all the high end options and you'll cut down your potential support issues.
In my experience (most time) support is just a marketing gag.
There is a good basic profiling program without all the high end options on the market: basICColor input. But maybe the price tag may surprise you. ;)
-
Hi
As a Capture One user, a question:
If I read the info here and the manual correctly the new ICC profile (as done using the "normal" Capture One instructions), will make a "pleasing" neutral "look", but keeps the tone curves from Capture One.
Will that be a drastic other look or quite similar, but with "correcter" colours?
As a fellow C1 user, Fuji shooter and with a Color Checker sitting unused on a shelf... I ended up buying Lumariver.
And Ive been really pleased with the results. At least for the current conditions, cloudy summer..., a better color rendition for sure but also tonally a little subtler. Skin noticeably more accurate. Very pleased overall.
-
It's hardly got much publicity yet so you're selling to the CM enthusiasts who've followed your other high end ventures. Sell at a high price and users will demand a lot of support.
CO doesn't have to be expensive. People like myself who bought CO early on can still follow a relatively cheap upgrade path to keep current. It's cost me less than LR overall to stay on the latest version.
I am in a similar situation. I got CO initially for €30 as CO for Sony and payed another €50 in the meantime. My only interest here is to get a replacement for the broken CO profiles. Should I get them I am done and out of here. CO colors are definitely wrong, the OOC jpgs are much closer to reality. Unfortunately, PhaseOne doesn't think so, I tried.
A long time ago I made some experiments with dcamprof even with Anders' help but got mixed results. Colors were great and showed me what could be achieved but the profiles had problems in certain images so eventually I couldn't use them. dcamprof has certainly evolved since then and I might try it again.
So I'd wish I could get a GUI version to make the process easier but twice to thrice the price of the software I want to fix doesn't quite work. And I don't even know yet if it will give me the results I want. Sorry to say that and I understand very well how much work it is to write this software.
Incidentally, can dcamprof produce the same profiles as Lumariver Profile Designer?
-
Incidentally, can dcamprof produce the same profiles as Lumariver Profile Designer?
author made some new changes that are not ported back to dcamprof code yet... but one might assume that those were not earth shattering ones
-
I am in a similar situation. I got CO initially for €30 as CO for Sony and payed another €50 in the meantime. My only interest here is to get a replacement for the broken CO profiles. Should I get them I am done and out of here. CO colors are definitely wrong, the OOC jpgs are much closer to reality. Unfortunately, PhaseOne doesn't think so, I tried.
A long time ago I made some experiments with dcamprof even with Anders' help but got mixed results. Colors were great and showed me what could be achieved but the profiles had problems in certain images so eventually I couldn't use them. dcamprof has certainly evolved since then and I might try it again.
So I'd wish I could get a GUI version to make the process easier but twice to thrice the price of the software I want to fix doesn't quite work. And I don't even know yet if it will give me the results I want. Sorry to say that and I understand very well how much work it is to write this software.
Incidentally, can dcamprof produce the same profiles as Lumariver Profile Designer?
If you just need to make one profile and have the time but not the money using DCamProf suits you better. It's free and for the most part it can make the same profiles as LRPD. There are a bunch of new features in LRPD which hasn't been backported to DCamProf (will probably do it eventually, but will be some time) but the features used for the default profile is there. LRPD is speciality software while the big name raw converters are large volume products, pricing isn't really comparable. If everything would be priced the same as large volume products there would be no niche products, or simply free or none. I do understand though that €100 is hefty if you just want to make one profile for a €300 compact camera, and I may look into catering that market later on, but for now I think DCamProf is the way to go for those users.
Regarding problems in certain images I'm always interested in having a look on those. I have a bit of a backlog currently so I'm slow to reply on complex issues though, but I'm always interested in looking at issues that can improve the software. Note that sometimes when it comes down to extreme conditions like lasers or other sorts of narrow band lights one have to make a tradeoff. Bundled profiles generally always choose robustness and let overall accuracy/quality suffer, while LRPD/DCamProf is more geared to best performance in good (=broadband) light. When shooting nightscapes and similar specially light situations when accuracy is unachievable/meaningless anyway it may be worthwhile using a maximally robust profile. You can probably do those with LRPD and DCamProf as well by tuning parameters but I haven't really focused on that so far.
-
If you just need to make one profile and have the time but not the money using DCamProf suits you better. It's free and for the most part it can make the same profiles as LRPD. There are a bunch of new features in LRPD which hasn't been backported to DCamProf (will probably do it eventually, but will be some time) but the features used for the default profile is there. LRPD is speciality software while the big name raw converters are large volume products, pricing isn't really comparable. If everything would be priced the same as large volume products there would be no niche products, or simply free or none. I do understand though that €100 is hefty if you just want to make one profile for a €300 compact camera, and I may look into catering that market later on, but for now I think DCamProf is the way to go for those users.
If someone has profiles to share for a Sony NEX-6 and a A6500 for CO I wouldn't mind to get a copy...
And it is not the camera price but the relation of CO vs LRPD. Actually, I find software pricing really difficult. Buy a certain piece of hardware and you get the software essentially for free and if it is the wrong brand the same software costs you an arm and a leg. You just feel ripped off if you payed.
Regarding problems in certain images I'm always interested in having a look on those. I have a bit of a backlog currently so I'm slow to reply on complex issues though, but I'm always interested in looking at issues that can improve the software. Note that sometimes when it comes down to extreme conditions like lasers or other sorts of narrow band lights one have to make a tradeoff. Bundled profiles generally always choose robustness and let overall accuracy/quality suffer, while LRPD/DCamProf is more geared to best performance in good (=broadband) light. When shooting nightscapes and similar specially light situations when accuracy is unachievable/meaningless anyway it may be worthwhile using a maximally robust profile. You can probably do those with LRPD and DCamProf as well by tuning parameters but I haven't really focused on that so far.
Thanks, nothing current. My experiments date back two or three years. I did send you the problematic images and you used them to further improve dcamprof. I want something robust which can be used for every image. I don't want to have to tinker with different profiles for different images. It just has to work ;) But it has to be better than CO. I can spot this look through rose-tinted glasses immediately. We are not in the analog film era anymore, you can do much better these days.
-
When shooting nightscapes and similar specially light situations when accuracy is unachievable/meaningless anyway it may be worthwhile using a maximally robust profile. You can probably do those with LRPD and DCamProf as well by tuning parameters but I haven't really focused on that so far.
time for a LrPD NightScape Edition or LrPD BlueLED Edition ;D
-
Regarding pricing, nearly all C1 users I've had contact with are pro users or very high level non-professionals, and C1 is not a cheap raw converter so the volumes are lower and pricing higher, and there's also more user support as users this segment more often have an interest in making advanced tuning. Lots of medium format users or very high end 135 cameras. The DCP space is more volume, more casual and less professional, and thus I made a specific product for that. It's the Basic edition that's intended to be the odd one out, not the others. I see it as a big jump down rather than a big jump up :-). Sure I'd love to sell tens of thousands of this and just need to charge €10, but profiling is niche software which quite few use, it's a connoisseur thing, and the relative low volume leads to steeper pricing (LRPD isn't the most expensive profiler out there...). Otherwise you can just as well give it away for free like DCamProf or Adobe DNG Profile Editor.
That said I might still consider a Basic/ICC version later on if the interest is proven to be large but I haven't seen much of that so far.
Ok.
It was not for the price itself that I asked it, just for the price difference.
BTW. I just bought the repro version. Now finding time to test it ;-)
-
time for a LrPD NightScape Edition or LrPD BlueLED Edition ;D
Heh, I don't think there's a need for a separate edition, but there may be a need for some rather different tradeoffs. This area is one of the aspects that I'm interested in doing further R&D. Desaturate and adding green (eg the central bandwidth) to the profile seems to be good ways to increase robustness in these situations, but it of course affects accuracy and look.
The key problem to work with is that you need a really wide transition zone to not get a disconnect between your normal range of colors and the extreme handling, and so far I haven't seen a way that makes it possible to keep a natural and accurate normal range and a super-robust extreme range at the same time, at least for certain cameras, as the extreme handling transition zone must stretch way into normal range colors. I'm speculating a bit here, but I've got the feeling that cameras that try hard with high ISO performance makes their color filters over-sensitive (as filtering away photons means losing signal) which makes it harder to make a sane robust profile, as they're more concerned with showing "a color" than "an accurate color".
I often say that color filters in cameras don't matter as much any longer, and for the normal range colors I think it's true the camera profile is pretty much in almost total control over the look, but when it comes to extreme color handling I think it's a factor. A camera that registers a strong signal in color ranges where the human eye doesn't makes it much harder to work with.
-
With all this discussion about licensing, why does Lumariver not respect the licenses of software it uses? A cursory examination shows the code contains LibTIFF, ExPat, and LittleCMS libraries yet none of the required license information is present. Depending on what other codebases are linked in, there are also signs that GPL code could be present as well.
-
Can I import a colorimetric DCP and apply tone curves and looks on top of it?
-
Can I import a colorimetric DCP and apply tone curves and looks on top of it?
There's no support for importing a raw profile at this time. You can import and inspect in text format, but not use it to add stuff on top. The software is designed to make profiles, not modify existing. It wouldn't be an impossible feature to add, but a quite big one so there must be a strong interest in it...
-
With all this discussion about licensing, why does Lumariver not respect the licenses of software it uses? A cursory examination shows the code contains LibTIFF, ExPat, and LittleCMS libraries yet none of the required license information is present. Depending on what other codebases are linked in, there are also signs that GPL code could be present as well.
Actually we do, or "I" in this case as this has been a one-man project (except for my colleague that helped me getting started with QT).
I've worked with many open and closed source licenses for more than 15 years, both commercially and non-commercially, both using and making. I've shared a lot of my work for free, been involved for a long time and is still involved in the open-source community. This is both my passion and profession. I respect software developers and I'm not in any case trying to misuse third-party libs. If there's some mistake I'll correct it, but I go through the licenses of the third party components to make sure I can use them commercially. Here's that license section: http://www.lumariver.com/lrpd-manual/#acknowledgements maybe I should cite licenses of the standard libs like ExPat tiff lcms but it's often not required. Not all libs require that license information is repeated in the docs, but I shall check it again. Some don't want to be cited in the docs other want it, it varies even with similar licenses so it's quite easy to make a mistake. The only GPL (a copyleft license that cannot be used in closed source software) code in there is from DCamProf which I am the copyright owner and have licensed to Xarepo which owns the Lumariver code.
Citing licenses in the docs should of course be done if required, but what's the really important thing is to make sure commercial use is ok at all, and that is what I check first before even using a library, while I may have been a bit sloppy in the citing roundup -- I did go through them but "legalese" (license language) can be a bit tricky to decode (and therefore there are many misconceptions on what's required and not). I hope I haven't missed anything, and I'm better at reading licenses than most software developers and laymen are, but now when you complain about it I became a bit uncertain...
Anyway taking LittleCMS as you mention as an example, it uses the MIT license https://opensource.org/licenses/mit-license.php,
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
So what does it mean that the copyright notice should be included in the Software? It means that if you integrate the code into your software (rather than use a pre-packaged lib like I do) the source code files must include that statement, so it doesn't suddenly change copyright or license so the company using the code suddenly think they wrote it themselves. It's for the software development. It doesn't mean that the license needs to be cited in the user docs or the lib must be mentioned. LittleCMS is used by pretty much every cross-platform software that has active color management by the way.
Funny you would mention expat (an XML parsing lib, also uses MIT license like lcms), and the MacOS version of LRPD actually uses the lib distributed with MacOS itself so it's not in the application package. The lib is there because Adobe's DNG SDK links to it, LRPD itself doesn't actually use it directly. Again it doesn't require citing in the docs. If it would tons and tons of software would need to mention it as this lib is very commonly used.
Looking at the libtiff BSD license it uses an unclear wording regarding citing (most BSD licenses use a clearer wording), so there maybe I should actually cite the license in the user documentation, most seem not to though. But you know what -- now when the software is finished and distributed I shall go through all the libs once again and mention them in that section and if uncertain like in the libtiff case I'll provide the license, it's better to mention one too many times than one too few, as there's always someone that assume I don't care about which libs I use and how I use them, but I can assure you I do care.
That said I do know it's quite common that some developers that don't really know much about open-source and licensing just use it as they please without giving it any thought on what's allowed, so I understand your suspicion especially if you don't know who I am and my history in software development. As an author and contributor to many open-source projects I'm very much aware of that situation.
Note that cross-platform commercial software like LRPD often use lots of open-source libs, as the cross-platform stuff usually is from the unix world which has a long tradition of permissive open-source licenses. Being license advisor to my former employee I know this scares business people, and there's been quite some FUD thrown around making the case that it's not safe to make commercial software other than using say Microsoft .NET or MacOS XCode as the alternatives would be riddled with dangerous licenses that force your code to be open-source (GPL is the big bad monster to those...). However this is not the case, you do need to check the licenses, and indeed GPL does put that type of limits, but nearly all common libraries has a permissive license and nearly always you just need to use a pre-packaged lib and don't need to modify the lib itself which makes it even less complicated. And the citing requirement thing is rarer than most seem to believe.
If you have more questions about licensing and libs we use in LRPD you can send me a private message. I'm myself quite interested in the subject, but I guess most readers are more interested in what LRPD actually does ;D
-
To avoid future misconceptions and really be in the clear I've now beefed up the acknowledgements section including license citing from libtiff, and libarchive that I actually had missed has the type of BSD that requires citing (as it uses a bunch of old code that has that type of license, rarely used these days): http://www.lumariver.com/lrpd-manual/#acknowledgements
-
To avoid future misconceptions and really be in the clear I've now beefed up the acknowledgements section including license citing from libtiff, and libarchive that I actually had missed has the type of BSD that requires citing (as it uses a bunch of old code that has that type of license, rarely used these days): http://www.lumariver.com/lrpd-manual/#acknowledgements
Thanks for clearing matters up! I'm glad to see you are definitely aware of licensing issues and went through the effort to ensure commercial usage was allowed.
I now need to make time to put LRPD through its paces. We still use an ancient product that requires running on a Windows XP virtual machine with Photoshop 7 (circa 2003). It remains the best product for creating camera profiles for C1. It is useless for Lightroom or other DNG applications and I certainly would like to get away from our own internal, hacked together approach.
-
We still use an ancient product that requires running on a Windows XP virtual machine with Photoshop 7 (circa 2003). It remains the best product for creating camera profiles for C1.
what is it ? the name !!!
-
what is it ? the name !!!
ColorEyes 20/20. Off the market for over a decade.
-
Many thanks for this tool, which is exactly what was needed.
I'll buy this later in the summer when I really have time to play.
A couple of cosmetic suggestions:
* buttons / settings not available in the edition that you are using should be hidden, to reduce clutter
* it would be helpful to include tool tips or other means of self-documentation to obviate the need to jump backwards and forwards between the program and your (excellent) documentation
* the tool could give some overall indication of the quality of the target and the quality of the profile. (Perhaps that is only available in the more advanced editions than the basic version I tried.) Quite a few of tweaks that I tried made little difference to the preview (when rendered).
Thanks again.
-
Many thanks for this tool, which is exactly what was needed.
I'll buy this later in the summer when I really have time to play.
A couple of cosmetic suggestions:
* buttons / settings not available in the edition that you are using should be hidden, to reduce clutter
* it would be helpful to include tool tips or other means of self-documentation to obviate the need to jump backwards and forwards between the program and your (excellent) documentation
* the tool could give some overall indication of the quality of the target and the quality of the profile. (Perhaps that is only available in the more advanced editions than the basic version I tried.) Quite a few of tweaks that I tried made little difference to the preview (when rendered).
Thanks again.
Thanks for the suggestions, they're all good. It comes down to time required to implement them and other priorities. I keep a list though, adding these on there!
Many tweaks does indeed have a small impact, especially if you only view the target image. It's almost impossible to view changes in skintone on a flat skintone patch on a target for example, what you need is real pictures and do A/B swapping between new and old (profile comparison tab), then changing tone operator (for example) becomes much more visible. Changing gamut compression is invisible unless you have an image with high saturation colors etc.
Regarding quality of the target there's no artificial intelligence there to identify if it's good or bad, but you can with some experience see it. Poor lightness matching of the grayscales usually mean uneven light (open up the tune matrix dialog to see matching), light dark patches means glare, oversaturated profile means glare, the glare number beside the (experimental) glare compensation checkbox means either uneven light or glare. However, due to that matrix matching is really robust and LUT correction is per default conservative a bad target shot doesn't necessarily mean a bad general-purpose profile, there's many factors involved, which does mean that such an artificial intelligence to make a good evaluation of the quality is quite tricky to implement.
However, just automatically identifying if the lighting is uneven or there's much glare would be quite easy to implement. That would be triggered by 90% of the casual CC24 shots though and since those shots generally still make good general-purpose profiles I'm not sure how valuable such a feature would be.
-
However, just automatically identifying if the lighting is uneven
typically (one might hope that readers always do this actually ) if you have a decently flat-fielding surface (I use Novoflex XL grey card) behind the target then FRV (fastrawviewer) will nicely illustrate visually how uneven is the light using its simulation of overexposure option ... I have a steel sheet painted with matte black paint on which with rare earth (painted black) magnets I mount that grey card and on top of it - a target... looking @ form of the shadows from those tall & thin cylindrical-shaped rare earth magnets help to make the light (I use one source) ~orthogonal to the target surface (I shoot with lens at angle and with light orthogonal - I rather have as even illumination as possible with the light source I use - Solux halogen bulb)
-
Dcamprof saved my tail last year with LR/ACRs totally effed up profiles for the E-M5II. Just noticed this new GUI based tool. Looks amazing and awesome. Will have to purchase and start using later in the summer when I actually have some time again. Honestly the new manual alone could be sold for the asking price - more useful information on building generic profiles than I've seen anywhere. Amazing work. Glad I'll have an excuse to contribute some money to the effort.
One question before I forget...
What do you now think about dual illuminant profiles? It seems StdA is drastically different from D50 in many ways and perhaps the interpolation is actually undesirable unless you really are right in the middle and can't/don't do a specific profile shot?
I guess my question is that if I try to creatively "warm" a D50 scene using LR/ACR WB sliders would I be better using a single illuminant D50/D65 or similar profile when making that WB adjustment rather than a dual illuminant profile that will start interpolating in a simplistic and perhaps "wrong" way towards the vastly different StdA profile? Or is that interpolation exactly what I want in that kind of situation?
I understand with a LookTable you almost certainly want to use single illuminant profiles since there is only one LookTable and it is unlikely you'll use the same table for StdA and D50. But I'm more wondering about the rest of the profile under "small" changes in WB - better to stick with one set of tables for the closest illuminant and leave interpolation to "large" changes.
Related question - are the "base look" options and tone operators tuned differently for StdA and D50? Meaning if I just leave all "defaults" to create a D50 and StdA profile will those profiles in fact likely have different LookTables? If so how does the software decide which to use when doing a dual illuminant profile?
Hope my questions are at least understandable if not downright stupid...
-
Many/most cameras really struggle when you get down to StdA (2700K), they're not really optimized for that, and you often gain from making manual tradeoffs in the optimization because the matching is so bad that the automatic optimization may not match with the tradeoffs you would prefer. The advanced tutorial has an example: http://www.lumariver.com/lrpd-manual/#tut_step4
That was not what you asked about though, but I just wanted that out of the way :). In any case a 2700K profile is generally much more of a compromise than 5000K, and on top of that tungsten profiles is often used in sub-optimal mixed light, as if you want good colors you'd strive for good light, which would be higher temperature. I haven't really investigated where the "breakpoint" is, probably different between cameras, but I assume that already at 3500K it's much better, and above 4000K I think the matching would be as good as at 5000K.
Dual-illuminant is about convenience, not about precision. You don't need to manually swap between different profiles. The interpolation as defined by the DNG spec is indeed simplistic, but I think it's okay regarding the often suboptimal situations a StdA profile is used in anyway, and good light is almost always 5000K and above when the high temp profile will take over. I have only briefly made some experiments with interpolation vs real profile for targeted temperature and from what I remember my conclusion was that it's okay, but a real profile is of course always better. When creeping down towards StdA it's certainly better to use a dual-illuminant profile with StdA than just a D50 profile with WB adjustment. Maybe at 4000K the interpolation do more harm than good, but the difference is not large.
I use dual-illuminant myself, for convenience. But then my shooting style is such that for all shots that matter the light is ~D50 or above (meaning that the daylight profile is then used alone), and the StdA is for my needs just a fallback for say documentary style indoors usually in bad light so I'm simply not as picky there. I rarely come across "real" StdA these days, it's generally a mix of artifical lights, often with bad CRI. If one is picky, shooting a color checker at the scene and make a custom profile for the venue, often with manual tuning, would be the way to go for that tricky lighting.
Regarding if it's better to stick with fixed profile than interpolation for small changes, I don't think it matters that much as the interpolation will have very weak effect when close to a main illuminant.
It is an interesting subject, would a 3000K-5000K be better than 2700K-6500K profile for example? Maybe, I don't know as I haven't done enough experiments. To test the simulation capabilites of DCamProf using SSF would be a place to start. I personally use the combo StdA-D50 or D55, I think D65 is unnecessarily high. It happens quite a lot from 3000K down to 2700K (the temp scale is not linear when it comes to color) so I'm thinking maybe one should step up a bit on the low, but I haven't made any serious testing there. It would be interesting to hear if someone else has some experience or ideas to share.
The "base look" is tuned for daylight. As it's subtle it won't cause any carnage at StdA, and maybe it even works good there, I just haven't tuned it for that specific light.
-
I've just snatched the Repro version to create some C1 profiles. Happy to support a fellow programmer/photographer.
-
I picked up the Repro version as well for my Sony and Capture One. Excellent work Anders,
Dave
-
It is an interesting subject, would a 3000K-5000K be better than 2700K-6500K profile for example? Maybe, I don't know as I haven't done enough experiments. To test the simulation capabilites of DCamProf using SSF would be a place to start. I personally use the combo StdA-D50 or D55, I think D65 is unnecessarily high. It happens quite a lot from 3000K down to 2700K (the temp scale is not linear when it comes to color) so I'm thinking maybe one should step up a bit on the low, but I haven't made any serious testing there. It would be interesting to hear if someone else has some experience or ideas to share.
Thanks Anders for the detailed reply. Very helpful!
It will probably be late summer before I have time to setup any controlled testing - but if I do end up trying out some different dual illuminant setups I'll be sure to share my results here.
-
When I want to download my reference file made with BasicColor, this window appears:
The reflectance spectra are missing and the illuminant is unknown or unsupported, so the colors can not be identified. Add an "ILLUMINATION_NAME" entry to the file (must be either D50 or D65). [/ I]
I solve this problem by adding the proposed ILLUMINATION_NAME "D50" text just after the CREATED draft.
But this information already exists in the field CONDITIONS OF MEASUREMENT inthe BasicColor file. Could you add this condition to avoid rewriting the information?
Regards
-
When I want to download my reference file made with BasicColor, this window appears:
The reflectance spectra are missing and the illuminant is unknown or unsupported, so the colors can not be identified. Add an "ILLUMINATION_NAME" entry to the file (must be either D50 or D65). [/ I]
I solve this problem by adding the proposed ILLUMINATION_NAME "D50" text just after the CREATED draft.
But this information already exists in the field CONDITIONS OF MEASUREMENT inthe BasicColor file. Could you add this condition to avoid rewriting the information?
Regards
Yep, added to the TODO list. Thanks for reporting.
(I'm not reading as often here currently. I'm reading frequently in some periods, other periods not so much. So if anyone has a specific support issue you can drop an email too, and indeed I got this issue via mail too and saw it there first.)
-
Hi Anders!
I have recently bought some of these lamps:
https://store.yujiintl.com/collections/high-cri-led-lights/products/bc-series-a60-high-cri-remote-phosphor-led-bulb-unit-2-pcs
which offer 5000K and D50 in an E27 socket and have impressive curves. They were originally thought just for enlightening my "darkroom" for tonal editing. Then I thought they might as well be used for shooting the Color Checker for creating color profiles for all my lenses. They would be much more comfortable to work with than the Solux.
For the shooting, I set the camera to 5000K. Iridient calls that 5150K (non-DNG figures).
However, when I view the resulting shots on my calibrated screen, the middle gray patch reads 96-97-96 in Solux light, and 96-96-91 in Yuji light. So it looks like the Yuji lamps are lacking in blue.
Question: Does this make a difference for the profiles? Or will it disappear because dcamprof/Lumariver Profiler calculates an ideal white anyway? I can not look through this and would appreciate enlightenment.
Best regards - Hening
I sent a copy of this post as e-mail to your PM address.
-
:) Sharing my Velvia Builds
NikonD810-jc1-D810-velvia.icc < Link > (https://www.dropbox.com/s/4vsj4wdj5xt7tdg/NikonD810-jc1-D810-velvia.icc?dl=0)
FujiXT2-jc1-XT2-velvia.icc < Link > (https://www.dropbox.com/s/x39azg84awggokh/FujiXT2-jc1-XT2-velvia.icc?dl=0)
-
Velvia Color Justification
Reference Raw: Checker24 in < Imaging Resource (http://www.imaging-resource.com/PRODS/fuji-x-t2/XT2hVFAI00100.RAF.HTM) >
Reference file: < here (https://www.dropbox.com/s/m6djw8fs7jszxae/XT2sg_ck24-Velvia-ref_427.txt?dl=0) >
Derived by converting Reference Raw to Tiff with Fujifilm RFC ver 4.2.7.0 and with simulated color set to Velvia.
Reference color was extracted with PatchTool.
Based on test images, new profile yields more pleasing blue sky, though old copy has lower dE.
Curve to be set to AUTO or standard film curve, just likes with C1 generic profile.
NikonD810-jc1-D810-velvia build 002 < here (https://www.dropbox.com/s/5h0us6feif3n45x/NikonD810-jc1-D810-velvia%20build%20002.icc?dl=0) >
-
The Lumariver profile designer is worth every € over dcamprof for ease of use. Indeed it is so easy to create new profiles that putting some work into enhancing the facilities for documenting the settings used to generate a particular profile would be welcome.
I find that the differences between different "looks" is very subtle and so probably not worth refining much further. My pictures certainly look much more natural than with the base Adobe profile.
One characteristic of the Natural+ profiles for the camera that I have worked most on (Leica SL) is that saturated highlights (e.g., on flowers) get lightened and desaturated. So I often have to reduce the highlights considerably in ACR/Lightroom. This may be a side-effect of the way that highlight roll-off is handled by the profiler. Is there any way of producing a profiles that produces darker, more constrasty, highlights?
It's sometimes instructive to compare what the Lightroom "Auto tone" setting does under different profiles. In my case, it often raises the shadows and increases the exposure. It would be good to have a tone curve in Lumariver that was closer to what ACR auto-tone produces, as I often find that to be a good starting point for further adjustment (typically for the Black / White points, e.g.)
-
One characteristic of the Natural+ profiles for the camera that I have worked most on (Leica SL) is that saturated highlights (e.g., on flowers) get lightened and desaturated. So I often have to reduce the highlights considerably in ACR/Lightroom. This may be a side-effect of the way that highlight roll-off is handled by the profiler. Is there any way of producing a profiles that produces darker, more constrasty, highlights?
Assuming you're working on Raw data instead of cooked pixels in tiff format, the highlight contrast for more defined highlights may be caused by the editing app itself which from what you describe is compression or flatness and dullness to colored flower petal highlights in the app's attempt to reduce the color gamut (primarily controlled by luminance) and thus dynamic range.
With ACR/LR's PV2012 you have to brighten with the White slider by first pulling back Highlights to -100. This puts back the linear scaling toward max clipping of highlights that was in PV2010's Exposure slider and thus preserves highlight definition.
I can't speak for how to do this in C1 or other Raw editing apps. This behavior with PV2012 is why I've stuck with PV2010.
I don't believe you can expect a camera profile to control this kind of behavior to highlights on a consistent basis since scene dynamic range with daylight lit colored flowers varies drastically both in color gamut and color clipping near full saturation.
-
Thanks. Yes, it's PV2012 that I am using.
I though that I remember reading somewhere in the manual that a setting raises and desaturates the highlights. I wonder whether it's possible to reverse that effect.
I can see that a universal profile may be impossible, but I would have hoped that it might be possible to generate a profile against which you don't have to fight to get a good starting point.
-
Thanks. Yes, it's PV2012 that I am using.
I though that I remember reading somewhere in the manual that a setting raises and desaturates the highlights. I wonder whether it's possible to reverse that effect.
I can see that a universal profile may be impossible, but I would have hoped that it might be possible to generate a profile against which you don't have to fight to get a good starting point.
I've found for preserving detail and definition in saturated bright surfaces to make them as bright as possible is to use HSL panel in ACR/LR. See the A/B comparison of only adjusting yellow luminance, but I used a dual illuminant DNG profile made in Adobe DNG Profile Wizard which always saturates these types of colors. You can also use the adjustment brush on just the areas of detail you want to preserve.
-
Velvia Color Justification
Reference Raw: Checker24 in < Imaging Resource (http://www.imaging-resource.com/PRODS/fuji-x-t2/XT2hVFAI00100.RAF.HTM) >
Reference file: < here (https://www.dropbox.com/s/m6djw8fs7jszxae/XT2sg_ck24-Velvia-ref_427.txt?dl=0) >
Derived by converting Reference Raw to Tiff with Fujifilm RFC ver 4.2.7.0 and with simulated color set to Velvia.
Reference color was extracted with PatchTool.
Based on test images, new profile yields more pleasing blue sky, though old copy has lower dE.
Curve to be set to AUTO or standard film curve, just likes with C1 generic profile.
NikonD810-jc1-D810-velvia build 002 < here (https://www.dropbox.com/s/5h0us6feif3n45x/NikonD810-jc1-D810-velvia%20build%20002.icc?dl=0) >
Thank you for posting this. I am interested in doing this myself for a couple of my cameras.
Are there any reference sites you can link to that step through the process a bit more in detail?
-
Very brief summary in < here (https://www.dpreview.com/forums/post/60017795) >
Too few feedback so I am unsure if these custom profiles work satisfactorily for general photography.
-
Will buy a lite version that allows:
- Opening multiple raw images at once
- Selecting a monitor profile different from the system one
- Selecting\adjusting a display curve applied to open raw images
- Selecting the workspace or it being ProPhoto or similar (larger than Adobe RGB)
- WB of each image by a right-click and selecting the weighting area square like the RT
- Exposure compensation +-3stops to set a middle gray as one wants to (the middle gray in the histogram being the default)
- Being able to tweak RGB primaries (CMY not needed) from zero by hue, saturation and lightness. I DO understand that tweaking one value will affect all other colors in the same way as the LUT tweaking does (in a worse way regarding the robustness of the profile)
- Grey axis stays grey
Basically I need an extended version of Adobe DNG Profile editor. What bothers me now I do not know whether the start matrix profile (the more so the LUT profile which I would like to strip the LUT off of) is good enough to my taste, and the controls I have are only hue and saturation without lightness. Ok, lightness might be absent as a control since it will be interconnected with the hue and saturation, but I want to be able to tweak the hue and saturation from zero with keeping the grey axis grey.
-
Will buy a lite version that allows:- Selecting a monitor profile different from the system one
Why would you want to do that?
-
Why would you want to do that?
A somehow valid use case is different monitor profiles Print White Point D50 (or whatever the visual WP of the lightbox on a particular paper is) vs sRGB Web D65 profile. Of course you need to relod the calibration externally. I am just not aware how Windows behaves when switching profiles via 3rd part apps like DispCAL profile loader. I suppose Win does not assign the default profile to the one you have switched to. I agree it is not a critical feature.
-
A somehow valid use case is different monitor profiles Print White Point D50 (or whatever the visual WP of the lightbox on a particular paper is) vs sRGB Web D65 profile. Of course you need to relod the calibration externally.
But the 'system' profile for display you always use is still (and alway) in effect so how can this work? How and why use a display profile that doesn't define the current display conditions?
-
But the 'system' profile for display you always use is still (and alway) in effect so how can this work?
/off topic/ on Windows platform it is up to a specific software code what to use (if at all)...
-
/off topic/ on Windows platform it is up to a specific software code what to use (if at all)...
Sure but that makes what you looking at even less predictable - I am also puzzled as to why would anyone need it...
-
/off topic/ on Windows platform it is up to a specific software code what to use (if at all)...
But it can only use one right? And it should be the profile that reflects the condition of the display, not a profile that doesn't. So confused by doing this produces anything useful but open to hear more.
-
But it can only use one right? And it should be the profile that reflects the condition of the display, not a profile that doesn't. So confused by doing this produces anything useful but open to hear more.
The profile includes the calibration curves as well, so different profiles can describe different states of the display with the same OSD settings but different calibration curves (say different gamma and\or white point targets) or other factors such as VGA vs HDMI connection.
-
The profile includes the calibration curves as well, so different profiles can describe different states of the display with the same OSD settings but different calibration curves (say different gamma and\or white point targets) or other factors such as VGA vs HDMI connection.
Describe it yes. Produce it? The display is currently calibrated so you're suggesting loading some LUT or profile updates OSD? It can in very, very few displays.
-
But it can only use one right?
/off topic/ because it is up to the code to decide if it wants to engage any CMS or not at all it technically can use different even for neighboring pixels on your monitor ;D and more so - different each time for each and every pixel ... Wild Wild West ... certainly nobody writes a code like this...
-
/off topic/ because it is up to the code to decide if it wants to engage any CMS or not at all it technically can use different even for neighboring pixels on your monitor ;D and more so - different each time for each and every pixel ... Wild Wild West ... certainly nobody writes a code like this...
So you can't answer my questions.
-
Describe it yes. Produce it? The display is currently calibrated so you're suggesting loading some LUT or profile updates OSD? It can in very, very few displays.
Do you not know a calibration can be made exclusively via calibration curves which are loaded to the videocard gamma table when the profile is selected? This usually needs a 3rd part app or manually selecting "as default" in the Color Managemnt pane in Windows.
-
Do you not know a calibration can be made exclusively via calibration curves which are loaded to the videocard gamma table when the profile is selected?
Yes I do.
-
Yes I do.
So what was your question then? Win applies the corresponding calibration curves when you change the default profile in the Color Management tab, but it is kind of too cumbersome.
Ok, I can erase that feature from the list
-
So what was your question then?
The one(s) still below, unanswered...
-
The one(s) still below, unanswered...
Care to quote once again? I am probably dumb and a non-native English speaker. I have tried to guess it was "Profiles describe but not produce".
The answer then is every profile with calibration curves describes the behavior of the display with the profile's calibration curves applied.
-
I think this maybe at least a food for thought http://forum.luminous-landscape.com/index.php?topic=118943.0
-
I apologize if this is old news - I just received an email regarding v 5.5 of BabelColor's Patch Tool. The email notes that one of the new features is the "Spectrum Generator"
PatchTool version 5.5 has a new “Spectrum Generator” tool with which you can generate spectral data from XYZ or L*a*b* coordinates.
Use the Spectrum Generator tool to generate a spectrum which matches input tristimulus values (i.e. XYZ or L*a*b*) for a given illuminant and Standard Observer. The conversion method used in this tool is based on Principal Component Analysis (PCA). PCA is a mathematical process by which a few spectral components (or base vectors), typically three to six, are extracted from a large number of spectrums forming a reference dataset. The goal of the process is that any spectrum (i.e. color) from the dataset can be obtained by adding the principal components in various proportions, with these proportions derived using the tristimulus values for one or more illuminant. The accuracy of the synthetized spectrum will generally increase as more components are used.The reference dataset used for component extraction is selected to cover a large gamut and is usually representative of a given group of pigments. The principal components of this tool were extracted from measured samples of the NCS, Munsell, and OSA-UCS color order systems. What this means in practice is that, for the same color coordinates, a spectrum generated by this tool is likely to be more similar to a NCS, Munsell, or OSA-UCS spectrum than to the spectrum of a Pantone chip.- Illuminants for 3 components fit: A, C, D50, D55, D60, D65, D75, D93, E, F2, F7, F11, plus two Custom Illuminants.- Illuminants for 6 components fit: A, C, D50, D65, E
From: http://www.babelcolor.com/patchtool_spectrum_generator.htm
Any thoughts on the usefulness of this feature as it relates to using spectral data in Profile Editor?
Thanks,
kirk
-
I apologize if this is old news - I just received an email regarding v 5.5 of BabelColor's Patch Tool. The email notes that one of the new features is the "Spectrum Generator"
From: http://www.babelcolor.com/patchtool_spectrum_generator.htm
Any thoughts on the usefulness of this feature as it relates to using spectral data in Profile Editor?
That is not a real spectral data. And there is not even a way to estimate its accuracy in relation to real spectrometer measurements.
-
I apologize if this is old news - I just received an email regarding v 5.5 of BabelColor's Patch Tool. The email notes that one of the new features is the "Spectrum Generator"
From: http://www.babelcolor.com/patchtool_spectrum_generator.htm
Any thoughts on the usefulness of this feature as it relates to using spectral data in Profile Editor?
Thanks,
kirk
matlab script from chineese dude works (with all the fine print that AD ref'd above of course) decent enough = http://www.gujinwei.org/research/camspec/ = I use modified for my purposes for couple of years to generate estimated CFA SSF for dcamprof
-
That is not a real spectral data.
From a Spectrophotometer the software supports, how so?
-
From a Spectrophotometer the software supports, how so?
Where have you seen measured spectral data in the referenced link?
That was about restoring spectral data from given integrated version (XYZ or LAB) by using PCA.
-
matlab script from chineese dude works (with all the fine print that AD ref'd above of course) decent enough = http://www.gujinwei.org/research/camspec/ = I use modified for my purposes for couple of years to generate estimated CFA SSF for dcamprof
It "works" with caveats. Try to use it on cameras with substantially different CFA or without those (Foveon for example) and see what errors that will give comparing to the real measured spectral responsivity curves.
-
Where have you seen measured spectral data in the referenced link?
Link or actual software product which does interface with a Spectrophotometer and does capture spectral data?
-
The spectrum generator only uses spectral information from a patch set to determine XYZ for a selected illuminant and only if the XYZ isn't provided for the illuminant. In the case of two selected illuminants, it uses the spectral information to derive a second set of XYZ values. Then it finds either the three principal component's based on the associated XYZs from their database of colors (Munsell, etc) or the 6 principal ones if a second illuminant is provided..
The documentation leaves something to be desired. I ran some tests and the PCA values are selected based on the actual spectrum, if provided. If two illuminants are selected the spectrum is used to determine the reflectance XYZs at both illuminants and the PCA values are much closer to the actual spectrum in most cases.
The spectral match is better when the second illuminant is selected since that requires spectral content otherwise the second illuminant XYZ is just an estimate.
Thus, one can derive PCA values two ways, from the XYZ or from the actual spectrum using two illuminants. If from the XYZ of only one illuminant, one can presume the spectrums are closer to those in their database in an XYZ sense. If from the spectrum of, say a printer and using two illuminants, closer to the printer's. I suppose one could compare the two PCA sets to estimate how close a specific printer was to the database of color objects under different illuminants.
The purpose is to expand the colors from a patch set to produce a "spectrum" that more closely approximates that of their reference database of colors. Presumably this will usually be closer to the spectrum of colors in nature as opposed to the limited set of spectra from a CMYK printer when using just XYZ values and a single illuminant.
-
Link or actual software product which does interface with a Spectrophotometer and does capture spectral data?
(http://reactiongifs.me/wp-content/uploads/2013/08/eddie-griffin-popcorn.gif)
-
It "works" with caveats.
works (not "works" !) with caveats that you need some measured (even not ideally) reference data from other cameras, yes ... for us hoi polloi who are using regular mass produced C&N&S&O&P cameras
-
I apologize if this is old news - I just received an email regarding v 5.5 of BabelColor's Patch Tool. The email notes that one of the new features is the "Spectrum Generator"
From: http://www.babelcolor.com/patchtool_spectrum_generator.htm
Any thoughts on the usefulness of this feature as it relates to using spectral data in Profile Editor?
Thanks,
kirk
One to many relationship. one XYZ can be a gazzillion of different spectra. I cannot see any use of this.
-
One to many relationship. one XYZ can be a gazzillion of different spectra. I cannot see any use of this.
Sure, and they're all metamers. But if you look at the spectra of existing pigments and combinations and decompose it, they collapse to a reasonable set of principal components that can, in linear combination, be quite a good match in most all cases.
However the XYZ triplet under one illuminant is certainly not very constraining so the synthesized spectrum is going to be fixed from the 3 principal components that best fit for that particular XYZ. One could just as easily publish a database of XYZ -> Spectra.
I can't imagine much application other than modeling metameric shifts under different illuminants when you don't have object spectra available but want to get some idea based on their large color database.
NOTE: I have re-corrected my first comment. Indeed, when only selecting 3 PCA components (single illuminant) the generated spectrums are the same whether or not the full patch spectrums or just the XYZ (or lab which is convertible to XYZ) is used.
-
Link or actual software product which does interface with a Spectrophotometer and does capture spectral data?
Have you actually read what the post and software was about (to which my post replied)?
The post was referring to spectrum generator from XYZ/LAB samples and was asking of using spectral data from that generator in profile editor. I did say it was not real spectral data since the generator does not measure any.
Is that any clearer now?
-
works (not "works" !) with caveats that you need some measured (even not ideally) reference data from other cameras, yes ... for us hoi polloi who are using regular mass produced C&N&S&O&P cameras
Not in this sense - PCA will only give you results very similar to the chosen dataset. Anything that is substantially different will not be recovered correctly. It is only useful to analyze similar data
-
One to many relationship. one XYZ can be a gazzillion of different spectra. I cannot see any use of this.
The point is that what a camera interprets is unlikely to be any of "a gazzillion of different spectra", instead it is likely to be a spectra that is available in the real world. Using this insight helps guide the trade-offs in creating a camera to standard observer transform.
As for PCA as a technique, the impression I get from reading a few papers on the subject is that it is not quite as good as using actual real world spectra. The problem is that reconstructing spectra from PCA doesn't necessarily result in spectra that you are likely to get from the real world. You can get the flavor of this problem from the realization that using unconstrained reconstruction will happily generate spectra with negative values.
[ Another approach I have read about recently that isn't based on real world spectra statistics, constructs the metamer set for each camera color, and uses the perceptual mean of the set volume as the representative standard observer color. One could tweak that approach to include real world statistics by weighting the mean according to real world metamer likelihood. ]
-
The problem is that reconstructing spectra from PCA doesn't necessarily result in spectra that you are likely to get from the real world. You can get the flavor of this problem from the realization that using unconstrained reconstruction will happily generate spectra with negative values.
I was wondering about how patchtool handles unrealizable colors in those circumstances. The choice is to come as close to the XYZ color as possible with a reflective surface from their dataset or return exact XYZ matches but with spectra allowed to be <0 or > 1.0. So I checked it with Adobe RGB (255,0,0) which is not realizable by existing reflective surfaces. Sure enough, the PCA spectrum goes negative and well over 100% in places.
-
With PCA as with many other machine learning techniques you are effectively fitting data and doing pattern recognition. Results can be quite good if the training set is large enough and of good enough quality. However you get 'plausible' results - not necessarily 'accurate' ones. It depends what one is after.
Jack
-
DCamProf also has a spectral generator since quite some time if someone wants to experiment.
https://www.ludd.ltu.se/~torger/dcamprof.html#generated_spectra
It's more of an experimental feature and I didn't add it to Lumariver Profile Designer. What it is typically used for in DCamProf is when you make a profile based on real spectral measurements but you have some gaps, and then you can fill it out with generated spectra. As many have noted you can have infinite variations of a spectrum for one XYZ coordinate, so what DCamProf does is that it has various models using gaussian distributions to make as smooth spectra as possible for a given coordinate, the rationale being that making a profile based on such spectrum will make it more all-around than using peaky spectra. Regarding "impossible" colors the generator will then fail to make a spectrum.
-
DCamProf also has a spectral generator since quite some time if someone wants to experiment.
https://www.ludd.ltu.se/~torger/dcamprof.html#generated_spectra
It's more of an experimental feature and I didn't add it to Lumariver Profile Designer. What it is typically used for in DCamProf is when you make a profile based on real spectral measurements but you have some gaps, and then you can fill it out with generated spectra. As many have noted you can have infinite variations of a spectrum for one XYZ coordinate, so what DCamProf does is that it has various models using gaussian distributions to make as smooth spectra as possible for a given coordinate, the rationale being that making a profile based on such spectrum will make it more all-around than using peaky spectra. Regarding "impossible" colors the generator will then fail to make a spectrum.
Interesting Anders.
I've kicked around the notion if using PCA to find the dominant absorption curves of a printer then using that info to optimize the response of a camera's CFA. Possibly by taking to images, one with D50 ish light the other with Ill. A. One could even add various CFLs/LEDs with known spectra. This should provide enough info to generate 5 or more PCs to characterize a CFA reasonably well. And it should work especially well for colorimetric imaging of that printer's prints. Know of any work done in that area?
-
I've kicked around the notion if using PCA to find the dominant absorption curves of a printer then using that info to optimize the response of a camera's CFA. Possibly by taking to images, one with D50 ish light the other with Ill. A. One could even add various CFLs/LEDs with known spectra. This should provide enough info to generate 5 or more PCs to characterize a CFA reasonably well. And it should work especially well for colorimetric imaging of that printer's prints. Know of any work done in that area?
I'm not sure if I follow, but if you mean a way to figure out what the spectral sensitivity functions are based on a bunch of color checker shots there is some work in that area done yes. I haven't studied it myself, but you can find some here: http://www.gujinwei.org/research/camspec/ and search for "Code for recovering camera spectral sensitivity from a single image" on that page.
-
I'm not sure if I follow, but if you mean a way to figure out what the spectral sensitivity functions are based on a bunch of color checker shots there is some work in that area done yes. I haven't studied it myself, but you can find some here: http://www.gujinwei.org/research/camspec/ and search for "Code for recovering camera spectral sensitivity from a single image" on that page.
I still stand by a possibility to tweak a matrix from zero like the DNG Profile maker. Then I`d buy. Maybe a separate product\utility.
-
I tried a variation of an example provided by Anders on using Lippman2000 cacuasian spectral data as a virtual target for a SSF profile:
dcamprof txt2ti3 -a "caucasian" -s 1 -f 400,700,2 Reflect_AllCaucasian_400_700_2nm.txt caucasian.ti3
dcamprof make-target -c ssf-600D.json -i D55 -p caucasian.ti3 -p cc24 target-caucasian-D55.ti3
dcamprof make-target -c ssf-600D.json -i StdA -p caucasian.ti3 -p cc24 target-caucasian-StdA.ti3
After feeling somewhat content with results using other virtual targets(CC24,CCSG,AdobeRGB-grid,Munsell) and real profile shots, I'm now really happy with skin tones. Even friends that are not technically inclined have commented about pleasant and realistic skin tones. I'm note sure why but the skin tones improved further still by removing all non neutral patches from the CC24 subset. I'm curious what others here make of this.
-
I'm not sure if I follow, but if you mean a way to figure out what the spectral sensitivity functions are based on a bunch of color checker shots there is some work in that area done yes. I haven't studied it myself, but you can find some here: http://www.gujinwei.org/research/camspec/ and search for "Code for recovering camera spectral sensitivity from a single image" on that page.
I spent all too long 15 or so years ago attempting to create a camera profiling tool using just such a technique. The starting point was a spectrally measured target. For any tristimulus value a camera records there are an infinite number of spectra that can give the pixel reading. If, however, you iterate through enough known colors, the possible camera matching functions converge. I can probably pull up GATF and other presentations I made on the topic if desired.
The profiles I created were colorimetrically accurate to a fault. We used them for product photography under controlled lighting. The problem was that mathematical accuracy did not translate into pleasing visuals. Discontinuities in the profile translated into ugly transitions in images. Franz Herbert at Integrated Color Solutions took a different approach of prioritizing aesthetics over mathematical accuracy. That ended up working far better in the real world.
-
I spent all too long 15 or so years ago attempting to create a camera profiling tool using just such a technique. The starting point was a spectrally measured target. For any tristimulus value a camera records there are an infinite number of spectra that can give the pixel reading. If, however, you iterate through enough known colors, the possible camera matching functions converge. I PLecan probably pull up GATF and other presentations I made on the topic if desired.
The profiles I created were colorimetrically accurate to a fault. We used them for product photography under controlled lighting. The problem was that mathematical accuracy did not translate into pleasing visuals. Discontinuities in the profile translated into ugly transitions in images. Franz Herbert at Integrated Color Solutions took a different approach of prioritizing aesthetics over mathematical accuracy. That ended up working far better in the real world.
I absolutely concur on the visual correctness over DeltaEs.
Any information on what colors are best to profile by would be great.
And what do you mean by controlled light? Xenon, fluorescent or any daylight simulated light sources?
-
I spent all too long 15 or so years ago attempting to create a camera profiling tool using just such a technique.
The problem was that mathematical accuracy did not translate into pleasing visuals.
We've both spent about the same time coming up with identical conclusions!
-
I spent all too long 15 or so years ago attempting to create a camera profiling tool using just such a technique. The starting point was a spectrally measured target. For any tristimulus value a camera records there are an infinite number of spectra that can give the pixel reading. If, however, you iterate through enough known colors, the possible camera matching functions converge. I can probably pull up GATF and other presentations I made on the topic if desired.
The profiles I created were colorimetrically accurate to a fault. We used them for product photography under controlled lighting. The problem was that mathematical accuracy did not translate into pleasing visuals. Discontinuities in the profile translated into ugly transitions in images. Franz Herbert at Integrated Color Solutions took a different approach of prioritizing aesthetics over mathematical accuracy. That ended up working far better in the real world.
Cameras just aren't designed for accurate color. Scene referred imaging with perfect L-I imaging response still produces relatively unattractive images. However, for reproduction work this, otherwise unattractive, is highly desired since the goal is to create a side-by-side matching copy.
However, even if a camera's imaging met L-I and "perfect (low dE)" prints could be made there are many reasons those may not match the original.
They could have different surface characteristics such as glossy or semi gloss characteristics that differ from the original. Colorimetric processes only retain accuracy when a print is illuminated at 45 degrees and there is no light from other angles that could reflect off a surface. A matte print w/o OBAs, displayed w/o glass, is impacted the least by this.
But even then a match might not occur unless the copy and original are displayed using D50 or a close spectral equivalent. This is because the reflected colors, simplified to the three CIE variables XYZ only match because the spectral characteristics of the original is not going to be the same. The two may be metameric at D50 (and 45 degrees, no uV, etc) but with a different illuminant metameric error will accrete.
And even with all that the CIE matching functions aren't perfect. Individual humans vary too. Sometimes quite a bit. Mostly this affects how two different people will see an image on two monitors, otherwise profiled identically, but with different backlight spectrums. Esp. CFL v LED. Print metameric error tends to be less as reflective spectra is usually much smoother than the monitor's RGB. It's especially noticeable on the shorter wavelength side from 440 to 500 nm where the "B" can match for one person but be off for another.
Here's a deep dive from a student at RIT about 20 years ago.
http://www.rit-mcsl.org/StudentResearch/mshaw/CMF_Thesis.pdf
Colorimetry works in a well controlled environment but there's a multitude of factors that can confound.
-
Cameras just aren't designed for accurate color. Scene referred imaging with perfect L-I imaging response still produces relatively unattractive images. However, for reproduction work this, otherwise unattractive, is highly desired since the goal is to create a side-by-side matching copy.
Wouldn't that result in two unattractive matching items? ;D
-
Wouldn't that result in two unattractive matching items? ;D
Yep, it just turns the first one ugly. ;D
It's an interesting psychological effect. If you print a typical landscape picture processed normally, then hang it on the wall and take a picture of that, print and hang it next to the first, you'll like the first picture but the second generally looks pretty garish. Kodak, and others, have trained us:
Paul Simon: "KodaChrome, give us those nice, bright colors ...."
-
I disagree, for camera profiles my experience has shown pleasant colors and accuracy can go together when sacrificing total accuracy, by targeting a range of important subject colors like caucasian skin tones(max 1 DE in this case). Color error models likely do a good job of predicting percetibilty of color shifts, but dont account for color shifts in skin tones looking more objectionable for human subjects when treated equally to non-skin tones.
-
I disagree, for camera profiles my experience has shown pleasant colors and accuracy can go together when sacrificing total accuracy, by targeting a range of important subject colors like caucasian skin tones(max 1 DE in this case). Color error models likely do a good job of predicting percetibilty of color shifts, but dont account for color shifts in skin tones looking more objectionable for human subjects when treated equally to non-skin tones.
Yes, for memory colors, especially skin, being off 3 dE can produce worse results than being off 15 dE in, say, foliage. If you look at the color shifts that output referred processing (normal photog) does you often get very large saturation increases in the greens while skin colors are kept pretty tight as people tend to like the look.
-
Yes, for memory colors, especially skin, being off 3 dE can produce worse results than being off 15 dE in, say, foliage. If you look at the color shifts that output referred processing (normal photog) does you often get very large saturation increases in the greens while skin colors are kept pretty tight as people tend to like the look.
The skin tone is what is mostly messed up in Adobe profiles and more often than not in native camera processing, being too red. Basically, you either have the right skin tone hue and natural reds and warmer greens and washed out blueish aquamarines\cyans, or good cyans and cooler greens but red skin tone and cyanish washed out blues and chemical bright reds. I am talking matrix here, do not see much sense in LUTs.
-
Yes, for memory colors, especially skin, being off 3 dE can produce worse results than being off 15 dE in, say, foliage. If you look at the color shifts that output referred processing (normal photog) does you often get very large saturation increases in the greens while skin colors are kept pretty tight as people tend to like the look.
My point exactly! Thanks for putting it so much more eloquently.
The skin tone is what is mostly messed up in Adobe profiles and more often than not in native camera processing, being too red. Basically, you either have the right skin tone hue and natural reds and warmer greens and washed out blueish aquamarines\cyans, or good cyans and cooler greens but red skin tone and cyanish washed out blues and chemical bright reds. I am talking matrix here, do not see much sense in LUTs.
I have the same feelings toward the Adobe Standard colors as some of my exes...Aside from that they provide a valuable resource for tone curves in the Camera profiles which can be conveniently loaded into Lumariver PD. Among them I found a Canon EOS 450D curve that works well for a large range of subjects with fairly minimal tweaking.
Coming back to color accuracy vs. subjective taste, Anders has done a lot of R&D on creating general-purpose profiles. I don't want to write-off his efforts just because I couldn't get it to work for my camera, which admittedly has a rather low DxOmark metamerism score. Hopefully my findings can aid future development.
-
I found two studies looking into improving camera profiling using hundred of colorchecker shots taken under varying lighting conditions and a prototype profile spec:
http://www.comp.nus.edu.sg/~whitebal/illuminant/illuminant.html
http://www.comp.nus.edu.sg/~whitebal/beyond/beyond.html
They happened to include the Canon 600D that I own and you can download the RAWs. Could this be useful for a improving a general purpose profile creation with current DCP spec?
-
Hi Anders,
I was wondering if it was possible to use the Dcam Target+ from Basiccolor in Lumariver Profile Designer?
-
Hi Anders,
I was wondering if it was possible to use the Dcam Target+ from Basiccolor in Lumariver Profile Designer?
You can, by loading your custom reference file, after choosing "custom target" under the target selection dropdown menu. Reference files can be found here if case you don't have one: https://www.basiccolor.de/reference-files/ (https://www.basiccolor.de/reference-files/)
-
Thanks for your answer, actually i think i have to modify a little bit the reference file as i got this message (image atached), to you know how to do it?
thanks
-
the file you got is a simple text file so all you need to do is pull it into Notepad or whatever and add that keyword and the correct value.
Whats the correct value? I'm not sure because I've never seen a dcam target but if you look at others, say the qp203, the right value is 7 whereas the correct value for a basic ColorChecker is 4. That tells me that (if you look at those two charts), it's the 'number of rows of patches'.
Basically, Lumariver is telling you that it cant figure out the patch grid setup of the file (x rows by y columns).
HJM-MBA:Lumariver Profile Designer.app/Contents/Resources] howardm% grep ROW *
cmp_dt8_gl_100.cie:LGOROWLENGTH 36
cmp_dt8_mat_100.cie:LGOROWLENGTH 36
it87_ref-r080505.cie:LGOROWLENGTH 12
passport_ref.cie:LGOROWLENGTH 4
qp203_ref.cie:LGOROWLENGTH 7
sc24_ref.cie:LGOROWLENGTH 4
-
Hello.
I've just made a new release, version 1.0.4. Here's a link to what's new: http://www.lumariver.com/lrpd-manual/#version_history
It's a minor patch release, that is mostly bug fixes and a few small improvements.
I don't have as much time to be active on the forum for the moment. I'm very grateful for the help provided by users, thanks for that. And there's always the support email if you get stuck.
-
Thanks i just sent you a email....with my problem with Dcam target+
Olivier
-
Thanks Howard,
i add the numbers of Rows (19) and D50 illuminant in the ref file but still i have problem as you see...
will try to figure what is wrong...
-
Thanks Howard,
i add the numbers of Rows (19) and D50 illuminant in the ref file but still i have problem as you see...
will try to figure what is wrong...
Had a look at the reference file, there's patches missing in it, more specifically in the reference border around. But those are relevant too and used for automatic flatfield correction so they are also needed. By some reason it seems many target manufacturers make up their own private ways of either arranging their targets or their reference files :(. For a custom grid LRPD expects, well, a grid. X rows and Y columns, all specified. Not patches here and there left out. So either you need to add those in manually in the text file, or you scan the target yourself with a spectrometer, or even better ask the manufacturer why they don't provide a fully specified grid reference file to their grid target...
There's just no reason for target manufacturers to make up own non-grid layouts, unless they have a reason to make the target hard to use in third-party software.
-
that was the same thing I thought when I found a picture/advertisement for the Dcam and the number of patches didn't jive w/ the ref file.
Did they leave out the entire border? Can one simply cut/paste the same values as existing B/W/G patches?
Weird.
-
Did they leave out the entire border? Can one simply cut/paste the same values as existing B/W/G patches?
Didn't look in detail, they did not leave out the entire border though. As long as there is one white, gray and black you can easily manually copy/paste, although it's a bit tedious. Another method is to strip away the border completely and just keep the center grid, but then you lose the flatfield feature that the border provides (and I'm not sure if white/gray/black is represented in some other patches than in the border, you need at least one white. You can do without black and grey, but they are nice to have, not the least to diagnose glare. A bright black means glare, and/or uneven light).
-
Anyone else looked at the selection of tone curves from Adobes Camera profiles? Going through them turned out to be worthwhile as I now spend less time editing with my favored curve:
(https://i.imgur.com/JzYHyUE.png) (https://imgur.com/JzYHyUE)
Also, out of curiosity, I wonder what the average curve would look like.
-
Bought Lumariver 2 weeks ago. It took a few tries but I finally got it right. I am very happy with the results. The bottom line is that I now have camera profiles that serve as nice accurate baselines from which I can evolve my images as I see fit. I found the documentation to be both thorough and very helpful. I originally bought basic, but after seeing how well it works, I am buying the repro version so that I can use multiple targets and create icc profiles for capture one.
I kept the settings in Lumariver neutral, including not applying a "look". I also turned off "Adobe Black Subtraction" to avoid crushing shadow detail.
Having a profiling option that doesn't cost a fortune is great since I am not a fan of the creative choices Adobe, its competitors, and camera manufacturers make when it comes to camera profiles and curves. Thank you 😀
BTW, I use Fuji. Although it doesn't seem to make a difference, I made one profile based on a DNG from Adobe DNG converter, and another profile based on a DNG from Iridient Developer. It was the same raw image for both. I used the Colorchecker classic in a very tightly controlled shooting environment.
-
Wondering if anyone else has tried this since my last post.
-
I have a question I am wondering if anyone can answer. I have a film scan of a Color Checker SG that I measure the patches of in 3DLUT Creator and then use that data with a Babel Color Patch Tool reference file to create a DNG Profile of in Lumariver Profile Designer. When I render the profile, the patched definitely change to close to the reference patches...especially the hue, but almost all of them are quite a bit more saturated and either lighter or darker than the reference patches. I have everything in the Profile Designer set to default and have tried utilizing almost all of the tools and options available, but that only makes things less accurate/pleasing. My main question is, how do I get the rendered profile patches to match the reference file patches?
-
I have a question I am wondering if anyone can answer. I have a film scan of a Color Checker SG that I measure the patches of in 3DLUT Creator and then use that data with a Babel Color Patch Tool reference file to create a DNG Profile of in Lumariver Profile Designer. When I render the profile, the patched definitely change to close to the reference patches...especially the hue, but almost all of them are quite a bit more saturated and either lighter or darker than the reference patches. I have everything in the Profile Designer set to default and have tried utilizing almost all of the tools and options available, but that only makes things less accurate/pleasing. My main question is, how do I get the rendered profile patches to match the reference file patches?
Realized I never tried a Reproduction Profile, so I've been trying that, but the software can't get past 81%...anyone else having this issue?
-
Realized I never tried a Reproduction Profile, so I've been trying that, but the software can't get past 81%...anyone else having this issue?
you can contact the author directly - the software is not bug free
-
you can contact the author directly - the software is not bug free
Thank you, I sent an email on 2/27 and one earlier today and am awaiting a response.
-
I have a question I am wondering if anyone can answer. I have a film scan of a Color Checker SG that I measure the patches of in 3DLUT Creator and then use that data with a Babel Color Patch Tool reference file to create a DNG Profile of in Lumariver Profile Designer. When I render the profile, the patched definitely change to close to the reference patches...especially the hue, but almost all of them are quite a bit more saturated and either lighter or darker than the reference patches. I have everything in the Profile Designer set to default and have tried utilizing almost all of the tools and options available, but that only makes things less accurate/pleasing. My main question is, how do I get the rendered profile patches to match the reference file patches?
Hello. Currently I don't have much time for the forums so support email is the best.
I'm not sure what you are trying to do here, but it seems like you are not trying to make a film simulation profile? That is you use a film scan to make a reference not of the real colorimetric colors, but the film response, and then use that file with a target shot of a regular camera, in order to make a profile that makes that camera look like the film? That's probably not going to work. Lumariver Profile Designer is not designed to be a generic LUT Creator software, but is designed to make camera profiles anchored in realism with only smaller subjective elements. It makes assumptions of how camera/scanner hardware works. This means that it always starts off with a linear matrix and make LUT corrections on top, which make robust smooth profiles, but requires that the system profiled is at large linear. If the behavior of the camera (or the reference file) would be grossly non-linear, that is the camera/reference does not work as real cameras do, the matrix matching will go haywire, and then the LUT correction, which is supposed to make only mild smooth refinements on top, will get into trouble. I haven't really tested these workflows but I wouldn't be surprised if you get crazy results or even if the software fails in optimization and get stuck.
For creating film simulation LUTs there are better tools out there, Lumariver Profile Designer is not intended for that purpose. It would require a different design which does not use a matching matrix at all but instead work with really dense targets (lots and lots of patches to cover the full gamut) and make a complete non-linear match.
If however I have mis-understood your workflow and you are really making a profile in the normal way, the best way is to use the archive project function and send a wetransfer/dropbox/whatever link to the support mail and I can have a look and see what goes wrong. The usual problem in that case is that there is some issue with the target photo (excessive glare, clipping etc), or that the grid is not correctly placed, or that there is some problem with the reference file not matching the target.
-
Currently I don't have much time for the forums
Hi Anders,
if possible - any approximate guesstimate about maintenance releases for LrPD and dcamprof with bugfixes ? thank you.
-
Hi Anders,
if possible - any approximate guesstimate about maintenance releases for LrPD and dcamprof with bugfixes ? thank you.
It's soon time for a new patch release for LrPD, I'd guess within a month or two. DCamProf is harder to estimate, as I prioritize supporting the commercial software. I have a new DCamProf release about 70% ready, it's more documentation than actual code left to do, so there will be a release eventually I just don't know when. In the autumn perhaps.
-
It's soon time for a new patch release for LrPD, I'd guess within a month or two. DCamProf is harder to estimate, as I prioritize supporting the commercial software. I have a new DCamProf release about 70% ready, it's more documentation than actual code left to do, so there will be a release eventually I just don't know when. In the autumn perhaps.
Thank you !
-
as I prioritize supporting the commercial software.
PS: as a side note - you need to change the licensing for LrPD again - it was cracked
-
PS: as a side note - you need to change the licensing for LrPD again - it was cracked
For those that wants to crack software it's relatively easy, it's just about removing checks. It's a little bit harder now than the first release, random crashes here and there will occur if not all counter-measures were compromised, but it's not rocket science, that would just be a waste of my time. All popular software gets at least semi-cracked sooner or later, that's just the way it is, so I guess I can see it as a compliment. A key generator is different from a crack though (it means that you can make unauthorized keys and thus don't need to re-crack every new patch release that comes out). It was for that the software's key scheme changed, and that does not need to be changed for a crack, and even if it would have to I'm done with that now. Sooner or later a key is stolen and you need to block it for the next release etc, make new checks etc. The only comforting in this is that a cracker must spend much more time than I have -- for the sake of my paying customers I'm spending minimal effort on piracy counter-measures, instead I try to provide the best support I can and fix bugs (the actual ones, not the ones caused by a bad crack...). I prefer supporting through email though as I'm not much on the forums currently.
-
Hi,
I purchased Lumariver last week, it's something I've looked for a while so thank you to the creator!!
I'm having a lot of trouble creating a usable profile even when I follow the directions. I know i'm missing something crucial in the exporting process but just don't know what.
My results yield a profile where the midtones/highlights are crushed/destroyed severely, where the ICC profiles are not usable at all. I've emailed "info@lumariver.com" a few days ago but haven't heard back.
I've attached pictures of my results. It's an exaggeration of curve to show how the different skin tones are treated. The Generic C1 ICC profile keeps all the colors very linear where as the new Lumariver profile handles them very differently.
My Gear:
Capture One - 11.01
Lumariver - 1.04 (Order # 69150422 )
Camera: Canon 5D Mk IV
Lens: Canon 24-70 f/2.8L II
Color Checker Passport
-
My results yield a profile where the midtones/highlights are crushed/destroyed severely, where the ICC profiles are not usable at all. ...
I've attached pictures of my results. It's an exaggeration of curve to show how the different skin tones are treated. The Generic C1 ICC profile keeps all the colors very linear where as the new Lumariver profile handles them very differently.
Hi,
I am sure Torger will chime in in due time. In the meantime, what do you mean by crushed/destroyed? Once you start playing with curves 'accuracy' is thrown to the wind: without the raw file nobody can tell you which of the two is more 'accurate' (including you:-). If you are after 'accuracy' you should not use levels/curves/brightness/contrast at all - all of that should be set in the profile for the given capture/viewing conditions. On the other hand you are allowed to use the 'Exposure Compensation' slider, assuming it works linearly (ACR/LR current process doesn't, I don't know about C1).
Jack
-
...
My results yield a profile where the midtones/highlights are crushed/destroyed severely, where the ICC profiles are not usable at all.
...
Color Checker Passport
...
Did you follow the detailed steps in the manual? http://www.lumariver.com/lrpd-manual/#c1_workflows
Most time the target shots are mediocre. May you share your CCPP-RAWs?
-
Hey Everyone,
Yeah Togers got back to me and has been super helpful I'm still having weird issues with colors. Maybe someone here has experienced this. I was able to come down the clipping and generally everything looks great.
I still get super weird uneven color hue changes in the sky that I can't seem to fix. Where blue turns purple.
-
I just want to share that for anyone looking to buy a X-Rite ColorChecker Digital SG, you can get one with calibrated/measured references from Image Science Associates (http://www.imagescienceassociates.com/mm5/merchant.mvc?Screen=PROD&Store_Code=ISA001&Product_Code=XRITECC&Category_Code=TARGETS). It's a great deal if you don't have a spectrophotometer.
Also CMP now offers a new robust target (early 2018) as they claimed (without optical brightening agents), namely Digital Target Studio Edition (http://www.cmp-color.fr/DT-SE.html) (DTSE) and it's shipped with individually calibrated reference data.
While basICColor has a new target called dcam mini (https://www.basiccolor.de/basiccolor-dcam-mini-en/) (late 2017)
Here's my 2018 targets comparison for anyone considering buying a new target.
Usability (glare, handling, multi-purpose): CCPP (ColorChecker Classic,Photo Enhancement,White Balance Chart*) -> dcam mini -> DTSE -> CCSG/IT 8.7 C1
*At first glance this patch appears to be a large version of the Neutral 8 patch from the original ColorChecker, but this is not the case.
The ColorChecker Classic’s Neutral 8 patch has a spectral reflectance which, although relatively flat across the spectrum, has a slope to it. This slope was due to its colo- rants and gave it a slight color cast, making it unsuitable for neutral balancing a digital camera.
The ColorChecker Passport’s White Balance Chart is very flat across most of the spec- trum. This shows that X-Rite has made a special formulation to remove any color cast
General Accuracy (optimum colour constancy in various lights) CC/CCPP/CCSG (made with a number of pigmented paints applied to paper with a variety of spectral characteristics) -> dcam mini (made with 3 colorants) -> DTSE (made with pigmented inks, on a substrate without OB) -> IT 8.7 C1 (printed)
Built (physical built quality/storage): CCPP/dcam mini -> CCSG/DTSE/IT 8.7 C1
Gamut (ultra saturated colors stuff): DTSE -> IT 8.7 C1 -> dcam mini -> CCSG -> CCPP*
* If you have your own reference data for the spectrum patches, you can profile the whole CCPP and cover some more saturated colors, though not as much as the CCSG.
Reference Matching (some are offered with calibrated reference data at additional cost/free vs measurements from batch): DTSE -> CCSG -> IT 8.7 C1/dcam mini/CCPP
There are also monstrous targets like ISA's Near Neutral/ColorBuild 300 and Library of Congress's Next Generation Camera Calibration Target.
-
I seen that the new version of MacOS requires that software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. I hope that the notarisation process is under way ...
-
Bringing this to the surface again...
I’m making Repro Profiles out of Capture One.
After applying the profile to a file back in C1, the readings I’m getting from the X-Rite CC (after boosting exposure to account for Linear Mode darkening) are good. But, even tho’ the blues read ok off the CC, they look a bit dead. Adding back in some contrast doesn’t help much.
Monitor is calibrated to D65/2.1/120.
On another note, last time I tried a Lumariver profile file in this https://deltae.picturae.com/index/home (two months ago) they were getting five stars. Now, when I load a file, I’m getting File Not Found. Odd!
Thanks.
D.