Zagadnieniem do którego dotarłem w ramach moich eksploracji EmguCV jest rysowanie. 
Podstawowym narzędziem rysującym jest metoda Draw. Metoda ta ma 11 przeciążeń, które osobiście podzieliłbym na 3 grupy: Rysowanie kształtów, Wyświetlanie tekstu, Rysowanie sekwencji.

Rysowanie kształtów:

Metoda Draw posiada 7 dedykowanych metod przeznaczonych do rysowania podstawowych kształtów geometrycznych. Metody te jako pierwszy parametr przyjmują strukturę opisującą kształt oraz 2 dodatkowe parametry: kolor lini, oraz jej grubość. Przy czym grubość 0 lub mniej oznacza wypełnienie kształtu kolorem.

	var rect = new System.Drawing.Rectangle(x, y, width, height);
	image.Draw(rect, color, thickness);

I w zasadzie jedyne co mogę stwierdzić to fakt, że działa.

Przypadkiem w którym nie jest już tak różowo jest koło/okrąg ponieważ to coś 

co powstaje w wyniku wywołania tego kodu:

	CircleF c = new CircleF(new PointF(centerX, centerY), radius);
	image.Draw(c, color, thickness);

ciężko nazwać okręgiem. Przydałoby się tutaj trochę antialiasingu, niestety klasa Image nie posiada żadnej metody ani właściwości gwarantującej taką funkcjonalność, a więc trzeba kombinować.
Pierwszym obejściem jakie znalazłem było wykorzystanie właściwości Bitmap która jest typu System.Drawing.Bitmap. Właściwość ta dla kolorów Brg, Brga oraz Gray zwraca wewnętrzną Bitmapę synchronizowaną dwustronnie z zawartością obrazu, dla pozostałych sposobów opisu koloru zwracana jest nowa/niesynchronizowana Bitmapa. Podejrzewam że ta właśnie synchronizacja jest przyczyną przegranej Emgu z metodą BitmapData w teście wydajności.  

Mając obiekt typu Bitmap możemy wykorzystać całe bogactwo biblioteki GDI+ w tym klasę Graphics. Narysowanie okręgu z antialiasingiem można wykonać takim kodem:

	using (var graphics = Graphics.FromImage(image.Bitmap))
	{
		graphics.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias;
		using (var pen = new Pen(color, thickness))
		{
			graphics.DrawEllipse(pen, x, y, diameter, diameter);
		}
	}

a efekt jego działania prezentuje się następująco

Drugim rozwiązaniem jakie udało mi się znaleźć jest użycie klasy cvInvoke. O ile klasa Image jest dobrze przemyślanym proxy do wielu funkcjonalności z OpenCV tak klasa cvInvoke ma na celu zapewnić dostęp do jak największej grupy metod, niekoniecznie trzymając się najlepszych wzorców. Większość (jak nie wszystkie) z metod tej klasy korzysta bezpośrednio z PInvoke, jest pośród nich także metoda cvImage.

	var center = new Point(centerX, centerY);
	int radius = dlg.Radius;
	var color = new Bgr(); // Jakiś kolor
	var lineType = Emgu.CV.CvEnum.LINE_TYPE.CV_AA;
	
	CvInvoke.cvCircle(image.Ptr, center, radius, color.MCvScalar, thickness, lineType, 0);

Metoda jako pierwszy parametr pobiera wskaźnik, można go znaleźć w klasie Image<,> pod właściwością Ptr, drugim parametrem są współrzędne środka okręgu, a kolejnym jego promień.
Czwartym parametrem jest kolor, nie jest to jednak ani liczba opisująca kolor, ani obiekt z grupy kolorów tylko coś nazwane MCvScalar, jak widać w powyższym listingu wartość tą można uzyskać z koloru przy pomocy właściwości MCvScalar. 
Piątym parametrem jest grubość linii, interpretowana tak samo jak w metodzie Draw, a szóstym jej typ. Są 3 typy linii 4-połączeniowa, 8-połączeniowa (używana przez metodę Draw) oraz AntiAliasing. Wyniki metody cvCircle z różną wartością tego parametru (w powiększeniu) przedstawia grafika poniżej.

Organoleptycznie stwierdzam, w tym miejscu błąd w OpenCV ponieważ przy wybraniu opcji 4-połączeniowej wyraźnie widać połączenia po ukosie, których nie powinno być. 
Ostatnim parametrem jest przesunięcie służące do skalowania wynikowego okręgu jeżeli 1 piksel ma być równy 1 jednostce we współrzędnych środka i długości promienia należy ustawić ten parametr na 0.

Rysowanie napisów

Jak każda biblioteka graficzna EmguCV umożliwia umieszczanie napisów na grafice. Sama klasa Image posiada przeciążenie metody Draw która jako parametry pobiera:

• napis który ma zostać narysowany
• opis czcionki – struktura zawierająca dane o czcionce
• pozycję tekstu
• kolor

Rysowanie sekwencji

Sekwencja (Typ Seq<T>) jest kolekcją pozwalającym przechowywać elementy w sposób uporządkowany. Elementy można dodawać na końcu (Metoda Push) albo na początku (PushFront) sekwencji. Sekwencja wymaga wskazania Magazynu (klasa MemStorage).

	using (var memStor = new MemStorage())
	{
		var seq = new Seq(memStor);
		var rand = new Random();
		for (int i = 0; i < 100; i++)
		{
			var point = new Point(rand.Next(100), rand.Next(100));
			seq.Push(point);
		}
	}

Metoda Draw posiada 3 metody do rysowania sekwencji punktów. W najprostrzym przypadku przyjmuje ona 3 parametry: wspomnianą sekwencję oraz grubość i kolor linii. Dwa ostatnie parametry są interpretowane analogicznie jak we wczesniejszych przeciążeniach. Co ciekawe przekazanie obiektu Seq<Point> wypełnionymi punktami sprawi, że grafika nie ulegnie zmianie (WTF?).
Po wczytaniu się w dokumentację znalazłem przyczynę. Sekwencja sama w sobie stanowi tylko abstrakcję dla innych implementacji. Jednak jako taka nie jest abstrakcyjna można ją tworzyć, można do niej dodawać elementy, jednak nie da się jej narysować. Kolejną ciekawostką jest fakt iż jedyną klasą dziedziczącą po sekwencji jest Contour<T>, a próba dziedziczenia i nadpisania jedynej wirtualnej metody InContour nic nie zmienia (podczas rysowania ta metoda nie jest nawet wywoływana). Na szczęście  użycie klasy Contour<T> daje efekt w postaci narysowania wielokąta. Którego wierzchołkami są punkty sekwencji. 

DrawPolyline

Jak sama nazwa wskazuje służy do rysowania wielu linii, czyli łamanej. Posiada 2 przeciążenia. Pierwsze z nich pobiera jako parametr tablicę punktów, flagę określającą czy domknąć łamaną (czyli zrobić z niej wielokąt), oraz kolor i grubość linii interpretowane tak samo jak przez metodę Draw. Z punktu widzenia programisty można tą metodę traktować jak uproszczoną wersję rysowania konturu.
Drugie przeciążenie różni się pierwszym parametrem jako który przyjmuje tablicę tablic punktów  i służy do rysowania wielu łamanych.

FillConvexPolygon

Metoda pozwala wypełnić kolorem wielokąt wypukły nie należy jednak używać tej metody do rysowania wielokątów wklęsłych albo figur z przecinającymi się krawędziami, metoda ta prawdopodobnie wykorzystuje algorytm skanowania linii (o ile dobrze pamiętam nazwę) wydajny ale ograniczony funkcjonalnie. Moim zdaniem metoda ta ma wąskie zastosowanie.

Przykładowe listingi prezentujące wykorzystanie metod jak  zawsze znajdują się w projekcie EmguExperiments

Pomimo bardzo bogatego zestawu metod klasy Image nie robi ona wszystkiego. Więc istnieje konieczność operacji bezpośrednio na punktach składających się na obraz. EmguCV oferuje dwie możliwości:

var pixel = image[row, column];
pixel.B = value;
image[row, column] = pixel;

byte bluePartOfPixel = image.Data[row, column, 0];
image.Data[row, column, 0] = (byte)78;

Najwyższa pora sprawdzić wydajność Emgu CV. Postanowiłem zaimplementować metodę generującą negatyw zdjęcia na kilka sposobów:

• GetPixel/SetPixel – metoda z góry skazana na przegraną, jej jedynymi zaletami są: nie zła czytelność kodu, oraz fakt że dostępna w .Net z pudełka
• BitmapData – wydajna metoda, główny konkurent Emgu CV pod tym względem, oprócz wydajności posiada same wady: wymaga używania sekcji unsafe, jest mało czytelna i błędogenna. Ze względu na ostatnią cechę zamiast się bawić w ręczną implementację wykorzystałem gotowca ze Stacka
• ColorMatrix – stare dobre GDI+ umożliwia dokonywania przekształceń matrycowych zarówno na orientacji pikseli jak i ich kolorów (potrzebna jest do tego klasa Graphics) implementację znalazłem pod tym samym linkiem, co w przypadku BitmapData
• Pixel Access pierwsza wspomniana w tym poście metoda dostępów do pikseli w EmguCV
• Pixel Access Fast – druga metoda
• Metoda Not – metoda w klasie Image dedykowana generowaniu negatywu obrazu

Testy wykonywałem na swoim laptopie (8 GB RAM, i5, dwie karty grafiki NVidia NVS 5400M oraz jakiś Intel). Test podzieliłem na 2 kroki Otwarcie pliku – polegające na wywołaniu konstruktora klasy z odpowiednim parametrem, oraz Wygenerowanie negatywu – właściwa robota. Odrzucałem wynik pierwszego uruchomienia Testu (podczas niego mogą wykonywać się operacje które nie występują przy kolejnych uruchomieniach). Test wykonałem tylko na trzech plikach, oraz uruchamiając program na różnych kartach grafiki (mam możliwość wskazania która karta powinna być wykorzystana).
Metoda badań nie jest może idealna jednak mimo to daje całkiem ciekawe wyniki:

Obraz 3702×2304 jpeg 916KB

NVidia NVS 5400M

Intel(R) HD Graphics 4000

Obraz 4320×3240 jpeg 3,21 MB

NVidia NVS 5400M

Intel(R) HD Graphics 4000

Obraz 5184×3456 jpeg 4,87 MB

NVidia NVS 5400M

Intel(R) HD Graphics 4000

Zgodnie z moimi oczekiwaniami BitmapData pokonał inne metody GDI+. Wywołanie dedykowanej metody Not detronizuje zabawę bezpośrednio na Pikselach, jak dla mnie jest to jednoznaczne ze stwierdzeniem "Jak coś jest już napisane nie pisz tego sam".
Bardzo interesujący natomiast jest fakt iż metoda BitmapData jest dwukrotnie szybsza od dedykowanej metody z Emgu CV. Jestem jednak daleki od stwierdzenia iż mój test udowadnia słabość tej biblioteki. Wskazany wynik może mieć wiele przyczyn, metoda Not może być na tyle prosta że Emgu CV nie ma co optymalizować (na co wskazywałby brak istotnych różnic przy uruchamianiu programu na różnych kartach grafiki), jednak ambitniejszych przekształceń po prostu nie chce mi się implementować "z palca" więc nie dokonam takiego porównania.
Warto też zwrócić uwagę na fakt iż przekształcenie matrycowe także nie wypadło źle w zestawieniu, a jego czytelność jest przyzwoita (co nie zmienia faktu iż kod pisany z jego wykorzystaniem zawsze powinien być komentowany).
Ostatnim elementem układanki jest czas pobrania danych z dysku. W przypadku Emgu CV odczytanie danych stanowi dużą część pracochłonności całej operacji. W moim teście popełniłem jeden błąd i większe zdjęcia wczytywałem z dysku SSD, a małe z talerzowego więc nie może on być podstawą wnioskowania o skalowalności tego rozwiązania.
Całość kodu testu znajduje się pod adresem: https://github.com/szogun1987/EmguExperriments/tree/master/EmguExperiments/Performance

W trzeciej części serii chciałbym ukazać łatwość z jaką przy pomocy EmguCV można dokonywać przekształceń obrazu. W tym poście skoncentruję się na 3 przekształceniach: Odbicie lustrzane (Flip), Obrocie, Skalowaniu.
Jednak zanim przejdę do właściwego tematu chciałbym wspomnieć o ręcznym zarządzaniu zasobami. Klasa Image<TColor, TDepth> implementuje interfejs IDisposable co wskazuje na konieczność zwalniania zasobów gdy tylko obiekt przestaje nam być potrzebny. Jednak dokumentacja Emgu mówi o braku takiej konieczności (prawdopodobnie jest to związane z faktem iż Emgu poprawnie implementuje ten interfejs a sama klasa posiada finalizer zwalniający zasoby gdy przyjdzie odpowiednia pora. Ja osobiście domyślnie wywołuję Dispose (czy to jawnie czy to przez konstrukcję using), chyba że mam wątpliwości czy zwalniany obiekt nie jest gdzieś jeszcze używany, dlatego w swoim projekciku raczej nie będę się stosował do zaleceń dostawcy.
 
Aby zrobić odbicie lustrzane obrazu należy na nim wywołać metodę Flip (albo _Flip), metoda ta jako parametr pobiera wartość FLIP.HORIZONTAL albo FLIP.VERTICAL gdzie FLIP jest Enum'em.
Przy okazji wrócę do tematu metod "podreślnikowych". Kilka moich eksperymentów potwierdziło że ich używanie zużywa mniej pamięci operacyjnej niż używanie ich odpowiedników bez podkreślnika na początku. Drugim spostrzeżeniem jakiego przy ich okazji dokonałem to fakt iż kontrolka ImageBox nie obserwuje zmian w obrazie i po wywołaniu metody z podkreślnikiem należy albo podstawić właściwość Image kontrolki ponownie albo wywołać na niej Invalidate. 
Wadą API Emgu CV jaką widać na przykładzie metod podkreślnikowych i ww. enuma jest nie trzymanie się konwencji nazewniczych przyjętych w C#.
Jednak odbicie lustrzane nie jest niczym nadzwyczajnym (nawet klasa System.Drawing.Bitmap posiada metodę RotateFlip), dlatego przechodzę do czegoś co w Windows Forms jest gorzej wspierane, a więc obrót. W Emgu CV dokonuje się go metodą Rotate (jakie zaskakujące), metoda ta nie posiada swojego "podkreślnikowego" odpowiednika prawdopodobnie ze względu na fakt iż zmienia ona rozmiar obrazu. Metoda ta posiada 3 przeciążenia w najprostrzym przypadku parametrami tej metody jest kąt obrotu w stopniach oraz kolor jakim zostaną wypełnione "dziury" w obrazie powstałe w wyniku niedopasowania, dodatkowo można zdefiniować czy wynikowy obraz ma być obcięty do oryginalnych rozmiarów (domyślnie obraz jest obcięty), środek obrotu – punkt niestety nie udało mi się ustalić sposobu jego interpretacji, a w dokumentacji którą znalazłem brakowało opisu tego przeciążenia metody Rotate. Ostatnim parametrem jest sposób interpolacji – pomijając obroty o wielokrotności 90 stopni jasnym jest że po obrocie piksele oryginalnego obrazu nie trafią idealnie w piksele obrazu wynikowego, więc kolory pikseli wynikowych należy obliczyć na podstawie kolorów pikseli które wylądowały w pobliżu. W zastosowaniach profesjonalnych może parametr ten może mieć znaczenie, jednak organoleptycznie nie udało mi się dostrzec różnic pomiędzy wynikami zastosowanymi z różnymi wynikami tego parametru.
Skalowanie obrazu wykonuje się przy pomocy metody Resize. Posiada ona 3 przeciążenia, wszystkie 3 mają parametr interpolationType interpretowany analogicznie jak taki sam parametr w obrocie. Najprostrze przeciążenie przyjmuje oprócz tego parametru także skalę. Drugie przeciążenie zamiast skali przyjmuje docelową szerokość i wysokość obrazu – przy czym obraz może się skalować inaczej wzdłóż osi X, a inaczej wzdłóż osi Y. Ostatnie przeciążenie do drugiego przeciążenia dodaje parametr preserveScale ustawienie go na true sprawi że obraz zostanie zeskalowany tak aby się zmieścił w docelowym prostokącie, nic z obrazu nie zostało obcięte oraz bez naruszenia proporcji, to przeciążenie świetnie się nadaje do generowania miniaturek (ponieważ takie warunki muszą one zazwyczaj spełnić.
Na koniec dodam że moim celem nie jest opisywanie na łamach tego bloga wszystkich elementów EmguCV – nie chcę powielać dokumentacji.
Przykładowy kod wykorzystujący ww metody znajduje się Tutaj 

W poprzednim wpisie wspomniałem o metodzie ToBitmap klasy Image pozwalającej na konwersję klasy Image na klasę System.Drawing.Bitmap, co pozwala na używanie wyniku obróbki obrazu w kontrolkach Windows Forms. Jednak taka konwersja nie należy do najszybszych operacji, po za tym powoduje zwiększenie zużycia pamięci, ponieważ obraz jest przechowywany w pamięci w dwóch postaciach. Ponieważ najczęstszym zastosowaniem obrazów jest ich wyświetlanie do EmguCV została dodana kontrolka ImageBox.

Jest ona pod pewnymi względami podobna do PictureBox z WindowsForms, podstawową różnicą jest fakt iż jako źródła używa klasy IImage (po którym dziedziczy Image<TColor, TDepth>) , a nie Bitmap. Kontrolka ta dodaje też kilka funkcjonalności np. skalowanie obrazka myszką, obsługę rolki itp. jednak mam nadzieję że da się to wyłączyć Edit.

Aby dodać kontrolkę ImageBox do projektu należy dodać referencję do EmguCV (operację tą opisałem w poprzednim poście) i to wystarczy aby używać tej kontrolki z poziomu kodu. Jednak aby ww. kontrolka pojawiła się także w toolboxie należy się jeszcze trochę wysilić.

Po kliknięciu prawym przyciskiem myszy w wolny obszar na toolboxie należy wybrać“Add Tab” ja swoją zakładkę nazwałem “EmguControls”:

Następnie należy kliknąć prawym przyciskiem myszy w nową zakładkę wybrać opcję “Choose Items”.

Na wyświetlonym oknie można należy wybrać przycisk “Browse”, wskazać ścieżkę do EmguCV.UI.dll i zatwierdzamy obydwa formularze.

Oprócz kontrolki ImageBox zostają też dodane też kontrolki HistogramBox, MatrixBox, PanAndZoomPictureBox ich eksploracją zajmę się w późniejszym czasie (o ile mi starczy chęci).

Na koniec dodam iż eksplorację EmguCV będę dodatkowo dokumentował na GitHubie w projekcie https://github.com/szogun1987/EmguExperriments

W projekcie brakuje bibliotek OpenCV ze względu na ich rozmiar, należy je sobie samemu podlinkować/skopiować.

Ponieważ projekt ma za zadanie ukazać możliwości API w jak najprostrzy sposób większość kodu będzie się znajdowała w EventHandlerach (nie znam dobrego polskiego odpowiednika tego słowa), a sam kod będzie pełen powtórzeń. Więc nie uznaję krytyki tych aspektów. Natomiast chętnie zapoznam się z innymi uwagami.

Edit:

Właściwością kontrolki determinującą zachowanie kontrolki jest FunctionalMode. Właściwość ta może przyjmować 4 wartości:

• Minimum – ogranicza się do wyświetlenia obrazka ta na której mi zależy.
• RightClickMenu – wyświetla menu pozwalające na dokonywanie przekształceń na obrazie, ponieważ Menu pokrywa większość funkcjonalności projektu EmguExperiments wyłącze je w swoim projekcie
• PanAndZoom – obsługa gestów myszy
• Everything – jak sama nazwa wskazuje wszystkie funkcjonalności – wartość domyślna dla właściwości FunctionalMode