Fred Kuo :: Blog

談一下 G7 +

Printing United Alliance 在今年年初推出 G7+，顯然就是 G7 的後繼規格，開宗明義大標題就說明了這兩個規格在概念上的不同：Reference dataset (RPC) vs. algebraic concept

Fig. 開宗明義大標題就說明了這兩個規格在概念上的不同：Reference dataset (RPC) vs. algebraic concept

G7+ 版調目標值是基於某一個參照數據集Reference dataset (RPC)，如 CRPC6 就是一個 reference dataset，相對於先前的目標值是從代數概念而來。這個代數指是TR015的版調曲線公式。

Fig. TR015 版調公式。

G7 +的版調值是來自 Reference dataset ，下面圖例是CRPC6的版調值(Tonality)，以 CIEXYZ_Y來標示版調值。但要做為印刷目標值之前，必須經由印刷品的紙白及cmy300的CIE_Y來做修正。

Fig. CRPC6參照數據集的版調定義。

Fig. 要做為印刷的目標版調之前，參照數據集的版調必須經由印刷品的紙白及cmy300的CIE_Y來做修正，也就是上面的 scaled_RPC(Reference Printing Condition)。

神奇的是，就CRPC6 這個數據集，從TR015 與scaled_RPC算出來的結果幾乎是一致的。

Fig. CRPC6 這個數據集，從TR015 與scaled_RPC算出來的結果幾乎是一致的。灰色是 TR015 版調，粉色是 CRPC6 scaled_RPC 版調，幾乎是重疊的。

灰平衡的定義倒是有明顯的不同，撇開公式， G7+ 的灰平衡受紙張的影響更大。在舊的G7定義中，cmy300 處的 a*b*值直接歸零，在G7+ cmy300的a*b*值仍受到紙張影響，還會透出少許的色相。

Fig. TR015 灰平衡 a* b*定義。

Fig.  G7+ 的灰平衡定義，a*,b*值須由 CIEXYZ 換算而來。

Fig. 以紙張 a*b* 值在 2.7,-6.6為例，在舊的G7定義，cmy300 處的 a*b*值直接歸零，在G7+ cmy300的a*b*值仍受到紙張影響，還會透出少許的色相。

除了版調與灰平衡定義不同，G7+提出一個新的元素：High Density Smoothing(HDS)，他主要帶來的影響就是要避免高濃度漸層斷階，讓高濃度部分層次更順暢。這個元素也帶來新的檢測項目：ΔTVI。

Fig.  DonHutchson 示範HDS在噴墨印表機高濃度階調的影響。比較一下右邊兩張圖，最右邊一張經由G7+校正，天空漸層的分佈相對平順。

相對來說，HDS主要給噴墨印表機這類比印刷機色域高出很多的設備，讓它在高飽和度的地方一樣有順暢的表現。相對於平版印刷機超過75%的部分在層次的表現已經有限，噴墨印表機這類高色域設備在超過75%還有很多表現空間，HDS的確保這個部分能有順暢的表現。

或者這麼說，當參照數據集色域越大，越能顯示HDS其效用。

在 G7+ 的驗證項目中，如前述，除了之前的 wΔL*_k、wΔL*_cmy and wΔCh外，因 HDS 又多了一個項目叫做ΔTVI。這個 ΔTVI 只發生在 CMY channel的 80%、85%、90%、95% 。也因為ΔTVI項目，wΔL*_cmy and wΔCh只需測到2%-75%。

Fig. MaxΔTVI 與 Average ΔTVI 算法。

同樣的，為因應HDS， G7+ 也推出新的P2P導具：P2P75+ target。主要變化是取消RGB 95%色塊，再加入 CMY 75%及85%色塊。舊的導具一樣可以做G7 +，舊導具缺的 cmy 75%及85%部分，可以用內差補點算出來，帶出來的數據不至於有太大的差異。

Fig. G7+ 也推出新的P2P導具：P2P75+ target。主要變化是取消RGB 95%色塊，再加入 CMY 75%及85%色塊。

既然公式都有了，我的工具自然也要能跟上。就我的工作場合，先寫了CRPC6參照組。

目前我把 G7、G7+兩個規格都放上來，先觀察一陣子再來決定要不要將這兩個功能分開。

Fig. ΔL*與 Δa*Δb*圖示，上半部為G7規格，下半部為G7+規格。

Fig. Avgw∆L*、Maxw∆L*、Avgw∆Ch、Maxw∆Ch、Avg∆TVI、Max∆TVI各項規格數據。上半部爲G7規範，下半部為G7+規範，可以看出數據有點不同，但差異不會太大。

Fig. 同樣的，灰色修正邏輯也是兩套，上爲G7，下為G7+，是有一點點差別。

Fig. 為了處理RPC、SPC、scaled_RPC、HDS…及各種圖示需求的先導數據。

Fig. 為了處理∆TVI的先導數具。

Fig. 各種樣本測試，三點(25%、50%、75%)灰色預測邏輯還是管用的。

以上，把理論搞清楚，工具也做出來了，工具流程介面與數據呈現方式要再整理一下。

開發色彩管理工具，兩個主要的概念，一個是取得光譜資料，另一個是這個資料是要來做什麼用的？

在取得光譜資料這方面上，兩個困難點： 一個是要能取得該儀器的sdk，另一個是要有足夠的程式語言能力去驅動這個sdk。

在取得sdk方面，有些很容易，有些很困難；有一些要付費，大部分是不付費的。有的要簽一大堆文件，還要提報告來。也有直接發個GitHub給你的。

在驅動程式語言方面，最多的是C#，然後是C++，MacOS 裏則有 Objectiv-C 及 Swift。我目前主要要驅動的儀器是i1，在xrite提供的sdk裡面，C#與C++都有提供範例，其中C++提供的範例很完整，如單點測量、掃描測量、色光測量等都有提到，C# sdk裏只有一個單點反射測量，於是，我的sdk之路自然是從C++開始。

Fig. X-rite i1Pro3 SDK in C++

Fig.-1  X-rite i1Pro3 SDK in C #

Fig.-2 X-rite i1Pro SDK in Objective C w/ Cocoa framework

C++最大的問題是沒有使用介面(user interface)，反正就是編譯出指令(executable)讓你能達成工作目的就是了，所以我的工具功能性沒問題，UI這件事情做不了太多。

Fig.-3 i1 SDK executable From C++

相對於C++，C#能有更好的介面能力，只是直到最近才對C#有一點掌握，尤其是Pro2雙向測量的邏輯花了很多時間才搞懂，在更了解C#後，現有的工具會一個個改寫到C#上面。

談到要寫介面，那又是另外一番功夫了。

開發工具的第二概念是，取得光譜數據後要怎麼用？

做色彩管理，取得Lab數值是最基本的，可以比色差、可以做icc Profile。但對印刷作業的系統管理，只有Lab是不夠的，在整個的印刷的作業中，我們還需要知道印刷濃度(Density)、印版版調(Tone Value)、印機版調、軟打樣校正時的白點(White point)、亮度、Gamma…；藉由一些數學工具，可以去預測濃度落點、去預測灰平衡落點、去預測修圖曲線…，藉由各式各樣的色彩取樣邏輯，去快速的做印機調整、數位樣調整、軟打樣調整或者是圖像調整…。這些我們需要的資訊都要由最基本的光譜值衍生出來。

Fig.-4 Beer’s Law SID prediction

Fig.-5 TVI curve

Fig.-6 Gray balance prediction

談了那麼多，回到這一次的主題：光源管理。

在印刷作業當中，不僅僅要管理印刷的色度、濃度、版調、數位樣精度、軟打樣精度…，觀測光源也是一個必須被管理的項目。

簡單講，對於印刷機控墨台的光源，我需要知道光源的三個數值：色溫(CCT)、亮度(Lux)與演色指數(CRI)來確保控墨台有一個良好的觀測環境。工作原則是：當亮度低於1500 Lux 則預備更換燈管，當演色指數CRI低於90時則預備更換燈管，CCT 我倒是沒那麼介意，不要差5000度太多就好，我會更重視CRI及Lux。

最早，這件事情是由i1Share這個軟體來取得這些數據。

Fig.-7 i1Share 管理光源三要項：CRI,CCT及照度。

基於兩個理由我必須發展自己的工具，一個是i1 Share 在數據管理上不是那麼方便，在使用上就是測量光源，然後把數據抄下來。我希望的工作方式是：測量後形成報告，資料直接進資料庫，方便以後做比對管理。第二個原因是i1Share不再支援Pro3，這個才是最主要的原因。

其實之前就想寫這個工具， CCT、照度(Lux)都沒問題，但是CRI一直有困難，有陸續去了解TM-30、CQS、TLCI 等光源評估指數，這些指數有一個共同點就是都會去參考某個數量的樣品顏色來綜合評估光源的演色能力。比如說CRI 的樣品色是8個、 R96a在CRI 後面再加6個、TM-30 的樣品數是99個、CQS樣品數是15個、TLCI 的樣品數是24個；我就在想，印刷產業已經明定D50為標準光源，我只要評估光源的光譜值與D50的相似度不就是演色指數的意義嗎？概念上跟執行上應該會比CRI簡單明瞭。

Fig.-8 CRI 測試光源(Test)與參考光源(reference)以其8個樣本色(TCS01-TCS08)的差異來對測試光源做評估，R96a在CRI 後面再加6個樣本(TCS09-TCS14)。

Fig.-9 TM-30 比對99個樣本色。

Fig.-10 CQS 比對15個樣本色。

Fig.-11 TLCI 樣本數為24個。

在尋找資訊過程中，美國電影藝術與科學學院(The Academy of Motion Picture Arts and Sciences)發表過光譜相似性指數(Spectral Similarity Index, SSI)，更重要的是，程式碼是開源的(in R language)；既然計算CRI遇到困難，以SSI 來取代CRI 會是一個好的方案。

於是，我的工具組多了一件工具：光源管理。如前述，這個工具會取得光源的三個數值：色溫CCT 、  照度Lux與SSI指數。

Fig.-12 SSI 直接比對測試光源(Test)與參考光源(Reference)的光譜值差異來評估光源的品質。

Fig.-13 SSI 開源程式碼 in R language。

SSI 照說是專為電影工業的攝影機而生，為因應CRI 已無法正確反應LED光源下攝影機的感色能力而研發出來的新型指數。然，這個指數一樣可以應用在電視攝影、靜態攝影及人類視覺上。

Fig.-14  此案例為一CRI 92光源下，三部攝影機的感色狀態，可以看出在某些色樣有明顯差異。

Fig.-15 最上方為參考光源(reference 3200K)下的攝影機感色狀態，下方三格分別是SSI 76 A光源、SSI 76 B 光源及SSI 88 光源下的感色狀態。可以看出SSI 88 光源下的感色狀態幾乎與參考光源相同。

SSI 單一指數數字越高表示光源品質越好，數字範圍為1-100 。標示形式為以中括號標示參考光源後再標示指數，如：“SSI[D55]: 87”。

在電影藝術與科學學院的文件中表示，SSI 90 為 “very good match”，80到90爲 “pretty good match”，60以下則 ”probably have color rendering issues” 。

Fig.-16  電影藝術與科學學院的文件，SSI 80 以上就是 Pretty good match。

公司之前的控墨台燈光規範是CRI必須達到90， 看來在SSI是可以訂在80。

把舊的 i1Share CRI 資料與SSI比對，以下三組資料分別為：CRI=91 vs. SSI=81，CRI=71 vs. SSI=72，CRI=93 vs. SSI=84。

可以非常的確認控墨台光源需求是SSI 80以上。

Fig.-17  i1Share CRI 資料與SSI比對，三組資料分別為：CRI=91 vs. SSI=81，CRI=71 vs. SSI=72，CRI=93 vs. SSI=84。

這次SSI先開發兩個版本，Win10 版及MacOS版，Win10 版是由C#開發，Mac版則是Obective-C with Cocoa framework。目前可支援Pro1/Pro2/Pro3。

Fig.-18 Win10 C# 版，工作程序：1.選取/連結設備、2.校正、3.測量。

Fig.-19 MacOS Cocoa 版本，開啟後自動連結儀器，操作時點<Calibrate>後即可<Measure>。

以下為幾個光源採樣，參考光源為D50。

Fig.-20 Just 燈箱，SSI[D50]=86, Lux=1754，藍色線為D50光譜分佈曲線，綠色線為測試光源光譜曲線。

Fig.-21 辦公室 LED 燈，SSI[D50]=69,Lux=320。

Fig.-22 大溪廠房中午12點，窗戶旁光源指數：SSI[D50]=85,Lux=3309。藍色線為D50光譜分佈曲線，綠色線為測試光源光譜曲線。450nm峰值(peak)應該是受到室內LED光源影響。

Fig.-23 大溪廠房上午10點半，窗戶旁光源指數：SSI[D50]=90，450nm處峰值(peak)受到室內LED光源影響。

由 Fig-22 與Fig-23案例，也大概可以有個概念：10點多左右的陽光比較接近5000K，到了12點可能就跑到6500K了。

之所以要形成自己的工具，主要是方便以後做數字管理，至於要用CRI或是SSI並不是問題，只要能維持固定的模式就能做有效的管理。目前對我來說，SSI 在概念上與運作上我都能足夠的掌握。

至此，我在光源管理上明確的規則是：照度 (Lux)維持在1500以上、演色指數(SSI)維持在80以上、色溫(CCT)比較沒那麼在意，5000度上下300都還能接受。

Fig.-24 光源資料直接進資料庫，方便以後做比對管理。

以上，要有數字才有管理。印刷作業，在標準化的基礎規範上，就是一連串的數據；不管是色度、濃度、版調、灰平衡…一直到這一次光源上的Lux、CCT與SSI，通通來自光譜資料。只要有一部光譜儀，就可以實現印刷作業上絕大部分的管理。

CIE Lab 時鐘

工作頁面：http://fredkuo.idv.tw/cieclock/

Fig. CIE Lab 時鐘，第8秒處，色角度42度，Lab 值55,74,67，換算sRGB 為255,38,0，換算AdobeRGB 為222,38,0，換算P3RGB為254,75,27。

色彩管理是一個講得清楚的東西，但有些地方真的很繁雜，就上面這個例子，一個色彩值Lab 55,74,67的顏色在你的顯示器該怎麼顯示？

我要知道面板的能力，是sRGB、AdobeRGB或是P3RGB？或者螢幕有沒有校正過？是否自帶icc Profile？這個icc 有自帶 Calibration嗎？系統或應用軟體有沒有做適當的設定？…很多因素會影響到顯示幕的顯示行為。是可以一一的講清楚，但真的很繁雜。

這個頁面比較是一個樣本演示，而不是某一種工作工具。以時鐘60秒走一圈的概念，取得60個色角度的Lab值，換算成RGB值之後以RGB值推動顯示器來顯示該色彩。這個過程中調用了三種LUT(Look up table)，分別是Lab到 sRGB、AdobeRGB 及P3RGB 的轉換表，也就是同一個Lab會被解釋成三種RGB的組合。如果你的顯示面板是P3面板，那麼P3 LUT 的RGB 數值會在你的面板顯示出正確的顏色，同理類推，如果是sRGB面板，那 sRGB LUT 的數值才會顯示正確的顏色。

這個頁面有多重的觀察行為：最主要的是，以一個週期60秒鐘呈現60個Lab樣本，依順時針色環顯示色彩的變化，讓對Lab色空間不熟悉的讀者可以體會一下ab色環的情境。

每一次色樣本變化，會顯示該樣本Lab值、該樣本的色角度、與其前一樣本的de00色差及3種LUT轉出來的RGB值。另一個錶面則呈現同一個色角度但 飽和度只有¼ 的色樣，同樣也有3個LUT的呈現。

Fig. 每一次色樣本變化，會顯示該樣本Lab值、該樣本的色角度、與其前一樣本的de00色差及3種LUT轉出來的RGB值。另一個錶面則呈現同一個色角度但飽和度只有¼ 的色樣，同樣也有3個LUT的呈現。

錶面的呈現呈三個色環，從外往內，分別是sRGB、AdobeRGB 與P3RGB 的RGB推動值，可以從這裡觀察出在那些色角度這三個色空間的差異。

Fig.  於L=67 三個色空間的ab圖，白色為P3，綠色為Adobe RGB，黃色為sRGB。可以看出Adobe RGB在綠色的色域最大，P3在橘色較大，藍色部分三個色空間都差不多。

Fig. 觀察8秒處，色角度42，三個色空間的色彩值有明顯差異。

Fig. 觀察51秒處，色角度144，三個色空間的色彩率有明顯差異。

Fig. 觀29秒處，色角度276，三個色空間的色彩幾乎無差異。

以上3個樣本觀察也呼應到3個 icc Profile的色域觀察。

以上，單一CIE Lab 時鐘頁面具備多方面的色彩管理概，花個一兩分鐘時間，經由不同樣本多重屬性的觀察，或許可以多體認到些什麼東西吧！

Android 特別色工具

之前寫了特別色上限下限的報告工具(參考 http://fredkuo.idv.tw/wordpress/?p=3681

)，工具的結構是由C#從藍牙光譜儀取得數據，由autoit 將數據丟到Server再由php解析數據形成報告並寫入資料庫。

這個工具用起來沒有問題，但既然已經有這個儀器在Android 上的 SDK，想說用手機來工作自然比在筆電工作要方便許多。

於是，寫了這個Android工具。Android 工具結構是由 java 調用SDK，以 JSON 方式將光譜數據POST到server；取用資料時是用 java 在背後執行Server 上 PHP 網頁，取得MySQL 資料後再由手機端 java 程式GET JSON 資料交由後續處理。

Fig. 工具主頁面分上傳、下載及儀器設定。

Fig. 特別色上下限測量及上傳頁面。

在這個介面填入公司碼、工號，測量上限、標準及下限樣本，按上傳後上述資訊會上傳Server形成報告，資料也會進資料庫供後續作業使用。

Fig. 資料上傳後於 php 網頁取得特別色上下限報告。

Fig. 下載標準頁面，填入公司碼及工號後按[下載標準]即可從server下載上下限色彩資料；然後量測運行中的樣本，若量測色彩值在上下限之內(依L值及Chrome 值判定)，則呈現綠色標示。

Fig. 若量測色彩值超出上下限則以紅色標示，另依L值及Chrome 值做出加減墨的指令；以上例，樣本的Chrome 值低於下限，因此呈現 + 號，表示要再加墨。

Fig. 若量測色彩值超出上下限則以紅色標示，另依L值及Chrome 值做出加減墨的指令；以上例，樣本的L值低於上限，因此呈現 – 號，表示要減墨。

由實體樣取得上下限的方式是一個很實際的做法，雖然CR30的絕對精度沒那麼好，以這種實體取樣、相對比對的工作邏輯是可以不用那麼在意絕對精度，這種做法在實際應用上沒有任何問題。

另一種特別色驗收方法是自訂色差，一般來講我都會說是三個色差，但飽和度加+ 3或是飽和度-3都是三個色差，整個批次差就可能到6，所以三個色差的說法其實並不合適，因為不夠精確。更好的說法會是與標準值不超過三， 批次差也不超過三，會是更清楚的規範。相較下來，上下限的做法會是最實際、最清楚的做法。

我還是把單一色差比對的工具做出來，內定值還是三，不過這個值是開放欄位，隨時都可以變更這個數字來做驗收規範。

Fig. 自定色差工具。同樣的，填入公司碼與工號，測量標準樣後上傳Server即可記錄標準樣數據。

Fig. PHP網頁呈現標準樣數據。

Fig. 填入公司碼與工號，自Server下載標準樣數據後對現行樣本測量，色差在3以內則呈綠色標示。

Fig. 可以隨時改變容差值，以上圖例，將容差改為2，當測量值超過兩個色差時即呈現紅色標示。

自定色差的操作給予生產者與驗收者一個彈性的緩衝，一樣可以經由談判取得一個數字去做驗收，而不是視覺及心情的感受。

用手機來操作確實也比筆電或是桌機來得方便許多；體積小、移動性強，沒有太多設定，隨時都可以拿出來操作，更多的來落實By Number的工作概念。

這邊還是要說明一下，這邊主要的工作還是建構工作方法，並不限定哪一個量測儀器，或是哪一個平台。只要能取得該儀器在該平台的SDK，PC、Mac、Android 、iOS，都可以納入我的工具架構。

標準化 脫軌

我做了很多工具，重點是 By Number。印刷標準化是一個很實際的應用，有清楚的目標值，經由工作程序當中的數據收集，對應出工作指令來達成最終的目標值。

我手邊的工作單位基本上走兩種標準化規格，Fogra39 或是 CRPC6。

走標準化的概念是，從客戶端稿件製作到最後印刷輸出，都遵循某一個規格，如前述的Fogra39 or CRPC6。

問題是，客戶端都有這個概念嗎？

以亞洲版的Photoshop，內定CMYK 設定是 Japan Color Coated。如果客戶端沒有認知到他的生產單位是以Fogra39或是CRPC6..其他不同規格的方式去生產，而沒有去做適當的軟體設定，那麼他對最終輸出色彩的預期將會有所落差。

在這裡要談的是，即使客戶端及生產端都已經認知有一致的色彩目標，我的生產單位是基於什麼樣的原因，讓我們偏離了標準化的軌道。

先簡單敘述一下標準化的工作程序：以CRPC6為例，客戶的影像稿從RGB轉成CRPC6 CMYK，然後生產單位依CRPC6規範生產，包括主色(CMYK) Lab值、版調值Tone Value、灰差、亮度差等等規範。

理論上這樣的工作程序沒有問題，但工作一陣子下來，業務端反應，為什麼膚色的地方有些時候會比較黑、比較髒。

與分色部門了解一下，說之前的分色是RGB轉成Japan Color CMYK， 好像沒有聽到這樣的反應，走了CRPC6的程序後才有這種反應。

分色部門找了一張圖來做演示，同一個取樣點，在AdobeRGB空間中的色彩定義是Lab 61,7,68。用Japan Color 分出來的CMYK 是36%,45%,100%,0%。用CRPC6 分出來的CMYK 為 0%,25%,100%,32%。

同樣都是要實現Lab 61,7,68 這個顏色，但分色出來的組合截然不同。

Fig. 客戶測試稿件，取樣1位置在AdobeRGB空間中的色彩定義是Lab 61,7,68。

Fig. 取樣1用Japan Color 分出來的CMYK 是36%,45%,100%,0%。

Fig. 取樣1用CRPC6 分出來的CMYK 為  0%,25%,100%,32%。

從這個條件去推演，Japan Color 在這個取樣點不會產生黑色，CRPC6則有K 32%。再來個劇本假設，如果黑色色座網點擴張太大，以Japan Color 分色那組在這個地方沒有任何影響，因為不含K成分，但CRPC6那組就會有明顯的影響，也就是業務口中的會變比較黑、比較髒的影響。

這個推論，應該就是問題所在了。簡單講就是Japan Color 與CRPC6分色邏輯不同所呈現的結果。

回到工作邏輯，如果印刷機是一個穩定的狀態，並不會造成問題，因為 CMYK 36,45,100,0 與0,25,100,32 都是呈現Lab 61,7,68這個色彩，所以沒有變黑變髒的問題。但如果機器不穩定，問題就出來了，CRPC6分色的問題是容易變黑變髒，Japan Color 的分色則是灰色平衡更不容易控制。這兩種分色沒有誰比較好的問題，只是問題的方式不一樣，終究的解決方案還是讓機器穩定。

對於這問題我還是提出了做法，也就是在CRPC6的基礎下重新組合黑色的分配，至於怎麼做倒是沒有一定的邏輯，簡單講就是在設定icc profile過程中關於總墨量及黑色形成的各種參數去trial and error 找出適合的設定。

Fig. 在設定icc profile過程中關於總墨量及黑色形成的各種參數去trial and error

同樣的取樣點，新 icc 分出來的CMYK組合是25%,39%,100%,5%。這個profile 已經放出去使用一個多月，還沒有收到不好的反應，看來這個單位會就這樣子一直用下去。

Fig. 取樣1用新 icc 分出來的CMYK組合是25%,39%,100%,5%。

如同上面提到的，終究的解決方法是讓機器穩定，但在平印機要讓機器穩定不是一件容易的事，這個方式只能是減緩問題，而不是根治問題，不過還是有其效益。

以上是一個印刷標準化脫離正常軌道的例子，再一個例子是一個走Fogra39的單位，因為乾燥背印的問題，我們也插入一段非官方的做法。

如上述，這次要解決的不是色彩的問題，而是印刷背印的問題。我們推論是乾燥的問題而導致背印的狀況。要處理乾燥問題，降低墨量是一種作法，於是我們先做出一個以Fogra39為基礎，但降低總墨量的profile。官方Fogra39的總墨量為330%，一連串的測試，我們把它降到280%，認為是一個視覺效果可以被接受的設定。

之後，就是做一個device link，將現行的CMYK link 到低墨量的profile 。

Fig. 同一個圖檔2號取樣點，分成CMYK後，總墨量為324%。

Fig. 同樣2號取樣點，Link 到新設定後，總墨量為261%。這樣的設定，省墨是一回事，重點是有效緩解背印的問題。

這個link已經放出去一年多了，實際上有減緩背印的問題，好像也沒有聽到不良的反應。這樣的做法其實會犧牲暗部細節的解釋，或許可以慶幸說，客戶對暗部細節的要求，還好而已。

這個案例也可以參考一下以下的連結。

http://fredkuo.idv.tw/wordpress/?p=3404

以上是兩個脫離標準化的案例，其實也不算是真的脫離標準化，只是犧牲一些細部的解釋來使得工作流程更為順暢，或是有更大的容錯；標準化作業流程的概念是沒有變的。

印刷標準化還是重要的基礎，而By Number則是應對所有狀況的基礎。

同一畫作於同一部機器上下模生產，已查覺有少許視覺差異。以CT25導具檢視，上下模在C座的中間調有2%以上的差距。對國畫這種低彩度的作品，2%的中間調差距已足夠引起客戶的關注。

這個印件我們處理了很久，敏銳的業務很早就反應了上下模的問題，這個問題已經不是印前去修改CTP曲線所能解決的。機台的控墨可以處理左右不平均問題，但無法處理上下不平均的問題。爭議了一段時間，印刷部門始終沒有做有效的回應。

該是數據說話的時候了，做一個測試樣，以CT25 檢視上下兩模的數據，這個視覺的差異很清楚的用數據表示出來，這只能是印刷部門去處理了。

Fig. 讓數據說話，上下兩模在C50有明顯差異，Y25也有少許差異，這差異已經有明顯的視覺感受，這個不是修圖或是修CTP曲線能夠處理的。

最後，在評估機器整理的成本、時間，以及印工、紙張…等條件考慮下，該印件我們以只取上模的方式交件。

CT23/25 是一個既精簡又全面的工具，可以知道滿版狀態、可以知道中間調狀態、也可以知道灰平衡狀態。一方面呈現現有狀態的資訊，一方面也提供提升品質的工作指令。

這個工具有能力協助達成G7 Targeted，更重要的它可以是一個日常的工具，隨時檢測問題，隨時了解問題，隨時改進問題。

這一次CT25的使用，清楚的揭露上下模不平均的問，促使公司做出該有的回應。

實際線上的現場作業充滿了變數，能越快的掌握數據才能越快的回應問題。

工具本身的意義是快速的揭露資訊，至於後續怎麼去處理問題、回應問題，那就是各種考量、各種意圖，沒有一定要怎麼做。但數據一定要先出來，才能有後面怎麼做的決定。

印刷色彩數據平台

色彩的呈現在現今已經可以是清楚的數據表現，從螢幕到數位樣到印刷這一路上都可以收集到色彩數據，如果這個產業能夠一直維持這些色彩數據的收集，那這個產業又會是什麼的面貌呢?

Fig. CT23 印刷數據取用導具。

想要去收集這一系列的色彩數據一直會有兩個方向的思維。

一個是色彩內容的製作者他希望後續的印表機輸出到印刷機輸出都能夠符合他在螢幕之前的想像。

一個是印刷品的生產者，當他在控制自己的生產品質時，他也希望能夠知道客戶端也是在符合標準規範的規格下去製作顏色，以減少對最終產品認知差距。

這個需要從生產端到製作端能夠確實的掌握數據才能達成最有效率的生產製程。

要收集螢幕、數樣到印刷樣數據在現今的軟體硬體都不是太大的問題，問題是很少看到有單位真的做好確實的執行。沒有被執行可能的因素有很多，第一個是認知不夠，不管是生產端還是製作端，如果沒有色彩即數據的認知，自然不會有後續的執行產生。再來是，即使有認知，如果執行的成本過高，不論是建置成本上的，或是知識上的，還是技術操作上的；在認知上覺得這些精力、成本的投入不足以呈現實質的價值時，自然也不會持續投入執行。

最後，也是我一直談的，當色彩生產品質發生問題時，這一整個從稿件製作到印刷成品，哪個環節出了問題，有沒有一個職務單位或是個人去負責問題的處理與糾錯？這就是我所謂的系統人員，他能夠清楚的掌握各個環節的數據狀態，就因為產業界裡中沒有一個清楚的職務，才以致於在出錯時，業務端、印刷端、印前端、或者是設計端之間互推責任，無法確切的解決問題。

試想，這些問題在足夠的數據揭露下，其實可以很快地標示出問題的出處，也可以很快地把問題修正。

這些都是確實的數據收集所能帶出來的優勢。

了解到產業從業人員對於數據收集的認知不足，或是執行門檻過高以致於數據執行無法落實，我一直在開發更精簡的數據收集工作方法，看能不能有更多的人能夠願意去執行數據的工作。

我的工具發展，從一開始就有數據收集與匯整的概念，希望透過快速的數據收集工具來了解產業中色彩問題進而很快的處理問題。

數據的收集主要有四大類，分別是螢幕、印版、數位樣及印刷機。

Fig.  印刷作業-系統人員數據工具組合。

簡單的概念是，印刷標準化已經定下了色彩的目標值(Fogra39/CRPC6/Fogra51… )，我們只要隨時監看及盡可能保持螢幕、數位樣及印刷機的色彩值能符合標準化的規範，整個生產程序就能降低過程中色彩現象的差異，進而讓生產程序保持順暢。

工具的使用當然是力求精簡，以最少的動作，取得代表性的最少樣本，就能大致評估設備整體的色彩表現能力。

印刷工具組

從印刷機這端開始談起，在印刷機端，工具組主要有兩個，一個是CT10- 掃描10(Color Target 10 patches)：一個strip reading就可以讀取紙張、CMYK滿版、CMYK 50 %及灰平衡共10個色塊，可以很快地知道滿版的色度好不好？中間調網點擴張正不正常？灰平衡是否正確？ 這是去了解印刷系統最精簡的工具。

印刷機端如果能夠持續收集這些數據，可以知道印機變化的狀況，並可以隨時彌補印刷機不穩定的因數。在觀察數據的變動狀況時，可以很快的制定修補的策略：看是要動機器？動版？或是動影像檔案？總之，有了數據的依據，修補策略很容易被定義出來，然後依此策略繼續維持輸出品質的穩定。

Fig. CT10 單一取樣數據表現。

Fig. CT10 數據後台，每一次量測後台都有數據記錄，可以隨時追蹤當時的印機狀態。

第二個印刷機工具是CT23-掃描23，CT23的組合除了CT10的10個色塊之外，再加入了RGB、CMYK25%、CMYK75%、灰25%及灰75%13個色塊，總共23個色塊。

多的這些色塊可以用來評估二次色RGB的落點、階調評估增加了25% 及 75%的評估、灰平衡也多了25% 及75%的評估，能看到更完整的系統狀況。在補償策略也更精細，經由三點灰平衡補償邏輯， CT23工具有能力達成G7 Targeted的規範。

Fig. CT23 單一取樣數據表現。

Fig.  CT23 單一取樣圖像表現。

Fig. CT23 50%網點擴張及三點式灰平衡修正邏輯圖形表現。

Fig. CT23 單一印件數據歷程。

Fig. CT23 單一印件歷程 trend chart 。

第三個工具是CT88(22×4)，CT10及CT23都是單層導具，很容易在日常印件中佈置在紙邊執行。CT88是一個4層的導具，公司通常在每月例行檢測時才執行這個導具，所謂的22×4就是：紙張丶2%、5%、10％～90%、95%、100%共22格，CMYK 4個頻道都放，所以是22×4總共88個色塊。

這88個色塊用來更精確的紀錄(揭露)5%的版調數據，並依此數據對版調做更精細的調整。長期工作下來的經驗，每月一次的CT88數據調整補償足以維持機器長期的穩定輸出。

Fig. CT88 印刷版調數據表現。

Fig. CT88 印刷版調圖形表現。

Fig. CT88 後台資訊。

數位樣工具組

再下一組的工具是數位樣的監看，不管是Fogra PSO或是 Idealliance G7都有數位樣張的規範，規範的內容大同小異，不外乎主色要少於多少色差？總平均必須小於多少？最大必須小於多少？數位樣的工具在很多套裝工具應該也都具備，我把他納進來主要是讓這些數據都能夠進到資料庫中，可以集合起來做長期的追蹤評估。

數位樣工具有三個，第一個工具一樣是CT23，同樣的，CT23的三點灰平衡修正邏輯可以很快把數位樣的灰平衡帶回來；與G7 的Control strip 2013 (84格)及Fogra media wedge CMYK(72格)的驗收規則相比，我會更注重灰平衡是否到位。

其他兩個工具就是CT72 (24×3 Fogra media wedge)與CT84(28×3 Control strip 2013)。工作邏輯一模一樣，就看是走Fogra 或是 G7 系統而已。

Fig. Fogra Media Wedge CMYK V3 proof report.

Fig. Idealliance Control Strip 2013  proof report.

印版

印版通常變數不大，我還是建立了長期的數據系統，印版考慮的變數會有溫度、沖版時間、藥水更換時間等等，通常變化不大。長期的觀察紀錄一樣有助於印版的穩定。把印版穩定下來，也是有助於印刷機眾多變數的排除。

Fig.  印版數據監控。

在正常的工作程序，工作邏輯，印刷廠該做的是把印刷輸出數值顧好，一切 by number，成品好不好看的主觀評估應該是在設計端就定下來了，印刷廠只是負責把交付的色彩數據依標準化規格實現出來而已。印刷端與設計端之間的依據應該在數位樣，一旦數位樣的數字是符合規範的，只要設計端認可的數位樣，系統健全的印刷廠按標準操作下來，通常不會有太大的問題。

螢幕

一般印刷廠通常不會去在意設計端的螢幕顯示能力是否足夠，但業界還是會出現這樣的現象：印刷廠端會去設計端校正他們的螢幕，用意就是盡可能降低設計師在螢幕前的色彩認知與印刷廠不要有太大的差距。所以，一個所謂的印刷廠系統人員，現在除了要掌握場內的印刷及數位樣數據外，他還必須擴及到設計端螢幕色彩的掌握。

於是，我繼續開發了螢幕端的數據工具，照說螢幕的工具在現今的商業軟體都有支援，我開發工具的主要目的還是要求精簡，用最少的操作程序來取得基礎的數據評估。

Fig. 螢幕工具組。

目前螢幕工具主要分兩個項目，第一個是EM6(Emission for 6 patches)，這個工具很快地從螢幕收集R、G、B、White、Gray、Black 6個數據，這6個數據可以很快地知道顯示器的色域能力、相對色溫(白點)及Gamma 值。順道也比對是否落入sRGB、AdobeRGB或是P3的規格中。讓系統的人員可以很快地知道這個顯示器的能力，進而確定該怎麼設定那個螢幕的使用目的。比如說要做軟打樣，AdobeRGB是一個必須達到的規格、其次P3，如果是sRGB，就只能做到70%的準確度。這些資訊系統人員都必須掌握到才好跟他的上游有良好的溝通。

Fig.  從螢幕讀取六個基本色塊，很快的了解螢幕基本能力。

Fig. 6個基本色塊可以取得螢幕色域(面積)、Gamma、相對色溫（CCT)、亮度(cdm2,燭光米平方)。不是很細的資訊，但是可以做很快的參照。

Fig. EM6 後台資訊，可以很快知道哪些螢幕具備什麼樣的能力。

第二個工具是EM16，這個工具用來檢測該螢幕的軟體打樣能力，16個色塊分別是CMYRGB滿版（100%）、CMYRGB 70%、紙白、灰50%及黑色

總共16個色塊。根據這16個數據可以很快知道該螢幕的軟打樣能力。

Fig. EM16，用精簡16個色塊來了解軟打樣能力。

Fig. EM16 後台資訊，依單一分數很快的掌握每個螢幕的軟打樣能力。

以上，從印刷機、數位樣、印版到螢幕，一個系統人員如果能掌握到以上數據，整個印刷系統的運作就大概都能掌握到，當有色彩問題糾紛時，這些數據攤出來，很快就能找出問題，並處理問題。

工具程式改寫。

我經常講的，印刷控制，就是把滿版做對、中間調(/灰平衡)做對，兩件事而已。這裡就是各式各樣的工具，幫你把這兩件事情做對。

能掌握這些工具，要做PSO或G7都不在話下。

之所以要改寫，主要是資料流(光譜值)帶動的方式跟之前不一樣。之前是由SDK 取得光譜資料後，以FTP的方式上傳到server再由Local 端啟動一URL 的php來解釋(計算)該上傳的資料，進而取得印機/印版狀況，也一併取得工作指令。

這次改寫的部分主要是資料流現在是由api的方式來帶動。

API的方式有很多面向的優點，第一個是，相對於FTP是比較安全的方法。

FTP需要建立帳號，在丟資料的時候，帳秘是必須跟著走的，帳秘還是有潛在被攔截的機會。另外FTP也需要開另一個port去溝通，在安全上就是又多一個風險。

api 的方式直接經由http來拋資料，不需要在server另外建立帳號，也就沒有賬號外流這類的風險。資料的傳遞直接用HTTP就可以達成了，沒有牽涉到其他的port；在功能的執行上，也減少了被防火牆或防毒軟體之類的干擾。

第二個是軟體發佈的方便性。

由於無需在server上建立賬號及處理賬祕，增加了軟體發佈的方便性。比如一旦務器掛掉要改由備援server去處理的話，衹要把目標服務器的URL改掉，馬上就可以轉過去。在軟體的維護及發佈上都會相對單純。

就安全性及方便性上，API方式當然優於FTP。

再來就是提供服務的方式可以更多元。

目前是FTP丟資料，PHP運算資料，以web broswer 來顯示處理後的資訊。api 是一個在網絡上拋接資料的方式，基本上就是 POST 與 GET 兩個概念。至於用什麼程式去拋接資料？什麼程式去計算資料？什麼程式去表現資料？並沒有受到限制，只要能找到http POST 跟 GET 語法就可以了。所以，不管是在客戶端或是Server端，程式語言的運用可以更多元。比如我有打算發展手機的介面，可以在不改變sever的架構下直接建構手機端post與get的工作介面就可以了。

Fig. Windows  autoit 客戶端 api POST語法。

Fig. Server端PHP api 接收語法

再遠一點的想法， 這裡就是一個印刷API的服務器 ，單純收取客戶端的光譜資料後，再反映回去功能性的資訊與工作指令。至於客戶端要用什麼樣的軟體來傳遞光譜值？或是要用什麼樣的儀器來取得光譜值？ API服務器並不做限制，只要把光譜值的格式規定好，服務器都能提供一樣的服務。或者也可以這麼說，衹要能取得儀器的SDK，這裡就能提供各種客制化的光譜值/色彩值的運用。

下面就再多帶一個例子。

這一次工具的發佈有多一個工具，就是右下角的EM6(for emission 6 patches)。

這個工具是想要經由6個基本色塊(R、G、B 255，White 255、Gray 127、Black 0)，很快的瞭解顯示器的能力，包括該顯示器色域頂點、面積，Gamma值、白點(CCT)與亮度(燭光米平方cdm2)，並同時與sRGB、AdobeRGB、P3做色域比較。

Fig.面板基本資訊。經由這6格數據，可以取得該顯示器色域頂點、面積，Gamma值、白點(CCT)與亮度(燭光米平方cdm2)。量測順序為R->G->B->White->Gray->Black

https://pbn.com.tw/RGBCheck.png

Fig. 我手機面板的基本訊息，可以很清楚它就是個P3面板。實際訊息可參考：

http://fredkuo.idv.tw/FograCT1/pbnEM6.php?f123=target.txt&f321=upload/em6_wq_2024-1-5_130133.txt&company=ecolor

這個工具的工作邏輯是，由i1取得面板上6組XYZ數據，由Autoit 以JSON打包送到server，server根據這6組數據計算出色域x,y、函蓋面積、Gamma等資訊，並與sRGB、AdobeRGB、P3做屬性比較。

這個工具的用意，是想要用最精簡的方式來確定面板的能力，一方面是滿足好奇心，常常看到顯示器的廣告，說它涵蓋多少%AdobeRGB、符合多少p3或符合多少sRGB？這個工具可以讓我很快的知道面板真實的狀況。

在確認面板狀況後，可以更清楚的知道怎麽去用它，或是説服別人這個面板的能力在哪裡？是否足以用來做哪些用途？(比如說是否足以用來做印刷軟打樣？)

工具的用法可參考之前的貼文。

http://fredkuo.idv.tw/wordpress/?p=3453

http://fredkuo.idv.tw/wordpress/?p=3668

http://fredkuo.idv.tw/wordpress/?p=3683

工具釋放位置：

https://pbn.com.tw/dcounter/

由於非正規登錄軟體，很多地方會被認為是病毒，有心測試的同學請耐心處理。有問題可以發問。

以上。

#PrintByNumber

#apiServer

被委託監印一個印件，以CRPC6為目標，有色彩精度的要求，在討論應該用什麼樣的精度驗收時，精度當然是越來越高越好，但若以 G7 ColorSpace 當規格，很難在產線上實行，那是認證考試時候用的，不是生產用的規格。Targeted 勉強可行，同樣的，不容易在產線上收到完整的 G7 verifier數據，但以25%,50%,75%三個點的版調及灰值做為代表驗收點，Targeted(3點參考)  做為驗收規格是可行的。

綜合以上，以gmi/c9 的方式可以符合上述的需求，所以，我提出來驗收的承諾是，以CT25 工具，gmi/c9  85分以上(c9 的驗收規範爲80分)，或是主色(CMY)兩個色差以內(Targeted 規範為3.5)，25%,50%灰差2以內(Grayscale 規範為3.0)。這個承諾規格已經高於G7的考試或是gmi/c9的規定。

二次色(RGB)及75%灰差(3次色疊印)受機器生產時的狀況影響較大，不好做出承諾。

作業程序其實跟G7考試差不多，先把CMYK滿版的濃度確定下來(以Beer’s Law 算出最佳色彩濃度)，再依灰平衡邏輯做3點版調修正，重新出版後才正式開印。

這次印刷的濃度設定如下：

Fig. CMY 色差壓在2以內。RGB的狀況也不錯，以gmi評分，取得主色項目32/32的滿級分。

依以上數據，在最佳色度狀況下，網點擴張都過大，這樣的訊息清楚的呈現當時機器的狀態，要達到更好的數據，改CTP曲線是一個最有效率的方式。

這也是這一次預設的工作模式：先把滿版做對，然後根據數據再出一套新的版下來。

從決定滿版濃度到一套新的版下來，預估在一個小時之內可以做到。這也是這一次的測試目的之一，想要去呈現出，當要對印件有數據精度的要求時，需要多加一個小時的工時及材料成本，來達成我們設定的精度追求。

在滿版色度要求到位時，3點版調修正資訊如下：

Fig.  依25%、50%、75%灰平衡目標值預測CMY版調修正，再重新出一組版。

改版後上機數據如下，有達到預期的效果。在滿版色度及灰平衡的要求都有進入承諾範圍。

Fig. 改版後上機的數據，有達到預期的效果；在滿版色度及灰平衡的要求都有進入承諾範圍。

依TR016規定，每個印件收集20個數據樣本，數據狀況如下：

先說結論，20個樣本下來，不盡然全都是85分以上，但平均下來是86.67分，這樣有算達成承諾嗎？

就我知道的幾個規範如Fogra PSO、G7、gmi、c9… 這些都是認證規範，並非生產規範。即使有提到生產規範也沒有清楚的交代；比如，要收幾個樣本、導具的位置、導具的數量、上下左右、橫放直放、通過率百分比…我還沒看到哪個規格在這方面有清楚的敘述。

印件收20個樣本，是沿用了TR016的規則，至於色彩精度幾分能及格(80分)則是採用c9的説法。

這次算是一個生產驗收的嘗試，以gmi/c9導具為分數計算基礎，帶上TR016生產規則形成以上的報告。至於總成績是取平均值或是最低值？或是某個百分比(70%)？其他如導具位置如何放置於？是否取不同位置平均值/最小值？這一次並沒有詳細的定義出來。

考試跟產線畢竟還是不一樣；我也還在摸索要以什麼樣的方式來達成以數據作為產線允收的規則？

不能夠太複雜、不能太繁瑣，現在產業上數據的執行率已經是夠低了，再多出來的規則如果不會被執行，那也只是自嗨而已。

我的想法是，印刷產業其實已經有明確的標準規範，在這個基礎下，生產者與客戶間是可以就可行性、生產者增加的成本及客戶願意負擔的費用間共同談出一個允收規則。

這一次就是一個嘗試、一個開端，結構還不夠完整，就先當個樣版，先走出第一步。

後面要來談的是，既然有了批次的數據，可以就這批次數據再做一些觀察與分析。

由SID trendchart 可以看出CMY色差的維持算蠻穩定的，但二次疊色(RGB)卻有較大幅度的跳動；二次色牽涉到兩座機座的共同穩定性；停機時間、機器速度、咬口強度或是色座本身的精度都有可能造成二次色的不穩定；不過整體下來，這次數據都還能維持在規定的容差範圍內。

灰平衡是由CMY三色組成，變動性更大於二次色，由數據可以看出75%灰的變動性也是非常大；不過大致上25%與50%灰還是能維持在寬容度之內。

以上數據公開上網，可以在這個連結看到所有的數據資料：

https://pbn.com.tw/FograCT23/lineGraphDT25.php?po=RBDaiS

#KeepPromise

#公開上網

#PrintByNumber

我就懶

製作工具的基本動機是：懶!

同樣件事情能不能用最少的步驟、最少的設備、最少的時間去完成它？

舉例說，當想知道這個印刷品的品質好不好，最快的方式是什麼？

在我的工具架構中，CT10 是最迅速有效的工具。刷過去5秒鐘就會知道現目前印機狀態滿版的位置，中間調的位置及灰平衡的狀況。

目前的程序是由SDK把i1的光譜數據帶給php運算，然後顯示出結果。

你這樣已經夠精簡了，我還想懶成什麼樣子！

就為了這個東西，斑馬尺。

Fig. Zebra ruler

從i1pro2開始，在做strip reading時，如果要取得M1模式，必須經由斑馬尺來做讀取(Pro2 M0 模式不需斑馬尺，Pro3 則是 strip 模式都需斑馬尺)。包包裡已經夠多東西了，實在不想再多這個重量。

找到 i1Pro Chart Design Rule 文件裡，有這樣的敘述：每一個相鄰色塊超過20個deltaE，可以不經過斑馬尺。

Fig. from i1Pro Chart Design Rule.相鄰色塊超過20個deltaE，strip reading 可以不經過斑馬尺。

於是舊的CT10的格式變成這樣。

Fig..CT10，上面為舊格式，下面為新的格式。

實際操作下來，確實可以不用斑馬尺。

Fig. 不用斑馬尺，i1Pro3就可以做strip reading。

把數據拿出來分析一下，目前排列最低色差發生在K50與C50之間，色差為30，能夠符合 Chart Design Rule 規則。

同樣的邏輯，當然也可以放在CT25這個工具上面。於是CT25也有新的格式。

Fig. CT25 工具，上面為舊格式，下面為新的格式。

CT25新格式的數據參考如下 ，最小色差發生在paper與c50之間，約deltaE33，符合低於20個deltaE的規則。

新版格式，確認每個色塊都超過20個deltaE，實際測試確實能夠使用。這樣以後就不需要再帶那根斑馬尺了。

都說科技來自人性。這個本性其實就是”懶”。但裡面更重要的是，我們如何能用最懶惰的方式，去達成我們設定的工作目標。

要懶，又要達成工作上的目標。我必須學習光譜計算、學習PHP、學習Autoit、學習驅動i1 sdk的c++、學習導具格式的xml、學習資料庫語言mysql、要瞭解ISO、idealliance各種標準的定義與規格、要不斷的測試程式語言的邏輯……。這個“懶”字，不容易啊！

要懶惰，又要能達成工作目標，關鍵就是邏輯。衹要能把邏輯講清楚。把這些工作邏輯用程式方法堆積出來。是有機會可以做到又懶惰，又能達成工作目標。