HaldCLUT: Film emulation from G'MIC in RawTherapee

[Beep6581]

Originally reported on Google Code with ID 2411

From here: http://rawtherapee.com/forum/viewtopic.php?f=2&t=5413#p37597

voidwalker made a patch to use G`MIC Film emulations (http://blog.patdavid.net/2013/08/film-emulation-presets-in-gmic-gimp.html)
in RT. 
The patch didn't apply to tip, so I made a new one which does.
You can use the cluts from above forum link to test.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-06 10:29:46

---

• _Attachment: clut_tip.patch_

[Beep6581]

This patch is priceless:)! Thank you!
The new entries need to be added to the default language file.

I am curios, why CLUT is provided as png image file vs a text?

Reported by michaelezra000 on 2014-06-06 19:14:03

[Beep6581]

Michael, I guess you wanted to thank voidwalker, not me :-)

There are some things, which should be done before this very good addition can be committed:

1.) As you said, language files
2.) Actually, it seems that only the last used clut is stored in memory, which means,
that using more than one (for different pictures) is very slow, especially when starting
RT
3.) The speed must be improved. Actually it takes between 10 and 20 seconds to apply
a clut at my machine. When it's applied once, it's quite fast
4.) It seemed to me, that going back and forward in history didn't work correctly with
clut, but I have to test it again.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-06 21:16:29

[Beep6581]

Addition:

5.) memory consumption is far too big. I applied a clut to one image. After a restart
of RT it needs about 470 MB instead of the usual about 50 MB (only file browser, no
editor opened).

Reported by heckflosse@i-weyrich.de on 2014-06-07 08:28:13

[Beep6581]

I had a deeper look at the source and came to the conclusion, that the patch isn't committable
for the following reasons:

1.) Main reason: RT applies almost all calculations also to the thumbs in file browser.
The majority of this calculations (if not all) scales with the size of the thumb.
    CLUTs do not and increase the time to calculate the thumbs dramatically each time
the thumbs are recalculated. So the time to start rt on a folder with a clut-applied
    image or the time to switch to a folder with a clut-applied image takes very long
(too long).
    This could be solved by changing the current thumb caching method (cache unprocessed
thumb) to a method, which caches the unprocessed thumb and the thumb processed with
latest modifications.
    That would also speed up file browser in general, but is a lot of work and a completely
different issue.

2.) Memory requirements: A 256x256x256 CLUT actually increases the used memory by about
400 MB (don't know why, because 200 MB should be enough), but even 200 MB are too much,
    especially considering the fact that this memory isn't freed (it could be, but
then it would take much longer to apply the clut to another image).
    Of course, on medium to high-end machines, this doesn't play a big role...

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-07 21:37:29

[Beep6581]

First of all thank you Voidwalker and Ingo for this first step.

Of course it is necessary to accelerate the process and to minimize memory consumption
... Is it necessary to use LCMS?

For me, the CLUT is an important step. Sure you can say "what's the point?". The answer
is that many professional photographers use it, and also that DxO proposed "DxO FilmPack"
and others manufacturer proposed "ICC profiles"...

An important point of improvement is the ability to generate the CLUT easely from RT
and two or more images. Then also posibility to mix.

:)

Reported by jdesmis on 2014-06-08 09:43:56

[Beep6581]

Hi Jacques, I also like the possibilities of the CLUT. If we can solve the points mentioned
in #4 I've absolutely nothing against this patch.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-08 10:51:09

[Beep6581]

Hi all! I am voidwalker from forum.

About memory and working speed. I need double color space convertion using LCMS 4096x4096
images (for level 16 HaldCLUT) while loading CLUT and this take much time. I can create
"precalculate" button in RT, and precalculate given HaldCLUT to a necessary working
color space, then save it to another PNG file like "portra_160_prophoto.png". Then
you can use it without initial color convertion only time for loading. It`s must be
more faster on loading and reduce memory usage, but its more "work" to "install" new
CLUT for users.

> I am curios, why CLUT is provided as png image file vs a text?

PNG format of CLUT have some benefits. You can open "ident_16.png"(zero CLUT) in Photoshop,
process it with some color convertions plugins (another Film emualtion) or curves.
Recived HaldCLUT will contain all color and tone convertions from Photoshop, and you
can use it for your images.

This is Adobe CUBE format specification for txt format of CLUT(3D-LUT) http://wwwimages.adobe.com/content/dam/Adobe/en/products/speedgrade/cc/pdfs/cube-lut-specification-1.0.pdf.

Reported by dmitry.volvap on 2014-06-09 07:32:28

[Beep6581]

I found some artifacts in sky, flowers ! (yellow_poppy.nef, 2010_MONTR_033.NEF, etc.),
with "superia", or "portra"...especially (more artifacts) if I increase "saturation",
or/and "contrast".

Due to gamut ? or anything else ?

:)

Reported by jdesmis on 2014-06-09 10:14:23

[Beep6581]

I confirm the artifacts when using default profile + "superia"-clut on yellow_poppy.nef

Reported by heckflosse@i-weyrich.de on 2014-06-11 15:49:35

[Beep6581]

The artifacts seem to be related to 'Working profile'. With 'sRGB' I don't get artifacts,
but I get them with 'Adobe RGB' and 'ProPhoto'.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-11 23:47:20

[Beep6581]

This is new patch. 
I made precalculation function in RT. It precalculate given HaldCLUT for working profile.
("Old" cluts need to be precalculate in RT before loading).
This is some CLUTs precalculated for ProPhoto working profile https://dl.dropboxusercontent.com/u/63060245/cluts/cluts_ProPhoto.zip

Now loading CLUT takes time only for loading png file. I reduce memory usage. For HaldCLUT
level 16 need 200MB of memory. Only one HaldCLUT store in memory (thumbnails with CLUT
maybe loading a little slower, but not too much)

Reported by dmitry.volvap on 2014-06-12 14:27:41

[Beep6581]

just move new entries to to the default language file.

Reported by dmitry.volvap on 2014-06-12 17:37:15

---

• _Attachment: clut_02.patch_

[Beep6581]

I tested, all worked fine but..but..

If I test the same "portra_160_16", in "direct Prophoto" with new values or after conversion
with the "old"...the result is very very very different !

Perhaps I make a mistake

Where is the good result ?

:)

Reported by jdesmis on 2014-06-12 18:08:54

[Beep6581]

in this version you need to adapt "old" versions of CLUTs to your work profile, and
use only adapting version of CLUTs. Try to use cluts from #11 with ProPhoto(!) working
profile. This will be correct result.

Reported by dmitry.volvap on 2014-06-12 18:41:16

[Beep6581]

@dmitry

It is what I done.

To compared :
1) I open (with the new CLUT) "gmic_portra160_16_Prophoto.dng"

2) with adapt Haldclut for RT working profile: I open (with the old CLUT) "ce4_portra160nc_16.png"
and attribute "Prophoto", then "adapt", I obtain "ce4_portra160nc_16.Prophoto.dng"
Now I open this new "png"

If I compare 1) and 2) result is very different

More:
It seems there is probably a gamma problem (or other things), shadows become darker
and highlights clearer

I have compared with "DxO Film Pack" (the trial version, I have installed yesterday),
and the result is very different.

Reported by jdesmis on 2014-06-13 04:27:12

[Beep6581]

gmic_portra160 and ce4_portra160nc its two different CLUTs from different sources. First(gmic_portra160)
I made copy from G`MIC, second(ce4_portra160nc) I made copy from Nik ColorEfex4 (Photoshop
plug-in).

"Kodak Portra 160 New" and "Kodak Portra 160 NC" its two different films with different
colors, its normal that they CLUTs make two different results.

At the forum, Patdavid said that he has HaldCLUTs with more precision http://rawtherapee.com/forum/viewtopic.php?f=2&t=5413&sid=8b5ec77b94ff017a89f825b7b3b55f6e#p37031
Maybe we can ask him to share them with us.

These CLUTs that I shared its only copy from G`MIC software and Nik ColorEfex4 software.

Reported by dmitry.volvap on 2014-06-13 07:45:12

[Beep6581]

@Jacques

Let me show you the "power" of HaldCLUT :)

I download the trial version of "DxO Film Pack" and process "ident_16" HaldCLUT with
all Film Profiles of "DxO Film Pack"

Let me show what I obtain:

This is image processed by "DxO Film Pack" profile Kodak Extar 100 -> https://dl.dropboxusercontent.com/u/63060245/cluts/dxo/dxo_film_pack_ektar.png

This is the same image processed by RT with copy of profile Kodak Extar from DxO ->
https://dl.dropboxusercontent.com/u/63060245/cluts/dxo/rt_dxo_ektar_example.png

Check the difference ;) You can obtain results from "DxO Film Pack" direct in RT.

This is the copy of all film profiles from "DxO Film Pack" trial version -> https://dl.dropboxusercontent.com/u/63060245/cluts/dxo/dxo.zip

Try to use them in RT, but don't forget to adapt them for your working profile!

Reported by dmitry.volvap on 2014-06-13 11:30:55

[Beep6581]

Voidwalker. here's a link to the images we use for testing : http://rawtherapee.com/shared/test_images/

Your latest patch works fine and is much faster than first one.

But there are still some issues: Try snow_street_night_shot.cr2 from test_images with
the prophoto adapted dxo_kodak_extar clut (look at the sky)

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-13 23:30:30

[Beep6581]

If we can solve the issues, we can benefit RT an important step...(Clut are very good).

I think the main issue (?) is that the "ident_16.png" file (ident_16_Prophoto.png)
shifts the histogram to the left.
This reflects what I wrote in # 15 "It seems there is probably a gamma problem (or
other things..perhaps the place in the process...), shadows become darker and highlights
become clearer"

jacques

Reported by jdesmis on 2014-06-14 04:47:50

[Beep6581]

I made  a change in "improcfun.cc" line 2780 and after with "gamma_srgb" and "igamma_srgb"

Now it seems to work fine...to verify :)

I had also add lable to "history_msg"

Reported by jdesmis on 2014-06-14 08:38:00

---

• _Attachment: clut_03.patch_

[Beep6581]

I can continue after  weekend.

Reported by dmitry.volvap on 2014-06-14 11:07:16

[Beep6581]

@dmitry

I did some tests with the base "ident_16" with "DxO FilmPack" and also "Photoshop".

This is a great tool.

Of course, one can easily simulate all colors films, slide, black and white. 

But it is very easy to render photo filters (85, 81, 82, etc..), negative,  posterize,
etc..

It will determine what functions we want, with what interface?

Reported by jdesmis on 2014-06-14 15:28:19

[Beep6581]

After many tests, it seems to me:
1) it is necessary to have several possible choices that may or may not combine:
   a) nature of the film
   b) grain (though of course we add this feature).
   c) Other, filters (color, ...), negatives, ...

2) In case b) (and perhaps in other cases ?) , artifacts may appear, and it would be
necessary to add a "filter" color (eg with a flat curve to choice the color and for
exemple avoid sky)

3) I think it would be appropriate to have the main options, pre-engineered and installed
in RT. The user should have a minimum of manipulations to do (eg fit a filter or a
film for sRGB ...)

:)

Reported by jdesmis on 2014-06-15 12:15:33

[Beep6581]

Jacques, I set the ownership to you. Hope you don't mind :-)

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-15 14:06:01

[Beep6581]

@Jacques

With your correction in #20 there no more need of adapting CLUTs. Just apply without
adapting. Super!!! I did not have this knowledge of image processing by RT. I had to
ask first before making this "stupid" adaptation function :(

And with this correction I dont see any artifact "snow_street_night_shot.cr2" with
"dxo_kodak_extar.tif"

Reported by dmitry.volvap on 2014-06-15 17:27:19

[Beep6581]

@Ingo

No problem, but the leader is Dmitry, we will work both together :)

@Dmitry

Yes #20 solved artifacts, but I think (to confirm by users - you are not stupid :))
that we must keep "adapt" because datas in RT are with "working profile" and those
"add" are with Prophoto....to tested !! But effectively if we can suppress "adapt",
it will be "Super !!"

I join a link (I hope it is good) with 4 packages :
https://www.dropbox.com/sh/gg1h9pw0k9oe79r/AABg_WipLrG6hEdJBN2NOT86a

* films colors (negatives and slide)
* films black and white
* special (filters, negative inversion,posterize...)
* grain - with differents types. For me it is not very good, and I proposed (after
test by users) probably to suppress or limited .

Reported by jdesmis on 2014-06-15 19:53:24

[Beep6581]

I have found why there are differences (with DxO and others...).
I'll proposed a solution (simple) with "new" png files (or tif)...and no adaptation.

With this modification the differences are very very little...:)

Reported by jdesmis on 2014-06-16 06:24:07

[Beep6581]

Jacques, which modification?

Reported by heckflosse@i-weyrich.de on 2014-06-16 09:26:33

[Beep6581]

@Jacques

I think the grain effect cannot be solved by CLUTs. It another task, and need another
solution.

About special filters like cooling or warming (85, 81, 82, etc..). CLUT is very expensive
(by memory) solution for this effects. Is it really need simulation of cooling/warming
filters, when RT has more better White Balance tool?

For negatives effect, has more less expensive, and more simple tool like RGB curves.

Maybe CLUTs will only simulate the colors of film ?

Reported by dmitry.volvap on 2014-06-16 10:22:43

[Beep6581]

I'll post a patch this afternoon...

@Ingo
The modification is easy to understand ! "png" that support "Clut" are elaborate with
a color-space (Adobe, sRGB, Prophoto). Those I "copy" the effects are in AdobeRGB.

If you use this CLUT in other Color-space you w'll have diffrences, or artifacts...

I simply convert data (before CLUT) to Adobe and reverse (after CLUT), If you want
to use "CLUT" (as with gamma)

@Dmitry
I think it is to the users to choose..
* for grain...I am expectative :)

* for others : 
  ** Negative inversion requires very little time...and for memory whats the problem
(if we used this tool for film ?)
  ** Filters : yes there are also WB, but if you look in Photoshop CS..there are the
two !

best regards

Reported by jdesmis on 2014-06-16 11:13:40

[Beep6581]

Jacques, since the default editing space in RT is ProPhoto, could we avoid going to
the smaller AbobeRGB space  for CLUT?

Reported by michaelezra000 on 2014-06-16 11:21:09

[Beep6581]

Michael

Want to work in "all price" with prophoto is an illusion. There certainly are advantages,
but also disadvantages .. what is the point of reproducing colors invisible, or imaginary.
Thats need a big "jump" if we choose Output sRGB !

Nevertheless, I am in general agreement to work with Prophoto ... despite some drawbacks.
Regarding the films (color) all without exception are clearly prophoto below (near
Adobe or little more) .

LUTs are built smart copies, but here I am inspired by DxO working entirely in AdobeRGB.

If you find any possible good quality prophoto copies, it will be easy to modify.

:)

Reported by jdesmis on 2014-06-16 11:40:29

[Beep6581]

Here a new patch

I disabled (not suppressed) adapted function.

You must use "png" from joined link "CLUTAD" - not others files (artifacts).

https://www.dropbox.com/sh/2z1c1pv3yagqo2p/AADx2XgFRhjQMpTdEWcT8wysa

If you change "working profile"...no problem. The code is only moved automaticly to
"Adobe RGB" for calculation, if you check "CLUT enabled" and choose a file.

Differences with "original" are visually almost imperceptible !

:)

Reported by jdesmis on 2014-06-16 13:32:06

---

• _Attachment: clut_04.patch_

[Beep6581]

if I want to use HaldCLUT copied not from "DxO Film Pack", what I need to do, with my
CLUT, for using it in RT (after clut_04.patch)

Reported by dmitry.volvap on 2014-06-16 14:02:13

[Beep6581]

If you want to use other CLUT...:
1) you must generate them in a correct "working profile"...wherein the CLUT that have
been developed. Probably sRGB..or AdobeRGB..perhaps Prophoto ?Otherwise there will
be artifacts 

2)after..we must change slightly the code with   "TMatrix toxyzad, torgbad, adtoxyz,
adtorgb" to adapt to another "CLUT profile construction"...It's easy to do (with a
"combo box"...or other). If you want I can do..no problem :)

Reported by jdesmis on 2014-06-16 14:09:48

[Beep6581]

I have no expirience in image processing. Can you explain me some moments? 

Why you convert to AdobeRGB? Why not to Color Space readed from PNG format? 

When we making copy by "ident_16.png" in what color profile we making this copy?

Reported by dmitry.volvap on 2014-06-16 16:37:44

[Beep6581]

Excuse my very bad english :)

I convert to AdobeRGB, because "DxO Film Pack" use this "Profile" to encode his LUT.

I am sure, because I have tested....

DxO always use AdobeRGB..why, why not ? Ligthroom use "Prophoto + gamma sRGB" call
"Melissa", but Adobe do'nt furnished LUT for film !

But when you code LUT...in RGB, the values depends from the "color space"...The only
values that are independant of "color space" are "Lab". 

When the "coder" (DxO...GMIC...others) fill its LUT with values, these values refers
to one profile, that of course, he knows ! (for GMIC I don't know...)

If you want to deliver the same effects ... You mix the RGB data, from image and those
of the LUT. They must have the same references otherwise, colors will be bad, or there
will be artifacts...in the case of DxO...it is "AdobeRGB" 

Is what I am clear ?

Reported by jdesmis on 2014-06-16 16:56:42

[Beep6581]

When we copy(!) CLUT with "ident_16.png", are you sure that we copy AdobeRGB color space
too?

Tomorrow I will test for difference clut_04.patch with your cluts, and clut_03.patch
with "old" cluts.

Reported by dmitry.volvap on 2014-06-16 17:48:54

[Beep6581]

Ok. I made some test by numbers. 

This is my action sequence:

I made target image with four colors:
     R    G    B
1)   0  246  255
2)  18  255   29
3) 255  141   18
4)  73   81  250

I processed this image with "DxO Film Pack" profile "Agfa Vista"
this 4 colors what i obtain, this is will be target colors, that we want to receive
in RT with copy of profile "Agfa Vista"
this is that 4 colors from DxO Film Pack:
     R    G    B
1)  14  249  255
2) 163  253   86
3) 255  137   12
4)   0    1  209

I build RT with clut_03.patch and load "dxo__agfa_vista_16.tif" with differnt working
profiles:

working profile AdobeRGB:
     R    G    B
1)  62  247  255
2) 189  252  103
3) 255  143    0
4)   1    1  209

working profile ProPhoto:
     R    G    B
1)  65  247  252
2) 177  252  121
3) 255  145    0
4)   0    0  207

working profile sRGB:
     R    G    B
1)  10  248  255
2) 162  252   86
3) 255  135   12
4)   0    1  208

I build RT with clut_04.patch and load "Agufa_vist200.png"(from link at #33) as a profile
.
with different working profiles (AdobeRGB, ProPhoto, sRGB) a received same colors,
as we expected:
     R    G    B
1)  115  244  255
2)  169  250  130
3)  255  142   47
4)   20   21  186

and for last I load "dxo__agfa_vista_16.tif" in RT with "clut_04.patch" (I know that
this is "wrong" CLUT profile, but I just decide to test)and recieved same color as
"clut_03.patch" with working profile AdobeRGB:
     R    G    B
1)  62  247  255
2) 189  252  103
3) 255  143    0
4)   1    1  209

The result was the most accurate color we recieved with "clut_03.patch" and sRGB working
profile. And clut_04.patch generate same colors as clut_03.patch with AdobeRGB working
profile.

Maybe we should convert to sRGB profile on the fly ?

Reported by dmitry.volvap on 2014-06-17 09:58:47

[Beep6581]

The "ident_16" file is a problem because it always shifts the histogram to the left.

I tried thinking that it must be a problem of gamma or allocation profile (not profile
conversion).

Finally, everything works correctly when assigning a "sRGB" profile to ident_16, but
this only works with "TIF" extension (with "png" the reslt is bad)

I retouched all CLUT for films, and again there is only the TIF (16 or 8 bits) extension
works (I choose 8 bits compressed and result is good)

I checked out several images with "Dx0FilmPack" and "RT", and with "layers difference"
Photoshop, the differences are tiny, totally invisible to the eye,in Lab mode (8 bits)
the differences are L=0 a=0 b=0

I checked again on other files and then I attach a link with the new CLUT.
No change in the code.

:)

Reported by jdesmis on 2014-06-17 10:00:13

[Beep6581]

I have tested with many files...and many "CLUT"(..,...,agfa_vista,...)...no visible
differences, tiny differences in histogram,  tiny differences in datas (<1 or 2 for
R,G,B in [0..255]) in Photoshop CS layers differences.

I create link for CLUT..my internet connexion is very low :)

Reported by jdesmis on 2014-06-17 10:56:28

[Beep6581]

I always use tif files, because RT builded by myself crash on png files, I dont know
why.

my tests on tif format files show more visible difference:

   DxO Film Pack with Agfa Vista            
     R    G    B     
1)  14  249  255
2) 163  253   86
3) 255  137   12
4)   0    1  209

  RT clut_04.patch with "Agufa_vist200.tif"
     R    G    B
1)  62  247  255
2) 189  252  103
3) 255  143    0
4)   1    1  209

With RT clut_03.patch and "ident_16.tif" I have no shifts.

Reported by dmitry.volvap on 2014-06-17 11:42:54

[Beep6581]

For png files, it is a build problem...due to Gtkmm64

Wait 20 minutes...and I join the link...

For me no more problem...(with CLUT) :)

I am very satisfied with the result.

Dmitri, you brought real innovation, - thank you very much - much better than that
obtained by ICC profiles.

Remains a major problem - the size of the CLUT file - where to put them so that they
are readily available to users. I do not think a link "Dropbox" to your or my site
to be sustainable.

:)

Reported by jdesmis on 2014-06-17 11:54:01

[Beep6581]

Here the new link !

"CLUADO_S" - for Clut in "Adobe RGB", and "ident_16" with "Attribute sRGB profile"

https://www.dropbox.com/sh/xikkh9jcspytpy9/AADaG4bsslkCjYhA7w0MMyO2a

:)

Reported by jdesmis on 2014-06-17 12:01:26

[Beep6581]

Dmitry, concerning the crashes with png files:

Try with a modified cmake command
Here's mine. 

cmake -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" -DPNG_LIBRARY:FILEPATH="C:/gtkmm64/lib/libpng14.dll.a"
-DPROC_TARGET_NUMBER:STRING=2

Without the -DPNG_LIBRARY:FILEPATH="C:/gtkmm64/lib/libpng14.dll.a" my builds also crash
with png files.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-06-17 12:14:10

[Beep6581]

we recieved different results with the same code and files :)
Maybe we need stop and synchronize :)

Reported by dmitry.volvap on 2014-06-17 12:17:52

[Beep6581]

I have a "little" deadline on my primary work, and I cannot react fast :( sorry for
that. But I will test new files later, maybe this evening.

Reported by dmitry.volvap on 2014-06-17 12:27:19

[Beep6581]

To be clear:

For me the good results are :
 * Clut_04.patch
 * last link with "CLUADO_S" 

Other things :
To do good comparison, "Lab" values are preferables to RGB...RGB depend of "working
profile", "Output profile" and "gamma"...Which are often differents between soft

Or, you can in the same condition use "Layer differences" (Photoshop) to objective
differences...

From my test betwween DxOFilmPack and RT, delta Lab are very tiny Delta_L<1 Delta_a<1
Delta_b<1, this is a very good result...for a "copy" :)

Reported by jdesmis on 2014-06-17 14:39:57

[Beep6581]

I use sRGB Output prifile and default gamma, and I have visible different with DxO Film
Pack with CLUTs from #44. 
The closest colors I recieved with clut_03.patch and sRGB working profile with CLUTs
from #17.

Maybe we need to read color space from CLUT tif file, and convert not only to AdobeRGB,
but to color profile readed from CLUT tif?

Reported by dmitry.volvap on 2014-06-17 16:17:50

[Beep6581]

Would it be more logical to convert the clut file to rt working space instead? This
wpuld give user some level of control.

Reported by michaelezra000 on 2014-06-17 16:45:29