🤗 🚤 🤮 डी में कार्यात्मक छवि प्रसंस्करण 💏 🕴🏻 🙍🏾

मैंने हाल ही में अपने डी लाइब्रेरी के लिए एक ग्राफिक्स पैकेज का काम पूरा किया है। Std.algorithm और std.range मॉड्यूल से प्रेरित होकर, मैंने निम्नलिखित लक्ष्यों को प्राप्त करने की कोशिश की:

छोटे दहनशील घटकों के रूप में सब कुछ प्रस्तुत करें
अंतर्निहित नकल से बचें और अधिमानतः आलसी गणनाओं का उपयोग करें
कोड लेखन प्रदर्शन और दक्षता में सुधार के लिए टेम्पलेट्स का उपयोग करें

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

पुस्तकालय पर काम के परिणामों से मैं बहुत खुश हूं, इसलिए मैं इस पोस्ट में कुछ दिलचस्प बिंदुओं को साझा करना चाहता हूं।

पुस्तकालय दृश्य की परिभाषा के साथ शुरू होता है:

///  ,    width, height ///       ///    enum isView(T) = is(typeof(T.init.w) : size_t) && // width is(typeof(T.init.h) : size_t) && // height is(typeof(T.init[0, 0]) ); // color information

स्थिर इंटरफेस घोषित करने का यह तरीका वही है जो std.range में उपयोग किया जाता है, उदाहरण के लिए, InInputRange । OOP के अर्थ में समान इंटरफ़ेस की घोषणा करने के बजाय, D में स्थिर इंटरफेस को सशर्त रूप से कुछ विशेषताओं (लगभग डक टाइपिंग ) के कार्यान्वयन के लिए परीक्षण का उपयोग करके निर्धारित किया जाता है। सत्यापन सफल होता है यदि संचालन जिस प्रकार को लागू करना चाहिए वह त्रुटियों के बिना संकलित है या एक विशिष्ट प्रकार है। आमतौर पर, इसके लिए IsExpression या trait compiles का उपयोग किया जाता है।

Std.range.ElementType के समान , हम पिक्सेल के रंग को देखने के लिए उपयोग किए जाने वाले प्रकार को प्राप्त करने के लिए एक टेम्पलेट को परिभाषित करते हैं:

 ///     view alias ViewColor(T) = typeof(T.init[0, 0]);

अगला, हम देखने के लिए कई विशेषज्ञताओं को परिभाषित करते हैं:

कोड

 /// Views    ///    enum isWritableView(T) = isView!T && is(typeof(T.init[0, 0] = ViewColor!T.init)); ///  view   ///    . ///  views  "direct views" enum isDirectView(T) = isView!T && is(typeof(T.init.scanline(0)) : ViewColor!T[]);

फिर, यह isForwardRange की परिभाषा के समान है : यह जाँचना कि प्रकार सभी बुनियादी सुविधाओं को लागू करता है, साथ ही साथ कुछ अतिरिक्त विशेषताएं इस विशेषज्ञता के लिए विशिष्ट हैं।

चूंकि पिक्सल तक सीधी पहुंच के कार्यान्वयन को स्कैनलाइन प्रत्यक्ष दृश्य के माध्यम से निर्धारित किया जा सकता है, इसलिए इसे लागू करने वाले टेम्पलेट मिश्रण की घोषणा करें:

कोड

 /// ,    view ///     direct view mixin template DirectView() { alias COLOR = typeof(scanline(0)[0]); ///   view[x, y] ref COLOR opIndex(int x, int y) { return scanline(y)[x]; } ///   view[x, y] = c COLOR opIndexAssign(COLOR value, int x, int y) { return scanline(y)[x] = value; } }

उदाहरण के लिए, एक छवि टेम्पलेट को परिभाषित करें जो स्मृति में एक छवि का वर्णन करता है:

कोड

 ///    ///      struct Image(COLOR) { int w, h; COLOR[] pixels; ///     y COLOR[] scanline(int y) { assert(y>=0 && y<h); return pixels[w*y..w*(y+1)]; } mixin DirectView; this(int w, int h) { size(w, h); } ///     void size(int w, int h) { this.w = w; this.h = h; if (pixels.length < w*h) pixels.length = w*h; } }

डी में एरर्स को एक पॉइंटर और लंबाई के माध्यम से लागू किया जाता है (और केवल मेमोरी का अनुरोध करते समय विस्तार या एक साथ चिपके हुए), इसलिए अभिव्यक्ति पिक्सल [w * y ... w * (y + 1)] सरणी की एक प्रति नहीं बनाता है।

इकाई परीक्षण संकलन समय पर पुष्टि करता है कि छवि वास्तव में isDirectView इंटरफ़ेस की शर्तों को संतुष्ट करती है:

 unittest { static assert(isDirectView!(Image!ubyte)); }

तो हम इस मॉडल के साथ क्या कर सकते हैं?

सबसे पहले, हम उन छवियों को परिभाषित कर सकते हैं जो वास्तव में पिक्सेल की एक सरणी को संदर्भित नहीं करते हैं, बल्कि उन्हें मांग पर गणना करते हैं:

कोड

 ///  view,    ///       template procedural(alias formula) { alias fun = binaryFun!(formula, "x", "y"); alias COLOR = typeof(fun(0, 0)); auto procedural(int w, int h) { struct Procedural { int w, h; auto ref COLOR opIndex(int x, int y) { return fun(x, y); } } return Procedural(w, h); } }

एक ही नाम का यह टेम्प्लेट एक स्ट्रिंग (जिसे मिश्रित किया जाएगा) को एक विधेय या प्रतिनिधि (लैम्ब्डा) में बदलने के लिए std.functional.binaryFun का उपयोग करता है। चूंकि फ़ंक्शन में वापसी प्रकार ऑटो है और इस फ़ंक्शन के अंदर घोषित संरचना लौटाता है, प्रक्रियात्मक Voldemort प्रकार का एक उदाहरण है।

एक रंग से भरी प्रक्रियात्मक छवि का सबसे सरल उदाहरण:

 ///  view,   ///     auto solid(COLOR)(COLOR c, int w, int h) { return procedural!((x, y) => c)(w, h); }

ध्यान दें कि कैसे लौटा हुआ दृश्य का रंग पैरामीटर प्रकार c से अनुमानित है, इसलिए ठोस (RGB (1, 2, 3), 10, 10) RGB पिक्सेल से दृश्य लौटाएगा, भले ही उसके पास पूर्ण रूप से योग्य नाम न हो।

इस मॉडल में एक और चीज का प्रतिनिधित्व किया जा सकता है, जो विभिन्न तरीकों से अन्य विचारों को बदलने वाले विचार पैदा कर रहा है। आमतौर पर इस्तेमाल किए जाने वाले कोड के लिए एक और टेम्पलेट मिक्सिन को परिभाषित करें:

कोड

 /// ,   view   ///  view,    ///  mixin template Warp(V) { V src; auto ref ViewColor!V opIndex(int x, int y) { warp(x, y); return src[x, y]; } static if (isWritableView!V) ViewColor!V opIndexAssign(ViewColor!V value, int x, int y) { warp(x, y); return src[x, y] = value; } }

आइए स्थैतिक को देखें यदि (isWritableView! V) रेखा , जो कहती है कि दृश्य [x, y] = c कथन को केवल तभी परिभाषित किया जाना चाहिए यदि अंतर्निहित दृश्य इसका समर्थन करता है। कुल लिपटा हुआ दृश्य परिवर्तनशील होगा तभी अंतर्निहित दृश्य भी बदला जा सकता है।

इस फ़ंक्शन का उपयोग करते हुए, हम एक क्रॉपिंग दृश्य को परिभाषित कर सकते हैं जो दूसरे दृश्य के आयताकार टुकड़े का प्रतिनिधित्व करता है:

कोड

 ///  view    auto crop(V)(auto ref V src, int x0, int y0, int x1, int y1) if (isView!V) { assert( 0 <= x0 && 0 <= y0); assert(x0 < x1 && y0 < y1); assert(x1 <= src.w && y1 <= src.h); static struct Crop { mixin Warp!V; int x0, y0, x1, y1; @property int w() { return x1-x0; } @property int h() { return y1-y0; } void warp(ref int x, ref int y) { x += x0; y += y0; } static if (isDirectView!V) ViewColor!V[] scanline(int y) { return src.scanline(y0+y)[x0..x1]; } } static assert(isDirectView!V == isDirectView!Crop); return Crop(src, x0, y0, x1, y1); }

अगर (isView! V) टेम्प्लेट बाधा की जाँच करता है कि पहला तर्क isView इंटरफ़ेस की शर्तों से मेल खाता है।

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

कोड

 ///   view  . /// Views    . void blitTo(SRC, DST)(auto ref SRC src, auto ref DST dst) if (isView!SRC && isWritableView!DST) { assert(src.w == dst.w && src.h == dst.h, "View size mismatch"); foreach (y; 0..src.h) { static if (isDirectView!SRC && isDirectView!DST) dst.scanline(y)[] = src.scanline(y)[]; else { foreach (x; 0..src.w) dst[x, y] = src[x, y]; } } }

फसल के समान विचार का उपयोग किसी ऐसे दृश्य को लागू करने के लिए किया जा सकता है जो निकटतम पड़ोसी एल्गोरिदम के अनुसार किसी अन्य दृश्य या तराजू को टाइल करता है (अधिक जटिल स्केलिंग एल्गोरिदम बेहतर शैली में कार्यान्वित किया जाता है)। कोड बहुत फसल के समान है, इसलिए मैं इसे यहां शामिल नहीं करता हूं।

यहां तक कि अगर फसल स्रोत को एक सामान्य तर्क के रूप में लेती है, तो इस फ़ंक्शन का इच्छित उपयोग और ऐसा है जैसे कि यह मूल दृश्य की विधि थी: someView.nearestNeighbor (100, 100) .tile (1000, 1000) .crop (50, 50, 950)। 950) है । यह संभावना "यूनिफॉर्म फंक्शन कॉल सिंटेक्स" (या बस यूएफसीएस) नामक भाषा की एक विशेषता के कारण है, जो आपको मस्ती (ए, बी ...) के बजाय a.fun (b ...) लिखने की अनुमति देती है। इस सुविधा का मुख्य लाभ फ़ाइनिंग 3 (fun2 (फ़न 1 (ए )) के बजाय फ़ाइनिंग (a.fun1 ()। फन 2 (), फ़न 3 () को व्यवस्थित करने की क्षमता है, जिसका उपयोग फ़ेओस में और इस पैकेज में किया जाता है।

साधारण परिवर्तनों के लिए, जिसमें दृश्य आकार नहीं बदलता है, हम एक सहायक फ़ंक्शन को परिभाषित कर सकते हैं जो उपयोगकर्ता द्वारा प्रत्येक पिक्सेल समन्वय के लिए निर्दिष्ट सूत्र के आवेदन को सरल करता है:

कोड

 ///  view    ///    template warp(string xExpr, string yExpr) { auto warp(V)(auto ref V src) if (isView!V) { static struct Warped { mixin Warp!V; @property int w() { return src.w; } @property int h() { return src.h; } void warp(ref int x, ref int y) { auto nx = mixin(xExpr); auto ny = mixin(yExpr); x = nx; y = ny; } private void testWarpY()() { int y; y = mixin(yExpr); } ///  x     y   ///  x,      scanlines. static if (xExpr == "x" && __traits(compiles, testWarpY()) && isDirectView!V) ViewColor!V[] scanline(int y) { return src.scanline(mixin(yExpr)); } } return Warped(src); } }

ताना पारित सूत्रों को मान्य करने के लिए एक ट्रिकी विधि का उपयोग करता है। TestWarpY फ़ंक्शन को टेम्पलेट के रूप में घोषित किया जाता है, हालांकि, शून्य टेम्पलेट तर्क के साथ। यह संकलक को इस फ़ंक्शन के शरीर के शब्दार्थ विश्लेषण का उपयोग नहीं करने के लिए मजबूर करता है जब तक कि इसका उपयोग नहीं किया जाता है। और चूंकि इसमें स्कोप x नहीं है, यह केवल तभी सफलतापूर्वक स्थापित किया जा सकता है जब yExpr x का उपयोग नहीं करता है। अभिव्यक्ति __traits (संकलन, testWrapY ()) सिर्फ यह जांचता है। यह सब हमें एक प्रत्यक्ष दृश्य स्कैनलाइन को परिभाषित करने की अनुमति देता है केवल अगर हमें विश्वास है कि हम इसे सुरक्षित रूप से कर सकते हैं। एक उदाहरण:

कोड

 ///  view    x alias hflip = warp!(q{wx-1}, q{y}); ///  view    y alias vflip = warp!(q{x}, q{hy-1}); ///  view    x  y alias flip = warp!(q{wx-1}, q{hy-1});

स्ट्रिंग स्थिरांक को परिभाषित करने के लिए q {...} सिंटैक्स केवल एक सुविधाजनक तरीका है। इस प्रविष्टि का उपयोग आमतौर पर डी कोड के लिए किया जाता है, जो तब कहीं पर मिश्रित होता है। अभिव्यक्ति के मिश्रण में सभी वर्णों तक पहुंच है - हमारे मामले में, यह ताना कार्य और लिपटा संरचना का परीक्षण तरीका है।

चूंकि vflip एक स्कैनलाइन विधि घोषित करने के लिए आवश्यक पहले दो शर्तों को संतुष्ट करता है, तो someView.vflip () एक प्रत्यक्ष दृश्य होगा, अगर कुछ दृश्य एक है । और यह vflip विज्ञापन के लिए स्पष्ट सत्यापन के बिना प्राप्त किया गया था।

चूंकि अमूर्त का उपयोग गतिशील बहुरूपता पर निर्भर नहीं करता है, संकलक सभी परिवर्तन परतों की कॉल एम्बेड करने के लिए स्वतंत्र है। दो बार एक छवि डालने से एक ऑपरेशन उत्पन्न नहीं होता है, और, वास्तव में, मैं [5, 5] और i.hipip ()। Hflip () [5, 5] एक ही मशीन कोड उत्पन्न करता हूं । एक बेहतर बैकएंड के साथ डी कंपाइलर और भी अधिक आक्रामक अनुकूलन कर सकते हैं: उदाहरण के लिए, यदि आप फ्लिपएक्सवाई फ़ंक्शन को परिभाषित करते हैं, जो एक्स और वाई एक्सिस को इन्वर्ट करता है , और रोट्रेक्ट डब्ल्यूडब्ल्यू (छवि 90 डिग्री वामावर्त घुमाएँ) को आरआर.एफएलएक्सएक्सवाईवाई () के रूप में। , फिर अनुकूलन के दौरान चार सफल रोटैकडब्ल्यू कॉल काट दिए जाते हैं।

चलो पिक्सेल पर स्वयं ऑपरेशन पर चलते हैं। Std.al एल्गोरिथम में मुख्य कार्य मानचित्र है , जो एक सीमा देता है जो आलसी किसी अन्य सीमा पर अभिव्यक्ति लागू करता है। हमारा colorMap रंगों के लिए इस विचार का उपयोग करता है:

कोड

 ///  view,    ///     view. template colorMap(alias pred) { alias fun = unaryFun!(pred, false, "c"); auto colorMap(V)(auto ref V src) if (isView!V) { alias OLDCOLOR = ViewColor!V; alias NEWCOLOR = typeof(fun(OLDCOLOR.init)); struct Map { V src; @property int w() { return src.w; } @property int h() { return src.h; } auto ref NEWCOLOR opIndex(int x, int y) { return fun(src[x, y]); } } return Map(src); } }

ColorMap का उपयोग करना, एक फ़ंक्शन को परिभाषित करता है जो एक छवि के रंगों को निष्क्रिय करता है:

 alias invert = colorMap!q{~c};

colorMap को स्रोत रंग प्रकार और परिणाम के मिलान की आवश्यकता नहीं होती है। यह आपको रंग रूपांतरण के लिए इसका उपयोग करने की अनुमति देता है: पढ़ा ("image.bmp")। ParseBMP! RGB (।) ColorMap! (C => BGRX (cb, cg, cr)) BGRX दृश्य के रूप में RGB बिटमैप लौटाएगा।

छवि प्रसंस्करण बहुत बार समानांतर के लिए अच्छी तरह से उधार देता है । std.parallelism समानांतर छवि प्रसंस्करण के कार्य को तुच्छ बनाने में मदद करता है:

कोड

 ///  view    ///  fun    /// . ///   , ///    , ///  vjoin  vjoiner. template parallel(alias fun) { auto parallel(V)(auto ref V src, size_t chunkSize = 0) if (isView!V) { auto processSegment(R)(R rows) { auto y0 = rows[0]; auto y1 = y0 + rows.length; auto segment = src.crop(0, y0, src.w, y1); return fun(segment); } import std.range : iota, chunks; import std.parallelism : taskPool, parallel; if (!chunkSize) chunkSize = taskPool.defaultWorkUnitSize(src.h); auto range = src.h.iota.chunks(chunkSize); alias Result = typeof(processSegment(range.front)); auto result = new Result[range.length]; foreach (n; range.length.iota.parallel(1)) result[n] = processSegment(range[n]); return result; } }

यहां तक कि अगर समानांतर उन कार्यों के साथ अपना नाम साझा करता है जो std.parallelism में मौजूद हैं, तो कोई संघर्ष नहीं है, क्योंकि उनके पास अलग-अलग हस्ताक्षर हैं और विभिन्न प्रकारों पर काम करते हैं।

इसी समय, ऑपरेशन को कई थ्रेड्स के बीच विभाजित किया जा सकता है, जिससे image.process () को image.parallel - (सेगमेंट => सेगमेंट।प्रोसेसर ) ()) के साथ विभाजित किया जा सकता है । Vjoin () ।

व्यावहारिक उदाहरण:

एक छोटा एनीमेशन बनाएं:

कोड

 import std.algorithm; import std.parallelism; import std.range; import std.stdio; import std.string; import ae.utils.geometry; import ae.utils.graphics.color; import ae.utils.graphics.draw; import ae.utils.graphics.gamma; import ae.utils.graphics.image; void main() { enum W = 4096; const FG = L16(0); const BG = L16(ushort.max); auto image = Image!L16(W, W); image.fill(BG); enum OUTER = W/2 * 16/16; enum INNER = W/2 * 13/16; enum THICK = W/2 * 3/16; image.fillCircle(W/2, W/2, OUTER, FG); image.fillCircle(W/2, W/2, INNER, BG); image.fillRect(0, W/2-INNER, W/2, W/2+INNER, BG); image.fillRect(W/2-THICK/2, W/2-INNER, W/2+THICK/2, W/2+INNER, FG); enum frames = 32; foreach (n; frames.iota.parallel) image .rotate(TAU * n / frames, BG) .copy .downscale!(W/16) .lum2pix(gammaRamp!(ushort, ubyte, ColorSpace.sRGB)) .toPNG .toFile("loading-%02d.png".format(n++)); }

यह कार्यक्रम 16-बिट चमक का उपयोग करके उच्च रिज़ॉल्यूशन में मूल छवि को खींचता है, जो फिर कमी के बाद 8-बिट sRGB छवि में कनवर्ट करता है। ज़ूम आउट करने से अलियासिंग से बचा जाता है, और सटीक आकार बदलने के लिए रंग रूपांतरण आवश्यक है।

यहाँ PNG फ्रेम को GIF में बदलने के बाद क्या हुआ है:

मैंडलब्रॉट सेट की एक ग्रे-सफेद छवि का प्रतिपादन:
कोड
```
 auto mandelbrot(int w, int h) { import std.algorithm, std.range; import ae.utils.graphics.view; return procedural!((x, y) { auto c = (2.0*x/w - 1.5) + (2.0*y/h - 1.0)*1i; return cast(ubyte)(1+ recurrence!((a, n) => c + a[n-1]^^2)(0+0i) .take(ubyte.max) .countUntil!(z => z.re^^2 + z.im^^2 > 4)); })(w, h); } void main() { import std.stdio; import ae.utils.graphics.image; mandelbrot(500, 500).toPNG().toFile("mandel.png"); } 
```
यह प्रोग्राम डी रेंज पर पुनरावृत्ति , टेक और काउंट यूटिलिटीज का उपयोग करता है, साथ ही साथ जटिल संख्याओं के लिए अंतर्निहित समर्थन, आपको एक एल्गोरिथ्म को संक्षिप्त रूप से लागू करने की अनुमति देता है जिसे लागू करने के लिए आमतौर पर बहुत सारी लाइनों की आवश्यकता होती है (हालांकि, अंतर्निहित जटिल संख्याएं अब std.complex के पक्ष में अप्रचलित होने की प्रक्रिया में हैं)।

काम का परिणाम:
चित्र

टेम्पलेट दृष्टिकोण प्रदर्शन में बड़े लाभ का वादा करता है। एक साधारण बेंचमार्क के रूप में, यह कार्यक्रम निर्देशिका में सभी छवियों के पैमाने को 25% तक कम करता है:

कोड

 import std.file; import std.path; import std.stdio; import ae.utils.graphics.color; import ae.utils.graphics.gamma; import ae.utils.graphics.image; void main() { alias BGR16 = Color!(ushort, "b", "g", "r"); auto gamma = GammaRamp!(ushort, ubyte)(2.2); foreach (de; dirEntries("input", "*.bmp", SpanMode.shallow)) { static Image!BGR scratch1; static Image!BGR16 scratch2, scratch3; de .read .parseBMP!BGR(scratch1) .parallel!(segment => segment .pix2lum(gamma) .copy(scratch2) .downscale!4(scratch3) .lum2pix(gamma) .copy )(4) .vjoin .toBMP .toFile(buildPath("output-d", de.baseName)); } }

मैंने बराबर ImageMagick कमांड के साथ काम करने के परिणाम की तुलना की:

 convert \ input/*.bmp \ -depth 16 \ -gamma 0.454545 \ -filter box \ -resize 25% \ -gamma 2.2 \ -depth 8 \ output-im/%02d.bmp

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

GitHub पर ग्राफिक्स पैकेज उपलब्ध है । इस लेख में उनके योगदान के लिए डेविड एल्सवर्थ का धन्यवाद।

डी में कार्यात्मक छवि प्रसंस्करण

More articles: