New profile making software: Lumariver Profile Designer

[torger]

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.

[torger]

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.

[torger]

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.)

[Hans Kruse]

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

[howardm]

Is there any consideration of a Linux version since dcamprof and Qt are so Linux friendly?

[torger]

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.

[torger]

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.

[torger]

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.

[scyth]

thank you !

[dchew]

I bet somebody needs some sleep. 

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.

[scyth]

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)

[torger]

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.

[scyth]

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

[scyth]

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

[Alexey.Danilchenko]

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.

[scyth]

What's the point

just for experiments as noted at the beginning of the text ...

[torger]

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

[Alexey.Danilchenko]

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).

[scyth]

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

[scyth]

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...