Co užitečného naprogramovat? (diskuse)

[Fluttershy, yay!]

Znáš

• CodeKata,
• TRY2HACK,
• Project Euler,
• OpenHatch?

[Begleiter]

Díky za odkazy. Pročtu si to.

[Kvakor]

Když by se to udělalo jako frontend pro badblocks, tak by stačilo jen udělat GUI na výběr zařízení plus vykreselní povrchu disku jako bitmapy s barevně odlišenými čtverečky pro bloky (resp. skupinami bloků). Ušetřila by se tím nízkoúrovňová část s diskovým zařízením, s přístupovými právy (jen badblocks musí mít práva na přístup k disku, GUI už ne), kód by byl přenositelnější a navíc by to bylo více ve shodě s unixovou filosofií.

Na druhou stranu, pravděpodobně by mnohem více kódu zabíralo to GUI než zbytek, tj. kreslení špatných bloků do bitmapy a komunikace s badblocks skrz roury via popen() ... a mimo toho, aplikace plně dle unixové filosofie by měla spíš načíst soubor se špatnými bloky z badblocks a dle parametrů to vyplivnout jako bitmapu v PPM

[Kvakor]

Grrr, tohle mělo jít o komentář vedle (ten o HD Tune a záložce Error Scan).

[lertimir]

Jenže hlavní síla HD Tune je v změření rychlosti přenosu a seek time na různých cylindrech. A to se prostě musí na tom disku nizkoúrovňovně naměřit.

[Begleiter]

Díky.

[nway]

Za mě bych uvítal něco jako HD Tune v záložce Error Scan. Hned je vidět poloha vadných sektorů. Ale nemám představu jak moc je to náročné pro začátek. Díky.

[Begleiter]

Díky za tip.

[Magog]

Mě by se třeba líbil program pro losování švýcarským systémem. Bohužel nic rozumného pro linux a ideálně open-source neexistuje. A vlastně i closed-source aplikace pro windows většinou za moc nestojí.

Pokud má jít o čisté C, tak možná by mohlo jít o jakési výpočetní jádro bez grafiky. Program by umožňoval, aby se k němu někdo připojil (např. po TCP) a dával mu příkazy a cucal si z něj data a s tím si dělal nějaké svoje věci.

[Ivorne]

Takové GTK je pro dělání GUI v C jako stvořené. ...moment, ono je pro gui v C skutečně stvořené!

[Begleiter]

Díky za tip.

[Jindřich Makovička]

Tohle dává smysl i jako webová aplikace. Kamarád kdysi napsal cosi obdobného pro karate.

[Tomáš]

Neber si to zle, ale někdy je lepší neprogramovat. V práci vídám (v lepším případě jenon vídám) cizí kód a něco z toho jsou takové prasečiny, že by bylo lepší, aby dotyčný člověk raděj neprogramoval. Nejdřív si zkus, jestli vůbec umíš algoritmicky myslet, napiš něco menšího, zkus si pročíst zdrojáky programů, které tě zajímají. Až si budeš myslet, že něco umíš, tak se nauč psát tak, aby ten kód byl čitelný, pochopitelný a udržovatelný.

[lucorp]

tym ze bude iba citat kod druhych bez toho aby skusal nieco pisat sam sa ale skutocne nikto dobre programovat nenaucil a nenauci.

[Begleiter]

Ano. Díky.

[Tomáš]

Ale to čtení je rozhodně důležité. Úplní začátečníci jistě ocení nějaký tutoriál, kde se dozví úplně základní informace. Pokročilejší by zase měli sáhnout po literatuře o návrhových vzorech (design patterns) a přeskočit tak několik stádií ve vývoji programátora-samouka.

[Fluttershy, yay!]

To mi připomíná jeden chat...

What are commonly used design patterns in Python?

Forget about it and enjoy Python without patterns as long as you can. I heard the Java crowd's coming.

[FrostyX]

To už jsem taky někde viděl, ale kde to bylo .. ?

[Fluttershy, yay!]

Na Rootu psal někdo nedávno něco podobného, ale já na to narazil někde jinde...

[lucorp]

o tom ze je citanie kodu druhych dolezite nikto nepochybuje, takisto ako nespochybnujem neodskriepitelnu dolezitost tutorialov a odbornej literatury. Ale je blbost zacat sa ucit programovat iba z tychto zdrojov, bez toho aby si clovek "osahal" programovanie cez pisanie vlastnych veci na ktorych sa nauci najlepsie co ako a preco funguje (nevraviac o skusenostiach do debuggovania pri zlozitejsich projektoch).

IMHO je dolezitejsia znalost "spravim to tak preto lebo ked to spravim inym sposobom tak sa stane XYZ", nez znalost typu "spravim to tak lebo to pisali v knihe XYZ"

[kralyk z abclinuxu]

IMHO je dolezitejsia znalost "spravim to tak preto lebo ked to spravim inym sposobom tak sa stane XYZ", nez znalost typu "spravim to tak lebo to pisali v knihe XYZ"

+1. Není nic horšího než bezhlavé papouškování cool patternů, setkal jsem se s tím v pár projektech a to je dost hrůza...

[Begleiter]

Díky moc za připomínku. To, aby mnou vytvořený zdrojový kód byl čitelný, pochopitelný a udržovatelný je mým cílem. I za cenu, že mi naprogramování vysněné aplikace bude trvat roky.

[Tomáš]

Záleží na tom, co je tvoje vysněná aplikace. Pokud jde o něco menšího, tak záleží na tom, kolik tomu můžeš věnovat času. Větší věci se stejně asi nedají naprogramovat v jednom člověku.

Trochu problém je, že věci spojené s udržovatelností a čitelností kódu se ve škole neučí. Takže pokud nemáš štěstí, tak se to naučíš jenom metodou opakovaných pádů na hubu. Pokud máš štěstí, tak programuješ pod někým, kdo už si tu hubu pořádně nabil. Nějaké zásady najdeš na internetu, což by mělo pokrýt základní pravidla, každý tým se v detailech liší od ostatních.

[Begleiter]

Díky.

[podlesh]

Hlavně je důležité mít na paměti, že je velmi záleží kolik lidí na programu dělá a odkud se bere zadání. Pokud program vymyslí a napíše jeden člověk, tak v podstatě není co řešit (tedy z hlediska "sw engineering", samozřejmě zůstává to "skutečné programování" jako jsou algoritmy apod). Teprve když začně být lidí víc, navíc se začnou střídat, a zadání přichází odjinud, to pak zcela mění situaci.

To měj hlavně na paměti až tady někdo přijde a začne povídat o pseudoprogramátorech a cvičených opicích.

[Jendа]

Pick one (průběžně doplňuji).

[kralyk z abclinuxu]

Exporting steganographic bits (least significant bits or noise) from WAVs and RAW photos as a block device. Linux nbd seems pretty simple.

Příbuznou problematikou se zabývám... Je velmi obtížné tohle udělat tak, aby to bylo bezpečné [1][2] (resp. lépe řečeno, aby to nebylo úplně okaté). V zásadě v současné době je toto ve fázi výzkumu, stav vývoje není zatím tak daleko, aby to šlo 'prostě naimplementovat'. (Toto je důvod, proč jsem nebyl schopen nějak úspěšně pokračovat ve vývoji steganografické knihovny představené někdy před rokem...)

[pc2005]

BadBIOS is a hoax. Can be a similar malware really build?

Já věděl, že to je pobídnutí k vytvoření nové třídy virů!!

[Josef Kufner]

Neprogramuj nic nového, ale opravuj chyby ve velkých projektech. Jen tím, že nějakou drobnost najdeš a opravíš, se naučíš orientovat v cizím kódu, poučíš se, jak to či ono řešili ostatní a bude to užitečné i pro ostatní. Otevři bugzillu svého oblíbeného programu a začni.

[Rezza]

+1.

[xxxxxxxxxxx]

Je potřeba nutně naprogranmovat zobrazovat/knihovnu pro formáty *.dwg a *.iges... Protože na světě nic takového neexistuje pod svobodnou licencí.

[Grunt]

A nebo je potřeba vyvinout nový digitální instrukčně orientovaný (otevřený) výměnný formát a tím naprosto rozbít zažité paradigmata v průmyslovém světě a neskutečně na tom zbohatnout… taky možnost, ne?

[xxxxxxxxxxx]

Hmm to mě zajímá! Ne že bych nechtěl svuj formát! Držím se přizemi. Ale co to znamená instrukčně orientovaný?

[pavlix]

Asi něco jako postscript?

[xxxxxxxxxxx]

Což znamená?

[pavlix]

Já jenom hádám, takže nebudu pokračovat ve vysvětlování, kdybych byl náhodou úplně mimo.

[pavlix]

Vůbec jsi nenapsal, co tě zajímá. V takovém případě nelze smysluplně poradit.

[Begleiter]

Zajímám se hlavně o šachy, ale není mi cizí třeba matematika.

[pavlix]

K tomu ti já osobně nic neporadím, ale aspoň to tu máš napsané ;).

[Begleiter]

Jinak děkuju za nakopnutí. Měl jsem v hlavě zmatek.

[pc2005]

Nejlépe, aby se to týkalo šachů (logických her) nebo matematiky.

Hodil by se mi soft v céčku na hledání izomorfismu větších grafů .

[Fluttershy, yay!]

lol

[Radek Miček]

Co třeba nauty nebo bliss?

[kralyk z abclinuxu]

Já bych zas potřeboval program na letní túry - nikdy nevim, jaký věci dát do báglu, aby se to tam vešlo, ale aby to byly pokud možno ty nejužitečnější. Navíc před túrou není čas, takže by to měl zvládat v polynomiálním čase.

[Grunt]

Na co bágl? Máš tahat znalosti, ne věci. Znalosti na rozdíl od báglu nic neváží. BTW: Kde túruješ?

[kralyk z abclinuxu]

Je fakt, že tenhle přístup bude asi snažší než pokoušet se řešit Knapsack Problem v polynomiálním čase Zajímavej odkaz btw. Zkoušel jsi to v praxi?

[Grunt]

Přílohy:

• 01.jpg (115668 bytů)
• 26052013256.jpg (585804 bytů)
• 26052013258.jpg (739317 bytů)
• 06.jpg (140879 bytů)
• IMG453.jpg (149631 bytů)
• IMG475.jpg (181495 bytů)

Je fakt, že tenhle přístup bude asi snažší než pokoušet se řešit Knapsack Problem v polynomiálním čase

To už by aproximovanýma metodama jít řešit mělo, ne? Nebo nevím jak ty, ale já cspsol (jednorozměrná verze problému) den co den používám.

Zkoušel jsi to v praxi?

No, spíš se na to hraju. Žeru kořínky vytažené ze dna rybníku, hraju se s lukem, testuju opékače, stavím bunkry a tak… nic vážného.

[Grunt]

cspsol

A proč o tom mluvim:

CG involves solving a sub-problem (which in this case is a integer knapsack problem).

[Dreit]

Ty příbytky se mi líbí, připomíná mi to jak jsme si měli postavit příbytek v lese na skautském táboře (měl vydržet alespoň dvě noci). Spolužák postavil velkou místnost, kam by se vešla celá skupina (4 stěny a plochá střecha), já jen přivázal větev do výšky mezi dva stromy a na ní naházel další větve jako střechu   On se s tím trápil několik hodin a dělal to pečlivě, já to spatlal za chvilku, předimenzoval střechu a ve volném čase kopal mělký příkop aby mi nenatekla voda dovnitř. Nikdo nečekal že to budu právě já, kdo se probudí ráno v suchu. Můj přístřešek měl ale jednu nevýhodu - sotva se tam vešel jeden člověk a do spacáku se musel soukat jako housenka

[Grunt]

Přílohy:

• IMG479.jpg (430058 bytů)
• IMG480.jpg (557781 bytů)

Jde o klasický wood shelter. Samozřejmě ani jeden z nich jsem nestavěl já, jen jsem na ně náhodně narazil (jakžto důkaz, že se v mém okolí pohybují ještě větší blázni než jsem já). Ten druhý mě zaujal, že ač očividně neměl žádnou výztužnou rámovou konstrukci, tak se s ním někdo pořádně vyhrál (větve pečlivě nařezané a zakleštěné do sebe) a zas tak málo místa jak říkáš v něm nebylo (viz fotky, dva lidi by se ta vyspali). Naházené to na hromadu nebylo, i když to tak na první pohled mohlo působit.

[Jendа]

Hezké.

[:)]

ťahať sebou panvicu, to si tovno môžeš do hatyžáka strčiť činku

[Jendа]

JJ, nejlíp se smaží na bočnici od case z počítače. Musí se ale opálit ten lak.

[Grunt]

Tak netvrdím, že se mi co se ULBP podařilo vyřešit vše, ale nástřel by taky nějaký byl.

[kralyk z abclinuxu]

Moderní pánve takřka nic nevážej... Případně existuje i víčko vod ešusu, že

[Jendа]

Grunt zredukuje počet nutných položek na 6 a vyřeší to bruteforce na své 486.

[Grunt]

Na 6 položek 486 nepotřebuju. To už si v mošně nějak přeskládám i bez té 486-ky.

[pc2005]

Stačí jen ručník ne?

[Tomáš]

A až to dodělá, tak může jen tak mimochodem přidat program, který s tím balením pomůže: nejdřív si nacpeš do všech věci RFID tagy a pak budeš chodit se čtečkou a pípat a pípat jako Sheldon.

[Jendа]

A současně by to mohlo spočítat výhodnou cestu té túry. Viděl bych to tak, že mu zadám waypointy a vzdálenosti mezi nimi, a on mi napíše, jakou nejkratší cestou je projít.

[Tomáš]

No tak doufej, že to nebude brát se stejnou váhou vzdálenosti ve vertikálním a horizotálním směru. To by teprve na horách byla legrace, když uvážím kolik lidí jezdí slepě podle navigace.

[Grunt]

Ty si nikdy na žádném vandru nebyl, že?

[Kvakor]

Na to by teoreticky stačil Dijkstrův algoritmus, ale v praxi je to k ničemu, protože nebude dost dat na přesné ohodnocení hran. Vzdálenot mezi waypointy přes souřadnice (viz tento vzorec) je nedostatečná i pokud se k tomu přidá zeměpisná výška (i když hrubý odhad říká, že metr do výsky je jako osm metrů do délky). Dokonce i když se přidá výškový profil, tak stále není zohledněný stav terénu, tj. jestli je tam les (a ten může být cokoliv od "parku" až po neprostupný prales), louka, zorané pole, keře (jako bonus ostružinové) nebo třeba mlází či bažina, nemluvě o rozličných překážkách (potoky, strouhy, ploty). A taky dost záleží na počasí nebo denní době, některým terénem se nedá chodit v noci nebo je za mokra neschůdný. Nakonec by z toho vylezlo něco podobného jako ohodnocování postupu u tahových strategií (s pravidly typu "Elfové mají bonus +1 pří průchodu lesem") a muselo by se do toho nacpat tolik dat, že by se tím strávilo víc času než vlastním výletem

[Grunt]

Teď vážně nevím co si mám myslet.

[Grunt]

Jo počkej a řešíš vůbec rozměry věcí (jak to sakra měříš?) nebo jen váha/cena?

[kralyk z abclinuxu]

No, to byla nadsázka.. Já to většinou až tak moc neřešim...

Navíc pokud není jistota, že bude na trase k dispozici pitná voda, tak stejně většinu místa/váhy zabere voda... Např. v Tatrách byly dny, kdy jsem měl v báglu třeba 3L vody a stačilo to tak tak (slunce pražilo...).

[Grunt]

No, to byla nadsázka.. Já to většinou až tak moc neřešim...

Proč, nápad je to zajímavý.

Např. v Tatrách byly dny, kdy jsem měl v báglu třeba 3L vody a stačilo to tak tak (slunce pražilo...).

Proto je fajn sebou tahat mapu. Ta neváží kg na litr. Zrovna v Tatrách by se ta voda nemusela pravděpodobně ani nijak upravovat.

[kralyk z abclinuxu]

Proto je fajn sebou tahat mapu. Ta neváží kg na litr. Zrovna v Tatrách by se ta voda nemusela pravděpodobně ani nijak upravovat.

Tam nebyl problém v tom, že bych nevěděl, kde ta voda je, ale v tom, že prostě na trase žádná v dosahu nebyla, což je typické pro hřebenovky. (Jinak pokud možnost byla, tak jsme samozřejmě z potůčků doplňovali...)

[Josef Kufner]

To chce s sebou nosit instantní vodu. Ta je mnohem lehčí.

[lacik]

Sice se ro netýká šachů ani matematiky, ale zkusím to navrhnout: frontend k databázím.

Naprogramovat návrh formuláře (nebo systému formulářů), buď skriptováním nebo naklikáním, pro zadávání dat do databází běžnými uživateli. Čili: admin vymyslí tabulky s relacemi v postgre, mysql, mssql nebo čemkoli jiném a naskriptuje frontend pro asistentku (nebo servisáky nebo prodejce nebo ...) pro blbuvzdorné zadávání dat do db a bez možnosti nějak zasáhnout do databáze nad rámec oprávnění běžného usera. Mělo by to fungovat i v rámci sítě nebo internetu.

[Petr "Glubo" Sýkora]

Takže něco jako Adminer Editor?

[lacik]

Díky za tip, vyzkouším, uvidím.

[JS1]

Jo, napadu mam spousta, ale jsou to spis "vyzkumne zamery" nez konkretni programy. O jednom jsem psal v blogpostu, dalsi jsou (bohuzel jsem zatim nemel naladu to sepsat) filesystem, hra ve stylu Minecraftu, socialni simulator, socialni sit a jeden radeji nejmenovany, na kterem delam ted. Detaily muzu upresnit, pokud by nekdo mel zajem o novy vyzkumny obor.

Dělám to, protože se chci z pozice "teoretického programování" dostat k praktickému programování.

To znam moc dobre. Otazka ovsem je, jestli to neni tim, ze prakticke programovani neni moc zajimave - vetsinou je to o reseni nekompatibilit mezi technologiemi, tedy vec X uz existuje ale tady se to jeste dela pres ruku, a toho ze pocitace jsou blbe a je potreba jim vsechno vysvetlit.

Par jednodussich napadu, ktere se tykaji matematiky bych ale mel:

• Desifrovaci system na sifrovaci hry pomoci jazykoveho modelu a mapovani featur (a mozna pak taky resic na substituticni a transpozicni sifry pomoci jazykoveho modelu); nejjednodusi pripad vede krasne na naivniho bayese.
• Nejaky system na automatickou tvorbu (uceni) regularnich vyrazu ze zadanych prikladu textu. Jako uzivatel oznacim priklady toho, co chci matchovat, a v nich toho, co chci vytahnout (treba cislo), a on si to nejak prebere a vyrobi regularni vyraz. (Eventualne to pak dovest dal a aplikovat to na programovaci jazyky nebo webove stranky. Ale to uz zase zni jako vyzkumny zamer.)
• Pro hardwarove orientovane - implementovat deep learning algoritmy v FPGA

[kralyk z abclinuxu]

(a mozna pak taky resic na substituticni a transpozicni sifry pomoci jazykoveho modelu)

Něco takového existuje, ale není to moc konfigurovatelný atd... Standalone open-source program by byl lepší.

[JS1]

To je slovnikovy utok, ja chci utok pomoci pravdepodobnosti na zaklade modelu n-gramu.

[Honz]

A co takhle číslíčka teplot do panelu KDE jak byly Ksensors...?

[Begleiter]

Díky. Tohle vypadá zajímavě a jednodušše. Zařazuju do užšího výběru.

[lertimir]

Můj nápad (ono je to spíš přání, které bych dost rád viděl realizované) je spíše z kategorie "zapojit se do velkého projektu".

Je to zásah do zobrazovacího/paměťového jádra grafického programu např. digiKam nebo rawtherapee či darktable tak, aby program měl dopředu napočítané zobrazení obrázků a při požadavku "Next", "Previous" se další zobrazil v podstatě okamžitě. Představa je taková. V každém okamžiku je podle nastavení parametru setřídění přesně definované, který obrázek je následující a předchozí. Program by ho načetl do paměti, rozbalil z jpeg do nekompresované velikosti (což chápu, že pro 24Mpix obrázek bude 100M), a z nekompresované velikosti vypočetl očekávané pohledy přesně v té velikosti zobrazení, v níž se bude třeba (pohledy mne napadají dva důležité a to "celý obrázek" tedy zmenšení do okna, a 1:1 pixelové zobrazení v konkrétní pozici výřezu). A mohlo by být konfigurovatelné kolik obrázku dopředu a dozadu si takto program předpočte. At počítá v době, kdy si foto prohlížím a ne až v době, kdy chci další. A když dnes stojí v podstatě 4G paměti efektivně 1K Kč není důvod proč spotřebou paměti neštřit uživatelův čas, nota bene když chce.

[Grunt]

Kravina první třídy.

A když dnes stojí v podstatě 4G paměti efektivně 1K Kč není důvod proč spotřebou paměti neštřit uživatelův čas, nota bene když chce.

Ještě větší kravina. To bych nedělal už jen z principu.

[kralyk z abclinuxu]

Pokud to bude konfigurovatelné, imho není problém. Běžné prohlížeče obrázků tohle dělají už dávno...

[Heron]

Ne, tohle není kravina. Tohle je věc, kterou měl už svého času dosový acdsee a kterou má většina komerčních programů. Protože to VELMI usnaďnuje a hlavně nepřerušuje práci.

Aneb proč bych měl čekat 5s na načtení dalšího obrázku, když ten procesor celou předchozí minutu nic nedělal. Vhodný readahead je obecná optimalizační technika.

[lertimir]

Ano acdsee to dokonce mělo tak, že ty blízké obrázky mělo přednahrátý v jednotlivých vrstvách grafické karty, takže next bylo skutečně okamžité, další obrázek byl už pomalejší (šel z paměti) a další ještě více protože šel z disku. Ale při "next" bylo hned slyšet disk, jak program zabral na dalším obrázku.

[Grunt]

Ne, tohle není kravina.

Ano, tohle je kravina. Zdá se že na tebe budou potřeba už i nějaké Rationale, takže tady je máš:

• První problém je v zařízeních samotných. Že vůbec kdy dovolili ukládat do RAW formátů čipu místo nějakého rozumného přenosného rastrového formátu. Lidi za to zodpovědné bych u zdi zastřelil jako první.
• Důvod je ten, že všechny rozumné přenosné rastrové formáty v sobě mají integrovanou podporu metadat (většinou založeného na TIFF markerech nebo EXIF) a v nich je zase z 90% implementovaná podpora Thumbnails. Ty tento problém řeší nejlépe.
• Ale budiž. RAW image format, tak RAW image format. Nechme problémy s kompatibilitou, možné problémy do budoucna, zaměřme se na Thumbnails. Klíčové slovo pro tento případ je standardizace:
  • DNG
  • ISO 12234-2
  Nevím jak jsou na tom s podporou čitelnosti Thumbnails jednotlivé formáty (resp. implementace), ale čekal bych že u těchto budou problémy nejmenší. Lepší nápad než implementovat takové obskurnosti by mohlo být i nalezení vhodného formátu a jednoduchý strojový převod, který by Thumbnails vygeneroval. Lepší nestandardní , ale systémové řešení než takové hacky.
• I když tohle všechno budu ignorovat, tak cvakat fotku za fotku do RAWu je kravina!!! Na cvakání je JPEG. Žere míň místa, stojí míň strojového času a pozitivně přispívá ve snahách o snižování dopadů globálního oteplovaní, plastové ekonomie a drancování přírodních zdrojů. Když máš tolik RAW souborů, že je problém zobrazit je v rozumném čase, značí to jiný problém než je přednačítání náhledů.

Ještě nějaké otázky?

[Heron]

Je vidět, že ty se prostě vyznáš ve všem. Ovšem jen teoreticky.

Ad 1) Celkem by mě zajímalo, co by se do toho rastrového formátu mělo vlastně ukládat. Hodnoty každé barevné buňky, hodnoty pixelu po demosaic masky (jakou metodou?) nebo co vlastně? Výhoda rawu je ta, že máš surová data tak jak vznikla (a moc se na ně nesahá) a po letech na ně klidně můžeš použít zcela novou metodu. Při uložení do obecného rastrového formátu o část informace přicházíš.

Ad 1 a 2) Aha, takže výrobci foťáků by měly volit formát podle toho, zda obsahuje náhledy.

Ad 3) RAW (CR2) náhled obsahuje.

Ad 4) Víš, jenže ono se nefotí podle toho, jaký to žere procesorový čas nebo místo na disku. Ono se fotí podle toho, co se chce fotit a nějaké místo na disku je zcela podružné. Takže na sportovních akcích se nafotí stovky fotek (často i rychlost 6 snímků za 1s) a potom se z toho vybere.

Když máš tolik RAW souborů, že je problém zobrazit je v rozumném čase, značí to jiný problém než je přednačítání náhledů.

Není. Problém je jen v tom, že ten procesor se fláká místo toho, aby si předpočítal data, která uživatel (už z logiky workflow) bude za chvíli potřebovat.

Navíc tohle vůbec není problém (jen) náhledů. On i ten 24Mpx JPEG z full frame (když už teda radít cvakat do JPEG, což je opravdu super formát pro následné zpracování) se nějakou dobu otevírá. Tohle je o tom, jestli ti autoři toho software přemýšlejí pro koho je ten software určen a jak se používá. Tohle téma se vůbec nemusí týkat jen obrázků, rozumný readahead dat se hodí všude dam, kde se pracuje s daty v nějakém sekvenčním pořadí.

[Grunt]

Je vidět, že ty se prostě vyznáš ve všem.

Si kuř. Se stačí vždycky jenom zeptat.

[Grunt]

On i ten 24Mpx JPEG z full frame (když už teda radít cvakat do JPEG, což je opravdu super formát pro následné zpracování) se nějakou dobu otevírá.

Mimo jiné je to důvod proč se Thumbnail zavedl. U JPEGu to nestojí I/O nebo prostor ale dekomprese zas stojí procesorový čas. Samozřejmě Thumbnail byly jen začátek. Pak se v JPEGu2000 pokračovalo tak, že jak se celkový obrázek rozloží na jednotlivá rozlišení, ty se seřadí do streamu za sebou (DC na začátku) a v podstatě tolik dat kolik načteš od začátku souboru, takové dostaneš rozlišení (plné rozlišení se dá načítat jen tehdy, kdy s ním opravdu potřebuješ pracovat). Proto tam myslím ani žádné náhledy zavedené nejsou. To byl formát opravdu navržený pro fotografy, bohužel má podíl na trhu takový jaký má.

[kralyk z abclinuxu]

V JPEGu mají thumbnaily afaik obvykle příliš malý rozlišení na prohlížení na celou obrazovku, sloužej jen k prohlížení třeba ve filenamageru, kde se skutečně jedná pouze o thumbnail (viz význam toho slova)

Nevim, jaký rozlišení maj v RAWu, počítám ale, že to taky nebude buhví co, kdyžtak mě někdo opravte...

[Heron]

V CR2 je to rozlišení stejné jako celý obrázek, ale kvalita je bídná (jpg 15Mpx do 1MB).

[kralyk z abclinuxu]

Hm, tak to na promítání/prohlížení stejně není...

[Grunt]

Jinak k tomu

A když dnes stojí v podstatě 4G paměti efektivně 1K Kč není důvod proč spotřebou paměti neštřit uživatelův čas, nota bene když chce.

Plýtvat pamětí či jakýmikoliv zdroji je vždy kravina. ImageMagick má výborný nástroj – stream. Je určen k práci s velmi masivními obrázky. Funguje tak že načte do paměti výřez z obrázku který si specifikuješ, zbytek jednoduše (i na disku) přeskočí. Jak velký je minimální blok, který se dá z disku načíst? Já bych zkusil stejnou strategii. Jeden bajt to asi nebude, ale i tak u malého náhledu na který potom aplikuješ NN interpolaci je docela velká šance, že to hodně sníží overhead.

[Heron]

Plýtvat pamětí či jakýmikoliv zdroji je vždy kravina.

Nevyužívat možnosti HW pro urychlení práce, když je ta možnost, je kravina ještě větší .

[Grunt]

V rozumné míře, v rozumné míře. I ty paměti musí nějaké malé Čínské ruky vykovat.

[lertimir]

Můj čas je také zdroj, a na to, abych jej šetřil, jsem ochoten něco vynaložit.

Moje situace je taková. Přijdu z focení, mám řekněme 1000 fotek, fotky jsou ve velikosti 7M když jsou jpegy nebo 25M když jsou to RAWy. v první fázi potřebuji fotky rychle projít, abych rozlišil, kterou ano a kterou ne. to znamená tak 4000 přechodů mezi fotkama na next/previous. Každá vteřina o kterou se jednotlivá fotka déle načítá je hodina práce navíc v té nejnudnější a neotravnější fázi práce z fotkama.

Navíc jak ImageMagic namarkuje fotky abych dále v editoru věděl, že tyhle mám jen sklopit do archivu a nebude se s nima pracovat?

[Fluttershy, yay!]

Odpovím za Grunta, necvakej tak divoce. ~,^

[lertimir]

O mne ani tak nejde. Já se s tím nějak vyrovnám, takovou akci mám jen občas a pokud mne to bude moc štvát, tak se vrátím k acdsee nebo k lightroomu. To co jsem tím chtěl, ale zdůraznit, že od určité úrovně práce s fotkama, která je někde u pokročilých amatérů, je linuxové zpracování fotek diskutabilní až nepoužitelné. A není to způsobeno nedostatkem funkcí. Možnosti úpravy fotek, které nabízí digikam jsou pro naprostou většinu případů dostatečné a pokud je potřeba více zvládne to gimp. Problém je v rychlosti a ve zpracování workflow s fotkama. Pro mne je to v podstatě jen o čase, který věnuji koníčku, ale profesionál je placen od toho, že dodá potřebný počet fotek, v požadované kvalitě a v požadovaném termínu, takže rychlost je killer feature.

Ale na urychlení zpracování fotek v linuxovém světě mu nepomůže nic. Nepomůže mu, když si koupí 32GB paměti, aby měl program dost místa a pracoval rychle. a mnoho jader mu také moc nepomůže, kromě nějakého záverečného dávkového zpracování, A i když ho linux může bavit, tak ve chvíli, kdy nefunguje, jak potřebuje, se s tím nedá nic dělat. Nejvíce mne zarazil ten odpor, proti tak jednoduchému řešení, jako předzpracování fotek.

A k tomu cvakání. V květnu jsem byl si zafotit na závodu Pražské schody. Tady jsem jen pro ilustraci nahrál 3 z asi 900 fotek, které jsem tam nafotil. Nejsou nejlepší, ale použitelné, jsou těsně za sebou (sériové snímání), časový rozdíl mezi nimi je pod vteřinu, ale byly schopné projít do druhého kola výběru. Které z těchto nejlíp vyjadřuje atmosféru? S tím, že samozřejmě musíš uvažovat i s případným ořezem. A takových fotek procházíš desítky. stovky, posuzuješ detaily: jsou ostré oči? jaký má výraz v tváři? Je tam pohybová neostrost? Je tam zachycená iterakce mezi jezdci? (což třeba když jsem fotil zespodu tu masu jezdců, jak se po zámeckých schodech řítí dolů a odhadují jak pojedou do zatáčky o 180° bylo zajímavé.) A myšlenka, že jsi schopen odhadnout ten okamžik, teď zmáčknout a ona atmosféra tam je, je lichá. Uděláš 300 fotek a vybereš jednu. Stejně tak, když sedím na podzim ráno ve 4 někde na posedu a čekám na svítání. Válející se mlha je každých 10 vteřin jiná a klidně z toho může být 150 skoro stejných fotek jednoho pole. Digitální doba dala v podstatě každému možnost fotit podobným způsobem, jako na kinofilm fotili asi jen reportéři z BBC a National Geographic, díky svým dost rozsáhlým rozpočtům. Více fotek je pozitivní, protože fotka má jednu pozoruhodnou vlastnost, a to že na té fotce je často vidět více, než jsem viděl v reálu, samozřejmě se tak člověk musí naučit mazat.

[Josef Kufner]

Ale na urychlení zpracování fotek v linuxovém světě mu nepomůže nic. Nepomůže mu, když si koupí 32GB paměti, aby měl program dost místa a pracoval rychle.

Zkoušel jsi napřed nakopírovat fotky do tmpfs? To by mohlo načítání docela urychlit, i když to bude za cenu delší přípravy na začátku, ale to si mezi tím můžeš jít udělat kafe. Editované/vybrané fotky bys samozřejmě musel průběžně ukládat jinam.

[Heron]

Vzhledem k tomu, že rychlost dnešních disků je tak 200ms na fotku (nebo 50ms v případě SSD), tmpfs práci příliš neurychlí. Pokud má někdo 32GB paměti, tak ty fotky budou po nahrátí z karty na disk stejně stále v IO cache.

[Jendа]

Mně nejdýl trvá rozbalení fotky. A to mám pomalý notebookový disk.

[lertimir]

32 GB nemám. Ale mám SSD a pracovní adresář pro obrázky je na něm. Nepomůže to.

[lertimir]

Jen pro upřesnění, zatím mám 8G, a když pracuji s fotkama tak mám v podstatě otevřen digiKam, někdy Gimp, někdy Inkscape. Ten digiKam v podstatě nikdy nevezme více než 2G a celkově to není v tomhle režimu nikdy přes 4G, tedy druhé 4G jsou cache, pokud projíždím přes fotky tam a zpět, tak určitě budou všechy blízké v cache, ale nepomůže to, fotka se načítá 1,5 vteřiny a více.

[Grunt]

Ok. 1000 fotek * 25 MB = 25GB dat, které musíš tak či tak načíst. Řešení je nenačítat 25GB. Ještě by mě zajímalo kolik % z toho vyházíš ihned poté co je uložíš, strojově zpracuješ, načteš a zobrazíš.

[Grunt]

Navíc jak ImageMagic namarkuje fotky abych dále v editoru věděl, že tyhle mám jen sklopit do archivu a nebude se s nima pracovat?

A nebo když už chceš teda funkční řešení, tak proč jednoduše nepoužiješ ImageMagick k tomu aby si všechny RAWy načetl, zmenšil do rozumného zobrazovacího rozlišení, sekvenčně konvertoval do JPEGu, ty pak projdeš rychlostí blesku, vyházíš co nechceš, list exportneš, vyměníš přípony a následný rm nebo mv spustíš na složku s RAWy. Práce na pět minut i když do ní započítám vypití čaje/kafe a dloubání v nose.

[Heron]

Tenhle typ filtrace nepovedených (tj hodně nepovedených) fotek lze provést přímo na přístroji. Pro detailní porovnání dvou skoro stejných fotek je potřeba občas i zazoomovat 1:1.

[Grunt]

Tak to ti stejně nic nepomůže. To musíš načíst/dekódovat vše (maximálně by se dal načítat/dekódovat zoomovaný výřez) jestli chceš nebo ne. Ale v tom případě zas nevím proč vadí doba načtení když se v tom budeš stejně půl hodiny šťárat.

[lertimir]

A můžeš mi vysvětlit, jak v tom případě poznám přesně, kde je rovina zaostření? Jestli má modelka perfektně ostré oči a dokonale vykreslené řasy, a nebo se zaostření posunulo již k uchu nebo k nosu a zobrazení očí je už měkké. Podobně polohy rukou, vykreslení vlasů. Něco z rozhodnutí je možné dělat nad celou fotkou, ale mnohé je 1:1 pixel posouzení. Argumentuješ v podstatě způsobem, že říkáš, že to, co potřebuji vlastně nepotřebuji, ale přitom neděláš v oboru a netušíš, co se u fotky řeší.

[David Jaša]

když jsou jpegy nebo 25M když jsou to RAWy

Tohle mě asi nepřestane fascinovat. Proč píšeš zkratku malýma a normální slovo VELKÝma?

[kralyk z abclinuxu]

Preloading obrázků při prohlížení šetří čas. Jestli o to nestojíš a cheš radši šetřit paměť, tak prostě preloading vypni v konfiguraci, a je to. Případ uzavřen

[Fluttershy, yay!]

OT ten PRISM-break je nehorázná sračka bandy jeblých fanatiků. Přečti si např. diskuzi k bug reportu ohledně zahrnutí derivátů Ubuntu.

[kralyk z abclinuxu]

No, ten výběr a popis dister je takovej podivnej. Hodnotu prism-break vidim spíš v některých těch ostatních seznamech...

[Grunt]

Tak preloading tak jednoho, dvou či jiného jednotkového počtu obrázků nebude asi problém implementovat v ničem. Ale kolik je dost? 45% problémů třeba v mplayeru by se dalo vyřešit nekonečným množstvím paměti…ale asi je důvod proč se tyto problémy podobným způsobem neřeší.

[Josef Kufner]

Tenhle přístup narazí v okamžiku, kdy ne počítači běží i něco jiného. Výsledkem je webový prohlížeč, který si veme 2.5 GB paměti, a najednou už 4 GB RAM v notebooku nestačí a další není kam dát.

[lertimir]

Ale fotky neupravuji na notebooku, kde přesnost podání barev je tristní, protože parevné ladění záleží na sklonu monitoru. A není problém mít konfigurovatelné monžství paměti, které na readahead rezervuji. Problém je, že i když mám 16GB tak mi to nepomůže, a stejně čekám 5 vteřin na další fotku. Pro fotky z dovolené z kompaktu je to možná lidem jedno, ale naprostá většina lidí, kteří fotí se zrcadlovkou fotí tak, že v jedné situaci vyfotí 3-8 podobných, lehce jiných fotek, a z nich se vybírá jedna, která je z té situace nejlepší. Což znamená projít mezi nimi ne jednou ale třeba 5 krát, což je tak cca 30 přechodů. A mnohdy po příchodu z focení je takových situací vyfoceno 100. Pak to znamená, že při tom prvních procházení a výběru 100 fotek z nimiž se dále budu zabývat provedu 3000 přechodů na next/previous když místo okamžitého zobrazení jedno z nich trvá 5 vteřin tak máme 15 000 vteřin ztráty, tedy 4 hodiny z té práce budu čekat. Pokud by mě koupě 16GB za 4k pomohla, koupím ji okamžitě, ale ten program by to musel umět využít. Před asi 4 lety jsem se o tom pokoušel přesvědčit Lemaitra z digiKamu a neúspěšně. Protože to nejsou fotografové.