Open-source citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 9. Přehled novinek v příspěvku na blogu.
Libre Graphics Meeting 2026, tj. čtyřdenní konference a setkání vývojářů a uživatelů svobodných a otevřených grafických softwarů, proběhne od 22. do 25. dubna v Norimberku. Dění lze sledovat na Mastodonu.
Vývojář Alexandre Gomes Gaigalas na GitHubu zveřejnil c89cc.sh, parser a kompilátor jazyka C89 napsaný v pouhém jediném skriptu o přibližně 8000 řádcích čistého bashe (bez dalších externích závislostí), který generuje ELF64 binárky pro x86-64. Jedná se o velmi jednoduchý kompilátor, který nepodporuje direktivy #include a dokonce ani funkci printf (lze použít puts), všechny dostupné deklarace lze nalézt v proměnné _BUILTIN_LIBC na konci skriptu. Skript je volně dostupný pod ISC licencí.
Francouzská vláda oznámila, že v rámci strategie 'digitální suverenity' zahájí 'přechod od systému Windows k počítačům s operačním systémem Linux' (sa sortie de Windows au profit de postes sous système d'exploitation Linux). DINUM (meziresortní ředitelství pro digitální technologie) požádalo ministerstva, aby do podzimu 2026 vypracovaly konkrétní plány nasazení Linuxu. Francie již dříve migrovala části státní správy na otevřená řešení.
Nezisková organizace Electronic Frontier Foundation (EFF) hájící občanské svobody v digitálním světě po téměř 20 letech opouští platformu X (dříve Twitter). Na platformách Bluesky, Mastodon, LinkedIn, Instagram, TikTok, Facebook, Threads a YouTube zůstává.
Terminálový textový editor GNU nano byl vydán ve verzi 9.0. Vylepšuje chování horizontálního posouvání pohledu na dlouhé řádky a chování některých klávesových zkratek. Více v seznamu změn.
Ministerstvo financí ve spolupráci s finanční správou dnes představilo beta verzi aplikace využívající umělou inteligenci pro předvyplnění daňového přiznání. Není třeba přepisovat údaje z různých potvrzení, ani hledat správné řádky, kam údaje napsat. Stačí nahrát dokumenty a využít AI.
Výrobce počítačových periferií Keychron zveřejnil repozitář se schématy šasi klávesnic a myší. Licence je restriktivní, zakazuje většinu komerčních užití a v podstatě jsou tak data vhodná pouze pro výukové účely, hlášení a opravy chyb, případně výrobu vlastního příslušenství.
Správce balíčků APT, používaný v Debianu a odvozených distribucích, byl vydán ve verzi 3.2 (seznam změn). Mezi novinkami figurují nové příkazy pro práci s historií, včetně vracení transakcí.
Společnost Anthropic oznámila Projekt Glasswing a s ní související AI model Claude Mythos Preview. Jedná se o iniciativu zaměřenou na kybernetickou bezpečnost, do které se zapojily velké technologické společnosti Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA a Palo Alto Networks. Anthropic věří, že nový AI model Claude Mythos Preview dokáže
… více »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: