given systems where textual information & facsimile, from viewpoint of easy reference, are the desiderata, the rationale for ECIRGBv2 seem very sound to me. if i understand the term «master» correctly, i think both sets of guidelines too weak for aesthetically critical work: i should always scan at much higher resolution & convert to lab, repurposing for whatever requirements the future may present—i believe this the best investment. but, [real] scholars will always need to handle the originals, anyway. ancient pigments can contain many out-of-gamut components. while Adobe1998 has deeper red space, have you compared input profiles of equipment under consideration to both? you may be contemplating reds that your scanner won’t see, anyway. extremely interesting work—i should love to have the opportunity to pore over those manuscripts. best, edward

Dear Edward, thanks for your reply, sorry for my English I wanted to say that Adobe 1998 is widely adopted but not suitable for rendering a lot of red nuances. I am trying to do some math for testing before replying to the excellent answer of Hanno. Thanks a lot for your time! Best regards, Giacomo ________________________________ From: eci-en-bounces(a)lists.callassoftware.com &lt;eci-en-bounces(a)lists.callassoftware.com&gt; on behalf of edward taffel &lt;etaffel(a)me.com&gt; Sent: Friday, March 20, 2020 7:17 PM To: eci-en(a)lists.callassoftware.com &lt;eci-en(a)lists.callassoftware.com&gt; Subject: Re: [ECI-EN] eciRGB_v2 space color for digitization of ancient manuscripts dear giacomo, regarding my statement: while Adobe1998 has deeper red space, i assumed from your statement Adobe1998 would be quite a good choice because of its larger adoption, but in the case of manuscripts that have many red inks a larger gamut in the red I think could be beneficial. that you deemed eciRGB the more limited in red. dr hoffdtadt’s intimation prompted me to make a quick visual comparison—apologies, i should have done this before commenting: eciRGB is certainly the deeper/better space for red. sorry for any confusion, edward On Mar 20, 2020, at 12:50 PM, Hanno Hoffstadt <Hanno.Hoffstadt@gmgcolor.com<mailto:Hanno.Hoffstadt@gmgcolor.com>> wrote: 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 Am 17.03.2020 um 18:01 schrieb Giacomo Marchioro <giacomo.marchioro@univr.it<mailto:giacomo.marchioro@univr.it>>: Hello, I am a technologist at the University of Verona, I am implementing a workflow for digitizing the rare book collection of the Capitolare library in Verona. I am deciding which color space to use for the master files of the digitized manuscripts. I am trying to decide between Adobe 1998 and eciRGB_v2. I would like to use eciRGB_v2 but I can't find the specification of eciRGB_v2 on ECI website, in particular how to convert RGB to normalized XYZ values, while the specification of Adobe 1998 is available online and seems more documented regarding these aspects. I would like to ask you if eciRGB_v2 specifications are available for free? And if there are any documents or guideline for the adoption of the eciRGB_v2 in artwork digitalization projects? Thanks a lot! Best regards, Giacomo Marchioro _______________________________________________ ECI-EN mailing list ECI-EN@lists.callassoftware.com<mailto:ECI-EN@lists.callassoftware.com> http://lists.callassoftware.com/mailman/listinfo/eci-en _______________________________________________ ECI-EN mailing list ECI-EN@lists.callassoftware.com<mailto:ECI-EN@lists.callassoftware.com> http://lists.callassoftware.com/mailman/listinfo/eci-en

Dear Hanno, thanks for your detailed answer that was exactly what I was looking for. I've tried to use the ICC profile specification but I wasn't able to parse it very easily so it's very handy to have this technical information to have an insight on how it works and see if it can fit the application. I apologise if I respond only now but I am not a colour scientist and I did not find the time to dive into your answer until now. At the moment, I don't have an OECF so I've tried to get the linearized RGB values using the inverse of your equations: if ( Rlin < (24 / 116)^3 ): R = Rlin * 116 * 841 / 108 else R = (116 * Rlin^(1/3) - 16) / 100 That would results in : if image < 0.08: linearizedimage = image*108/116.*841 if image >= 0.08 linearizedimage = (image*100+16)/116.)**3 However, the results are not right. Is it possible that instead of R = Rlin * 116 * 841 / 108 you meant R = Rlin * 116 * 841 /108 /100 ? Thank you very much! Best regards, Giacomo ________________________________ From: eci-en-bounces(a)lists.callassoftware.com &lt;eci-en-bounces(a)lists.callassoftware.com&gt; on behalf of Hanno Hoffstadt &lt;Hanno.Hoffstadt(a)gmgcolor.com&gt; Sent: Friday, March 20, 2020 5:50 PM To: eci-en(a)lists.callassoftware.com &lt;eci-en(a)lists.callassoftware.com&gt; Subject: Re: [ECI-EN] eciRGB_v2 space color for digitization of ancient manuscripts 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 Am 17.03.2020 um 18:01 schrieb Giacomo Marchioro <giacomo.marchioro@univr.it<mailto:giacomo.marchioro@univr.it>>: Hello, I am a technologist at the University of Verona, I am implementing a workflow for digitizing the rare book collection of the Capitolare library in Verona. I am deciding which color space to use for the master files of the digitized manuscripts. I am trying to decide between Adobe 1998 and eciRGB_v2. I would like to use eciRGB_v2 but I can't find the specification of eciRGB_v2 on ECI website, in particular how to convert RGB to normalized XYZ values, while the specification of Adobe 1998 is available online and seems more documented regarding these aspects. I would like to ask you if eciRGB_v2 specifications are available for free? And if there are any documents or guideline for the adoption of the eciRGB_v2 in artwork digitalization projects? Thanks a lot! Best regards, Giacomo Marchioro _______________________________________________ ECI-EN mailing list ECI-EN@lists.callassoftware.com<mailto:ECI-EN@lists.callassoftware.com> http://lists.callassoftware.com/mailman/listinfo/eci-en

Dear Hanno, I am really grateful for your kind support! You are very welcome to visit us, it will take a while before we will finish building the laboratory but speaking with colour experts like you all would be extremely beneficial for us. Hoping that soon we will have more freedom to travel, let me know if you come to Verona. Best regards, Giacomo ________________________________ From: eci-en-bounces(a)lists.callassoftware.com &lt;eci-en-bounces(a)lists.callassoftware.com&gt; on behalf of Hanno Hoffstadt &lt;Hanno.Hoffstadt(a)gmgcolor.com&gt; Sent: Monday, March 23, 2020 7:26 PM To: eci-en(a)lists.callassoftware.com &lt;eci-en(a)lists.callassoftware.com&gt; Subject: Re: [ECI-EN] eciRGB_v2 space color for digitization of ancient manuscripts Dear Giacomo, thanks so much for spotting this mistake, and sorry for that! Your version including / 100 is of course correct. I forgot to adjust the scaling of the L* function for RGB in the linear part (the equations for L* use a range of 0-100; not 0-1). At the transition from linear to cube root, both equations must yield the same value (8 / 100), which you already used in the inversion. For completeness (to avoid that other readers use the inverted version below which refers to my erroneous post), the linear part of the inverted function is linearizedimage = image * 100 * 108 / 116 / 841. I do hope to be able to visit your venerable library some time! Best regards, Hanno Am 23.03.2020 um 17:45 schrieb Giacomo Marchioro <giacomo.marchioro@univr.it<mailto:giacomo.marchioro@univr.it>>: Dear Hanno, thanks for your detailed answer that was exactly what I was looking for. I've tried to use the ICC profile specification but I wasn't able to parse it very easily so it's very handy to have this technical information to have an insight on how it works and see if it can fit the application. I apologise if I respond only now but I am not a colour scientist and I did not find the time to dive into your answer until now. At the moment, I don't have an OECF so I've tried to get the linearized RGB values using the inverse of your equations: if ( Rlin < (24 / 116)^3 ): R = Rlin * 116 * 841 / 108 else R = (116 * Rlin^(1/3) - 16) / 100 That would results in : if image < 0.08: linearizedimage = image*108/116.*841 if image >= 0.08 linearizedimage = (image*100+16)/116.)**3 However, the results are not right. Is it possible that instead of R = Rlin * 116 * 841 / 108 you meant R = Rlin * 116 * 841 /108 /100 ? Thank you very much! Best regards, Giacomo ________________________________ From: eci-en-bounces@lists.callassoftware.com<mailto:eci-en-bounces@lists.callassoftware.com> <eci-en-bounces@lists.callassoftware.com<mailto:eci-en-bounces@lists.callassoftware.com>> on behalf of Hanno Hoffstadt <Hanno.Hoffstadt@gmgcolor.com<mailto:Hanno.Hoffstadt@gmgcolor.com>> Sent: Friday, March 20, 2020 5:50 PM To: eci-en@lists.callassoftware.com<mailto:eci-en@lists.callassoftware.com> <eci-en@lists.callassoftware.com<mailto:eci-en@lists.callassoftware.com>> Subject: Re: [ECI-EN] eciRGB_v2 space color for digitization of ancient manuscripts 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 Am 17.03.2020 um 18:01 schrieb Giacomo Marchioro <giacomo.marchioro@univr.it<mailto:giacomo.marchioro@univr.it>>: Hello, I am a technologist at the University of Verona, I am implementing a workflow for digitizing the rare book collection of the Capitolare library in Verona. I am deciding which color space to use for the master files of the digitized manuscripts. I am trying to decide between Adobe 1998 and eciRGB_v2. I would like to use eciRGB_v2 but I can't find the specification of eciRGB_v2 on ECI website, in particular how to convert RGB to normalized XYZ values, while the specification of Adobe 1998 is available online and seems more documented regarding these aspects. I would like to ask you if eciRGB_v2 specifications are available for free? And if there are any documents or guideline for the adoption of the eciRGB_v2 in artwork digitalization projects? Thanks a lot! Best regards, Giacomo Marchioro _______________________________________________ ECI-EN mailing list ECI-EN@lists.callassoftware.com<mailto:ECI-EN@lists.callassoftware.com> http://lists.callassoftware.com/mailman/listinfo/eci-en _______________________________________________ ECI-EN mailing list ECI-EN@lists.callassoftware.com<mailto:ECI-EN@lists.callassoftware.com> http://lists.callassoftware.com/mailman/listinfo/eci-en