Už teď je z toho odšumem nechutnej blivajs (ať už to je to v tomhle ohledu původní snímek co zmrzačila jen automatika foťáku nebo k tomu došlo až v PC), ne tak ještě na ten odšum přitlačit.
To už by bylo lepší namalovat to vodovkama než dál tlačit. Nebo rozhodně alespoň nepoužívat ISO 400, když už je nutny cvakat s ultramegazoooomem.
Protože je to v původní barevné verzi bez nějakyho dalšího dobarvování/odbarvování. Zašlé zažloutlé klávesy, klasika. Záběr alá takový test hloubky ostrosti.
Přepaly nepřepaly, na těch předních lístcích je vidět něco mnohem podstatnějšího. Odkud a jaky světlo při focení bylo. Sezhora kolempolední košovkovo světlo na takovy foto.
Tak z té mnou udělené nuly si odečti ještě jeden bod. Jsem si ani nevšiml, že to je v kategorii makro a přitom to makro vůbec není - ani to není dobře.
Aby to bylo makro, tak by čmelák při focení pomocí 350D musel být přes celý snímek - při focení by se nejspíš ani celý nevlezl do hledáčku, protože čmeláci jsou pomalu větší jak snímač 350D.
Vpohodě, prostě jsem netušil, že ve výkřicích do tmy se nesmí. I kdyby se třeba někomu prográmek pod GPL licencí šikl při vlastních experimentech. Gradientům zdar.
PS: Obvzlášť těm co si to neprohlíží na profi grafikách + monitorech v kompletně desetibitovym zobrazovacím řetězci (30 bitů celkem, řetězec: grafický program - ovladač - grafika - monitor).
Není třeba dělat z komára velblouda. Web za to může jen v ojediněléch případech, a to prakticky jen pokud zobrazuje foto v jiné než nahrané velikosti (nebo ho dokonce resampluje a teda z JPeGu dělá jiný JPeG). To se tuná sice děje, ale jen v případě ikonek. Takže pokud se na nějakym monitoru foto z webovky sype, a to stejny se při prohlížení na PC (prohlížeč fotek / ediitor) nesype, tak v tom případě to není problém webu, ale prohlížeče.
A s tím porovnáváním je to opravdu nejjednodušší. Tj. uložit si soubor nahraný: http://cdn.photopost.cz/foto/2019/12/id7528-1576433790.jpg
A porovnat velikost v Bytech (nebo i obsah - třeba total commander - soubor - porovnat podle obsahu) s tím co bylo na webovky původně nahráváno. Pokud data souborů sedí, tak je to prostě ten samý soubor, a pak servíruje server prohlížeči to co bylo na server nahráno, ale prohlížeč to zobrazuje jinak.
Kdysi jsem na TK zahlídl, že baryt položit na sklo emulzí, ale furt jsem to ještě takto nezkoušel. Na vánoce bych chtěl udělat nějaky kontakty po dlouhé době, tak snad zkusím, a když tak "se podělím", jestli jo nebo ne. (při ořezu zůstane rozměr papíru původní místo odřezání polepené části - z rubu páska může zůstat)
Tohle je ze Zerene Stackeru. Teda šestnáct kousků ze ZS metodou PMax + substacky + retuš. Ale složitost samože stoupá s počtem. Pohrát si s jedním je v lepším případě o té úpravě pár míst.
Někdy je to víc hraní, když je tam něco "před něčím". Třeba chlupy, tykadla, antény, pokud jsou před něčím (co u chlupů je v podstatě pokaždy), tak to program neumí rozlišit a předmět "před" je prolnutý předmětem "za", takže se to vepředu stává jako by průhledným. A chce to potom retuš, aby to co má být vepředu zůstalo bez prolnutí s tím co je vzadu.
Řešení je přes ty substacky + retuš. Stoh snímků většinou složím celý, a pak si vybírám několik nejdůležitějších částí, podskupiny snímků, ktery skládám zvlášť (v rámci stejnyho zarovnání celyho stohu). Ty pak prolínám přes retuš.
Pro jeden snímek to je teda většinou postup: export z raw do tiff, dávková retuš špíny na snímači, několik složení v ZS, retuš v ZS, finální doretušování v PS. A tak dál, podle toho kolik toho je. U těch šestnácti nahozených nahoře je to už teda po tomto zpracování. Včetně aj vyretušování smítek co zůstaly na pestřence (oprotivá té verzi Test5150, kde je to včetně čpíny na snímači a aj smetí na pestřence a podobných neduhů).
Relativně to s tou trpělivostí je taky u mě jeden z důvodů, že to ještě není hotovy a možná teda ani nebude. Nakonec po vyretušovaných šestnácti stohů tyhle výsledny kousky panoramatu vůbec nic nechtělo dát dohromady tak, jak bych potřeboval (zkoušeno PS, APG, PTG).
Takže to co je hore je to co mě čeká, jestli se k tomu kdy někdy vrátím. Šestnáct vrstev PSD, v každé vrstvě jeden už finální snímek ze skládání a deformace těchhle snímků ručně, aby seděly/navazovaly pixelovou pozicí co nejpřesnějc se sousedy.
Zatím je takhle zdeformováno jen pár prvních snímků (dva nadsebou po levé straně). Ty už teda navazují přesně, no ještě jich ale většina zbývá.
Pokud se teda někdy k tomu ještě vrátím, tak postup by u tohto měl být takový, že jak budou všechny snímky přesně zarovnany, tak je opět rozložím do šestácti snímklů, Tiffů, kterými nakrmím APG, ktery má pro mě vyhovující funkce pro sjednocení barev a tónů. Takže APGčku by už v tom případě nemělo dělat problém snímky pospojovat díky ruční deformační předpřípravě a výsledek z něj bude perfektně navazovat, než když bych se to snažil ručně rovnat třeba přes křivky.
VH: to co tam je vidět bych označil za důsledek silnější JPeG komprese. Komprimuje se po maticích v několika stupních. Jakmile se dostane do nějaké matice víc detailů, už se potom tolik nekomprimuje. Naopak v ploše bez detailů se komprimuje víc.
Snímek je dost hodně komprimovaný. Má jen něco přes 300 kB, takže o to větší rozdíl je mezi obsahem matic (bloků) s detaily a matic s plochou s menším počtem detailů.
Je to unáhleny. Ta pohybová neostrost v tomto případě rozhodně nefunguje, že šlo o autorský záměr. Tj. je to prostě nepovedený mobilocvak. Pokud se teda někdo hodně nasilu nesnaží za vším něco hledat (u tohoto výsledku pokud si teda spíš někdo nechce něco nalhávat), ale takovou případnou vynaloženou energii jde uplatnit líp.
Jo, o těch jsem už slyšel, ale nějak nad nima nepřemýšlel - zapomněl na ně. Možná by to bylo jednodušší a pomohlo to. No minimálně jednu výhodu by řešení přes USB mít mělo. Vyšší rychlost.
Ne ne, SD kartu jsem vůbec neřešil. Resp. měl jsem řešení zálohou obrazu SD karty. Takže obnova "rychlá", vzetím nové SD karty, nahráním obrazu a jede se dál. Horší, že tady v tom případě to odešlo tak brzo, že při tomto tempu pár výměn SD karet a jsem na ceně stabilnější náhrady ( USB-M.2 SATA + M.2 SSD ), která si díky připojení přes USB jako mass storage řeší fyzicky ukládání svou vlastní logikou a nemělo by se teda fyzicky přepisovat furt stejny místo (ať už při kompilaci programů nebo používám maly texťáky pro zápis relativní nakrokované pozice).
Jiří: Tak k dokonalosti to má daleko. Týden po zprovoznění odešla malina (Raspberry Pi 3B+ posazeny nad drivery, ale naštěstí jen SD karta přepisováním furt stejnyho místa, takže aktuálně předělávám na M.2 SSD), ale jinak v rámci možností s ruční pilkou na železo, pilníkem a základní stojanovou vrtačkou. Mít k ruce frézu, bylo by to ještě krapánek na jiné úrovni.
Same: S 3D Makrem jsem nějak moc nepohl, a pak zkusil mikroskopický objektiv. A tak se rozhodl radějc rovnou pro všechny tři osy pro tenhle případ, aby to nedopadlo právě jak s 3D Makrem, kde nevím, jestli se někdy dostanu k dalším dvěma osám. Ale tu osu Z jsem asi rok těžce provizorně používal i na mikro.
Luděk Horáček |
To už by bylo lepší namalovat to vodovkama než dál tlačit. Nebo rozhodně alespoň nepoužívat ISO 400, když už je nutny cvakat s ultramegazoooomem.
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Aby to bylo makro, tak by čmelák při focení pomocí 350D musel být přes celý snímek - při focení by se nejspíš ani celý nevlezl do hledáčku, protože čmeláci jsou pomalu větší jak snímač 350D.
Luděk Horáček |
Luděk Horáček |
PS: Obvzlášť těm co si to neprohlíží na profi grafikách + monitorech v kompletně desetibitovym zobrazovacím řetězci (30 bitů celkem, řetězec: grafický program - ovladač - grafika - monitor).
Luděk Horáček |
A s tím porovnáváním je to opravdu nejjednodušší. Tj. uložit si soubor nahraný:
http://cdn.photopost.cz/foto/2019/12/id7528-1576433790.jpg
A porovnat velikost v Bytech (nebo i obsah - třeba total commander - soubor - porovnat podle obsahu) s tím co bylo na webovky původně nahráváno. Pokud data souborů sedí, tak je to prostě ten samý soubor, a pak servíruje server prohlížeči to co bylo na server nahráno, ale prohlížeč to zobrazuje jinak.
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Někdy je to víc hraní, když je tam něco "před něčím". Třeba chlupy, tykadla, antény, pokud jsou před něčím (co u chlupů je v podstatě pokaždy), tak to program neumí rozlišit a předmět "před" je prolnutý předmětem "za", takže se to vepředu stává jako by průhledným. A chce to potom retuš, aby to co má být vepředu zůstalo bez prolnutí s tím co je vzadu.
Řešení je přes ty substacky + retuš. Stoh snímků většinou složím celý, a pak si vybírám několik nejdůležitějších částí, podskupiny snímků, ktery skládám zvlášť (v rámci stejnyho zarovnání celyho stohu). Ty pak prolínám přes retuš.
Pro jeden snímek to je teda většinou postup: export z raw do tiff, dávková retuš špíny na snímači, několik složení v ZS, retuš v ZS, finální doretušování v PS. A tak dál, podle toho kolik toho je. U těch šestnácti nahozených nahoře je to už teda po tomto zpracování. Včetně aj vyretušování smítek co zůstaly na pestřence (oprotivá té verzi Test5150, kde je to včetně čpíny na snímači a aj smetí na pestřence a podobných neduhů).
Luděk Horáček |
Takže to co je hore je to co mě čeká, jestli se k tomu kdy někdy vrátím. Šestnáct vrstev PSD, v každé vrstvě jeden už finální snímek ze skládání a deformace těchhle snímků ručně, aby seděly/navazovaly pixelovou pozicí co nejpřesnějc se sousedy.
Zatím je takhle zdeformováno jen pár prvních snímků (dva nadsebou po levé straně). Ty už teda navazují přesně, no ještě jich ale většina zbývá.
Pokud se teda někdy k tomu ještě vrátím, tak postup by u tohto měl být takový, že jak budou všechny snímky přesně zarovnany, tak je opět rozložím do šestácti snímklů, Tiffů, kterými nakrmím APG, ktery má pro mě vyhovující funkce pro sjednocení barev a tónů. Takže APGčku by už v tom případě nemělo dělat problém snímky pospojovat díky ruční deformační předpřípravě a výsledek z něj bude perfektně navazovat, než když bych se to snažil ručně rovnat třeba přes křivky.
(jen pro případ ... APG = Auto Pano Giga)
Luděk Horáček |
Snímek je dost hodně komprimovaný. Má jen něco přes 300 kB, takže o to větší rozdíl je mezi obsahem matic (bloků) s detaily a matic s plochou s menším počtem detailů.
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Luděk Horáček |
Viz. taky tenhle text, kterymu bych rád v nejbližších měsících doplnil pokračování.
Luděk Horáček |
Same: S 3D Makrem jsem nějak moc nepohl, a pak zkusil mikroskopický objektiv. A tak se rozhodl radějc rovnou pro všechny tři osy pro tenhle případ, aby to nedopadlo právě jak s 3D Makrem, kde nevím, jestli se někdy dostanu k dalším dvěma osám. Ale tu osu Z jsem asi rok těžce provizorně používal i na mikro.
Luděk Horáček |