🏉 🧝🏿 🔪 तकिया 2.0 में Alpha_composite अनुकूलन इतिहास 🙇🏻 👨🏼‍🎓 🙏🏿

हाल ही में, पिलो छवियों के साथ काम करने के लिए पायथन लाइब्रेरी का दूसरा संस्करण जारी किया गया है। जैसा कि बहुत से लोग जानते हैं, यह प्रसिद्ध पीआईएल लाइब्रेरी का एक कांटा है, जो कि इसकी काफी उम्र के बावजूद, हाल ही में, पायथन में छवियों के साथ काम करने का सबसे समझदार तरीका बना रहा। पिलो के लेखकों ने आखिरकार न केवल पुराने कोड का समर्थन करने का फैसला किया, बल्कि नई सुविधाओं को भी जोड़ा। और इनमें से एक विशेषता अल्फ़ा_कम्पोसिट () फ़ंक्शन थी।

यह फ़ंक्शन दो पारभासी छवियों के मिश्रण को लागू करता है। यह कार्य एक अपारदर्शी पृष्ठभूमि पर एक अल्फा चैनल के साथ एक छवि को ओवरले करने का एक आम मामला है, जो शायद कई लोगों से परिचित है। आप विकिपीडिया पर पारभासी चित्रों के मिश्रण के बारे में पढ़ सकते हैं। मैंने लंबे समय तक इस बारे में एक लेख लिखा।

तब से, मैं पहले से ही उस लेख के अंत में सूचीबद्ध की तुलना में अपनी आवश्यकताओं के लिए एक अधिक इष्टतम कार्यान्वयन लिखने में सक्षम हूं। और यह पता चला कि यह कार्यान्वयन C में लिखे तकिया के नए संस्करण से Alpha_composite () से तेज है। बेशक, मैं इससे खुश था, लेकिन मैंने पिलो से कार्यान्वयन को बेहतर बनाने की कोशिश करने का फैसला किया।

पहले आपको एक परीक्षण बेंच की आवश्यकता है।

bench.py

from PIL import Image from timeit import repeat from image import paste_composite im1 = Image.open('in1.png') im1.load() im2 = Image.open('in2.png') im2.load() print repeat(lambda: paste_composite(im1.copy(), im2), number=100) print repeat(lambda: Image.alpha_composite(im1, im2), number=100) out1 = im1.copy() paste_composite(out1, im2) out1.save('out1.png') out2 = Image.alpha_composite(im1, im2) out2.save('out2.png')

स्क्रिप्ट वर्तमान फ़ोल्डर में पड़ी हुई in1.png और in2.png फ़ाइलों को लेती है और उन्हें paste_composite () फ़ंक्शन के साथ सौ बार पहले मिलाती है, फिर Alpha_composite ()। मैंने पिछले लेख ( एक , दो ) से फाइलें लीं। Paste_composite () का औसत रनटाइम 235ms था। मूल Alpha_composite () का ऑपरेटिंग समय 400ms था।

क्यों अल्फा_कंपोजिट () इतना धीमा है, मुझे लंबे समय तक अनुमान नहीं लगाना है। कार्यान्वयन को देखते हुए, यह स्पष्ट है कि फ़ंक्शन फ्लोटिंग पॉइंट नंबरों पर सभी गणना करता है। ग्राफिक्स के साथ काम करते समय, फ्लोटिंग-पॉइंट नंबर एल्गोरिदम का वर्णन करना आसान बनाते हैं, लेकिन उनका प्रदर्शन हमेशा पूर्णांक से कम होता है। पहली चीज जो मैंने की थी वह पूर्णांक के साथ काम करने के लिए सब कुछ अनुवाद कर रही थी:

 typedef struct { UINT8 r; UINT8 g; UINT8 b; UINT8 a; } rgba8; Imaging ImagingAlphaComposite(Imaging imDst, Imaging imSrc) { Imaging imOut = ImagingNew(imDst->mode, imDst->xsize, imDst->ysize); for (int y = 0; y < imDst->ysize; y++) { rgba8* dst = (rgba8*) imDst->image[y]; rgba8* src = (rgba8*) imSrc->image[y]; rgba8* out = (rgba8*) imOut->image[y]; for (int x = 0; x < imDst->xsize; x ++) { if (src->a == 0) { *out = *dst; } else { UINT16 blend = dst->a * (255 - src->a); UINT8 outa = src->a + blend / 255; UINT8 coef1 = src->a * 255 / outa; UINT8 coef2 = blend / outa; out->r = (src->r * coef1 + dst->r * coef2) / 255; out->g = (src->g * coef1 + dst->g * coef2) / 255; out->b = (src->b * coef1 + dst->b * coef2) / 255; out->a = outa; } dst++; src++; out++; } } return imOut; }

और तुरंत 5.5 गुना की वृद्धि प्राप्त की। परीक्षण ने 75 एमएस में काम किया।

एक अच्छा परिणाम है, लेकिन यह जांचना आवश्यक था कि तस्वीर कितनी उच्च गुणवत्ता वाली निकली। एक संदर्भ के रूप में फ़ोटोशॉप का परिणाम लेने से बेहतर कुछ भी नहीं है, मैं साथ नहीं आया। उपस्थिति में, परिणामस्वरूप दो छवियां फ़ोटोशॉप में प्राप्त लोगों से अप्रभेद्य थीं, इसलिए मुझे यह पता लगाना था कि मतभेदों को अधिक सटीक रूप से कैसे चित्रित किया जाए।

diff.py

 #!/usr/bin/env python import sys from PIL import Image, ImageMath def chanel_diff(c1, c2): c = ImageMath.eval('127 + c1 - c2', c1=c1, c2=c2).convert('L') return c.point(lambda c: c if 126 <= c <= 128 else 127 + (c - 127) * 10) im1 = Image.open(sys.argv[1]) im2 = Image.open(sys.argv[2]) diff = map(chanel_diff, im1.split(), im2.split()) Image.merge('RGB', diff[:-1]).save('diff.png', optimie=True) diff[-1].convert('RGB').save('diff.alpha.png', optimie=True)

इनपुट पर, स्क्रिप्ट चित्रों के साथ 2 फ़ाइल नामों को स्वीकार करता है। इन चित्रों के प्रत्येक जोड़े के बीच अंतर हैं: पहला, अंतर बस देखा जाता है और एक ग्रे पृष्ठभूमि (मूल्य 127) में जोड़ा जाता है ताकि आप दोनों दिशाओं में विचलन देख सकें। तब सभी विचलन, एक से अधिक मूल्य, 10 गुना बढ़ जाते हैं ताकि वे नेत्रहीन दिखाई दें। तुलना परिणाम 2 फ़ाइलों में लिखा गया है: diff.png में आरजीबी चैनल, diff.alpha.png में ग्रे के रंगों के रूप में अल्फा चैनल।

यह पता चला कि Alpha_composite () और फ़ोटोशॉप के परिणाम के बीच का अंतर काफी महत्वपूर्ण है:

कोड को फिर से ध्यान से देखने पर, मुझे एहसास हुआ कि मैं गोलाई के बारे में भूल गया था: पूर्णांक शेष को छोड़ कर विभाजित हैं। यदि हम एक गोल परिणाम प्राप्त करना चाहते हैं, तो हमें लाभांश में आधा विभाजक जोड़ना होगा:

 UINT16 blend = dst->a * (255 - src->a); UINT8 outa = src->a + (blend + 127) / 255; UINT8 coef1 = src->a * 255 / outa; UINT8 coef2 = blend / outa; out->r = (src->r * coef1 + dst->r * coef2 + 127) / 255; out->g = (src->g * coef1 + dst->g * coef2 + 127) / 255; out->b = (src->b * coef1 + dst->b * coef2 + 127) / 255; out->a = outa;

रनटाइम 94 एमएस तक बढ़ गया। लेकिन संदर्भ से बहुत कम अंतर हैं। हालांकि, वे बिल्कुल गायब नहीं हुए।

सिद्धांत रूप में, हम यहां रुक सकते हैं: इस बिंदु पर मौजूद विसंगतियां मुख्य रूप से उच्च पारदर्शिता वाले पिक्सेल में केंद्रित हैं, जो कि रंग चैनल मूल्य को इतना महत्वपूर्ण नहीं बनाता है। लेकिन सिर्फ मामले में, अल्फ़ा_कम्पोज़िट () के मूल संस्करण की जाँच करते हुए, मैंने पाया कि यह व्यावहारिक रूप से मानक से अलग नहीं होता है। वहां रुकना असंभव था।

जाहिर है, प्राप्त अशुद्धि गुणन के दौरान गुणांक की अपर्याप्त सटीकता का परिणाम है। आप प्रत्येक चर के लिए अतिरिक्त महत्वपूर्ण बिट्स स्टोर कर सकते हैं, जो विभाजन की सटीकता में सुधार करता है। मिश्रण चर विभाजन के बिना गणना की जाती है, इसके साथ कुछ भी करने की आवश्यकता नहीं है। आउट चर को मिश्रण को 255 से विभाजित करके प्राप्त किया जाता है। गणना करते समय, हम मिश्रण के मूल्यों को शिफ्ट करते हैं और src-> एक 4 बिट्स अप करते हैं। नतीजतन, आउटा में 12 महत्वपूर्ण बिट्स होंगे। दोनों गुणांक में, आउट द्वारा विभाजन होता है, जो अब 4 बिट बड़ा है। इसके अलावा, गुणांक स्वयं 4 बिट अधिक प्राप्त करना चाहते हैं। नतीजतन, लाभांश पहले से ही 8 बिट्स द्वारा स्थानांतरित कर दिया गया है।

 UINT16 blend = dst->a * (255 - src->a); // 16 bit max UINT16 outa = (src->a << 4) + ((blend << 4) + 127) / 255; // 12 UINT16 coef1 = ((src->a * 255) << 8) / outa; // 12 UINT16 coef2 = (blend << 8) / outa; // 12 out->r = ((src->r * coef1 + dst->r * coef2 + 0x7ff) / 255) >> 4; out->g = ((src->g * coef1 + dst->g * coef2 + 0x7ff) / 255) >> 4; out->b = ((src->b * coef1 + dst->b * coef2 + 0x7ff) / 255) >> 4; out->a = (outa + 0x7) >> 4;

बेशक, समान 4 बिट्स को छवि पिक्सेल में रखने से पहले सभी गणनाओं के परिणाम को स्थानांतरित करने की आवश्यकता होती है। यह विकल्प थोड़ा धीमा भी काम करता है: 108 एमएस, लेकिन इसमें पहले से ही लगभग कोई पिक्सेल नहीं है जो मानक से एक से अधिक मूल्य से भिन्न हो। गुणवत्ता पर परिणाम हासिल किया गया है, आप फिर से प्रदर्शन के बारे में सोच सकते हैं।

जाहिर है, यह कोड प्रोसेसर के दृष्टिकोण से सबसे इष्टतम नहीं है। डिवीजन सबसे कठिन कार्यों में से एक है, और यहां प्रत्येक पिक्सेल के लिए 6 विभाजन किए गए हैं। यह पता चला कि उनमें से अधिकांश से छुटकारा पाना काफी सरल है। Paste.c फ़ाइल में समान PIL में, गोलाई के साथ तेज़ विभाजन के लिए एक विधि वर्णित है:
a + 127 / 255 ≈ ((a + 128) + ((a + 128) >> 8)) >> 8

नतीजतन, एक विभाजन को 2 पारियों और एक जोड़ से बदल दिया जाता है, जो अधिकांश प्रोसेसर पर तेज होता है। 4 की मौजूदा शिफ्ट के साथ एक शिफ्ट में समूहीकृत होने के बाद, मुझे यह कोड मिला:

 UINT16 blend = dst->a * (255 - src->a); UINT16 outa = (src->a << 4) + (((blend << 4) + (blend >> 4) + 0x80) >> 8); UINT16 coef1 = (((src->a << 8) - src->a) << 8) / outa; // 12 UINT16 coef2 = (blend << 8) / outa; // 12 UINT32 tmpr = src->r * coef1 + dst->r * coef2 + 0x800; out->r = ((tmpr >> 8) + tmpr) >> 12; UINT32 tmpg = src->g * coef1 + dst->g * coef2 + 0x800; out->g = ((tmpg >> 8) + tmpg) >> 12; UINT32 tmpb = src->b * coef1 + dst->b * coef2 + 0x800; out->b = ((tmpb >> 8) + tmpb) >> 12; out->a = (outa + 0x7) >> 4;

यह पहले से ही 65 एमएस में पूरा हो गया है और पिछले संस्करण की तुलना में परिणाम नहीं बदलता है।

कुल मिलाकर, काम की गति में 6 गुना सुधार हुआ, एक पूल अनुरोध भंडार को भेजा गया था। एक मानक के साथ अधिक से अधिक समानता हासिल करने की कोशिश कर सकता है। उदाहरण के लिए, मैं फ़ोटोशॉप द्वारा उत्पन्न अल्फा चैनल को पूरी तरह से सही ढंग से दोहराने में सक्षम था, लेकिन अधिक विरूपण को पिक्सल में पेश किया गया था।

बड़ा अपडेट

एक बार फिर मैंने विचार किया कि क्या किया गया था और यह तय किया कि फ़ोटोशॉप एल्गोरिथ्म के साथ आने के लिए यह मूर्खतापूर्ण होगा कि जो कार्य किए गए हैं उनके लिए अज्ञात है और जिसके कार्यान्वयन को भी नहीं देखा जा सकता है। फ्लोट पर एल्गोरिथ्म के संचालन को एक संदर्भ के रूप में लेना आवश्यक है। मैंने उस स्क्रिप्ट को थोड़ा संशोधित किया जो अंतर पाता है ताकि यह कुछ आंकड़े प्रदर्शित करे।

diff.py

 #!/usr/bin/env python import sys from PIL import Image, ImageMath def chanel_diff(c1, c2): return ImageMath.eval('127 + c1 - c2', c1=c1, c2=c2).convert('L') def highlight(c): return c.point(lambda c: c if 126 <= c <= 128 else 127 + (c - 127) * 10) im1 = Image.open(sys.argv[1]) im2 = Image.open(sys.argv[2]) diff = map(chanel_diff, im1.split(), im2.split()) if len(sys.argv) >= 4: highlight(Image.merge('RGB', diff[:-1])).save('%s.png' % sys.argv[3]) highlight(diff[-1]).convert('RGB').save('%s.alpha.png' % sys.argv[3]) def stats(ch): return sorted((c, n) for n, c in ch.getcolors()) for ch, stat in zip(['red ', 'grn ', 'blu ', 'alp '], map(stats, diff)): print ch, ' '.join('{}: {:>5}'.format(c, n) for c, n in stat)

मैंने 16 मेगापिक्सेल पर दो चित्रों का एक बहुत ही गंभीर परीक्षण मामला तैयार किया, जहाँ प्रत्येक पिक्सेल संयोजन अद्वितीय था।

make_testcase.py

 def prepare_test_images(dim): """Plese, be careful with dim > 32. Result image is have dim ** 4 pixels (ie 1Mpx for 32 dim or 4Gpx for 256 dim). """ i1 = bytearray(dim ** 4 * 2) i2 = bytearray(dim ** 4 * 2) res = 255.0 / (dim - 1) rangedim = range(dim) pos = 0 for l1 in rangedim: for l2 in rangedim: for a1 in rangedim: for a2 in rangedim: i1[pos] = int(res * l1) i1[pos + 1] = int(res * a1) i2[pos] = int(res * l2) i2[pos + 1] = int(res * a2) pos += 2 print '%s of %s' % (l1, dim) i1 = Image.frombytes('LA', (dim ** 2, dim ** 2), bytes(i1)) i2 = Image.frombytes('LA', (dim ** 2, dim ** 2), bytes(i2)) return i1.convert('RGBA'), i2.convert('RGBA') im1, im2 = prepare_test_images(63) im1.save('im1.png') im2.save('im2.png')

उसके बाद, मैंने दूसरे छोर से शुरू करने का फैसला किया: पूर्णांक एल्गोरिथ्म की सटीकता बढ़ाने की कोशिश न करें, लेकिन पूर्णांक के साथ काम करने के लिए फ्लोटिंग-पॉइंट एल्गोरिथ्म लाने की कोशिश करें। यह वह जगह है जहाँ मैंने शुरू किया था:

 double dsta = dst->a / 255.0; double srca = src->a / 255.0; double blend = dsta * (1.0 - srca); double outa = srca + blend; double coef1 = srca / outa; double coef2 = 1 - coef1; double tmpr = src->r * coef1 + dst->r * coef2; out->r = (UINT8) (tmpr + 0.5); double tmpg = src->g * coef1 + dst->g * coef2; out->g = (UINT8) (tmpg + 0.5); double tmpb = src->b * coef1 + dst->b * coef2; out->b = (UINT8) (tmpb + 0.5); out->a = (UINT8) (outa * 255.0 + 0.5);

और यही मैं आया:

 UINT16 blend = dst->a * (255 - src->a); UINT16 outa255 = src->a * 255 + blend; // There we use 7 bits for precision. // We could use more, but we go beyond 32 bits. UINT16 coef1 = src->a * 255 * 255 * 128 / outa255; UINT16 coef2 = 255 * 128 - coef1; #define SHIFTFORDIV255(a)\ ((a >> 8) + a >> 8) UINT32 tmpr = src->r * coef1 + dst->r * coef2 + (0x80 << 7); out->r = SHIFTFORDIV255(tmpr) >> 7; UINT32 tmpg = src->g * coef1 + dst->g * coef2 + (0x80 << 7); out->g = SHIFTFORDIV255(tmpg) >> 7; UINT32 tmpb = src->b * coef1 + dst->b * coef2 + (0x80 << 7); out->b = SHIFTFORDIV255(tmpb) >> 7; out->a = SHIFTFORDIV255(outa255 + 0x80);

तकिया 2.0 में Alpha_composite अनुकूलन इतिहास

More articles: