Velký úklid v počítači

27.8.2014 16:52 | Přečteno: 3372× | Linuxové drobty |

Před časem jsem hledal, jak v systému najít duplikáty souborů a nechat jen ty, které jsou ty "správné". Ve finále jsem použil program fdupes.

Situace

V systému jsem tušil, že mám mnoho duplikátních souborů. Jeden zdroj pro takové duplikáty byly mé soubory na nichž mi záleží. Jsou to hlavně vytvořené fotografie a někdy také vytvořená videa. Jednak jsem za 10 let používal několik managerů na fotky, které ukládaly soubory v různých adresářových stromech, jednak jsem někdy při koupi nového disku na něj zkopíroval foto archiv, aby se fotky jistě neztratily i při poruše disků. A teď již ani nevím, kde všude fota mohou být. Za druhé jsou to zdroje z netu, které mne třeba zaujaly vícekrát a stáhl jsem je někdy více než jedenkrát.

Běh

Program fdupes -r /mnt /windows > duplicates1 běžel několik dní, prošel všechny připojené diskové systémy a nakonec vyprodukoval soubor duplicates1, který obsahoval 1616445 řádku a byl velký asi 150MB. Přičemž organizace souboru je takováto:

/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/standa/PC090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/S3/PC090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_1_/1209-1846-St090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_2_/1209-1846-St090085.JPG

/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/standa/PC090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/S3/PC090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_1_/1209-1845-St090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_2_/1209-1845-St090084.JPG

/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/standa/PC090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/S3/PC090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_1_/1209-1846-St090085.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_2_/1209-1846-St090085.JPG

/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/standa/PC090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky-zdroj/S3/PC090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_1_/1209-1845-St090084.JPG
/windows/zaloha_2/z_externiho/__Movie____/_STANDA_Argentina/Argentina-fotky/Argentina-fotky_2_/1209-1845-St090084.JPG

/windows/zaloha_2/Filmy/foto_zazalohovat/backup_/cfc-0012/dcim/165canon/mvi_6541.avi
/windows/zaloha_2/Filmy/video/Radek/nezpracovano/CFC-0012/DCIM/165CANON/MVI_6541.AVI
/mnt/crypted1/Foto/zpracovano/foto_zazalohovat/backup_/cfc-0012/dcim/165canon/mvi_6541.avi
/mnt/afx/obrazky/Photo_original/2006/norsko/avi/norsko-20111207_4403_1.avi
/mnt/basic/public/obrazky/obrazky/Photo_original/2006/norsko/avi/norsko-20111207_4403_1.avi
/windows/zaloha_2/foto_zazalohovat/backup_/cfc-0012/dcim/165canon/mvi_6541.avi

Tedy jednotlivé duplikátní soubory jsou sdruženy do bloků, vzájemně oddělených prázdnými řádky, a jednotlivé instance duplikátního souboru tvoří řádky následující po sobě v jednom bloku označené plnou cestou. Pořadí řádků v bloku můžeme považovat za náhodné a je pravděpodobně dané pořadím jak program procházel stromy adresářů. Otázka je, co s tím? Smazat několik set tisíc souborů tak, abych smazal ty které chci a ne ty které nechci.

Incrementální mazání

Vytvořil jsem si proto dva skripty, kterými jsem postupně vytvářel mazací příkazy. Skript 1: pracovní název uklid_1

#!/usr/bin/perl
use strict;
use warnings;

use Path::Class;

my $path="/mnt/hlavni/obrazky/Photo_original";
my $spath="/mnt/public/obrazky";
my $extension=".CR2";
# my $teststr="/mnt/afx/obrazky/Photo_original/2006/norsko/avi/norsko-20111207_4403_1.avi\n";

my $dir = dir("/home/user/tmp"); # tmp dir with output from fdupes
my $cnt = 1;
my $name = "duplicates";
my $delname = "dupdelete";

my $file = $dir->file($name.$cnt);
my $filenewdup = $dir->file($name . ($cnt+1));
my $filedelete = $dir->file($delname . ($cnt+1));
my $filelog = $dir->file($name . ($cnt+1) . ".log");
my $abc = 0;


# openr() returns an IO::File object to read from
my $file_handle = $file->openr();
my $file_handledup = $filenewdup->openw();
my $file_handledel = $filedelete->openw();
my $file_handlelog = $filelog->openw();
my @mujlist;
my $n=0;
my $i;
my $j=0;
my $c=0;



$file_handlelog->print("Blocks generated for deletion:\n");
# Read in line at a time
while( my $line = $file_handle->getline() ) {
       push(@mujlist, $line); $n++;
# if inblock add line end of block
  if ( $line =~ /^$/){
#      print "d".$n . "\n";
      $j = 0;
      foreach $i(@mujlist) {
# if exists in block requested file flag $j for deletion 
        if ((index( $i,$path) ge 0) and (index( $i,$extension) ge 0))
        {$j = 1;}
      }
#      print scalar @mujlist . "\n";
      if ($j == 1) {
# generate delete set or ($k=~/^$/)
        foreach my $k (@mujlist) {
          if (((index( $k,$path) lt 0) or (index( $k,$extension) lt 0)) and not ($k=~/^$/) and (index( $k,$spath) lt 0) ){
            chomp $k;
            $file_handledel->print("rm \"" . $k."\"\n");}

        }
# generation end
      $file_handlelog->print("Blok begin " . ($n-scalar @mujlist) . " end ".$n."\n");
      $c++;
      }
      else {
        foreach my $k (@mujlist) {
          $file_handledup->print($k);
        }
#       $file_handledup->print("d".$n."\n");
      }
      @mujlist=();
  }
  else {

    }

}
chmod  (0755, $file_handledel);
$file_handlelog->print("Number of block processed = " . $c."\n");
#print "count = $abc\n i = $i\n j = $j\n";

V současnosti nemají skripty žádný CLI, a jejich ovládání se děje editaci stringů na řádcích 7-15. Funkcionalita je následující:

1. Program očekává, že v adresáři $dir (v tomto případě /home/user/tmp) bude soubor $name.$cnt (v tomto případě duplicates1), vytvořený programem fdupes podle výše uvedeného formátu.
2. Program vytvoří soubory $name.($cnt+1), $delname.($cnt+1) a ($name.($cnt+1).".log" v tomto případě soubory duplicates2, dupdelete2 a duplicates2.log. Do kterých zapíše: Do souboru dupdelete2 sadu příkazů rm "path" pro smazání duplikátních souborů, a souboru nastaví executable flag. Do souboru duplicates2 zapíše upravenou kopii souboru duplicates1, která má vyřazené ty bloky, které byly zpracovány a z nichž byl vygenerován mazací script. Do souboru duplicates2.log napíše seznam bloků, které byly zpracovány, s počátečním a koncovým číslem řádku v souboru duplicates1
3. Logika zpracování: V $path je primární datový strom, který bude zachován a v $extension je string, který musí název souboru obsahovat, aby byl zpracován (typicky je to ukončující string názvu souboru - extenze). Pouze bloky duplikátních souborů, které obsahují soubor s touto podmínkou (patří do stromu a mají string) jsou zařazeny do zpracování. Ke všem souborům daného bloku bude vygenerován mazací příkaz s výjimkou těch, které obsahují string $path nebo $spath sekundární strom/úložiště

Program je možné používat inkrementálně. Zvýšením hodnoty $cnt=2 bude vstupní soubor duplicates2 a výstupní soubory duplicates3, dupdelete3 a duplicates3.log. Také je možné si postupně kopírování skriptu na uklid_2 s hodnotou $cnt=2; atd vytvořit inkrementální sadu skriptů, které definují postupně duplikátní části a vytváření skripty na jejich mazání a faktické mazání spustit, až když jsem s celkovou posloupností spokojen.

Duplikátní soubory v jednom adresáři

Skript uklid_1 funguje výborně na vlastní data, kdy vím, že v jednom adresáři nebudu mít duplikátní fotku. U informací získaných se může stát, že v jednom adresáři budeme mít pod různými jmény více totožných objektů, třeba získaných v různých časech. Uklid_1 by je nechal všechny. Vytvořil jsem si proto skript 2, pracovní název uklid_a1. Je to drobná modifikace v části generující mazací přikazy, která ponechá pouze jediný objekt v adresáři specifikovaném v $path.Všechno ostatní je označeno ke smazání. Cesta $spath se nevyužívá a ten který zůstává je první soubor z bloku v dané cestě (i když třeba nemusí mít nejlepší jméno)

# generate delete set or ($k=~/^$/)
        $cjump = 0;
        foreach my $k (@mujlist) {
          if ((((index( $k,$path) lt 0) or (index( $k,$extension) lt 0)or $cjump) and not ($k=~/^$/)) ){
            chomp $k;
            $file_handledel->print("rm \"" . $k."\"\n");}
          else {$cjump=1;}
        }

(plus je ještě třeba zadefinovat $cjump někde nahoře.)

Tímhle způsobem jsem smazal větší část z nalezených duplikátních souborů a uvolnil si prostor. Možná když budu mít čas, tak ke skriptu doplním ještě nějaké CLI, sloučím skripty do jednoho s přehozením CLI volbou a doplním skripty, které by jednak počítaly obsazený prostor duplikáty, jednak mohly setřídit soubor duplicatesX inverzně podle velikosti souborů, aby se člověk zabýval tím, co přinese prostorový zisk a ne malinkými soubory. (samozřejmě nejvíce duplikátní soubor je ten s velikosti 0 bytů.) Ale teď mi pro můj problém toto řešení stačí

       

Komentáře

[Bedňa]

Riešenie s fotografiami je jednoduché. Drž zbierku v takom meradle, že to teba, alebo niekomu komu to budeš ukazovať dokáže baviť pozerať a nie nudiť.

Ja viem, že väčšina ľudí na to nedá a keď sa kolegovi narodila dcéra, tak mal po mesiaci niekoľko tisíc fotiek, spýtal som sa ho kto to dokáže odpozerať. Opoveď bola že hádam nemôže mazať fotky s dcérou.

Takže buď nekompromisne mažeš, dokážeš to rozumne sortovať a zálohovať aspoň na dvoch miestach inak nemajú žiadnu cenu a nikoho neukecáš na to pozrieť si ich, alebo ak áno druhý krát už nepríde. Sám tam nikdy nenájdeš čo si chcel.

[FrostyX]

S tím bych mohl souhlasit. Když mi někdo ukazuje fotky a já mám koukat na bambilion fotek, kde každá je stokrát dokola, jen trochu jinak, je to dost otrava. Případně na facebooku, když každý den přibude deset fotek stejného mimina, ve stejné poloze a ve stejném oblečení, nevím co si o jeho rodičích už myslet.

Na druhou stranu si dovedu představit, že na stáří bude člověk za slušnou sbírku fotek rád. Teda pokud to bude alespoň trochu v rozumné míře a nebude litovat, že místo toho, aby se např věnoval svému dítěti když rostlo, tak ho vlastně jen pozoroval z dálky a fotil. Takže bych úplně radikálně nepromazával, spíš jen tagoval *top* fotky a pouze ty ukazoval ostatním.

[gtz]

facebooku

strašná moda a ani si člověk neuvědomuje, že k fotografiím co tam narval už nemá práva.

[Bedňa]

Fotkám na večné časy dávam meno a potom viem podľa čoho hľadať. Hádžem ich do kategórií čím mám zas ďalší filter, samozrejme ako som písal, ide o kritické mazanie a kto si raz za čas na to nenájde čas určite príde k problému ale ukážem ti fotky z dovolenky a po desiatich minútach ide návštevu jebnúť páč zaujímavé fotky začínajú možno o 100 fotiek ďalej ako ste začali.

[gtz]

jistě máš pravdu, ale problém někdy je ten, že zkoušíš xx managerů, každý si to chce nasáčkovat k sobě a pak ty fotky bobtnají. A když zálohuješ, protože se bojíš o data tak ty místa a úložiště bobtná. Ideální je aby foto manažér nechal fotky tam kde jsou a jen si udělal odkaz apod. do své databáze. Ale takových moc není.

[Bedňa]

Nemám skúsenosti s rôznymi foto manažérmi, ale určite by náhľady a podobne nemali rvať medzi Fotky, to potom môže byť fakt vážny problém hlavne pri zálohovaní a skriptoch, ktoré rozhodujú čo zálohovať.

[Josef Kufner]

~/.thumbnails

[|🇵🇸]

Co když se focením živí?

[Bedňa]

Tak by to doporučenie mal ešte znásobiť a nechávať si len TOP pre zákazníkov.

[|🇵🇸]

Nikoliv, pokud záleží primárně na obsahu fotky. Příklad: když budu dělat atlas rostlin, potřebuju ke každé kytce několik různých fotek (příp. kreseb).

[Bedňa]

Příklad: když budu dělat atlas rostlin, potřebuju ke každé kytce několik různých fotek (příp. kreseb).

Kámo ale v blogu som nezaznamenal nič o odbornej fotografií, pretože to má zmysel vďaka študovaniu niekoľkých záznamoch (Nehovoriac o makrách kde softvér skladá obraz aj zo stoviek záznamov). My sa tu ale bavíme (teda kurwa myslím) o foto pre svoje pamäti, aspoň tak mi to vyplynulo z blogu.

[|🇵🇸]

IIRC OP někde psal, že fotí (polo)profesionálně, pokud si to s někým nepletu.

Netuším, co fotí, nýbrž píšu podle toho, s čím se setkávám – ten tvůj komentář (všechny) totiž zní jako přehnaná generalizace.

[lertimir]

Neživí mne focení, fotím pro radost, a občas někomu na zakázku. Ale to s čím fotím nyní je poloprofi vybavení, konkrétně fulframe zrcadlovka Canon 5DMkII. Problém s fotkami vznikl jednak historicky díky různým správcům fotek, nejdříve asi 4 roky ACDSee, pak asi další 4 (možná 5) roky Lightroom a DxO na RAWy, ale čím více jsem byl trvale v linuxu, tím více mne štvalo rebootovat do Windows, abych mohl fotky upravovat, vyhýbal se tomu a skládal to větších pracovních celků, nedalo se to dělat tím, že teď něco dělám v linuxu, dám si přestávku a upravím 5 fotek. Navíc tento režim začal dělat větší chaos i v tom, že jsem když jsem byl v linuxu, soubory s fotáku, nebo soubory, které jsem třeba předzpracoval na notebooku, ukládal do dočasného místa a teprve později se k nim vracel v Lightroomu a zařazoval je do databáze. (samozřejmě kromě zakázek, které jsem zpracoval hned). Takže zdrojové fotky byly na mnoha místech.

Pořád skřípu zuby nad tím, jak jsou ty linuxové fotoeditory hrozné. Ale na rozdíl od situace před 5 lety, kdy to používat v podstatě nešlo, teď už používat jdou, byť se skřípěním zubů. Problém není v rysech, fičurách a funkcích. Ty už jsou v podstatě všechny potřebné. Nadávám na workflow. Moje raw fotka má 21Mpix a 24-34MB, i jpeg má od 5 do 14 MB na fotku podle dynamiky obrázku a ISO, rychlost práce s nimi je strašná právě proto, že ty editory/prohlížeče nic nedělají když se na fotku koukám, ale příští fotku začnou zpracovávat až když se odhodlám zmáčknout next. Ale jak jsem psal už se s tím dá žít, a je to pro mne lepší než rebootovat do windows. V současnosti má základní archiv původních originálních fotek přes 500GB, rozhodně je to o dost méně než polovina z toho, co jsem skutečně nafotil, ale také ještě do něj není stažené vše. Pro ukázku vám posílám jednoho pavoučka z makro fotek. Pavouček i když je dost redukovaný v kompresi tak zařadit nejde pro velikost, takže jsem jej dal na http://ulozto.cz/xpmwU2Ub/lipa-20110911-596-jpg. Jen tak mimochodem, když zařadím velký soubor do diskusního příspěvku je to opruz, co s tím. Náhled komentáře mi neprojde protože soubor je příliš velký, a položka nejde vymazat. Musel jsem vytvořit soubor o nulové velikosti a ten zařadit.

Ale fotky byly jen část té otázky s duplikátními soubory. Druhá podstatná objemová část byly videa z netu.

[Michal Kubeček]

rychlost práce s nimi je strašná právě proto, že ty editory/prohlížeče nic nedělají když se na fotku koukám, ale příští fotku začnou zpracovávat až když se odhodlám zmáčknout next

Editory nevím (používám GIMP), ale z prozhlížečů třeba geeqie (nástupce gqview) umí preloadnout následující fotku (možná i víc).

[lertimir]

To nejde.

Představ si situaci, přijdu s fotákem mám řekněme 20GB fotek, něco RAWy kdy je třeba max kvalita, něco jpegy a něco snímky kde jsem vzal oboje, jpeg by měl stačit, ale muže být že podmínky vyžadují táhnout kvalitu z RAWu. V první fázi potřebuji zredukovat cca 1000 fotek na cca 150. tedy na klasifikovat 1.smazat. 2. použitelné. 3. ano kvalitní. V téhle fázi řeším technickou kvalitu, to znamená, že pokud třeba fotím modelku a mám clonu tak aby DOF bylo cca 20 cm, tak pokud zaostřím kousek blbě, je to špatně, protože půl hlavy bude neostré. Ten prohlížeč mě musí umět fotky rychle projít, namarkovat na uvedené kategorie, provést na kategorie výběr, umět rychle přepínat mezi celou fotkou a 1:1 zobrazením pixelů, ty výběry někdy přemarkovat a následně ty nevybrané smazat. S tím, že to smazání bude třeba někdy po týdnu, kdy se rozhodnutí o těch špatných stabilizuje. Někdy je vhodné i mít další selekt jako jsou barvičky v digikamu na selektování jedné situace. Ty jednoduché prohlížeče fotek sice prohlíží rychle, ale to je tak vhodné na to, když mám hotové fotky v adresáři a chci je ukázat návštěvě.

gqview neznám, protože pracuji v KDE, ale je tam gwenview a očekávám, že je téhle kategorie. Má to preloadle, přeskakuje rychle, ale nedá se s tím managovat

digikam je na udržbu fajn, ale hodně pomalý, kdybych ho mohl nastavit tak, že si vezme jen pro sebe 16GB paměti, ale bude tam mít 10 fotek dopředu dozadu rozbalené, v 1:1 výřezech a celých pohledech na fotku a když přehodím na next bude to okamžité tak už skoro nemám výhrad. No možná ještě jednu dotaženou integraci mezi RAW developerem (patrně rawtherapee) a managerem. Ve win propojení mezi Lightroom a DxO celkem fungovalo. A pokud je třeba upravou křivek tahat ty další bity informací z RAWu jsou kvalitní raw defeloper který se nastavuje mimo default velmi potřeba.

[Michal Kubeček]

gqview neznám, protože pracuji v KDE

To by neměl být problém, já taky mám KDE a coby prohlížeč používám v podstatě jen geeqie (dříve gqview).

Z toho prvního odstavce bych asi jako jediný problém viděl to, že geeqie sice umožňuje togglovat šest nezávislých značek a pak podle nich kombinovat výběr, na který lze aplikovat hromadné akce, ale ten výběr se neukládá při ukončení programu (ale možná by to někde šlo nastavit, to jsem nezkoumal).

[Rad]

mne se casem osvedcil a uz leta pouzivam docela primitivni system:

- fotim RAW i JPG

- ukladam vsechno do jednoho adresare: RRMM (RR: rok, MM: mesic) a v nem zvlast adresar pro RAW

- kdyz je nejaka akce, kde jeste nasekam vice fotek (tematicke foceni - treba pro animovany film, nebo dovolena, ...), tak jeste udelam dalsi adresar (JPG a pak zvlast RAW)

faze 1: na prehled (JPG) pouzivam gthmub (pokud si dobre pamatuju), co se mi oparvdu (ale opravdu) nelibi, mazu.

faze 2: spoustim skript, ktery maze vsechny RAW, ke kterym neni referencni JPG

na upravy (RAWu) pouzivam bud GIMP (velice silny nastroj - jedina nevyhoda: pouziva dodnes bohuzel jenom 8bit hloubku. na bezne veci opravdu staci, na web, papir pro rodinu, ale profi bilboardy bych v tom ale nedelal) a MyPaint (jednodussii editor)

uppravene fotky (jakysi TOP of TOP pro prezentaci, darovani, ...) pak davam bokem ('akce', rodina, ...). je to manualni prace, ale ma to vyhodu: presne vim, co kde mam.

skeny z negativu mam zas zvlast: adresare podle cisla negativu (jako index), k nemu vedu zaznamy kdy to bylo focene (obdobi), cim (aspon aparat - mam cca 30 strojku), a cca co to je

zkousel jsem ruzne manazery - dopadlo to vzdy katastroficky: bordel1, bordel2, bordel3 sice miluju zautomatizovat co se da (protoze jsem desne liny), ale tady se ukazala jakakoliv automatizace desne kontraproduktivni. ledaze bych si napsal vlastni manazer fotek (na to jsem zas liny)

tak snad je ta informace k necemu

PS: desne nerad neco mazu - ukazalo se, ze nekdy po letech tam objevim vecicku, ktera stoji za to si s ni pohrat. clovek se posune nekam jinam, zmeni se mu vnimani - treba kdybych byl kdysi mazal kdejaky rozmaznuty snimek, dnes bych prisel o vzacne snimky (naladovky, neskutecne nahody, vzpominky)

:)

[Josef Kufner]

Já mám na automatizaci skript, který stahuje fotky z SD karty – mount && mv && umount. Cílový adresář vytvoří podle dnešního data. Pokud to je nějaká akce, Adresář přejmenuji podle názvu akce, případně upravím datum (akce byla včera) a přesunu mezi tříděné.

Pokud mám k dispozici GPS log (podobný script na stažení z GPS loggeru), nechám spárovat s fotkama podle času (gpscorrelate) a skriptem nechám nakreslit PNG s mapou trasy. To celé přihodím k fotkám.

Takže i když fotky nijak zvlášť netřídím, tak mám uspořádané balíčky, které dávají smysl.

Btw, v geeqie se mi osvědčilo mít nastaveno mazání do koše a koš nastavený jako ./trash. Takže nedokonalé fotky jdou do podadresáře u fotek.

[Michal Kubeček]

To jsou ale dvě nesouvisející věci. Nevidím žádný problém v tom, abych si na jedné straně archivoval všechny fotky kromě technicky úplně zkažených, ale na druhé ukazoval ostatním jen rozumně malý zlomek z nich.

[Bedňa]

Tak ukáž techniku ako to odfiltruješ a napíš dôvod prečo ukazovať fotky tu sme ležali a tu sme ležali o 5minút neskôr, potom o desať... nedá sa to filtrovať, nikdy viac si ich nepozrieš, rovnako ako môj kolega, akurát ich máš moc "a to sa oplatí".

[Nicky726]

Na to lze použít hvězdičkování a pak ukazovat jen ty, co překročí určitou hranici. Současně se ale snažím rozumně promazávat a pro vyhledávání ještě štítkovat. Akorát je takové pořádání časově náročné.

[xkucf03]

Pořád je ale lepší, když to udělá fotograf jednou, než když to neudělá a pak promítá znuděným divákům tisíce fotek.

[|🇵🇸]

To záleží na tom, jestli má fotograf k těm fotkám také co říct.

[Michal Kubeček]

Kdyby měl být stejný celkový čas, tak ano. Určitě je příjemnější za hodinu vidět 120 fotek s půlminutovým zajímavým komentářem ke každé než 720 fotek po pěti sekundách s dvouslovným nebo vůbec žádným komentářem ke každé. Ale pokud by v obou případech měl být stejný počet prezentovaných fotek a mělo jít o několik set, tak už je to IMHO jedno, oboje bude ubíjející. Výhoda je ale, že toho, kdo prezentuje rozumnou formou, nenapadne takhle prezentovat 600 fotek, zatímco uspávání návštěv slideshow 600 a více fotek přesně tak, jak vylezly z foťáku, už jsem bohužel několikrát zažil.

[|🇵🇸]

Varianta (b), dotyčný hovoří a na pozadí běží fotky dokreslující to, o čem je řeč. Nedokážu si to představit v případě „jak jsme se dva týdny váleli v Chorvatsku“, ale u „obrazil jsem půlku památek v Kjótu“ ano.

[Michal Kubeček]

a napíš dôvod prečo ukazovať fotky tu sme ležali a tu sme ležali o 5minút neskôr, potom o desať...

A proč bych podle vás měl psát důvod k něčemu, co jsem výslovně napsal, že se dělat nemá?

[kavol]

+1 ... já si tedy archivuju skoro všechny, včetně těch technicky úplně zkažených, aby mi nechyběly čísla v sekvenci a nechytl jsem paniku, že jsem omylem smazal něco důležitého nebo že se mi rozpadá filesystém, ale jinak souhlas

(vyjímku tvoří fotky z telefonu, které jsou pojmenované timestampem, u těch se mi sekvence smazáním jedné nerozpadne, navíc se snažím nefotit na telefon věci, na kterých mi záleží, nýbrž jenom "pracovní poznámky")

pak je postup takový, že po stažení fotek si je tematicky roztřídím (rozházím do adresářů podle toho, ze které akce jsou, a pokud nejde o nějakou akci, ale ad-hoc, tak většinou podle místa anebo motivu, rozdělené po rocích), vybrané adresáře potom proženu convertem abych si vygeneroval menší verze souborů, již zpootáčených podle exif, a tyto rozkopíruju mezi to, co chceme někomu předat osobně (což jsou aktuálně vpodstatě jen fotky dětí, které při návštěvě kopírujeme prababičkám na karty ve fotorámečcích), a to, co chci plácnout na web, no a potom podle toho, jak nás kdo moc otravuje nebo jak moc se chceme pochlubit, tyto kopie se ženskou probereme, smažeme z toho nepovedené, duplikáty a nudné[*] fotky, a to hodíme do galerie, eventuelně prezentujeme osobně (a to, o co nikdo neotravuje, mi hnije "k probrání" léta )

[*] tady je trošku problém, že některé věci chci mít plácnuté na webu jen kvůli dokumentární hodnotě, čili pak je nudné, třeba když na české řece člověk typicky potká za den pět-šest jezů, a z každého mám dvě-tři fotky bez jakékoli akce, jen aby byl dobře vidět profil a průjezd, případně nebezpečí

[Sajfi]

Ano, je to vlastně známý citát, že "Nejlepším přítelem fotografa je odpadkový koš.". Sám se držím pravidla, když někde promítám fotky z cest, maximálně 100 fotek a maximálně do hodiny, aby to lidi udrželo při pozornosti.

Funguje to tak, že když vyvoláte film a zarámečkujete dia (dnes spíše stáhnete kartu z foťáku), vyřadíte jen technicky špatné fotky, ostatní je úžasné, protože pořád máte v hlavě kontext. Pak si to projedete za týden, najednou toho už tolik úžasného není, hlava už trochu zapomněla a hodně toho vyřadíte. No a pak je dobré to založit, zapomenout a po půl rokce, jednom roku, když si to znovu projedete, opět vám spousta fotek nic neříká a vyřadíte je. No a nad tím zbytkem má teprve cenu se začít zamýšlet, protože v tu chvíli na to koukáte už docela nezaujatě, vlastně podobně, jako někdo, kdo tam s vámi nebyl a nezná kontext.

[Bedňa]

Postupujem nejak podobne. Nieje nič horšie ako nudiť rodinnú sešlosť stovkami fotografií.

Osobne všetko sortujem a podstatným dávam meno. Keď si chcem zaspomínať aspoň viem kde to je a nepreberám sa povlom.

[JS1]

To je takovy folklor. Nase generace ty miliony fotek (a jineho balastu) nasbira, ale nebude mit srdce to vyhodit. Nastupujici generace, bez zateze s tim spojene nostalgie, to pak probere a vyhazi. Mozna si schova par skutecnych perel. Ale to uz nam bude jedno.

[xkucf03]

To bych spíš tipoval, že se to bude navěky válet někde na disku, než že by to někdo probíral a selektivně promazával. Stačí se podívat, s jakými objemy dat pracovala předchozí generace – z pohledu velikosti dnešních disků naprosto směšné množství → není potřeba nic mazat, nic tě k tomu nenutí a klidně si můžeš nechat všechno.

Spíš se ta data budou zpracovávat automaticky – rozpoznávání obličejů nebo míst a předmětů na fotkách – třeba nějaký tvůj vnuk položí dotaz nad rodinnou databází fotek a vytáhne si všechny, na kterých jsi ty nebo určitá kombinace osob. Nebo třeba bude sledovat, jak se měnil určitý dům nebo ulice v čase

[Josef Kufner]

Teoreticky, pokud má něco v názvu "záloha", tak by to mělo být možno v klidu smazat, neboť někde je originál, který byl zálohován.

Jinak deduplikaci můžeš provést výměnou souborů za hardlinky. Struktura ti zůstane, místo se uvolní. A jako bonus o nic nepřijdeš.

V druhém kroku doporučuju si tam udělat pořádek. Fotky mají datum a použitý přístroj v EXIF, podle toho je lze časově snadno seřadit a seskupit. Pak stačí jen popsat, co to bylo za akci, ale to už píšeš po adresářích, kterých je obvykle o dva řády méně než fotek.

Při úklidu je dobrou strategií začít přesunem úplně všeho do adresáře "staré harampádí" a vyzobávat si postupně to, co je podstatné. Co tam zbyde může být v klidu archivováno pro případ, že se tam něco podstatného zapomnělo, ale obvykle už se na to bude jen prášit na starém nepoužívaném disku.

[manasekp]

ja jsem takovou situaci elegantne vyresil smazanim celeho disku(omylem). Pak jsem ziskal zpet ze zaloh jenom to opravdu dulezite a zbytek zmizel

[Dreit]

Já před asi dvěma lety řešil hledání duplicit, když jsem sesypal na hromadu fotky ze dvou notebooků a všech SD karet co jsem našel. Napsal jsem si na to tehdy i BASH skript o pár řádcích.

 

1) přesypu všechno do jednoho adresáře a spustím skript

2) skript se podívá do EXIF dat na datum a čas, který se ve formátu 2014-08-02_05-40-12 uloží do proměnné jako budoucí název fotky

3) následně se podívá do adresáře (názvy 2014-05, 2014-06 apod.) jestli už tam fotka s takovým názvem existuje

4a) pokud neexistuje, tak fotku přejmenuje na název z proměnné a uloží do odpovídajícího adresáře

4b) Pokud už fotka se stejným časem existuje, použije se srovnání MD5 součtů proti všem fotkám se stejným datem a časem v adresáři. Při shodě se fotka nekopíruje. Pokud se součet liší, připíše se na konec další pořadové číslo v řadě a fotka se překopíruje.

 

K dokonalosti to má ale daleko. Třeba program pro import fotek ve Windows Vista zasahoval do fotek i když je měl jen kopírovat, takže u několika pixelů se nepatrně lišila RGB hodnota (WTF?!) a tím pádem ani nesedí MD5 součet a vznikají duplicity.

 

P.S.: Nakonec to vypadá, že problém se vyřešil sám. Rodiče už několik let přemlouvám aby si fotky přetřídili, doteď se k tomu nedostali a vymlouvali se. A teď koukám na RAID1 oddíl a po fotkách se slehla zem

[Dreit]

Zapomněl jsem dodat, že fotek bylo při posledním sčítání asi osm tisíc, z čehož by kolem tisíce (bez legrace) mohly tvořit fotky kočky v rozličných polohách a situacích.

[|🇵🇸]

Nevím, ale to zní jako práce na několik kliknutí s něčím jako FreeFileSync.

[=^..^= AmigaPower®]

Nechápu že při dnešních kapacitách disků někdo řeší duplicitu, to sem dělal naposled s Amigou bez HD...