Creating wider gamut G'MIC Color Presets?

I’m really fond of using the G’MIC Color Presets (particularly the Films: Negative [Old] presets) as a last step (using lut 3D module) in the pipeline before the “output color profile” module in darktable.

I believe the correct way to apply these is to use sRGB as the “application color space” in lut 3D.

I suspect this means my colors will be limited to the rather narrow sRGB color space, even if I chose Adobe RGB as my “export profile” in the “output color profile” module. I’d rather be using a wider gamut. My production master files (TIFF) are in Adobe RGB (1998) since nearly two decades back, so that I’d like to continue with that practice. Can anybody recommend a way of creating wider gamut (Adobe RGB) versions of the presets found at

Also, would I be better off using HaldCLUT or Cube version of the G’MIC Color Presets for maximum quality? darktable supports both.

I suspect I should ping @patdavid for this question. :slight_smile:

Perhaps @David_Tschumperle as well? We have other colour enthusiasts on the forum that I am sure would be clambering to chime in.

One little idea from me is that G’MIC interpolates its CLUTs, so, in a way, narrow becomes wide. The main issue in my mind is that most CLUTs are designed from the context of sRGB. I mean how many people design their CLUTs with Adobe RGB in mind?


Thanks! Also found this slightly related thread. Does not give an answer to my question though.

I have no idea how they’re generated and if it’s possible to create Adobe RGB ones from some sort of “source”. I see they’re updated quite regularly. Last update was made 2021-05-13.

There may be several topics in that thread.

  • color space
  • accuracy
  • compression

Color space
If you use a hadclut built for sRGB I think you could try to convert the file (which is an image) to Adobe RGB to get a new hadclut working in Adobe RGB. That should work. Am I wrong ?

I’m afraid you cannot increase the level of information contained in the LUT.
The precision depends on the size of cube and of the numbers themselves. Most of the halcluts are 8 bits but some of them are 16 bits.
However any transformation of the cube at constant size will tend to decrease the accuracy.

Some time ago GMIC used to provide routines to compress / uncompress LUTs.
You’ll find some tips here but I don’t know if that still works.

I hope that helps

David’s research has resulted in being able to not just compress CLUTs well but expand them without much loss. I suppose that the error would depend on the density of the original CLUT. My concern is

To clarify, what I mean is that a CLUT designed for sRGB may not have the same quality as one designed from ground up for AdobeRGB; however, with G’MIC’s flexibility we could arrive at a happy medium.

Hi @mikae1 !
I’m new here, but I studied a lot 3D-Lut and LUT in general for a project I had.

  • I think that 3D-Lut are the best for color grading, they give best accuracy. But they are not as easy to find/create as 2D-LUTs.
  • You would be surprised : the size of professional lut are sometimes extremely small. But most of the time they are stored in a proprietary format and I suspect that the data is a mathematical formula, or a curve, so the accuracy is perfect.

The problem is that create a 3D-LUT is cumbersome, or expensive. Programs are not cheap and have a steep learning curve.
But there’s a free one, that I tested and seems good, in my opinion, GrossGrade :

But you can use 2 websites to create your own 2D/3D LUT :
LUT Generator | ARRI (not really tested)
LUTCalc I used this one, as you can choose the accuracy.

The websites are more about color grading from a source like camera to final color profile. The program is more about creating effects like sepia, desert, bluish, whatever.

Edit : Have you read this ?


Thank you all for your replies!

I was thinking that this wouldn’t work as the gamut is sRGB and the conversion won’t automagically expand the gamut beyond the source space? I’m not sure though, this is more of a question. If I want to try this, should I assign the sRGB profile to the .png and then convert to Adobe RGB? Sorry, that may be Photoshop lingo. Not sure how I’d do it with free tools. Guess there’s a way in ImageMagick or G’MIC?

I’m reading the quote below as a sign that it won’t make the gamut any wider?

That’s a very nice find, thank you! :sparkles: Seems at least the beta will be free. I’ve been wanting to try 3D Lut Creator for some time. Russian software just like GrossGrade.

Yeah, read it some year ago. Perhaps I should give it another read.

1 Like

Not expert about Photoshop lingo, but that seems correct to me.

It won’t make the cube transform more accurate. But if my guess is correct, you should get a new cube applying in the Adobe RGB gamut (which is wider than sRGB one).

1 Like

I realize I still have questions :slight_smile: The G’MIC Color Presets are available from or Those from are routinely updated (last update 2021-05-14) but are “only” 512x512 px. Those from are 1728x1728 px, but they were last updated 2015-09-20.

Are the 1728x1728 px ones from necessarily better, or should I go for those more recently updated?

Thanks! Regarding HaldCLUT vs. Cube versions of the G’MIC Color Presets from, do you know if they are “the same”?

A 512x512 haldclut corresponds to a 64x64x64 cube while a 1728x1728 haldclut corresponds to 144x144x144 cube. The interpolation calculation will be more accurate in the second case.

If I remember well the rawtherapee halcluts are 16 bits instead of 8, which provides also more accurate values.

To be honest, I’m not able to see any difference in the result.
GMIC team considers that a 48x48x48 cube is enough to be accurate. That’s the size of the compressed clut.

I cannot answer really. Can you see the difference ?

Some answers here, I’ll try to not be pedantic. :smile:
A photo/picture can an embedded color profile (the most cases) and none. If you work with a jpeg/raw from your camera there will be an embedded color profile (sRGB, Adobe1998, and so on), but sometimes photos don’t have (and it’s bad).

  • If you attribute (assign) a color profile to a photo, you say to the photo : whatever is you profile (and maybe you have not), I say that it is sRGB (for example). so this pixel R=123, G=148 and B=251 will now correspond to this pixel in the color profile I assign to you. So when you do that the colors in your photo change instantly, as the pixel R=123, G=148 and B=251 is not the same color in sRGB or in Adobe1998.
  • However, if you convert a photo from a profile to another, every pixel color will be converted to be the “same” in the new color profile. 2 photos in different color profiles, but the 2nd is converted from the 1st, will look like the same. So the pixel R=123, G=148 and B=251 in sRGB will become R=101, G=122 and B=255 in Adobe1998 (whatever). The big difference is here : a color inside the 1st profile can be outside the profile in the 2nd. That means that every pixel outside the profile will be clipped. To avoid this you’ll have to change it, by lower the light for example.

G’mic/ImageMagick may do that, I don’t know, as I attribute and convert profiles with Gimp, which is able to do that correctly in the last versions. And sorry if you already knew that.

1 Like

Personnaly I use a 63x63x63 3D-lut with an insane amount of decimals, because G’mic is not impressed and works at the same speed, more or less. So bigger file does not hurt the workflow.

Besides, I did a test with a poor 3D-Lut (like 8x8x8) and a big one. Then I opened the 2 results as layer with gimp, and the above layer was set to “difference”. And yeah you see them. especially in the borders of objects/persons, the silhouettes. But all picture is concerned.

No one seemed to notice this remark of mine. For an interesting discussion on G’MIC, CLUTs and more read CLUT compression.

With so low definition (8x8x8), indeed, you can see a serious difference with normal ones. But between 48x48x48 and 63x63x63 ? Really ?
Of course, 63x63x63, or even more, doesn’t hurt if your hardware supports it !
Dt supports 256x256x256 LUTs.

Sorry, I’m not sure to understand what you mean there but that doesn’t seem to be related to gamut width…
Anyway, I have myself transformed LUTs to compressed LUTs using GMIC command line (not sure this is still available, but that was a quite long process). With my not so young eyes I could not see any difference between the produced images (at least above of 33x33x33).

I rarely play with LUTs and haven’t looked into G’MIC’s management of them, so take my comments with a grain of salt. The reason for bringing up compression is the idea that compressed LUTs must be decompressed. If that is true, I suppose it could become any size, not just 33, 48 or whatever the default is supposed to be. David recently published a paper on this. The link I provided provides the details on that. Here is one of G’MIC’s commands:

Exactly. And as the speed is the same…

All my respect to Eugene Vdovin, the creator of GrossGrade program. As he said:

The current developing status is early BETA, and the author of the program is a single mortal man, so please, don’t judge severely for the unfinishings existing in this BETA or for incompletely actual documentation. In this case “BETA” stands for “beta than nothing”.

Hope someday he develop a Linux version of his program. Meanwhile we are going to continuous using other apps.