Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Rěším problém jak organizovat si fotky a zkouším se zkamarádit s digikamem, ale nedaří mi v něm najít jak realizoavat základní workflow. A to:
1. Načíst fotky z media (karta, databanka) do archivního adresáře. V průběhu přenosu případně přejmenovat a ideálně prohlížet ve fullscrenu a ihned vyházet a nepřenášet technicky špatné.
2. Pokud první výběr nešel udělat v pruběhu přenostu tak tedy následně vyházet špatné.
3. Otagovat a fotky (to digikam umí dobře)
4. Vybrat fotky, které chci upravovat, a překopírovat je do pracovního adresáře. To snad vůbec nemá, nikde jsem to nenašel, ani tu možnost procházet sadu fotek a markovat je a ani triviální kopii, snad jedině "uložil jako" po editaci. Kopírování by mělo nakopírovat i tagy k nové fotce.
5. V pacovnímím adresáři fotku upravovat, případně vyvolat RAWy a případně mít i od fotky více verzí obět s držením tagů
6. Finální fota nakopírovat do adresáře na hotové fota.
Celkem triviální workflow, a připadá mi jediný logický. Jednoduché podmínky, nikdy nešahat na originální foto a oddělit hotové od rozpracovaného. Backup na vše, dlouhodobá archivace na archiv a hotová fota. Ale nijak jsem nenašel jak to realizovat v digikamu (nebo v něčem jiném v linuxu. Před časem na Win jsem tohle dělal v ACDSee a tam to fungovalo.) Nebo je tam nejaký jiný fígl v digikamu? Poradte. Pro mne je nepřijatelné, abych přechod mezi archivem a pracovním adresářem dělal jako "uložit jako" z editace fotky to je na mrtvici. Stačí uklepnutí a je po původních datech.
Jak vidím tak workflow v digikamu nikdo nedělá.
Ad 1) Neumí. Soubory zkopíruji do příslušného adresáře a pustím na ně skript (soubory se přejmenují dle data a času, v případě RAW se vytáhne vložený JPEG a RAW se uloží do podadresáře).
Ad 2) Prostě klávesou DEL v Album view? Bohužel neumí "párovat" JPEGy a RAW, takže plánuju skript, který příslušné raw/blabla.cr2 smaže dodatečně.
Ad 3) Ano, to je důvod proč jsem na něj přešel z MaPiVi.
Ad 4) Neumí. Lze to obejít: nechat spuštěný digiKam a pomocí souborového manažeru s náhledy souborů tyto soubory prostým drag&drop překopírovat kamkoliv jinam ve struktuře adresářů, které jsou zahrnuty v albech/sbírkách digiKamu. digiKam automaticky zaregistruje nové soubory. Bohužel u nových souborů nebude vědět, že jsou kopií (pracovní verzí) archivního souboru.
Co očekáváte od akce "markovat"? Není problém to vyřešit vytvořením samostatné větve ve štítcích a následně pomocí vyhledávání takto označené soubory zobrazit. (Ale uznávám, je to neohrabané.)
Ad 5) Verzování neumí. Řeším to ručně vytvořením kopie s číslováním na konci názvu souboru.
Ad 6) Neumí.
Vy třeba vůbec nezmiňujete interoperabilitu - digiKam se zaměřuje na XMP (což je fajn) a současně se snaží udržovat vazbu na IPTC (ale už jen částečně a bugy nejsou považovány za zásadní). Smazání (třeba v důsledku poškození) databáze a její znovuvytvoření importem z metadat souborů pak může vést k nepříjemným překvapením.
Některé typy údajů se spravují komplikovaně - např. IPTC location lze editovat jen jednotlivě pro každý obrázek. Obcházím to paralelním používáním MaPiVi.
Největší problém je domluvit se na "workflow", každý očekává něco jiného a co si budeme povídat: digiKam programují především programátoři a ne fotografové...
Osobně nechápu, proč ztrácejí čas s editorem (showFoto) namísto zlepšování digiKamu jako Content Management System (štítky, verzování, synchronizace metadat, decentralizovaná správa fotek). Editorů a prostých prohlížečů je už dost. Aniž bych to myslel zle, tak by též prospělo vyhodit z loga "like a professional", působí to jako sebeironie.
Přes to všechno: netuším, zda je v linuxu něco lepšího.
Díky za odpověď. Byl jsem na dovolené takže odpovídám až teď. Nedá se říci, že by mi udělala radost. Hlavní otázka v současnosti pro mne je, zda-li správu fotek budu moci udělat pod linuxem a nebo musím jít směrem virtualizace XP a správy buď ACDsee nebo Adobe Lightroom. Zatím mám tak pouze 40000 fotek, většinu jen zařazených v Canoním softu. V jistém směru je to nyní otázka dlohodobé volby, to co mám ještě jsem schopen překlopit do jiného softu ale až budu mít tak 150 000 fotek to si nedokážu představit že to změním, a to bude tak do 5 let. Takže k tomu co jsi psal.
Ad 1) OK. skript je možné řešení
Ad 2) No DEL sice jde, ale to markování, které má jak ACDsee tak lightroom tak třeba Canon DPP (což odhaduji, že máš podle přípony RAW) je, že separuješ od sebe označení a akci DPP třeba má značky 1,2,3. Procházíš fotky s tím, že je vlastně posuzuješ podle nějaké podmínky, např, je špatná, nebo je třeba moc světlá, nebo WB potřebuje posunout do teplé nebo studené atd. označíš tak sadu, můžeš si výběr zkontrolovat, přeznačit a až tehdy, kdy jsi spokojen, tak spustíš akci, jako výmaz nebo posun v barvě či jasu atd. Přímý DEL je těžké vzít zpět. A nikdy bych nemazal originální raw, disky jsou levné, a máš základ s nímž můžeš i v budoucnu pracovat. DTP studia běžně pracují s 16 bitovou barvou v souborech a v současnosti už jsou profi monitory s 10-bitovou barvou a dá se očekávat že za pár let bude 10-bitová hloubka i v tiskárnách, když to nesmažeš, máš zdroj, jak to využít.
Ad 3) Tady jsem spokojen, to je dostatečné.
Ad 4) Pokud to zkopíruješ mimo digikam, tak nevezeš s sebou tagy. V digikamu to zkopírovat lze, když to udělám jako přesunutí a puštení na jiný adresář ve struktuře alb, ale když tohle máš dělat pro 200 fotek tak je to strašně času. Když fotíš dynamické situace vyrobíš hodně fotek a pak je třeba vybrat ty, které danou atmosféru nejlépe zobrazují, takže procházíš a vybíráš. Ty jiné programy mají hot key, který přepíná označení/zrušení stejně jako třeba v Krusaderu mezerou markuješ soubory, naprosto nejefektivnější výběr, než to chytím myší, přesunu, pustím a vyberu z menu, že chci kopírovat, mám tím markovacím způsobem projítých 10 souborů. Mě to připadá jako triviální, ale naprosto nezbytná věc. A další kritická věc je rychlost přechodu mezi fotkami. Alespoň z hlediska práce s velkým množstvím fotek. Když fotím krajinu je to jedno. Počkám si na světlo, vyfotím tak 5 snímků, s čím nejsem spokojen, smažu už ve foťáku. Ale akční fotky, sport, párty, koncert, svatba, tam není čas, buď rychle mačkat spoušt nebo sériové snímání vyrobí kvanta fotek, někdy i přes 1000. A je třeba v prvé řadě vyhodit takové bez ducha, z každé sekvence vybrat tak 1 nebo 2 fota, která ji charakterizují. A když projíždíš sekvenci 30 fotek za sebou dopředu dozadu nekolikrát a hledáš tu 1 která je z nich nejlepší tak každé zpoždění je znát. Při dnešních pamětech nechápu, proč by to digikam nemohl mít předpřipravené v operační paměti takové pohledy, výřezy, jaké potřebuješ když stiskneš "next", na monitor se vejde tak 2Mpix což je tak 6 MB spotřeba paměti na fotku pro celoobrazovkový náhled, pokud tam mám panýlky, toolbary tak méně. Předpočítat 10 fotek dopředu a dozadu zabere jenom nějakých 20*6=120MB. ACDsee má přechod na "next" pod 0.1 sec, digikam tak 1-2 sec, což je při 1000 fotkách skoro půl hodina času na přechody jen při přechodech postupně dopředu, pokud porovnávám fotky přechody tam-zpět-tam-zpět několikrát za sebou tak ztráta narůstá mnohem více.
Ad 5.6) jasné
Ad interoperabilita) to je také závažné, vracím se s dovolené s 2000 fotek v notebooku a dalších 40k je ve stacionáru. Netuším jak to sloučit. Asi příště budu muset udržovat a synchronizovat dvě kopie databáze. Nechci zdrhnout s fotkami z linuxu, ale nástroj, který mi umožní během 2 hodin vybrat z 1000 fotek 30-50, které stojí za to a alespoň základním způsobem je doladit nemohu najít.
Z kontextu tuším, že to měla být odpověd na původní dotaz, nikoliv na můj příspěvek.
U bodu 3 bych vážně doporučoval nejprve vyzkoušet, obsahuje mnoho chyb (viz kde bugs).
Z těch, které mne trápí nejvíce je chybějící podpora UTF-8 pro IPTC (původní standard byl pro US ASCII, ale dnes se přímo doporučuje používat UTF-8) a s tím související chybný "přepis" UTF-8 českých znaků do US ASCII - digiKam používá nějakou knihovnu KDE, která pro převod považuje zdrojový text za latin1 (západní Evropa).
Je třeba též dát pozor na práci s různými programy ukládajícími informace do metadat fotky: digiKam považuje za obsahově shodné např. EXIF comment = IPTC caption = XMP Dublin Core Description = XMP Tiff ImageDescription (a obdobně pro štítky). Takže při případné editaci v jiném programu a následném zpětném importu do digiKamu nemusí výsledek úplně odpovídat očekávání. Je třeba vyzkoušet. Vím o čem mluvím, migroval jsem cca 15 tis. fotek s EXIF / IPTC metadaty, krásně jsem si procvičil exiv2 v bash skriptech, abych vyřešil různé "features" a chyby digiKamu.
A mimochodem - metadata se _vždy_ ukládají do databáze a navíc je možné je navíc současně ukládat to fotek. U některých operací to nefunguje automaticky (např. přejmenování štítku/tagu), takže je vhodné občas "sesynchronizovat" databázi s fotkami.
U bodu 2: Light table je dobrá věc, ale nelze tam přenést obrázky přímo z Image preview (resp. lze, ale jen ten jeden zobrazený a zbylé je tam pak nutné přetáhnout), pouze z album view, což otravně zdržuje. Pro rychlý výběr špatných/dobrých fotek stačila mnohem jednodušší věc: zachovat zoom při přecházení mezi fotkami v Image preview (vždy se vrátí na auto-fit).
Asi každý pracujeme s jinou fotografickou technikou. Když máš hloubku ostrosti 5cm nepoznáš z těch malinkých náhledů, kde přesně je zaostřené. Když fotím modelku je kritériem, aby měla ostré oči a řasy. Na náhledu jsou oči přes 4 pixely a řasy vůbec naprosto nic nejde poznat, jen kompozici, třeba že má zrovna teď ruku před obličejem. Ale markování už jsem si vyřešil, značení na 1 hvezdičku může zastoupit, to co chci. I když hvezdičky jsou myšleny jako permanentní marker tak tako tento jeden dočasný fungovat mohou. K tomu krename: to sice je možné, ale na druhou stranu jakékoliv operace mimo digikam poruší vazby mezi informacemi v jeho databázi. zkusil jsem si to testovacím způsobem a přišel po přejmenování o tagy. Ale základní přejmenovávání má. Nepsal jsem, že přijdu o rawy, ale ať rawy nemaže, když psal o skriptu jak je chce smazat. tiff je formát na práci a ne na ukládání, zkusil jsem si jich prá vyrobit ale můj 16bitový tiff má 120MB, což je opravdu i na mne moc na jednu fotku pak bych 1TB zaplácl s cca 8000 fotkami, což vyfotím za půl roku. Ale finálně už mám dojem že společně s programem Bibble to půjde zůstat pod linuxem s fotkama.
Tiskni
Sdílej: