I cannot wait to experience this module. Thanks a lot also from my side.
A little OT and newbie question…
Is there an easy way to do this multi-replies? I only see that full quote button…
TNX
Great source !
In the gamma category, most of the values are not applicable in dt, especially the log ones.
The log colour profiles are camera manufacturers’ raw profiles. To take advantage of them we would have to make dt able to treat them as a raw profile (before color input module).
EDIT: see log and hdr explanations by Sony https://helpguide.sony.net/di/pp/v1/en/print.pdf
1 Like
You select the piece of text you want to reply to. A Quote overlay does appear just above your selection. Clicking on it adds the quote to your current message.
I hope that answer the question…
2 Likes
It does!
Thank you very much!
Cheers
Axel
BTW, Philippe maybe you could write a text for the darktable blog?
See for example : blog | darktable
1 Like
Impressive! It claims to achieve 99% compression !!.
G’MIC provides already some tools to compress and uncompress the lut files.
The @jpg comment is more text cube file related which is bigger than equivalent png file, by nature.
But the interesting news here it that, with a 99% compression rate, it could turn possible to store the lut (compressed) data along with the image’s dev parameters (instead of keeping only the file name).
For reference https://hal.archives-ouvertes.fr/hal-02066484v3/document
I’d gladly share the decompression code (in C++) for integration into any free software that needs this feature 
https://framagit.org/dtschump/libclut
4 Likes
That sounds great !
Is there any convention already defined to distinguish a compressed haldclut from an uncompressed one ? Or is there an automatic way to know that a png haldclut is compressed ?
I don’t have non-compressed HaldCLUTs anymore in G’MIC, so all CLUTs available in G’MIC are compressed this way.
Something to be integrated into your dt 2.8 presentation (as there is for each new module for dt 2.6), is that what you think about ?
Indeed there will be a need for documentation for this module.
But I was also thinking about a blog post to show what could be done with this new module. As an example see this blog post:
This is more a communication to advertise the new features.
It’s easy to create HaldClut.png files with G’Mic, you just have to have an identity.png file and apply a movie profile to it in Gimp. I wrote a French .pdf to create dtStyles so the first part explains how to do it: https://drive.google.com/file/d/0B1cvWUEQ2QwiUUg2eXE4T3N5VGs/view
I also used this method with DxO and I think it can be done with PS and his presets.
I hope the translation with Deepl is Ok.
1 Like
I think your are doing here manually what @anon41087856 was suggesting in this issue:
The limited number of points of dt color checker LUT and the small number of keypoints of the 3D LUT compression algorithm sing the same music for me.
Would the limited number of keypoints from 3D LUT compression fit into the color checker LUT EDIT: (lab<->rgb transform apart) ?
@hanatos, would you have any idea about this ?
EDIT: I rephrase my question. Instead of rebuilding the full 3D LUT from the compressed keypoints, would it be possible to interpolate directly an image with the keypoints themselves, as color checker does with 6x4 or 7x7 patches ?
I didn’t see this post from Aurelien Pierre, thank you for the link.
For the method I edit in my Acrobat, I started from the Dutch_Wolf video: https://youtu.be/m_cLCL5PJk4
that I have translated for French users. Dutch_Wolf kindly provided the modified.cht file to make it work.
I had opened a topic on darktable FR : Convertir Film Emulation de G'Mic en DTStyle
I have a big archive of HaldCLUT in uncompressed.pdf so the ones I made with the G’Mic profiles in Gimp, also the ones with FilmPack from DxO and the profiles proposed by Fuji.
yes the gmic compression is very similar as it solves a very similar problem. there are subtle differences. the system in dt allows unbounded input (extends outside the cube bounds, we have an extra two “hdr patches” usually in the mix to steer the behaviour for bright values). it’s simple to apply it to rgb or camera rgb, just needs a refit (and i think this is indeed what we should be doing to profile cameras too).
there is a trade off in speed. our RBF are global, i.e. for every point you always need to evaluate all 49 nodes (49 is just because 7x7 still looked manageable in the gui). the gmic diffusion approach uses about 10x this number of nodes, at which point a global RBF should maybe be slower (hence my question in the other thread).
i like the RBF system because you can manually edit it to taste after the fact, and because it has a linear part it degenerates to. i’m positive speed could be improved, too.
gmic’s diffusion-based approach would probably mean if you want to edit the nodes you’d be best off re-running the uncompression as a whole rather than doing it on the fly for the whole image (even 256^3 is still only 16MP).
I’ve made work the decompress_clut.cpp (+ CImg.h) stuff from @David_Tschumperle inside my local dt copy.
But, to make it work I’d to cheat with the build and remove the option-Wshadow from CXX_FLAGS in build\src\iop\CMakeFiles\lut3d.dir\flags.make to allow decompress_clut.cpp to compile.
This can be a show stopper as the CImg.h is a huge and heavy concrete C++ library, in case we cannot disable the option -Wshadow specifically for it. It would be a huge work to modify the code to avoid shadowing (I don’t even know if it would be possible).
The code is available here: GitHub - phweyland/darktable: darktable is an open source photography workflow application and raw developer branch lut3d.
I’ve made my tests with the following files:
I’ve extracted the compressed files from the GMIC clut library but one should be able, thanks to GMIC tool, to compress any cube or png haldclut file of his choice (there is still some work to be done here).
As announced by the GMIC team, one cannot see the difference with the uncompressed file ! However, there is a price, at least with the current code, we get a one second overhead when opening the applying the compressed lut.
1 Like
gmic caches the extracted cluts. you could use the same cache dir as them and have the benefit that both tools benefit from one tool extracting the clut.
I can do this probably. Will check today.
I’ve done some cleaning this morning, and I can say CImg now compiles with -Wshadow, at least for g++ version 5.5.0 (and later).
The modified CImg.h file can be downloaded from the repo : Sign in · GitLab
2 Likes