[ECI-EN] Offine-Re: eciRGB_v2 space color for digitization of ancient manuscripts

Am 20.03.2020 um 17:59 schrieb Hanno Hoffstadt &lt;hanno.hoffstadt(a)gmgcolor.com&gt;om>:  Dear Giacomo, we do not have a technical document on eciRGB_v2 on the ECI website (as far as I know). However, the profile itself is provided for free, and in conjunction with the ICC profile specification, it is possible to uniquely identify the desired transformation. I will just do that for you, and I hope that is enough of a reference. (It might be a good idea that we also upload this to the ECI website.) The matrix M in XYZ = M * RGB consists of the primary colors encoded as 32-bit (s15.fixed16) XYZ numbers stored in the rXYZ, gXYZ, bXYZ tags. These are: rXYZ: 0000.A678, 0000.51FE, 0000.0000 gXYZ: 0000.2D94, 0000.9A20, 0000.115D bXYZ: 0000.22C9, 0000.13E2, 0000.C1D0 or converted to decimal floating-point: 0.A678 = 42616 / 65536 = 0.65026855... 0.51FE = 20990 / 65536 = 0.32028198... 0.0000 = 0 0.2D94 = 11668 / 65536 = 0.17803955... 0.9A20 = 39456 / 65536 = 0.60205078... 0.115D = 4445 / 65536 = 0.06782531... 0.22C9 = 8905 / 65536 = 0.13587951... 0.13E2 = 5090 / 65536 = 0.07766723... 0.C1D0 = 49616 / 65536 = 0.75708007... So I would recommend to write the calculation from linear RGB to XYZ, both in range [0,1] as [ X ] 1 [ 42616 11668 8905 ] [ Rlin ] [ Y ] = ------ * [ 20990 39456 5090 ] * [ Glin ] [ Z ] 65536 [ 0 4445 49616 ] [ Blin ] This is completely exact (if I made no typos), and it is also identical for version 1, 2, and the ICC v4 version of v2. By the way, yes, eciRGB is larger in red than AdobeRGB. That was necessary in order to include the yellow ink from offset printing. Also, the white point of eciRGB is D50 (in the ICC version), which can be seen by setting RGBlin = (1 1 1), or summing the rows: XYZ = 1/65536 * (63189, 65536, 54061) = (0.9642, 1.0, 0.8249) The white point of AdobeRGB is D65. The second part of the calculation is the tone reproduction curve which maps linear RGB to the final RGB in the document. This was a simple gamma 1.8 for version 1, but we thought that using an L* curve would make the gray axis visually equidistant and thus could provide slight advantages from 8-bit encoding. For the ICC v4 version of v2 we could use so-called "parametric curves" and simply put in the parameters of the L* formula to get a calculated L* curve. For the ICC v2 version (eciRGB_v2), we had to use a tabulated L* curve. A table is linearly interpolated in CMMs, which causes minimal rounding errors compared to a true L*. I tried to minimize them by choosing the optimal number of curve points, which turned out to be 700 - in case someone wonders about this seemingly arbitrary resolution of the rTRC, gTRC, bTRC tags :-) For the sake of our specification, we use the intended algebraic L* formula: The L*-related formula for R in the range of [0,1], and same for G, B, is: if ( Rlin < (24 / 116)^3 ): R = Rlin * 116 * 841 / 108 else R = (116 * Rlin^(1/3) - 16) / 100 Again, this is written to be exact, using only integer constants. Multiply the resulting RGB with 255 for the usual RGB scaling, and you are done. Best regards Hanno Hoffstadt _______________________________________________ ECI-EN mailing list ECI-EN(a)lists.callassoftware.com http://lists.callassoftware.com/mailman/listinfo/eci-en