képrendező

 ( pch | 2013. szeptember 12., csütörtök - 19:11 )

Üdv!

Olyan képrendező kategorizáló progit keresek amivel megoldható az alábbi probléma:
Sok kép sok könyvtárba van.
Van olyan, hogy több azonos kép több könyvtárba is megvan.
Cél:

Minden képből csak egy legyen.
Lehessen kategorizálni. (pl.: család, esküvő, keresztelő, etc)

Ne(!) rakja évszám/hó/nap szerint alkönyvtárakba

Lehetőleg GTK alapú legyen.

Tudtok valamit ajánlani?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Kérdés:

Valójában valami olyasmit szeretnél ami összeönti a képeidet egy helyre utána pedig cimkézi őket?
Esetleg olyasvalamit ami békében hagyja a fileokat csak csinál egy nagy listát.. amit cimkék szerint tud utána túrni?

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Első körbe a duplikációkat kellene eltüntetni.
Ezek után lehetne keresni pl.: arc szerint, (de gondolom ez még nem megy)
Szóval marad a kézi címkézés, és könyvtárba másolás.

pch

--
http://www.buster.hu "A" számlázó
--

picasa

Én régen szórakoztam az imgseek-kel. pyQt, szóval nem gtk, de tud pár mókás dolgot. Egyrészt lehet vele duplikációkat keresni: http://www.imgseek.net/desktop-version/user-s-guide#batch , másrészt tud olyat, hogy rajzolsz egy ábrát, és ahhoz hasonlót keres a képek között.

A doksiban azt írja, hogy sok kép hozzáadása lassú, de majd dolgozik rajta... nos, úgy látom hogy az utóbbi 6-8 évben erre nem került sor :D

Ez, ha jól rémlik a sok év távolából épp jó lehet. Nekem túl bonyolult - és lehangolóan lassú - volt, más utat választottam.

És az a más út titkos?
Nekem is pont ugyanez kellene mint pch-nak.
--
AGA@
Fork portal és az egyik logóm :)

Ehe, nem, csak túl egyszerű :D Eleve csak raw-ba fotózok, így jpeg kép csak elvétve kerül be, amúgy:

/data/Images/$ÉV/$DÁTUM-egyedi-megnevezés-helyszín-miegyéb itt laknak a raw képek. Ez alatt a bib könyvtárba kerülnek a kidolgozott jpeg, a tiff8 vagy tiff16 könyvtárba kerülnek a nyolc illetve tizenhat bites tiffek, a proof alá meg a mintaképek, amire egy watermarker ráírja a "minta proof" szöveget (http://blog.fisher.hu/index.php/2013/04/21/egy-jobb-watermarker/). Már ha ezekből készül ugye, proof sok szokott lenni, jpeg kevesebb, tiff mégkevesebb, plusz ezeket általában törlöm is.

Jham, a raw képek mellé - ha olyan a fotósorozat - néha írok metadatát, pl. helyszín, előadók, ilyesmik. De ezt már a raw konverter tárolja a saját fájlaiban.

Ja igen, és felmásoláskor minden fájlról készül egy md5sum, hogy időnként lehessen ellenőrizni a fájlok épségét.

Ahha. Akkor nálam ez az utolsó kitétellel ... együtt bukott :)
--
AGA@
Fork portal és az egyik logóm :)

Szerencsére anno kb. így kezdtem el, mert script másolta fel a képeket, és mi lett volna más, mint a dátum a könyvtárnév. Erre engedtem rá mindenfélét (pl. az imgseek-et is), hogy na majd aztán... aztán az lett, hogy ezeket feladtam, és 2004 Júliusától kezdve már az "új" módszert használom.

A deduplikációt egy scripttel meg tudod oldani. Minden file-ról generálsz hash-t, leteszed egy index file-ba. Ha azonos a hash, nézel fileméretet, ha az is azonos, akkor cmp-vel összehasonlítod a két file-t. Egyezés esetén azonos a két file, az egyiket törlöd, ha kell a hivatkozás, csinálsz helyette symlinket.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ez egyébként milyen hash algo, hogy utána még a biztonság kevéért fileméretet nézegetni és cmpzni kell, crc2?
mert azért ezt én sem értem, pedig én már sok mindent nem értettem itt

Ha úgy gondolod, hogy két különböző file-ból képzett hash garantáltan eltérő, akkor igen hatékonyan sikerült mondjuk néhány MB-nyi képfile-t alig néhány 10 byte-ra tömörítened. Persze értem én, hogy roppant kicsi annak a valószínűsége, hogy különböző file-okból azonos hash képződik, de nem nulla.

Elismerem, lehet, valami elkerülte a figyelmem, meggyőzhető vagyok, de valamiért ezt gondolom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

nem, locsemege, ezzel nem sikerült mondjuk néhány MB-nyi képfile-t alig néhány 10 byte-ra tömörítenem

Magam is ezt mondom. Vannak a file-jaink, amelyből hash-t számolunk. Ez az értelmezési tartomány lényegesen nagyobb, mint az az értékkészlet, amely halmazon a hash keletkezik, szükségképpen az értelmezési tartomány különböző elemeihez rendelődik az értékkészlet azonos eleme. Tehát a hash függvényünk inverze nem függvény.

Még mindig tévedhetek, de még mindig úgy érzem, hogy jól mondom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

van sok-sok nagyságrenddel kevesebb fileod, mint "az értékkészlet, amely halmazon a hash keletkezik", nagyságrendileg azonos mérettel

rákérdeztem a hash algod minőségére, erre hülyeségekkel fárasztottál, itt tartunk most

Ha az algoritmus tud az összes file-ról, akkor igazad lehet. Valami olyasmire gondoltam, hogy file-onként sha256sum-ot számolunk.

Ha minden file-unk 1 MiB-os - az egyszerűség kedvéért -, akkor ezzel a mérettel lehet nekünk 2^8388608 féle file-unk. Mindegyikből számolhatunk sha256sum-ot. Ezek lehetséges értékei egy 2^256 nagyságú teret ad. Még mindig az az érzésem, hogy lehet több olyan file, amelyekből képzett sha256sum ugyanazt generálja.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

>> ezzel a mérettel lehet nekünk 2^8388608 féle file-unk

de nincs. és ami még fontosabb, hogy nemhogy 2^8388608 nincs, hanem 2^256 sincs, megközelítőleg sincs, nagyon távolról megközelítőleg sincs, és nem is lesz soha

ami van, az a hash algod. amire rákérdeztem, csak...

Miután az algoritmus függetlenül generálja a hash-t, eből az következik, hogy noha a file-jaink számossága valóban lényegesen kevesebb, mint ezen elképesztően nagy számok, ugyanakkor lehet két eltérő file-unk, amelyből azonos hash generálódik, mégha ennek valószínűsége roppantul kicsi is. De nem nulla.

Rákérdeztél, válaszoltam. Az volt a válaszom, hogy sha256sum.

Amit eredendően írtam, az azért jó, mert a fileméretet és a file-ok tényleges tartalmát gyakorlatilag - ahogyan Te is állítod - sohasem kell majd vizsgálni. Implementálni viszont kell ezt is, mert az életben egyszer belefuthatsz a különböző file-okból származó azonos hash-be, s akkor szükség van a tüzetesebb komparálásra. Számomra nem elfogadható az, hogy úgy írjak meg egy programot, hogy tudom, általában jól működik, ám kis valószínűséggel ugyan, de hibázik.

Természetesen más az, ha tévedek, ezért hibás a program, viszont ne legyen úgy hibás, hogy tudom, hogy rossz, és lusta vagyok jól megcsinálni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

mert az életben egyszer belefuthatsz a különböző file-okból származó azonos hash-be

mindenképp szólj majd, ha ez veled sha256 használata mellett megtörténik

Elvileg nem történhet meg - lásd fentebbi okfejtésem -, vagy arról beszélsz, hogy ez roppant valószínűtlen?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

tehát implementálsz valamit (sha256 minden egyes képre), ami nem alkalmas a feladatra (ack by locsemege), de összehasonlíthatatlanul erőforrás-igényesebb, mint egyszerűen egyező fileméret esetén tartalmat hasonlítani (amit szintén implementálsz)

csak addig eroforras igenyesebb, amig par keprol beszelunk. ha mondjuk sok-sok tomoritetlen raw fotorol van szo, ahol ha ugyanaz a felbontas, akkor a filemeret azonos, akkor mar inkabb elso korben a hash osszehasonlitast csinalnam en is, mint az izombol minden file-t minden filevel megoldast.

vagyis kevés képnél erőforrásigényes soknál meg nem?


No rainbow, no sugar

ket kepnel valoban felesleges hash-t generalni, egy compare oszt kesz.

es tegyuk hozza, hogy ez arra all, amit irtam: ha tomoritetlen kepekrol van szo, ahol a filemeret nem dont el semmit, mert azonos felbontasban ugyanakkora a helyfoglalas. kepzett fotosoknal gyakran elofordul, utomunka elott nem szeretik a tomoritest.

ebben az esetben szamolj utana. ha mondjuk van 100 keped, akkor hashgyaros modszerrel az osszeset 1x felnyalod, a hashgeneralashoz, utana mar a par 10 byteos rekordok kozott vegzed a comparet // aztan ha egyezes van, akkor vagy elhiszed, hogy tenyleg egyedi a hash, vagy biztosra mesz. de ez mar egyeni izles kerdese, en megfutnam a masodik kort. //

hash nelkul elso korben minden kepet beolvasol az osszehasonlitashoz, a masodik korben mar csak 99-et, harmadikban 98-at...

en megfutnam a masodik kort

Erről beszélek egy ideje, de valahogy az az érzésem, feleslegesen. Ez nem feléd szemrehányás értelemszerűen.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vagyis ha van 100 képed ahol azonos a hash, a fájlméret akkor célszerű egy teljes byte-to-byte/binary összehasonlítást is elvégezni mert lehet hogy mégis különbözőek? :)


No rainbow, no sugar

Ez egy valószínűtlen, ám lehetséges eset, így igen. Tudom, nem engem kérdeztél.

Amúgy nem igazán értem, hogy mi abban az érthetetlen, hogy egy nagy számosságú halmaz minden elemét leképezünk egy jóval kisebb számosságú halmaz egy-egy elemére, akkor nyilvánvalóan lesz olyan, hogy a nagy számosságú halmaz több különböző eleméhez a kis számosságú halmaz ugyanazon elemét rendeltük hozzá. Persze ettől még írhatsz smiley-t, mert az legalább vidám.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

igen. vegyunk mondjuk egy 4096x3072 pixeles 32 bites szinmelysegu kepet. ennek a tomoritetlen merete 4096x3072x4 = 50331648 byte azaz kb. 50MB errol kepzunk hasht, ami eljarastol fuggoen mondjuk 32-1024 byte. de legyen 2048, hogy nagyobb mozgasteret hagyjak.

nos ha ezt az 50millios bytesorozatot 1:1 -ben azaz oda-vissza egyertelmuen hozzá tudod rendelni egy 2048 byte meretu sorozathoz, akkor szvsz. kapsz egy matematikai nobeldijat, mert megalkottad a vilag leghatekonyabb tomoritoalgoritmusat.
// a pcforumon van ra probalkozas, hogy minden szamot 2 byteba tomoritsenek, fingom nincs, sikerult-e mar :D) //

+1

Különböző-e két kép ha csak a fejléce vagy az exifje változik? :)


No rainbow, no sugar

Természetesen különböző. Ugyanakkor, ha kinézetre azonos képeket keresel, akkor a helyzet lényegesen bonyolultabb. El kell végezni egy transzformációt, hogy méretben azonosak legyenek, utána pedig pixelenként súlyozva kell különbséget képezni, majd egy adott differencia alatt azonosnak tekinteni őket, afölött különbözőnek. Ez már egy tartalmi összehasonlítás, ráadásul egyezőnek mondja a nagyjából egyező képeket is. Itt külön gond az is, hogy a közel azonos tartalomból a jobb minőségűt kellene megtartani.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kép nem, csak az azt tartalmazó fájl. :)
Egyébként nem tudom, a tineye open source-e. Ha igen, akkor érdemes lenne ott körülnézni. :)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

csak neked: engedelyezem a minden kep megtekintessel valo osszehasonlitasat.

Köszi, de nem én akarom ezt hanem ti. Főleg egyező hash esetén. Valamint minden képre - filera - hasht számoltatni ha kell ha nem.

Egyébként tudtommal a számítástechnika mai állása szerint lehetséges egy adott fájl kis részét is beolvastatni nem kell hozzá az egészet.


No rainbow, no sugar

nekem tokmind1, hogy te hogy dontod el, szemmel vagy a file egy reszenek elemzesevel.
en altalaban ( foleg a csaladi fotokbol ) meghagyom a duplikatumot is, mert ha mondjuk osszekuszalodik a filerendszer, akkor ket kepbol nagyobb esellyel mentheto az egyik, mint egybol.
sot ami igazan fontos, arrol meg backupban is tobb peldany van.

Mindenképpen index file-t írnék, amely tartalmazza a file elérési útját a nevével, a hosszát és a hash-t. Utána ezen a textfile-on igen gyorsan lehet dolgozni, megúszva ezzel a lassú HDD elérést. Egyedül akkor kell file-hoz nyúlni, ha hossz és hash egyezés is van, de mint fentebb kibeszéltük, ennek csak akkor van realitása, ha valóban egyezik a két vizsgált file.

Egyébként két stringet összehasonlítani kicsit gyorsabb, mint nekiesni a két file byte-onként történő összehasonlításának.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

>> Egyébként két stringet összehasonlítani kicsit gyorsabb, mint nekiesni a két file byte-onként történő összehasonlításának.

persze, de a hash nem a bokorból ugrik elő, hanem le kell gyártanod és szinkronban kell tartanod a fájlok tartalmával

Elérési út, hossz, hash, indexelés ideje négyeseket tárolva indításkor végig fut az indexen, megnézi, hogy az atime/mtime nagyobb-e, mint az index-ben levő, ha igen, újraindexeli.

BlackY

versus "Utána ezen a textfile-on igen gyorsan lehet dolgozni, megúszva ezzel a lassú HDD elérést. Egyedül akkor kell file-hoz nyúlni"

Hash-t az új file-nál egyszer generálsz, az összehasonlításkor folyamatosan nyúzod a HDD-t.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ezt mondom én is

Mert az archiválásra szánt képek gyakran módosulnak. Mindig elfelejtem.

BlackY

ja hogy most a profi fotósok - akik mindent rawban tartanak, és jellemzően rettegnek a duplikátumoktól - felbukkanása után ezek olyan archiválásra szánt fényképek, amik nem módosulhatnak archiválás előtt

nem tudom milyen gyakran, szerintem gyakrabban, mint hogy a sha256 hashük ütközne eltérő tartalom esetén

Idézet:
Ne(!) rakja évszám/hó/nap szerint alkönyvtárakba

Ez alapján több évnyi fotóról beszélgetünk, aminél igen, a képek nagy része marha ritkán fog változni.

BlackY

Ez igaz. Sok file esetén egy-egy új file megjelenése alkalmával egy-egy új hash kiszámítása nem olyan nagy erőforrásigény, mint a sok file egyenként történő összehasonlítása. Összehasonlításnál mindig az összes többi file-al kell azt megtenni - nyilván csak méretazonosság esetén -, míg hasht használva csak az új file hash-ét kell generálni, utána rövid stringeket komparálni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha már áttérünk a gyűjteményhez hozzáadogatós scenariora: nem feltétlenül van mindig becsatolva a teljes gyűjtemény

Akkor térjünk vissza a nem gyűjteményes hozzáadogatós-hoz. Ha nincs meg a teljes gyűjtemény, akkor hogy keresel a teljes gyűjteményben duplikációt? Ha van egy indexet, akkor legalább annyival előrébb vagy, hogy nem kell elérni a teljes gyűjteményt, ha új fájlt találsz és csak annyi akarsz közölni a userrel, hogy LEHET, hogy egyezés van.

BlackY

És akkor mennyire értelmes dolog deduplikációról beszélni? Egyébként az elérési út alapján azonnal skipelhetők az indexfile azon bejegyzései, amelyek nem csatolt filerendszerre hivatkoznak. Persze ez elég béna megoldás, mert felcsatoláskor lehet az egész adatbázison molyolni megint.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Majd valaki kiszámolja pontosan ha akarja, de maradjunk annyiban, hogy annak nagyságrendekkel nagyobb a valószínűsége, hogy egymás után tízszer megnyered a lottó ötöst... ;)

Ez így van. Ebből számodra az következik, hogy megengedhető ismert módon hibát véteni a programban?

Mondom, ha az ellenőrző összeget képező függvény inverze is függvény lenne, akkor egy igen hatékony tömörítő eljárásunk lenne így. De nem az.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon örülnék, ha ez lenne a legnagyobb hiba a programokban.

AFAIK (http://web.archive.org/web/20091104233440/http://blogs.sun.com/bonwick/entry/zfs_dedup) a ZFS is tud verify módban dedupolni, ami pont azt csinálja, amit locsemege ír. Készítsünk index táblát a fájlok hashéről (ott: blokkok), számoljuk a beérkező fájl (ott: blokk) hash-ét, nézzük meg az index táblában van-e, ha biztosra akar menni a sysadmin és be van lőve a verify, azért nézzük össze a blokkok tartalmát.

BlackY

Azért az feltűnhetett volna a linkelt blog bejegyzésből, hogy a ZFS deduplikációnál _sincs_ alapból blokkszintű összehasonlítás. Nem véletlenül. Kifejezetten nem ajánlott a használata, a feleslegesen nagy overhead miatt. Mindjárt azzal kezdi az írás is, hogy 50 nagyságrenddel kisebb a valószínűsége, hogy SHA-256 ütközés történjen, mint egy nem detektálható ECC memória hiba a legmegbízhatóbb hardveren ami kapható... Pedig mainframek esetén ez aztán nem túl gyakori jelenség, mert mindent többszörösen tárolnak és ellenőriznek.

A verify mód pedig a fletcher4 hash algoritmushoz van ajánlva, mert az ugyan gyorsabb, mint az SHA-256, viszont nem megbízható (nem Secure Hash Algo, mint az SHA), emiatt szükséges a blokkszintű ellenőrzés. Ráadásul ennek használatát is csak nagyon szélszőséges esetekben ajánlják csupán.

Erre vonatkozott a "tud" állítmány ;)

Viszont ott egy blokk kötött méretű és valszeg kisebb, mint egy raw kép (természetesen ettől még a képnél továbbra is rohadt alacsony a valószínűsége egy hash ütközésnek, de nem ugyanaz, mint egy FS blokknál). Amúgy alternatíva, amivel még tovább csökkenthető az egyezés valószínűsége: több hash függvényt is rá kell küldeni a fájlokra és mindegyiket hasonlítgatni. Tippre a fájltartalom ellenőrzős ág tényleg csak duplumoknál futna le belátható időn belül (mármint hogy belátható időn belül nem lenne elérhető akkora tárkapacitás, amin lehetne annyi kép, hogy mondjuk három független hash is ütközzön)

BlackY

Nem értem mit nem lehet érteni azon, hogy 2^256 irgalmatlanul nagy szám és készakarva se lehet ütközést generálni SHA-256 hashnél, nem hogy véletlenül.

Egy a 115792089237316195423570985008687907853269984665640564039457584007913129639936-hoz az esélye. Mit nem lehet ezen felfogni. Ekkora számmal majdnem a teljes univerzumunk összes atomját meglehetne különböztetni (az 2^266), néhány ezer filenál ehhez képest esélytelen, hogy egyező hash jöjjön ki különböző tartalom mellett. Egyszerűen olyan kevés rá az esély, hogy nem érdemes vele foglalkozni. Csak felesleges overhead a tartalom összehasonlítgatása minden egyes alkalommal.

A blokk mérete lehet, hogy kisebb, de sokkal több van belőle, mint a képfilejaidból valaha is lesz. Nagyságrendekkel több. Mégsincs ütközés.

Több hash függvény használata is felesleges.

Azért azt érzékeled te is, hogy mi a különbség a nagyon kicsi és a biztosan nulla között?


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen, érzékelem, hogy túl sok itt a tufa, akik csak végletekben tudnak gondolkodni.

Néha muszáj. Én nem örülnék, ha egy jó képem elveszne azért, mert véletlenül egy elkefélt példányéval azonos hash jött ki.
És lehet ezért hülyézni, ettől még...
Na mindegy, nem fárasztom magam kettőtökkel.
Kb. annyi, mintha poliverzumnak magyaráznék. :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

ROTFL. Én nem értem, miért baszom el az időmet rátok.

Ennyi erővel aggódhattok azon is, hogy az összehasonlítás alkalmával bithiba történik (mitöbb, 256 bithiba ;) és pont emiatt fog egyezőnek tűnni a két tartalom, miközben nem az és a "jó képed elveszne, mert véletlenül az elkefélt példány" helyett az kerülne törlésre...

Bocs, hogy nem érdekel a véleményed.
Azzal az arab szöveggel tettél érte eleget. Azóta nem tudlak emberszámba venni.
:D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen, az látszik, hogy a logikus gondolkodás nem az erősséged.

i̻̔̽ͯ̄͒́̎ͅl̻̰̭̗̣̪̩͗̎ͯͣ͆̓l̬̱͚̟̹͉ͦͥ̔̈́̓ͨ͋ͤͤḙ̩̲̍͐ͣ̈́̆͗ͅͅg̐ͥͬͣ̀̿̂a͚̤̙̠̫̫̳̫̐̌̾̉̽̈̅̍͗̑l̴͎̲͇̯͉̖̊ͤ̈͐ͬ


No rainbow, no sugar

mi sem ertjuk, miert baszod el az idonket rank. szerintunk ami!=0 az<>0 akarmilyen kicsi szammal jellemezzuk, es az ilyen hibafaktorok szoktak a legvaratlanabb pillanatokban elokerulni, hajkihullast okozva, ezert nem kerunk belole.

Arról nem beszélve, hogy az említett példája kapitális baromság.
Ugye ha két fénykép között mondjuk van 1-2-10-20 bitnyi eltérés, ami hardver hiba miatt úgy változik, hogy a két képet azonosnak látom, akkor a két fotó valószínűleg egyforma volt, max. az érzékelőn megjelenő zajban tértek el. (pár pixelnyi eltérés).
Viszont ha az sha256 hash egyforma két fotónál, akkor a két kép vagy bitről bitre egyforma vagy a világon semmi közük egymáshoz, mert egy-két bitnyi eltérés óriási változást hoz az sha256sum kimenetében. (ha rosszul vagyok informálva, csak szóljatok!)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Mivel ilyen alapos srácok vagytok csak szólok, hogy érdemes SHA-256 ütközést találnotok mivel a BTC fórumon 7-8K BTC is adnak egy ilyenért - ha jól számoltam - ami édestestvérek között is vagy 200 millió forint :D


No rainbow, no sugar

Hááát... én csak rákerestem, hogy sha256 collision... Bele nem olvastam a találatokba, de mintha nem lenne egy lehetetlen dolog.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Hát nem is a googlen kell találni, hanem fotózzatok sokat és akkor: hátha beüt.

XD


No rainbow, no sugar

Ez az egész értelmetlen egyébként, mert ugye az mindenképp megvan, hogy ellenőrizni kell a hash-ek egyezőségét. Ha találok két egyezőt (aminek egyébként kicsi az esélye), akkor és csak akkor összehasonlítom a két fájlt bitről bitre, hogy valóban azonosak-e? Ha azonosak, akkor az egyik felesleges. Ha nem, akkor találtam egy ütközést. Nem hinném, hogy fotó archivumok esetében ez komoly overhead lenne.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Legalább már tudjuk, hogy nálad miért kicsi az esélye, hogy "találj" "két egyezőt".

Nagy szakértők a srácok... ;)

SHA-256-ban nem bíznak meg, mert lehet hogy az univerzum végéig egyszer talán előfordulhatna ütközés és egy szaros fotójuk emiatt törlődne, de az nem tűnik fel egyiknek sem, hogy még a netbankjuk SSL forgalmát is csak egy 160 bites SHA-1 hash védi...

Attól tartok, nagyobb az arcod, mint a tudásod.
Igaz, törvénysértő tartalmak előállítására már fussa... :D
(igen, az az arab szöveged végeredményben törvénysértő volt, ha szigorúan vesszük)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

hagyd, nem érdemes.

Felfogásbeli különbség van köztünk. Én azt mondtam, ha valamit meg lehet szépen csinálni, akkor csináljuk meg hibátlanul, ne egyfajta valószínűségi rendszer legyen ez, mégha a valószínűség nagy is.

Ti gyakorlatiasan közelítettetek a problémához, s abból indultatok ki, hogy annak valószínűsége, hogy a programot végrehajtó gép hibát vét a futtatás során, sokkal nagyobb, mint a hash ütközésé.

Mindnyájan értjük, miről van szó, nem szakmai vita ez igazán, sokkal inkább arról szól, hogy van, aki megenged valamennyi hibát, van, aki meg úgy látja, ha van elvileg is jó módszerünk, akkor programozzunk ennek ismeretében hibátlanul, s nem nagy valószínűséggel jól.

Ez filozófiai különbség köztünk.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

[13-09-14|12:13:46] {@gabucino} Felfogasbeli kulonbseg van koztunk. [Ao]
[13-09-14|12:13:49] {@gabucino} ^jol mondja
[13-09-14|12:13:54] {@gabucino} van aki felfogja, van aki nem

Látom jó vagy matekból. Nem nulla az esélye annak sem, hogy a több megányi képednek a tartalma is pont úgy változzon, hogy egyezést láss összehasonlításkor.

Zsenikém! Próbálj meg gondolkodni, még ha nehezedre is esik!
Annak, hogy két, látványában lényegesen eltérő képnek a hash-e megegyezzen, minimális, de nem nulla.
Hogy ugyanilyen mértékben eltérő képek bithiba miatt a hasonlításkor megegyezzenek, kb. nullára tehető.
(erről valamiért az ikerprímek jutnak eszembe, de egy ekkora zseninek, mint te, kár is magyaráznom... :D)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

kb. nulla az már nulla?

Hosszú... trollkodás megy, gondolkodás nem.
Szakadj le rólam!

De még utoljára: igen, ezt már elhanyagolhatóan kicsinek tartom, míg az egyező hash-t nem feltétlenül.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Jól van, menjél, generáljál néhány SHA-256 ütközést. Majd gyere és szólj, ha sikerült. Viszlát addig is! :))

Egy elég? Mert azt már sikerült. :D
(a többiek kedvéért: tudtommal még senki sem tudta bizonyítani, hogy két eltérő fájl nem adhat azonos hash-t mondjuk sha256-tal, a többi csak szórakozás ezzel a nagyarcú script kiddie-vel :D)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

"tönkrement a szemem, egyelőre úgy fest, nem nagyon lehet vele mit kezdeni. Viszont emiatt sűrűn előfordul, hogy szavakat, mondatokat, egész sorokat átugrok olvasás közben anélkül, hogy észrevenném."

áá értem, nem (csak) ostoba vagy, hanem vak (is)

Te tényleg egy kretén állat vagy, nem csak a híred olyan.
Remélem, előbb-utóbb téged is utolér valami kellemes betegség és lehet majd rajta szórakozni.
Anyád büszke lehet rád.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Hallod sasszem, kemény meló volt elolvasni az arab szöveget, mi? Így már nem csodálom, hogy azóta is frusztrált vagy... ;)

...
Ilyenkor érzem igazán a szellemi fölényemet. Te tényleg beteg vagy. Csak agyilag. Poliverzummal közös a pszichiátered, ugye? :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen-igen, vak vezet világtalant... :(

Ezért az utóbbi néhány hozzászólásért kár volt. :( Nem igazán értem, nagyon intelligens emberekből mitől hal ki az empátia, illetve érzelmileg mitől lesz valaki olyan, mint a sivatag.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem halt ki.
Benne sohasem volt, csak a régi, indexes nikkje már az enyészeté. Ott lehetett igazán látni, milyen is valójában. :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Valamit "benéztél", sose volt indexes "nikkem".

Aha. Kár, hogy neked kicsit nehezen tudom elhinni. :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Semmi gond, "elnézem" neked. ;)

Sajnálom, hogy elrontottam a szórakozását "a nagyarcú script kiddie-vel".

Nem rontottad el: végül kihoztam belőled a pszichopatát. :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

A szellemi fölényeddel "láthatóan" nem volt nehéz. ;)

Egyébként sem volt nehéz, csak szerettem volna, ha más is látja, hogy súlyos elmebeteg vagy, akit nem lenne szabad kiengedni a zártosztályról. :D


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

ha más is "látja"

> szellemi fölényemet

http://i.imgur.com/31W2Z.gif

De még utoljára: igen, ezt már elhanyagolhatóan kicsinek tartom, míg az egyező hash-t nem feltétlenül.

és csak ezen a ponton tévedsz

Mert?
Képekről beszélünk!
Továbbra is csak annyi a gondom, hogy _tudtommal_ nincs bizonyítva, hogy két eltérő tartalmú fájlnak nem lehet azonos a hash-e sha256-t használva. Ergo ilyen esetben, ha egyezést találok, inkább ellenőrzöm mégegyszer, egyéb úton is.
Ennyi, nem több.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

ha gondolod kidolgozhatjuk azt az eljarast is, ami memoria vagy mas hardverhiba eseten is jo eredmenyt ad :D)
bar erre az esetre mar vannak komolyabb hardverek, amiket gyarilag felkeszitettek, csak sajnos nem a home szegmensben.

* latom ujabb bejegyzes kerult a nevem melle a hupmeme-be, mar ezert megerte :D)

nice trolling 3/10

És biztosan tökéletes az eloszlása is?

Alternatív javaslat (a' la ZFS): programnev check [--paranoid]. A paranoid kapcsoló nélkül hash egyezést elfogad teljes egyezésnek, ha meg van adva, akkor tartalmat is ellenőriz. Ez a megoldás már elfogadható lenne?

BlackY

akkor most elmegyek lottozni.

Az imgseek (és alighanem még pár cucc) a kép tartalmát hasonlítja össze, így pl. megtalálja ugyanannak a képnek a színes és ff verzióját is mint egyezőt. Vagy az eltérő méretűeket. Ez fotós szempontból jóval hasznosabb.

Az fdupes pont ezt csinálja.
Vagy jön csomagban vagy itt találod:
https://code.google.com/p/fdupes/

Úristen mit indítotttál itt el ezzel. :D :D :D :D Sírva röhögök a végeredményen :D :D

Eszembe jutott Ken Rockwell írása, a fotográfusok hét szintjéről. Beindult a számháború, ami tényleg nagyon mókás, figyelembe véve a való életet.

"Mostanában ezek az idióták sajtómunkához tervezett digitális tükörreflexes gépeket vesznek, mint például a Canon EOS-1D vagy a Nikon D1X, melyek technikailag gyengébb eredményekkel szolgálnak, mint a kattintgatók gépei"

Konkrétan ez egy akkora ökörség, hogy hiteltelenné teszi az egészet.
Nikont nem ismerem, de az 1D nagyságrendekkel jobb képminőséget produkált, mint a vele egykorú többi Canon, leszámítva tán az 5D-t.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Az 5D elve nem lehet egykorú mert négy évvel később jelent meg. Egy évvel később jelent meg az 1Ds, ami ugye a stúdióvonal, jóval nagyobb szenzorral, vélhetően jobb dinamikával (amit amúgy később az 5D lealázott, meg a Sony alpha széria valamelyik amúg nyomi gépe mégkésőbb megint).

Az 1D a maga négy megapixelével nem volt egy hűdevalami (konkrétan geci moirés volt, ennél rosszabb anno csak a kodak csúcsváza volt, mert abban kb. nem is volt antialias filter, mert jó ötletnek tűnt), L-es üveggel egész fasza képeket csinált. Vagy egy 50-es ojjektívvel. Meg persze 200-as iso alatt, ehe. 400-ra csak sajtófotóhoz volt értelme feltekerni, mert elkezdett csíkozni a kis édes.

Nekem az 1D az 1D-től 1DmkIII-ig a teljes széria. :)
Én speciel egy mkIII-at használtam évekig. Meg egy mkII volt a kezemben.
Pont arra volt kitalálva, amire nekem kellett: street+riport fotó.
Amikor volt választási lehetőségem, hogy 5D full frame vagy 1D, gyorsabb sorozat és talán hosszabb élettartam, én az 1D-re szavaztam.
Az ős 1D-t persze nem ismerem, ahogy a Nikonokat sem. (D1X annyira régi? Mert akkor kevertem valamivel - emiatt gondoltam, hogy a komplett szériáról beszél a kedves szerző és nem a legelső 1D-ről)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

A szerző arról beszél, hogy az idióták megveszik a marha drága vázat, noha töredék költséggel kb. ugyanolyan vagy jobb képeket csinálhatnának - mert a fotózáshoz nem értenek, csak vesznek egy drága valamit és az milyen jó lesz majd. De üveget már nem vesznek hozzá, ehe.

Értem én, hogy miről beszél, csak itt is bizonyos fokú lenézést, illetve jelen esetben némi SI faktort is véltem felfedezni. Nem csak most, már évekkel ezelőtt is (akkor még 300D-vel rohangáltam :) )
Nem tökmindegy, mivel mászkál és kattogtat az ember? A végeredmény számít, a többinek semmi jelentősége. Mostanában max. telefonnal (nagy ritkán egy ősi G9-cel) fényképezek, ha épp rámjön. Azért ezeken elég jól érzékelhető, hogy ha az ember rá van kattanva egy adott témára, akkor nagyon nem mindegy, milyen gépet használ. (kompaktnál csak a shutter lag zavar, a mobilnak már a dinamikája is)


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

De, épp erről van szó. Mármint mindegy. Lásd hetedik szint :)

Már szinte bánom. Azt nem értem, miért baj az, ha elvileg is jó megoldást mondok, a valószínűleg jóval szemben. Ez engem arra emlékeztet, mint amikor valaki memóriafoglalás után egyből használja a pointert, s nem ellenőrzi, hogy a visszatérési érték NULL, vagy sem. Úgy is lehet, általában működik is, aztán ha meg nem, akkor nagyot bukfencezik a program.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, de itt 99.99999999999999999999 999999999999999999999 9999999999999999999999 99999999999999999999999999 99999999999999999999 99999999999999999 99999999999999999% eséllyel jó megoldást cseréltél volna 100%-ig jó megoldásra és mindezt úgy, hogy közben a 100%-ig jó megoldás háromszor annyi sorból van meg. Egyszerűen nem éri meg, minek? Főleg hogy nem egy bank adatbázisába generálsz sót, hanem egyszerű családi fotókról van szó.

Ráadásul itt ennél okosabb mesterséges intelligenciás megoldások kellenek (pl. két kép megvan különböző felbontásban), azokban meg jó, ha a 99.9%-os eséllyel való működés megvan.

Érdekes, amit írsz, de...

A példámban említém, hogy 1 MB-os file-ok esetén 28000000 féle file-unk lehet, ebből generálunk 2256 féle hash-t. Egyenletes eloszlást feltételezve ugyanazt a hash-t 27999744 darab file generálhatja, azaz ennyi file adhat hash ütközést egy adott hash mintára. És ez bizony nekem egyáltalán nem tűnik kevésnek. Konkrétan egy ép ésszel felfoghatatlanul nagy szám. Lehet, rosszul írok valamit, de akkor mondjátok, mit néztem be.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Te nem akarsz véletlen kaszinót nyitni? Szívesen járnék hozzád minden nap játszani. ;)

Vegas az élő példája hogy a bank mindig nyer. Ha nem nyer, akkor is.

Hogy komolyan vegyem a témát, itt kockázatelemzésről van szó. Mint amúgy mindig.
Adott egy folyamat, ami során bizonyos valószínűséggel hibás döntést hozhat az automata rendszer. Ha az adathalom értéke nagyobb egy szintnél, akkor egyéb módszert is be kell vonni. Az adathalom értékét az adattulajdonos dönti el.

Természetesen - mint írtam is - ez a bitszintű összehasonlítás a gyakorlati felhasználás során marhára értelmetlen, mert a kép tartalmát, (általában luminosity-t) redukálva egy kezelhető mérete, szokás összevetni, egyezés esetén pedig mindig pontosabb összehasonlítást és/vagy vizuális megerősítést kell kérni. Így nem csak a bitre egyező, de a nagyon hasonlító, pl. átméretezett képeket is ki lehet szűrni.

Nem beszélve arról, hogy ennek csak akkor van értelme ha nagyon sok a duplikáció, ha százból két kép egyezik, az engem legalábbis nem érdekel. Sokkal fontosabb kérdés a képanyag megfelelő tárolása, archiválása, ahol a mondjuk kb. 1% felesleges adat még belefér. _Szerintem._ Már csak azért is, mert a képeim eleve négy helyen vannak.

*) Feltételezem, hogy nem milliós nagyságrendű képről van szó, aminek maximum a fele egyedi adat, a többi felesleges. Nekem a 11 év alatt százezer fájlos gyűjteményem jött össze, gondolom más se nagyon kattogott össze jóval többet.

Arra célzol, hogy a rengeteg hash ütközés lehetősége ellenére a lehetséges hash-ek száma is elviselhetetlenül nagy? Tudom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ezek az áltudományos fejtegetések ép ésszel felfoghatatlanul nagy számokról, mintha a pixelek tetszőleges kombinációjának nem csak töredéke adhatna értelmes fényképet, illetve mindenkinek a hülyének nézése azzal, hogy magyarázod, hogy a hashből nem lehet visszaállítani a képet, vagy a hajánál fogva iderángatott memóriafoglalásos téma külön nevetségesek

azzal sincs semmi baj, ha """biztosra""" akarsz menni, csak akkor miért kell első lépésnek olyan brutális overkill, mint a sha256?

Mondjuk ebben van valami: MD5 bőven elég és (ez számomra meglepetés volt) érzékelhetően gyorsabb, mint az SHA256.
Korábban nekem úgy tűnt, azon problémáztok, hogy minek újra ellenőrizni, ha a hash egyezik.


Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Értem, hogy az a problémátok, hogy abban, amit én írtam, minden bennevan, mégpedig az így előállított képek szinte 100 %-a zaj, a maradék értelmes kép, de még ez a közel 0 % értelmes kép is emberi elmével végtelennek tekinthető, amúgy persze véges számú.

Mindamellett továbbra is kiemelném, egy _elvileg_ is jó megoldást keresünk, s noha igen kicsi a valószínűsége, mi garantálja, hogy nem éppen két értelmes kép esetében lesz hash ütközés?

További kérdésem, hogy a fejtegetésemet miért nevezted áltudományosnak? Még csak azt sem mondom, hogy nem hibás, de akkor legalább lássam, mi a baj vele.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

locsemege, a baj ott van, hogy a bitről bitre összehasonlításnak is van hibája, mert sem a memóriának, sem a processzornak nem 100,000000000000000000% a megbízhatósága, hanem kevesebb. Ehhez képest az sha256 ütközése elhanyagolható valószínűségű.

Az, hogy szerinted a bitről bitre összehasonlítás biztosan nem hibázik, egyszerűen nem igaz.

Tudom. Nyilván az a rossz érzés az egészben számomra, hogy egy algoritmusról tudom, hogy hibázhat, noha kis valószínűséggel, míg meg lehet úgy írni, hogy elvileg is jó legyen, ráadásul nem sok plusz munka. Amikor az ember megír egy programot, illik kezelni a hibákat, illik malloc() után ellenőrizni a visszatérési értéket, nem abban bízni, hogy a kernel úgyis adott memóriát, mert szokott, és különben is az a dolga. Ezt pont ilyennek érzem, miközben tudom, hogy jóval nagyobb probléma, amikor bugos egy program, bizonytalan a hardware.

Viszont azt mondom, legalább tegyük meg azt, hogy nem növeljük ismert módon a hibázás lehetőségét, éppen elég baj, hogy a rendszereink nem tökéletesek.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A baj szerintem nem is ezzel van, hanem hogy milyen módszert választottál a hash egyezés esetén történő összehasonlításra. A tartalom összehasonlításnak nagy lesz az időigénye, és minden duplikátum esetén elvégeznéd, amiből jóval több lesz, mint hash ütközésből. Én a kép készítésének idejét hasonlítanám össze 2. körben, ezt ki lehet gyűjteni a hashek elkészítésekor és kb. ugyanolyan gyorsan össze lehet hasonlítani, mint 2 hasht. Persze annak valószínűsége, hogy két különböző kép ugyanakkor készült, jóval nagyobb, de figyelembe véve, hogy milyen kicsi annak valószínűsége, hogy a hashük ütközzön, ezzel már biztosra mehetsz.

"e még ez a közel 0 % értelmes kép is emberi elmével végtelennek tekinthető, amúgy persze véges számú."

ahahaha


No rainbow, no sugar

Kicsit konkretizálhatnád, mi ezzel a problémád. Valóban nem precíz, de szerintem érthető megfogalmazás volt.

Az összes lehetséges kép - példámban 1 MB-os fileméretekkel - 28000000, ennek jelentős része optikailag értelmezhetetlen zaj. Ennek tehát töredéke értelmes kép, de még az is egy irdatlan nagy szám. Erre írtam, hogy végtelennek tekinthető, természetesen nem matematikai értelemben. Értsd úgy, hogy borzalmasan nagy, bár véges.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én már ott elvesztettem a fonalat, hogy _képadatokat kellet volna összehasonlítani erre ti elkezdtetek hasht számolni _fájlokra, mert az a tuti. (Ami nem az, mert ha a fájl egyéb részei módosulnak, akkor az szerintetek egy különböző kép lesz mindenképpen pedig nem az.)

Mert vagy egyszerűsítitek a dolgot és például megpróbáljátok a file, fejléc, exif, iptc adatokat is használva dolgozni, vagy ha precízebbek akartok lenni akkor pedig óvatosabban kéne fogalmazni mert jópár esetben nem annyira triviális ez a dolog köszönhetően a sokféle formátumnak. Pl. Fuji a rawba beleteszi a dátumot is másodperc pontosan. (Nem véletlenül fos az összes képkatagolizáló program egy bizonyos szint felett és nem is szeretnek mindenfélével dolgozni. )

Ehhez képest azon megy itt az elmélkedés hogy sha256 nem megbízható muszáj ellenőrizni mert hátha. Mit gondolsz nem készült/készül eddig több tíztonnányi teszt az algoritmus fejlesztése/elfogadása/bevezetése körül sokkal több fájllal mint amennyit a fórumon valamennyien lefényképezünk életünk végéig? (Ha már az elmélet nem elég :P)

És ezt még én is fel tudom fogni aki nem vagyok programozó, de akkor ti kicsodák vagytok akik egy ördöglakat versenyen már az első flash form kérdésen elbuknátok?


No rainbow, no sugar

Így van, én mindig binárisan pontos file-okról beszéltem, azaz duplikáció alatt azt értettem, ami pontosan ugyanaz a file, csak más elérési úton. Tehát számomra ugyanaz a vizuális élmény jpeg-ben, png-ben, raw-ban, tif-ben már nem duplikáció.

Arra az esetre is írtam egyébként valamit, amiről Te beszélsz. Azonos méretre hozni, pixelenként különbség abszolútérték súlyozva - például (p1(x, y)-p2(x,y))2 -, ennek összege osztva a pixelek számával. Ezt kell komparálni valami konstanssal. Ha nem éri el a konstanst, akkor az duplikátum, mert az eltérés a képek között kicsi, különben eltérők a képek. De ez csak egy gondolat, ki kellene próbálni, használható-e.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

>Tehát számomra ugyanaz a vizuális élmény jpeg-ben, png-ben, raw-ban, tif-ben már nem duplikáció.

Még mindig nem érted, ez szóba sem került.

Nálad már az sem két azonos kép aminek, pl az exif adatain kívül minden bájtja egyforma, pedig ez egy elég gyakori felhasználási eset, hogy például publikálásnál, átadásnál a kedves user kitörli/átírja a geo adatokat a másolatból vagy más egyéb személyes infókat.


No rainbow, no sugar

Akkor, mint ahogy írtam is, más algoritmust kell alkalmazni. Előbb a feladatot kell meghatározni, s utána keresni rá megoldást. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

hiaba probalod mosdatni az nsa-t, en az utobbi idok dokumentumainak fenyeben akkor is gyanusnak talalom az sha256-ot :D)

Picasa?

Nem GTK (nagyon nem :-) ), de
- gyors
- arcfelismerő tanítható
- nem erőlteti rád a tárolási struktúrát (másolás nélküli import)

Nekem akkor segített sokat, amikor adott személyekről kellett képet válogatni majd' 10 év terméséből. Korábban nem tag-eltem ilyen szempontok alapján (most sem), de a második átnyálazás után rászántam az időt az arcfelismerésre Picasával.

A raw mellett megtartom a jpg-t is, mert van, amikor nincs türelme a családnak arra várni, hogy elkészüljön a kép. Hiszen szerintük kész.

Pár hónapja váltottam darktable-re a raw feldolgozáshoz, nekem egyelőre tetszik.

A dupla fájl szűrésére javasoltak jó megoldást.

mean

A picasa linux megszűnt nem?
Vagy a sima picasa még van?
Esetleg fut is linuxon?

pch

u.i.:
Duplikáció kész.
gthumb megoldotta
Elvileg van címkézés is benne, elég faja kis progi..

--
http://www.buster.hu "A" számlázó
--

Itt van néhány tipp a duplikátumokra:
http://askubuntu.com/questions/4072/how-can-i-find-duplicate-photos

Ebből a digiKam talán még a kategorizálást is fogja tudni úgy, ahogy szeretnéd, de ezt azért szerintem teszteld inkább.

Shotwell?

Kölcsön kellett kérnem haver FullHD monitorját, hogy végigolvashassam a kommenteket, de megérte. :D

Vagy egyszerű nézetet választasz a beágyazott helyett. Még az oldal forrásának olvasása is szóba jöhet. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én a Ctrl+A, Ctrl+C, Alt+F2, Kwrite, Ctrl+V, F10 megoldást szoktam erre használni, így azt is látom, hogy melyik hozzászólás olvasatlan még :)

BlackY

Most, hogy mondjátok, kiraktam a böngészőt teljes képernyőre. Pedig nem szoktam, de így tényleg látszik. Mondjuk érdemi tartalom már nem volt benne.
--
AGA@
Fork portal és az egyik logóm :)