I understand that you can still export CLUTs as .icc profiles.
I’d be really interested to know what well known image retouching software allows to import .icc profiles, just to apply a color-modification filter on an image 
I haven’t seen such software. But even if there is no such software, this doesn’t disprove the reviewer’s comment. ICC profiles do store colour tables, and those could be used for image retouching. David’s task is to show that, although he could store CLUTs in ICC profiles, he doesn’t for reasons X, Y and Z.
I can see that argument. A channel with 256 possible values can be divided exactly into 16 divisions, which means 17 samples. Of course 17 is very low, but the same argument applies to 65536 possible values, which can be divided exactly into 32 divisions, which needs 33 samples.
So the argument is valid, but is it correct for this application? Does it matter that David’s scheme has non-integer divisions? I don’t know. David might say it doesn’t matter for reasons X, Y and Z.
(Disclaimer: I have no known connection with David, or TOG, or the reviewer.)
Because I’ve seen no software that takes icc profiles as input to apply color changes in an image ?
Apart from that, not sure that saying file format X is better than Y is useful, unless you demonstrate X is better suited to store the data. Here .icc profiles are able to store CLUTs, and then ?
As the reviewer said, that’s still a classical storage as an array of colors, I don’t see the added value compared to using .png or .cube.zip files.
I still don’t get it, why subdivising by 17 is better than by 16…
Hi,
(disclaimer: I didn’t read the paper, so take my comments for what they are…)
FWIW, I agree with @snibgo, this seems to be a fair point, and something you should be able to address very easily in your revised version. It doesn’t matter much that you think it’s not worth it: as you have been unlucky to find a (self-proclaimed) expert reviewer who thinks this is a necessary comparison, this is something you “should” do, if you really want to resubmit to the same journal. It wouldn’t be the first time people add content just to please some reviewers looking for an excuse to “kill” a paper. I agree it shouldn’t work that way, but unfortunately sometimes you have to bite the bullett…
On the other hand, I can totally understand why you were upset by this comment:
In general, I would suggest that the authors spend a significant amount of additional time learning about ICC profiles, color science and color tables. That will provide a solid foundation upon which to attempt to re-write this paper.
This kind of patronizing statements serve no purpose other than feeding the reviewer’s ego, and I think the best thing to do is simply ignore them…
HTH
We are not dividing by 17. We are dividing into 16 intervals, which means taking 17 samples.
This may be a misunderstanding by the reviewer. (If so, the submitted paper may need to be clearer.) For input values of 0 to 255, so 256 possible values, there might be a sampling at value=256. The reviewer seems to asume that is so.
With 17 samples, the sample points are then at at 0, 16, 32, 48, 64 , 80, 96, 112 ,128, 144, 160, 176 , 192, 208, 224, 240, and 256.
With 16 samples, the sample points would be at 0, 17.066, 34.133, 51.2, … 256.
On the other hand, David’s scheme may not take a sample at 256. In that case, 16 samples would mean 16 (not 15) intervals.
Not quite, the upper limit for an 8 bit table would be 255, not 256.
For integer increments you want 255/(n-1) to be an integer, since the factors of 255 are 3,5,17 you get integer steps with a product of some of these +1.
e.g for 16 steps, the samples are at 0, 17, 34, … 238, 255.
@paulmiller: see my last post above. The reviewer may be assuming (possibly incorrectly) that a sample is taken at 256.
Ah. Comprehension failure on my part - I thought you were describing an actual table, not the reviewer’s mistaken version. Sorry.
Indeed, 256 is not a part of the interval. 255 is the last value.
That seems to answer the reviewer’s problem.
From the Hal-archive paper https://hal.archives-ouvertes.fr/hal-02066484 , the domain is [0,255]^3 , so it is fairly obvious that 256 is not part of the interval, and that samples of sizes 16^3, 32^3, 64^3, 128^3 and 256^3 from a cube of [0,255]^3 give intervals of those sizes, giving integral divisions.
Perhaps this is not so obvious in the new paper, or the reviewer was having a bad day.
For precision, we might want domains [0,65535]^3 or larger. Perhaps the new paper addresses these.
The new paper might also consider the extent of lossiness. In the thread Help to create a set of "PIXLS.US" color LUTs ? - #56 by David_Tschumperle , “The PseudoGrey CLUT cannot be lossy compressed without losing its pseudogrey property”. I guess the pseudogrey property was below the quality threshold. Is there some analysis of what CLUts can be effectively compressed, or where problems occur?
rawproc will allow an arbitrary application of a “colorspace” transform (‘convert’, in the ways @Elle taught us) at any point in the toolchain, using an ICC profile as the output profile, if there is an input profile attached to the internal working image at that point in the toolchain. I use LittleCMS for the heavy lifting ( cmsTransform(…) ), so whatever it can handle in a profile is valid, including LUTs.
Reading the snippets you provide, it would seem the author of them is not aware (or disdainful of) other LUT formats and their applications. A good counter example is the grading of log format video; these LUTs are not used from ICC profiles. His objection to your lack of consideration of an ICC approach shouldn’t be a constraint to your paper’s acceptance. With regard to ‘competition’, if the committee is actually thinking in those terms they’re doing a disservice to the concept of scientific inquiry and the presentation of alternative work to the same end. If they both meet the grade, I would argue both papers should be accepted.
If the other papers are relevant to your line of inquiry, go ahead and cite them. Who knows, you might find something additional to consider. I know in dissertations such completeness is a virtue; this may not be that sort of writing, but doing it probably helps you get past the acceptance wicket…
I haven’t published anything before but I recall being taught to cite beyond what I used for completion and to avoid the nasty business of accusations of plagiarism. Red tape for sure. As for ICC, merely mentioning it as a possibility might be enough.
1 Like
Incidentally: the decompression part of David’s work takes a sparse clut and fills in the blanks, making a complete clut.
I’ve done the same thing, at Sparse hald cluts (2017). My goal was different: given two versions of the same image, what haldclut transforms from one version to the other? The pixels of one version give the RGB indexes into a haldclut, and the corresponding pixels of the other version give the colour values. Then we fill in the blanks, so we can use the same transformation on other images.
Beware: my method uses ImageMagick, and is clunkier than David’s, and probably slower. I didn’t even write it up properly because I became distracted. But it works.
I expect David’s method could be easily tweaked to similarly find the clut that transformations from one image to another.
Some remarks on this topic:
- For those interested, here you will find our WIP revised version (12 pages) : https://tschumperle.users.greyc.fr/tmp/revised_draft.pdf
- Compared to the HAL report, it contains more details about the use of different colorspaces and error metrics for compression/decompression, a comparison with RBFs for reconstruction, and an additional section about what @snibgo mentionned (haldclut creation from a pair of images).
- At this point, I don’t really know what we could add
There is already a filter in G’MIC that does a similar thing : Colors / CLUT from After - Before Layers .
I really don’t think we want such big domains. Even 256^3 is never considered in practice. It’s already way too large to store color transformations (that are smooth most of the time). Right now, I’ve never seen a CLUT file defined for 256^3. I don’t imagine considering 65536^3 then (and theoretically, this would require 786432 GB of memory for the storage ).
Beware, I’m not saying that the value precision of the CLUT transformed colors must be 8 bits or less, I’m just talking about the precision of the input colors (as we are using interpolation, and the CLUTs are smooth, it’s OK to stay with quite low ‘spatial’ resolution as 33,64,…).
I have read (more like skimmed) the revised paper. I don’t have the time to give proper feedback but I must say that it is richer than before and therefore looking much better. Would probably be ready after one more revision.
We are talking two different things here: domains and sampling frequency. If images have 16 bits/channel/pixel, then our cluts should have that precision for RGB indexes into the clut and also the colour values within the clut. Hence domains [0,65535]^3. If we don’t have that precision, we are discarding data or rounding results. This may not matter if we are making a final image but probably will matter for intermediate results. Rule of thumb: don’t discard data until you know you will never need it.
Larger domains may be needed if we are using cluts to manipulate displacement maps. (We are more sensitive to change of location than to change of colour.)
So we need domains of [0,65535]^3 or more. The fully-populated clut would have 65536^3 entries. With current computers, making such cluts is not reasonable. But sampling at 256^3 is reasonable (16 million entries). Even 1024^3 is reasonable. For future-proofing, we don’t want to restrict sampling to 256^3.
How much error would a domain restriction of [0,255]^3 restriction give? Less than one part in 256, obviously. For final images this would not be visible. But for some purposes, this does matter.
I’m not saying that David’s paper imposes a [0,255]^3 restriction. As far as I can see, it should work with any size of domain. But it makes that assumption, and there is no statement that larger domains can be used.
(Am I being picky? Possibly. But it took Gimp a long time to break free of the 8-bit restrictions. I don’t want current work to accidentally fall into the same trap.)
Actually, I don’t talk about “sampling frequency”. When I talk about a 8bits/channel CLUT with a resolution lower than 256^3, e.g. 64^3, then I consider that the CLUT has been downscaled with 3D averaging boxes. It’s not like I sample the CLUT at each 4th voxel. I consider the CLUT data have been averaged to produce a single voxel for each 4x4x4 voxels in the corresponding 256^3 CLUT.
That is a bit different.
In particular, because if the CLUT function is sufficiently smooth, this way of downscaling won’t destroy much details in the CLUT color variations. And CLUTs are usually very smooth color functions. In this context (and only in this context), it is acceptable to stick with low CLUT resolutions (32^3, 64^3,..) without losing important color information.
For CLUTS, I really don’t see the interest of considering a 65536^3 definition domain. 256^3 is already overkill (I’m saying it again, because the CLUT functions are really smooth, of course it would be different for 3D functions with a lot of discontinuities inside). This doesn’t prevent having CLUTs working for 16bits/channels images.
Also, of course we use linear/bicubic interpolation to get the transformed color for any [R,G,B] color input (with float-valued precision). If your CLUT is 128^3, it means that for a 8 bits-depth/channel image, you’ll read the CLUT values at locations (x + dx,y + dy, z+dz), where dx,dy,dz can be either 0 or 0.5. For a 16 bits-depth/channel image, we’ll just have more different possible fractional parts for (dx,dy,dz), but that doesn’t add extra complexity in the code, once you have a 3D value interpolator working at a floating-point precision.
In that case, I guess the type of function is really different : a displacement map may contain strong discontinuities.
Note that our proposed method doesn’t limit in theory the CLUT “spatial” resolution. We chose [0,255] for the sake of clarity, but the multi-scale reconstruction algorithm can work with any resolution. What I can say is that the reconstruction of a 256^3 CLUT probably takes a few minutes, considering the high number of voxel values to reconstruct.
Thanks for the clarificaton.
I suspected this was the case, but the paper doesn’t say this. I think it should.
One point I missed from reading the paper is that the key points are located on the CLUT sample locations - and you move the key points to the nearest CLUT sample when performing the multi-resolution algorithm. I couldn’t understand how m(x) could work since it would probably be 1 everywhere. The C++ sample code you posted earlier makes this clear.