Soutěž: Machr na algoritmy - Oprava obrázku
Zadání
V tomto machrovi budete opravovat díry v obrázcích. A to tak, že načtete zadaný obrázek a všechny chybějící (průhledné) pixely nahradíte nějakou barvou tak, aby zapadaly do zbytku obrázku. Tyto průhledné pixely mohou být ve skupinkách, vyzkouším vaše výtvory i na obrázku, ve kterém bude chybět více než polovina, abych viděl, jak se program zachová. Pixely mohou samozřejmě chybět i na okraji obrázku.
Povolené jazyky: C, C++, C#, Visual Basic, Java, JavaScript, PHP
Pokud budete chtít použít jiný, zeptejte se v komentářích.
Hodnotit budu:
- Kód - max. 30 bodů
- Výsledné obrázky ("kvalitu" oprav) - max. 30 bodů
- Časovou náročnost algoritmu - max. 30 bodů
- Komentovanost kódu - max. 10 bodů
Výhra
Vítěz dostane placku Machr a ocenění do portfolia.
Výsledky
| Jméno | bodů | Řešení ( Stáhnout vše ) |
|---|---|---|
| Milan Suchomel | 70 | Stáhnout řešení |
| Martin Skalík | 55 | Stáhnout řešení |
| Michael Škrášek | 54 | Stáhnout řešení |
| Bohumír záviš | 38 | Stáhnout řešení |
| Tomáš Brůna | 34 | Stáhnout řešení |
Zajímaví machr, zapojuju se, už jen udělat rozumné míchání barev a je
hotovo 
Vojtěch Pospíchal:14.4.2016 17:46
Obrázek který si sem dal jako příklad, ale nemá vadné pixely průhledné a černé (0;0;0;0) Má je průhledné a bílé (0,255,255,255). Pokud to tedy není defekt stažení z Chromu na Windows.
Vojtěch Pospíchal:14.4.2016 19:42
Můžeš tedy prosím poskytnout nový obrázek, abych mohl upravit svoje
řešení?
I přesto, že mi GIMP ukazuje průhledné bílé .... moje aplikace mi
ukazuje průhledné černé a funguje 
tak hotovo, není to úplně nejlepší ale už jsem nepřišel na jiné
funkční řešení
Díky všem za účast, zde jsou výsledky:
Michael Škrášek - 54 bodů
Kód (20 bodů)
- pozn. kód
FillRectangle(new SolidBrush(new_color), x, y, 1, 1);vybarví čtverec 2 × 2, ne jeden pixel
- neustále volat Color.FromArgb(0, 0, 0, 0) je trochu zbytečné - lepší je tuto metodu zavolat jednou na začátku a barvu si uložit (nebo používat Color.Transparent, což je totéž)
- tělo metody compare_color (19 řádků) se dá zkrátit na jeden řádek
return c1.A == 0 && c1.R == 0 && c1.G == 0 && c1.B == 0;Kvalita oprav obrázků (10 bodů)
- zajímavé, ale poněkud divné
Časová náročnost algoritmu (15 bodů)
- GetPixel a SetPixel jsou velmi pomalé
- když procházíš obrázek, procházíš a kontroluješ i pixely, které už jsi zpracoval vlnou
Komentovanost kódu (9 bodů)
- lepší než komentáře vedle hlavičky metody jsou dokumentační komentáře - píší se pomocí tří lomítek (///) před metodu / třídu a jejich obsah se pak dokonce zobrazuje v našeptávači, ukázku můžeš vidět např. zde: https://msdn.microsoft.com/…04awywx.aspx
Poznámky
- při každém ukládání / načítání vytváříš nový SaveFileDialog / OpenFileDialog , lepší je vytvořit si je jednou při spuštění (ideálně je vytvořit jako komponenty formuláře - najdeš je v toolboxu)
- u obrázku s většími dírami se program zasekl a Visual Studio ho po minutě ukončilo s tím, že neodpovídá
Milan Suchomel - 75 bodů
Kód (25 bodů)
Kvalita oprav obrázků (30 bodů) -> placka
- není to vůbec špatné, u děr s průměrem do cca 32 pixelů většinou dosti přesvědčivé
Časová náročnost algoritmu (15 bodů)
- oprava obrázku trvá dosti dlouho - metody getRGB a setRGB jsou velmi pomalé
Komentovanost kódu (10 bodů)
- nejlépe komentovaný kód ze všech 5 výtvorů
Poznámky
- u větších děr obrázek neopraví kvůli přetečení zásobníku -> -5 bodů
- při každém ukládání / načítání vytváříš nový JFileChooser, lepší je vytvořit si při spuštění aplikace jen jeden (nebo jeden pro ukládání a druhý pro načítání), aby se uchovávala poslední složka, ze které se načítal (/kam se ukládal) obrázek
Tomáš Brůna - 34 bodů
Kód (15 bodů)
- ten try catch uvnitř cyklu je dosti zbytečný, šlo by to vyřešit krátkou podmínkou
- proč ten obrázek znovu načítáš do náhledu ze souboru, když ho máš v proměnné?
Kvalita oprav obrázků (0 bodů)
- tvoje metoda je možná přijatelná pro díry o velikosti 1 pixelu (i když i tam by asi byl lepší průměr okolních pixelů), pro cokoli většího vypadá katastrofálně
Časová náročnost algoritmu (20 bodů)
- jeden průchod pixely - rychleji to asi ani nejde
- GetPixel a SetPixel jsou velmi pomalé...
Komentovanost kódu (9 bodů)
- komentáře tam jsou, i když nebylo moc co komentovat
Poznámky
- sice se pokoušíš měnit okno podle velikosti obrázku, ale chová se to naprosto nesmyslně - s obrázkem 512 × 512 se mi okno nevešlo na obrazovku, ale obrázek byl úplně nahoře a polovina z něj byla mimo okno (šířka okna je podle kódu 4 * šířka obrázku... už tady mi něco nesedí)
- aplikace spadne, pokud je chybějící pixel u levého okraje -> -10 bodů
Martin Skalík - 55 bodů
Kód (10 bodů)
- velmi nepřehledný
- metodu opravObraz by bylo lepší rozdělit do několika kratších metod
- jednopísmenné názvy proměnných jsou velmi špatný zvyk (výjimkou jsou proměnné for cyklu), vůbec není poznat, k čemu která z nich je - např. tohle:
int r = 0, l = 0, u = 0, d = 0;jak z toho mám poznat, k čemu ty proměnné jsou... (po přečtení zbytku kódu jsem odhadl, že to asi bude right, left, up, down)
- několikrát se opakuje jedna (celkem dlouhá) část kódu
Kvalita oprav obrázků (10 bodů)
- zajímavé, ale ve výsledku to není nic moc, započítáváš jen horní a levé pixely
Časová náročnost algoritmu (30 bodů) -> placka
- jediný výtvor, který nepoužívá getPixel a setPixel
- nejrychlejší výtvor, obrázky zpracuje prakticky okamžitě
Komentovanost kódu (4 bodů)
- používáš TODO komentáře namísto klasických - TODO má označovat, co je třeba přidat / dokončit, ne vysvětlovat kód
- moc komentářů tam tedy nemáš
Poznámky
- nechápu, proč to ukládáš jako Bitmap.Config.RGB565 a ne jako Bitmap.Config.ARGB_8888
Bohumír záviš - 38 bodů
Kód (5 bodů)
- naprosto nepřehledný, formátovaný naprosto náhodně (kdyby to IDE neuměly naformátovat, nevyznám se v tom - nebylo ani poznat kde začíná metoda a kde končí)
Kvalita oprav obrázků (10 bodů)
- zajímavé, ale ve výsledku to není nic moc, započítáváš jen horní a levé pixely
- nechápu, k čemu mají být módy horizontální a vertikální, přepíší prakticky celý obrázek na hromadu čar
Časová náročnost algoritmu (20 bodů)
- metody getRGB a setRGB jsou velmi pomalé, jinak to není špatné
Komentovanost kódu (3 bodů)
- někde jsou, někde ne a úplně náhodou chybí zrovna u nepřehledné části...
Poznámky
- nauč se prosím alespoň trochu českou gramatiku, číst ty tvoje návody byla noční můra...
- aplikace podivným způsobem vypisuje některé barvy v obrázku (0sd0r0g0b0a0r0g0b0a0dsdfd1335580sd-8569611... apod.) nechápu účel
- při každém ukládání / načítání vytváříš nový FileChooser, lepší je vytvořit si při spuštění aplikace jen jeden (nebo jeden pro ukládání a druhý pro načítání), aby se uchovávala poslední složka, ze které se načítal (/kam se ukládal) obrázek
Placku tedy získává Milan Suchomel, polemes Gratuluji
Ještě pár obecných poznámek:
- metody typu GetPixel a GetPixel jsou velmi pomalé, mnohem rychlejší je použít něco jako getPixels na Androidu, LockBits v C# apod.
- používejte dokumentační komentáře - viz. např.
http://www.tutorialspoint.com/…entation.htm
https://msdn.microsoft.com/…2s063f7.aspx
- dávejte si pozor na neošetřené výjimky a výtvory pořádně otestujte podle zadání
Níže se můžete podívat, jak si jednotlivé výtvory poradily s velkými dírami v obrázku
Michael Škrášek:24.4.2016 22:13
U těch kódů jsem si to fakt neuvědomil 
, a škoda, že jsem LockBits
neznal dřív ...
Komentáře pro sebe fakt nevedu, jen jsem popsal kód
Prostě jsem si měl kód zkontrolovat , ale s tim SaveFileDialog /
OpenFileDialog nevidim důvod v čem by to bylo lepší. Jinak gratulace
vítězům.
Přetečení jsem si byl vědom Jen jsem nevěděl jak to opravit Díky moc za skvělého
machra.
Martin Skalík, díky , taky
gratuluji k úspěšnému Machrovi.
Zobrazeno 30 zpráv z 30.