képrendező

Multimédia

Ü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?

( nikin v | 2013. 09. 12., cs – 20:49 )

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

( Fisher v | 2013. 09. 12., cs – 21:52 )

É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.

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.

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.

( locsemege v | 2013. 09. 12., cs – 23:05 )

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

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

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

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

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

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.

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...

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) //

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

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

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

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

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

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

AFAIK (http://web.archive.org/web/20091104233440/http://blogs.sun.com/bonwick/…) 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.

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...

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. :)

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. :)

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. :)

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

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. :)

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. :)

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)

Math.log10( 2**256 / 2 / ((2**10)**4 * 16 * 8 ) / 10**12 / 3600 / 24 / 365.25 )

=> 43.11513513102286

Ha a teljes state space-t elosztom kettővel, majd osztom 16 terabyte-nyi bittel - azt mondván, hogy annyi fajta fájlom van, mint amennyi a jelenleg legnagyobb elérhető tárhely bitjeinek száma, amennyi fájlom nem lesz, mert akkor 1 bit lenne mindegyik - majd osztom ezer milliárddal (1e12), mondván, hogy 1 másodperc alatt ezer milliárdszor változik meg az összes előbb említett fájl - majd megnézem, hogy ez mennyi ideig tartana hogy legyen ütközés, akkor is 1e43 évet kapunk. (Hiba joga fenntartva)

Ez nem megérthető intuitíven. Tehát soha nem fog ütközni.

Szerk.: most látom, hogy régi topic-ba írtam.

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

+1, lottó ötösre nagyobb az esély :)

Amúgy Windows alapú megoldás, ami néz file méretet, és bit szinten összehasonlítja / HASH-t számol, és ha akarod, mint smart selection csak 1 képet hagy meg, ha valamiből több van:

http://noclone.net/

Ez megoldás a duplikációk kiszűrésére, azonban így elmarad a saját fejlesztésű hash+compare script írásából származó öröm.

Sakk-matt,
KaTT :)

"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. :)

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

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.

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.

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

( mean | 2013. 09. 13., p – 06:01 )

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

( carlcolt | 2013. 09. 14., szo – 13:28 )

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

( Cozi v | 2023. 01. 16., h – 14:52 )

Sziasztok!

2023 elején keresek olyan képrendező programot Linux alá, ami:

* de-duplikál

* enged meta adatolni

* a JPG exif adatai alapján időrendbe rakni a képeket

* valamilyen GUI-n a képekre kattintva kiválasztani azokat és külön mappába elmenteni

* esetleg képet forgatni

Shotwell-t néztem, de nem tűnt igazinak (vagy csak még barátkozni kéne vele).

Mit tudnátok ajánlani?

Akkor hoppon maradtál, mert van Linuxra is :D De linuxos PC-n amúgy sem lehet semmit csinálni, ki kell dobni, komolytalan. Ahhoz, hogy valaki fontos ember legyen, vagy nagyot véghez vigyen, kell legalább egy prémium Mac, mert azért fekáliával ne gurigázzunk már, mégis csak az a professzionális produktivitási platform, és szebben is mutat, ha beülsz vele a Starbucksba. Csóringer ingyen húsnak híg a leve / nincs pénz Windows licencre témájú linuxos proli géppel amúgy sem kéne senkinek égetnie magát, nem elég hipszter, meg az nem true/certefied Unix úgy se.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ha adnak a sztárbakban konyektort, szívesen kiveszem az akksit a gépből, és akkor mindenki láthatja a legális, pénzes windóz liszensz-matricámat. Az meg, hogy FreeBSD fut a gépen, azt meg úgyse érik fel ésszel.

/OT

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Azért csak óvatosan, Bill Gates gyerekei is így lettek kitagadva, még a végrendeletből is. Alternatív dugi OS-t talált az apjuk a gépükön, meg dugi androidos telót, mikor csak Windows meg Windows Phone lett volna engedélyezett, konzolból meg Xbox és Kinect. Azt a windowsos matricát viszont le kéne szedni, különben Stallman nem dedikálja neked azt a gépet. Bár lehet a BSD miatt nem is fogja, mert nem GöNú licenc, meg a BSD licenc enged mindent, ami nem etikussch, meg nem copyleft, anti-freedom rabság. Esetleg ha GNU utils-t felhúzod neki és beraksz bootoláskor egy GNU/BSD logót. Tim Cook még megáldhatja, de csak akkor ha kötött hipster beanie-ben szállítod le neki a Starbucksba, és akkor is csak akkor, ha fake MacOS skint húzol fel rá, vagy egyébként kinéz egy Hackitoshnak, vagy szépen le van festve.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A geeqie tud dedupliklálni (megadható similarity % is, hogy mi alapján tekintse egyformának, az átskálázott, kicsit croppolt, kissé átszínezett képeket is simán megtalálja), bár automatikusan nem csinálja meg, a döntést manuálisan neked kell egyesével meghoznod. Hasonló beállításból lőtt képsorozat esetén hajlamos fals pozitívakat találni már 90-94%-os similarity környékén is.

Mappákba bedobálni elég egyszerűen tudod, valamint forgatni, tükrözni is. Azt most nem tudnám hirtelen megmondani, hogy csak az EXIF orientation flag-et állítja-e át vagy ténylegesen módosítja a képet, mint a jpegtran.

Az EXIF alapú sorrendezést viszont gyanús, hogy nem tudja, legalábbis még nem sikerült rávennem.

Régóta vágyok én, az androidok mezonkincsére már!

http://sign-el-soft.hu/cgi/ng-xim.html#keposszehasonlitas

http://sign-el-soft.hu/cgi/ng-xim.html#kepgyujtemeny

http://sign-el-soft.hu/cgi/ng-xim.html#hasznroviden

http://sign-el-soft.hu/cgi/ng-xim.html#makrok

http://sign-el-soft.hu/cgi/ng-xim.html#kepatmeretezes

( pink v | 2023. 01. 18., sze – 10:18 )

Nekünk megjelenítési oldalon volna szükség valamire, egyfajta családi fényképalbumra.
Ami idő és geolokáció alapján kereshető.

. Raspberry Pi-n kellene futnia
. TV-n, HDMI-n keresztül és
. webszerveren (nginx) keresztül használhatónak lennie.

Ilyesmit használ valaki?

Azt mondod hogy TV-rol es telefonrol nem jo nativan csakis webbrowserbol?

A legtobb okos tv tudja a dnla-t meg a telefonok is. De ha a raspin fut a digikam, akkor az a TV-re is lehet kotve es akkor ott elinditjak a digiKam-ot. Vagy nem ertem a felhasznalasi igenyt. 

Ul valahol a raspi a pinceben es elerheto a neten. A DigiKam DNLA servere meg szorja szet hogy ehun vagyok. Tv bekapcsol es elkezdi nezni a kepeket az ember. Telefont elokapja es megnezi rajta a kepeket. 

Minek kell ide a koztes webbrowser?

TV-re meget natívan, HDMI-n (össze van kötve), de valahogy a családtagokat (local és remote) is ki akarom szolgálni, kik tablettel, laptoppal, telefonnal támadnak.

Access control se ártana, de túl bonyolult meg nem lehet (idősebbeknek is kényelmes legyen). Pl. URL-ben van a shared secret, és eleve így osztom meg. Családi nyomkövetőnél is így van, csak ott szessönönként rotálódik a kulcs és szerver oldali lejárata is van. Itt ez nem lényeges.

pontosan azt tudja amiket felsoroltal csak akkor a google orzi a kepeidet. Van akinek ez eelkepzelhetetlen mert mittomen..blablahblah... :D

Viszont kenyelmes, az AI felismeri az arcokat, helyeket, dolgokat (pl. az osszes gesztenyes kepemet legyen az szedes vagy sutes barmikor, vagy gesztenyeember csinalas a lanyommal), neha csinal a google jopofa kollekciokat mondjuk "anyaknapja", "hogy megnott ez a gyerek", "trip to paris",  stb. Mindenhonnan elerheto egy bongeszobol stb stb. De szerintem tuti mashol is van ilyen, nem csak a googlenel. Csak mast en sem ismerek. A digikam es a google cloud lefed mindent amire nekem szuksegem van. 

Azert hallottal mar a googlerol ugye? :D

Persze a google-ről hallottam :-)

Most merült fel nálunk az igény egy könnyen böngészhető fényképkezelőre. Eddig nullát foglalkoztam ezzel a témával; startmezőről indulok. Mivel nem is érdekelt, nem is próbáltam ki megoldásokat.

Own hosted-ra gondoltam, ha már ott van a szerver.
A google előnye lehet, hogy backelve vannak a képek, bár ekkora mennyiségű adatnál már gondolom nem férek bele az ingyenes keretbe.

Backup-ra - ha már így szóba került - szintén szívesen hallanék tippeket. Eddig AWS csomagokat nézegettem, [olcsó havidíj / lassú és drága visszaállítás] kombóban.
Korábban rsnapshottal még mentegettem egy offline eszközre, de jelenleg gyakorlatilag még egy RAID sincs alatta - ami elég gáz.

Mivel ezek blobstore-ok nem blocktore-ok igy nagyjabol ertelmetlen a backup ha csak nem akarsz egy masik helyen biztosnagi masolatot is tartani az adatrol (az osszes adat el van maszatolva egy vagy tobb regioban nem block-onkent hanem blob-ban).

A google alkalmazasok mind telefonon mind PC-n (windowsra van hivatalos, minden masra szamos az API-n keresztul mukodo megoldas fizetos vagy ingyenes) tudjak a felhobe syncelest azaz azonnal ott van a telefondorol a kep (ha beallitod) a dokumentum a PC=drol, stb stb.

Selfhosted cloud-ban ott a nextCloud amiben mindenfele plugin van pl. a Memories multimedia plugin ami azt tudja mint a google photos

Photoprism?

Nálam dockerben fut RPi-n, böngészőből szépen működik, távolról VPN-en keresztül érem el.

TV-re nem tudom hogyan gondoltad megjeleníteni, de ha kirakod egy FS share-re a forrásképeket, gondolom kb. bármi megjeleníti (pl. Kodi biztosan), ami futhat akár azonos RPi-n is, ami a TV-re van kötve direktben.

Köszi, megnézem.

RPi TV-re van kötve HDMI-n.
Webszervernek kint van egy lába WAN-on. Használunk rajta más own-hosted dolgokat, pl. nyomkövető. Így ez már eleve adott.
Olyan megoldásra gondoltam, amit akár fater is elnyomkod. Küldöm a linket, vagy eleve van egy URL-je benne egy kulccsal, amivel tudja böngészni azokat a dolgokat, amik engedve vannak.

Fontosabb a web-es rész. Ha a TV-n nem megy natívan, azt túlélem.

( Cozi v | 2023. 02. 16., cs – 12:52 )

Végül a digiKam-ot izzítottam be, meglepően gyorsan pattog, mutatja a képeket, teszi a dolgát. Az alapfunkciókon túl még nem használok benne semmi mást.

Egyetlen technikai bajom van vele. Ubuntu 22.04 alatt LVM-ben van egy LV-em, 3.5 TB körüli méretben. Az /etc/fstab-bal felcsatoltam az /usr/data alá, gondoltam, oda rakom a média állományokat, így az ezernyi fényképemet is.

A digiKam nem találja ezt a könyvtárat, nem mutatja. Ha szim.linket készítek és beteszem a ~/Képek alá, azt sem mutatja a program állományválasztó párbeszédablaka. Állítottam a jogosultságokon is, de nincs eredmény.

Valakinek lenne ötlete,  hogyan lehetne a digiKam számára használhatóvá, elérhetővé tenni egy ilyen csatolt könyvtárat? (Vagy mit ronthattam el?)

Üdv, Cözi