Legacy ImageMagick Discussions Archive

I've found a solution on another forum. I used the GIMP plugin G'MIC from the command line. It's really simple to install on linux; I used homebrew on mac with
The script takes a LUT input (in my case .CUBE) and converts it directly to a Hald Clut PNG
I created a quick and dirty script to take a directory of files and quickly give the PNG output.

I'm glad you found a solution after so many years!

however, Since LUT are simply a MASK to a picture (apply bit per bit with a corresponding math function),
II believe 2D LUT (PNG) should be supported directly with image magick.

this would avoid us the trouble to load the image in photoshop to apply the LUT on image.
LUT are also used in direct feed camera for streaming (with OBS/Twitch/Youtube)

thanks for Image Magick though, great program.

ImageMagick supports both "2D" and "3D" luts, using "-clut" and "-hald-clut" respectively. However, IM needs the luts to be images, and doesn't support formats such as .CUBE.

How can we make a feature request to support .cube and/or other basic 3D Lut data files? (.lut, .shlut, .3dl, .cube)

Currently ImageMagick supports other data files such as CDLs. However it currently only supports HALD files for LUT transforms.
In order to create the HALD files ImageMagick users need to use a separate software package, find a conversion script, or reverse engineer and write a converter.

I recall this subject has been brought up in other posts. I know FFMpeg supports .cube and other 3D Luts, I believe. And it may remove some of the HALD limitations, such as support for negative or over 100% values.

How can we make a feature request to support .cube and/or other basic 3D Lut data files? (.lut, .shlut, .3dl, .cube)

Post this same message to the Developer's forum.

B4adle7 wrote:How can we make a feature request to ...

Post to the Developers forum: http://www.imagemagick.org/discourse-se ... 1351dd23dd

To help the developers, you should include references to documentation on the formats you would like supported.

Ideally also suggest how IM will identify the format. If any of those formats are valid image formats, then a suffix (.lut etc) isn't sufficient.

B4adle7 wrote:And it may remove some of the HALD limitations, such as support for negative or over 100% values.

It already does, in the sense that if the hald-clut contains values outside 0 to 100%, those values will be used in output. However the input coordinates to the hald-clut correspond to input values of 0% at top-left to 100% at bottom-right. Do you want this to be more flexible? If so, please describe.

Thank you for the responses, and forgive the delay in reply.
Yes I will post that to the developers forum.

If any of those formats are valid image formats, then a suffix (.lut etc) isn't sufficient.

Unsure of the note here, but just in case. .lut is a "Look Up Table". Same data as in a .cube, shlut, or .3dl file. Basically the non-image version of a HALD CLUT file. Since Imagemagick supports CDL files (.cdl, .cc) (Color Decision List), that are XML data files of color transforms, would think doing the same with their LUT counter-parts would be an of-course.

The second part of the response asks for a description. And to be fair have not had a breath to explore using .exr files and the full 32 bit HDR version of IM.
Commonly have used .png HALDs to do the color conversions of Log colorspace to linear or the desired sRGB/rec709 viewing colors.
However more and more often encounter instances where color transforms (LUT/CDL) are done oddly, or over-done, pushing colors over (1.0+) or under (negative) in one color transform, then back into acceptable range with another. (Think kids drawing outside the lines).
However in order to process the data and keep everything matched, the same is needed.
PNG does not support below 0 or above 1.0.
Also you bring up a good point, what if it is not just the color range that needs matched, but the range also.

The data formats mentioned are not images. Direct data to transform color values. They are usually simple ascii text files allowing for 1D and 3D color transforms. This is a link that mentions several of the commonly used ones.
https://kb.pomfort.com/livegrade/cdl_al ... or-export/

Thank again for the response. Will see about adding that to the developers post

1D cluts are images in ImageMagick. But you can create them as text values and import them via NetPMB image formats into 1D images of 1 or 3 channels. Hald-Luts in ImageMagick are 2D images. I know of no way to convert from text formats to Hald-Luts, currently in ImageMagick. In HDRI compiled ImageMagick, if you have values outside the Quantumrange for your compile, you can use TIFF or PFM formats to store images that go outside the range such as negatives and fractions. Perhaps one of the other users have more to contribute her than I.

wlange wrote: ↑2016-11-29T13:14:50-07:00 I see. The most common ones seem to be Autodesk .3dl and Adobe .cube. If these don't differ in themselves, that might be a good start.

I'm not an expert in this field. But if ImageMagick was able to utilize most common standards, it might help some folks. Just my $0,02.

Agreed.
I see a lot of common response of '''Just take it into this software, and convert it to this format, then invert it into this file type'''.
"Let them eat cake"?
Often the needs for supporting standard formats for image transforms are for script processing and automation.
Yes, it is fairly straight forward convert a .3dl or .cube file into a usable HALD image. But that is another 1 or 2 steps to add to the process, when the same information needed is already there in a standard data format.

e.g. Imagemagick already supports CDL data format (Color Decision List, and .xml of Slope, Offset, Power, Saturation)

B4adle7 wrote:Yes, it is fairly straight forward convert a .3dl or .cube file into a usable HALD image

Can you provide any help or information as to how to convert the 3Dlut format into a HALD image?

How they are being created now is by taking an identiy HALD.
e.g.
magick.exe convert hald:4 -depth 16 C:\temp\identy_hald.exr

Then taking it into your compositing app of your choice, applying the LUT (.cube) via an OCIOLutTransform node, then saving the HALD file out as desired for what the LUT it represents.

Under development:
Currently am trial and erroring to create a script/app to directly covert the .cube file LUT into a .png or .exr HALD file.
By creating creating magick commands to draw the specified 3DLut color per pixel it seems to be starting to come together.

Thinking out loud:
Just for mental brainstorming and part of the trial and error.. a common .cube/3DLut generally has 32768 color entries.
It doesn't seem that a HALD necessarily needs to be a square. Or does it? Do they need to match one of the exact HALD resolutions?
These are rhetorical questions.
The current status of the little function creates a HALD image that is 128x256 to cover the LUT entries.
However that creates a psychodelic image.. wooo. 32768 is not square-rootable, so can't really turn it into a square.
Getting ready to go back and have it draw the LUT-HALD at 256x128 to see whether that does the trick.

Currently the thought is applying all the 3DLut values. However if that does not do the trick, will rewrite the function attempting to pick through the LUT data and cherry-pick colors to force what possible data in the LUT into one of the required sizes.

Hope some of that makes sense. Applying the HALD LUT is built into a lot of my conversion commands. Hoping to feature request it into Imagemagick to support 3DLuts. Thanks for the response.

ImageMagick does not have OCIOLutTransform node, as far as I know. What is it? Is that code available?

For imagemagick purposes, we do not have any mechanism to apply the CUBE LUT to a HALD image, such as OCIOLutTransform node, as far as I know. What is OCIOLutTransform? Is that code available?

So we need a way to convert the CUBE LUT data directly to HALD format.

Right now in IM 7.0.8.16, we can convert a CUBE LUT into an image.

http://www.fmwconcepts.com/misc_tests/c ... brant.cube


It is smaller than a HALD image, but does show some similarities.

fmw42 wrote: ↑2018-12-13T16:04:11-07:00 ImageMagick does not have OCIOLutTransform node, as far as I know. What is it? Is that code available?

For imagemagick purposes, we do not have any mechanism to apply the CUBE LUT to a HALD image, such as OCIOLutTransform node, as far as I know. What is OCIOLutTransform? Is that code available?

So we need a way to convert the CUBE LUT data directly to HALD format.

Right now in IM 7.0.8.16, we can convert a CUBE LUT into an image.

http://www.fmwconcepts.com/misc_tests/c ... brant.cube

Oh.. I need to check this out.

An OCIOLutTransform is the same thing as saying CLUT. Same concept and function, just rather than using a HALD image it uses a data file of the same information.

But the above information is very interesting. I need to go test and make use of. If IM already does a conversion from a .cube to an image very handy. Also the strip if HALD colors is a nice setup that solves some other worries about HALD image dimensions. I was hoping they weren't restricted to square, but not confirmed yet.

Thanks 42

Ok.. very interesting. Did not know about the
magick cube:"<lut.file>" "<out_hald_file_image>"
ability.
But no go yet. It seems the image it produces has the color gradients going in different directions than what the working HALDs have. e.g. green seems to go from low to high horizontally left to right. But in HALD images, they are top to bottom for each value of blue.

Thanks for the responses, each time getting a chance research it a bit more.

B4adle7 wrote:I was hoping they weren't restricted to square, but not confirmed yet.

IM hald cluts are limited to square. If the hald image is non-square, only the top-left square within the image is used.

In addition, the hald must have an integer level number, where the number of pixels in the hald is pow(level,6).

For example, level 16 has pow(16,6) pixels, 16777216 pixels, which is a square with 4096 on each side or a cube with 256 on each side.

That is the only 3D clut processing that IM has built-in.