DCamProf - a new camera profiling tool

[torger]

The upcoming 0.9.10 release will have a gamut compression function as a look operator.

Attached a ProPhoto jpeg demonstrating the result.

EDIT: Arggghhh after the forum update the ICC profile is stripped from the uploaded JPEG, so I can't use that any longer. Removed the attachment. Here's a direct link to the image:

http://torger.dyndns.org/gamut-compression.jpg

Embedded:

[torger]

If you like the concept of gamut compression in the profile, it's probably still a wise thing to compress to a larger gamut than the target gamut, as you still have good tonality and decent hue stability even with parts of one channel clipped.

The posted example above has the target gamut to exactly the border (AdobeRGB and sRGB in the example), which means that there's no clipping. This makes it unnecessarily desaturated. The AdobeRGB result looks quite good when clipped to sRGB, but with DCamProf you can simply add say 20% extra range to the sRGB gamut which is what you would do.

[Frederic_H]

The upcoming 0.9.10 release will have a gamut compression function as a look operator.

Good idea. I noticed you have lowered the adjustfactor for saturated colours, was it related to the curve change ?

[torger]

I noticed you have lowered the adjustfactor for saturated colours, was it related to the curve change ?

No, I just re-adjusted it because it was a bit too high to my eyes. It only makes a change to really super-saturated colors.

The purpose of the neutral tone reproduction operator is to maintain color appearance from the linear colorimetric rendering. So what I use as a reference is the linear colorimetric rendering, push exposure a bit to make it easier to compare (important with linear exposure push, I use RawTherapee for this), and the do an A/B swap and look globally over the whole image and think "did the saturation increase or decrease?" and the adjust these factors until the saturation appearance is the same.

For an ideal result I would probably need a more complex function than the current simple rolloff, but I think it's adequate as is. A 100% perfect result is in any case not possible as human color perception is much too complex to just model with a curve and static saturation adjustments.

[torger]

I've now uploaded 0.9.10. The only new stuff is the gamut compression look operator. The ntro_lookop_conf.json contains a commented example, so it should be easy to figure out from that.

Hopefully it will now be a bit wider space between releases again. Now after gamut compression is done I have no (important) features left on the todo list.

[torger]

I'm shooting way too few sunsets obviously.

I've become aware of that the tone reproduction operator, and the new gamut compression feature, has some pretty severe look issues around the sun, or more general the very last step into clipping. It can clip into white too early, or clip into white and then go back into color, and then clip again.

This is a bug of the severe kind considering how popular sunsets are, so it's a high priority to fix this. I don't know yet if it's a hard or easy fix.

It's strange how work intensifies after the software is "finished" and people start using it

[Iliah]

All look things, even "simple" Kodachrome, and I mean film, not imitations, have their issues. It is important that the start has an option of being more or less colorimetric, and looks are achieved in a profile editor or in the image editor / converter. One or even a dozen of fixed looks can't cover it all. Some issues will remain, whatever we try.

[torger]

0.9.7 ICC profiles are unaffected (or if you set keepfactor for curve to 1.0 on 0.9.10), while there is some DCP-specific clip issue also in the older version.

The curve adaptations for the tulip thing was really a can of worms... those that want a bit of stability until I've sorted this out should stay with 0.9.7

This may be one of those cases Iliah mentions, that there's no good way to solve both cases well, but I'll try some more.

So I have three things to fix
1) luminance curve that was added for the tulips has no good clip behavior
2) DCP looktable has some clip issue that can cause a slight artifact near clipping, which is not seen if an ICC profile is rendered
3) I must rethink clipping behavior for the gamut compression feature, it's now no good.

[AlterEgo]

those that want a bit of stability until I've sorted this out should stay with 0.9.7

I think I will put 2 binaries in the next build then

[AlterEgo]

0.9.7 is (mostly) unaffected (or if you set keepfactor for curve to 1.0 on 0.9.10)

can you please add this line to the manual (web page) may be ? I mean to the news section of it

[torger]

can you please add this line to the manual (web page) may be ? I mean to the news section of it

I think you can stay low with publishing new builds until I get 0.9.11 out. I'm thinking of reverting back to 0.9.7 on the web, I'll do that if it starts to take a long time to get 0.9.11 out.

It's good to get things out early as my users contribute to testing (the "user contract" is to be prepared that new stuff can be buggy, and inform me if they find severe bugs), but now when I have these bugs on the table I don't need more reports for the moment.

I've added a note on the front page.

[AlterEgo]

I think you can stay low with publishing new builds until I get 0.9.11 out. I'm thinking of reverting back to 0.9.7 on the web, I'll do that if it starts to take a long time to get 0.9.11 out.

It's good to get things out early as my users contribute to testing (the "user contract" is to be prepared that new stuff can be buggy, and inform me if they find severe bugs), but now when I have these bugs on the table I don't need more reports for the moment.

I've added a note on the front page.

may be also put a prominent contact web form how the users can submit bugs somewhere @ the top of the manual itself (may be even above the news section for lazy ones), listing what shall be supplied to you...

[torger]

2) DCP looktable has some clip issue that can cause a slight artifact near clipping, which is not seen if an ICC profile is rendered

This was not a bug, except from a poor default. The -h 90,30,15 with gamma encoding leaves too few table entries close to clipping. Either disabling gamma encoding (-G) or increasing to -h 90,30,30 removes that issue. I'll investigate the best default and hard-code that to the next release.

[AlterEgo]

MS Windows build v0.9.7 back for downloading @ https://app.box.com/DCamProf-Windows-MingW

[Tim Lookingbill]

That last sample tulip image you posted inline (not linked) has the (RT) profile embedded. I extracted it using Colorsync script and it appears to be a 2.2 gamma version of ProPhotoRGB going by Photoshop's CustomRGB in Color Settings dialog box.

The 3D gamut plot is identical to ProPhotoRGB viewing in Colorsync Utility.

The DCamProf tulip preview on my sRGB display viewed in Photoshop shows the tulips as blobs of red, no petal distinction detail as in the other two to the right. I just assigned 1.8 gamma ProPhotoRGB to the image and the petal distinction was restored but the entire image of course lightened accordingly from the 1.8 gamma assigned to 2.2. gamma encoded data.

[torger]

I'm having good progress in fixing the issues, hopefully I can release a 0.9.11 today.

[torger]

I have now released 0.9.11. Now everything should be back to normal, and I urge 0.9.7 users to move to 0.9.11 and test that.

The main problem was a clipping bug that was introduced in 0.9.8 and thus exists in 0.9.9 and 0.9.10 as well. This is now fixed.

This means that those of you that preferred the "old curve" of 0.9.7 should still try 0.9.11, as the desaturation (such as seen in the traffic lights of Frederic's example a while back) should now be gone. The new curve may be a little bit desaturated still, but it should not be a big difference. The advantage of the new curve is same as before, tonality of high saturation colors (mainly reds) are significantly improved, which can be demonstrated with Bart's tulips. If you still prefer the 0.9.7 curve you can reconfigure by setting KeepFactor to 1.0 as discussed before, so there's no reason to stay with 0.9.7 now (assuming I've not missed some other severe bug, but then I'm glad to get help finding it ).

The Gamut compression has also been fixed by adding a compress limit configuration (suitable defaults in provided example config), so we let the colors go outside our destination gamut near clipping, which is necessary for making a smooth transition into the sun.

You may still get a "fried egg" effect around the sun depending on how your lens has reacted because DCamProf keeps more color in highlights than say ACR. The fried egg is there in the raw (so it's not a profile artifact as such), but if you keep more color it becomes more visible. This can be re-configured if you're a frequent sunset shooter, but I prefer the current tradeoff.

[Frederic_H]

On a different topic, can targets with different spectral resolutions be merged into a single ti3 ? One chart is in 5nm increment and goes up to 730nm, the other in 10nm increment and up to 780nm.
I'm not getting error messages while attempting to merge, but have seen the end of certain lines filled with 0s in the resulting file.

[torger]

On a different topic, can targets with different spectral resolutions be merged into a single ti3 ? One chart is in 5nm increment and goes up to 730nm, the other in 10nm increment and up to 780nm.
I'm not getting error messages while attempting to merge, but have seen the end of certain lines filled with 0s in the resulting file.

Yes it's fine. DCamProf fills out with zeros such that all patches cover the same range after merge.

[AlterEgo]

0.9.11 build for Windows ( mingw = dcamprof.exe + libgomp_64-1.dll + both manual & tutorial / = copies of Torger's web pages / in 3 formats : IE archive .mht, Mozilla archive .maff and regular .pdf ) : https://app.box.com/DCamProf