Hromadné spracovanie obrázkov ?

[miroB]

Máte skúsenosti s technikami: Skia, SVG, Direct2D, GDI+, ImageEn (platené), Image32 ?
Alebo prípadne iné?
Idem riešiť zhruba túto úlohu pre moje fotografie:
-   Prečítať všetky obrázky v zadanej ceste a upratať ich do databázy s týmito požiadavkami:

•    čítať exif (dátumy, čas, poloha GPS, foťák, SW verzia, rozlíšenie, natočenie, ISO a ďalšie ). Exif čítanie mám.
•    Každý súbor by bol hashovaný algoritmom BlakeX kvôli očakávaným duplikátom (duplikované súbory sa uložia len raz, ale so všetkými odkazmi) Mám hashovanie Blake2b a asi stačí..
•    Ide o zálohovanie, takže sa vytvorí zrkadlový obraz súborov, ale s novo generovanými menami GUID (očakávajú sa duplikáty. Preto sa zmenia mená, tie musia byť potlačené, lebo všetky súbory/obrázky budú v jednej knižnici). Dúfam nevadí 150 000+ súborov v jednej knižnici. Bude na nich odkazovať databáza.
•    Odkladať do DB zmenšené  a správne otočené obrázky (kópie). Zapisovanie obrázkov do Blob ovládam
•    verzia pevného rozmeru 640x480, preto potrebujem rýchle  zmenšenie a prípadne aj otočenie
  ale k tomu ešte aj menší a rýchly náhľad (môžem extrahovať thumbnails). To viem.
•    vo veľkosti cca ako medium icons vo Windows Explorer. Práca s medium icons nad databázou:
•    veľmi rýchlo zobrazovať zmenšeniny, ako vo windows explorer
•    možnosť hromadného označenia, resp. výber zo zoznamu obrázkov (cca nejaký zoznam ikon)
•    rôzne druhy rýchleho sortovania ikon (budú rôzne kritériá v zmysle databázy, očakávam zoznam ikon v rozsahu 10 - 1000 položiek. Pôjde o výber, ale aj s prípadným popisom - komentárom)
•    z náhľadu medium icons rýchle prepnutie len určitého výberu na kvalitnejší náhľad v rozmere 640 x 480
•    zobraziť originál obrázku (napríklad jednotlivý obrázok o veľkosti až do 20 MB) z náhľadu s možnosťou vpísania komentára (textu)  z databázy priamo do obrázku
•    skopírovať výber do zadanej knižnice ( súbory originálov a k ním prípadne aj rozmer 640x480)
•    export jednotlivých obrázkov do iných formátov ( pdf, webp, heic, heif, alebo tlač)
•    export výberu obrázkov do jedného dokumentu predpokladám 1 až 10 položiek ( pdf alebo tlač. Asi spravím pomocou TMS.)
•    v databáze bude aj cesta k originálom (aj ku všetkým ich duplikátom)
•    Cesty a názvy súborov/fotiek budú “rozbité na atómy”. Jednotlivé výrazy/slová medzi delimitermi budú tiež priradené k obrázkom pre možnosť vyhľadávania (nejaký číselný json zoznam odkazov na položky pomocnej tabuľky)
•    grupovanie fotiek (podobný obsah, podobná poloha) Podobnú polohu (ostrovy/zhluky) už mám. Podobný obsah zatiaľ nemám..
•    Databáza bude SQLite

Výzva smerom k technikám je najmä rýchla transformácia obrázkov, rýchle zobrazovanie zmenšených verzií a prípadné iné skúsenosti z oblasti.
Napríklad zobrazovanie: bežný TImage nezobrazí fotku veľkosti 20MB dostatočne rýchlo.
Je iná technika, ktorá to zvláda za polovicu času, možno menej.
Prípadná kompatibilita s Android je tiež zaujímavá.
Napríklad ImageEn má hodne silné možnosti (rozpoznávanie tvárí a ďalšie pokročilé funkcie), ale cena od 500+ eur do 790+ (asi bez DPH) je nepríjemná.

[vandrovnik]

A jak že zní konkrétní dotaz? :-)
Z vyjmenovaných věcí aktivně používám jen Direct2D.

[Radek Červinka]

Image32 je klasicka knihovna, umi rychle zmensovat obrazky atd, ale bez HW podpory.

SKIA je momentalne asi TOP, za vyvojem je google, v D12 je specialni verze s podporou Vulkan API, ktera neni opensource a IMHO nic rychlejsiho asi neni (i bez Vulcan ktera je pro starsi Delphi).

SVG je graficky formát a to je uplne neco jineho.
GDI+ je dobra, ale historicka knihovna.

Direct2D je HW akcelerovane, ale dnes bych to nahradit SKIA.

Firemonkey podporuje jak Direct2D, tak GDI+, tak SKIA.

Tvuj problem je ze
a) chces pracovat s obrazky
b) chces o nich ziskavat info

[miroB]

..
Tvuj problem je ze
a) chces pracovat s obrazky
b) chces o nich ziskavat info

Tvoje zhrnutie je zhruba výstižné. Ďakujem za informácie k technologickým možnostiam.
Skrytých problémov je viac:
- V prvom kole sa z obrazovej časti spraví transformácia (správne natočenie a zmenšenie). Pre správne natočenie musím čítať Exif. Windows Explorer to tiež využíva. Inak by mnohé obrázky boli dolu hlavou, alebo by ležali.
Tento prvý proces s databázou a analýzami v zásade zbehne len raz. Alebo pri nových obrázkoch, preto na čase až tak nezáleží.
- Otázky sú pre "každodenné" využívanie:
  ak chcem rýchlo prezerať zálohované súbory v plnej veľkosti:
  - OTOČENIE - asi by som ich mal už zálohovať otočené. Skôr aj origo, aj otočené.
  - VEĽKOSŤ - niektoré z obrázkov sú obrovské. Tieto by som mal možno tiež uložiť duplikovane - v pôvodnej veľkosti a v rozlíšení max 4K (to pre rýchle prezeranie na PC - asi nie je jedno, či rýchlo prezerám súbory do 3MB alebo nad 20MB). Pôvodná veľkosť sa hodí na výrezy, alias "priblíženie", takže tej sa určite nechcem zbaviť.
  Pre OTOČENIE a VEĽKOSŤ by sa mi zišli praktické poznatky, či tie časy transformácií hrajú významnú rolu. Pretože ide aj o milisekundy (zhoršenie, alebo zlepšenie na jednom obrázku). Na rozdiel od prvého načítania do databázy sa prezeranie udeje stovky krát, nie len raz.
Miesto na diskoch mám s rezervou, až bude poriadok, ešte kopu miesta ušetrím. Takže mať uložené viaceré verzie vôbec nie je problém. Ide o to, či sa také riešenie citeľne prejaví vo výkone. Samozrejme môžem robiť testy (vždy robím), ale ak má niekto skúsenosti, možno ušetrím kopu času.
Nejaká transformácia bude vždy, nebudem ortodoxne optimalizovať všetky fotky len na jednu konkrétnu obrazovku. Sám ich mám niekoľko a samozrejme tie fotky nebudem využívať jediný. To by boli rozlišovačky od 1920x1080 do 4K. To by už bolo príliš veľa záloh.
Preto záleží aj na tom, že akým komponentom zobrazujem.
Pre Delphi 10.2 Tokyo nebol bežný Load do TImage práve optimálny. Skontrolujem, ako to má D 12.2
Tu popísané problémy sú len časťou môjho bádania.

Napríklad by mi pomohol názor užívateľa ImageEn. Tam by mohli byť skryté kvality, ktoré by mi vedeli možno výrazne pomôcť.

Zhrnutie: Nie som síce na samom začiatku, mnoho už mám, ale idem sa viac rozbehnúť a nechcem chytiť nejaký horší smer.

[Radek Červinka]

No já jsem něco podobného dělal ve stylu:
- mam uložené originály
- při požadavku na seznam obrazku jsem si sáhnul do cache na disku, kde jsem měl zmenšené obrázky na cca 256 pixelu v jednom směru, pokud tam nejsou v cache, tak jsem ho z originálu resiznul a ulozil do cache pro priste (resize je celkem nárocna operace)

to je tak vsechno co ti mohu poradit

[miroB]

No já jsem něco podobného dělal ve stylu:
- mam uložené originály
- při požadavku na seznam obrazku jsem si sáhnul do cache na disku, kde jsem měl zmenšené obrázky na cca 256 pixelu v jednom směru, pokud tam nejsou v cache, tak jsem ho z originálu resiznul a ulozil do cache pro priste (resize je celkem nárocna operace)

to je tak vsechno co ti mohu poradit

Čo presnejšie máš na mysli pre "cache na disku"? Niečo ako existujúce thumbnails, ktoré vyrobí windows explorer? Sú prístupné cez nejaký Shell, alebo?
Inak si viem zrejme na disk extrahovať aj thumbnails, ktoré sú priamo súčasťou origo obrázku.
Ale celkove mám predstavu o viacerých verziách jednoho obrázku pre rôzne účely (hromadné zobrazovania, rýchle prezeranie mini obrázkov, ale aj obrázkov v nejakej "poctivejšej" veľkosti).

Je tu ešte jedna opomenutá technická otázka: Máte informácie o max počte súborov v jednej jedinej knižnici, aby to nejak nebrzdilo môj systém?
Napríklad starší televízor Samsung (asi rok 2014/16) vie nahrávať filmy, ale neodporúča sa viac ako 800 súborov na jednu knižnicu externého disku (ten mám 6TB, takže hafo miesta). Telka používa nejakú verzia linuxu. A je pravda, že keď sa blížim tomu počtu tak blbne. Ten disk viem čítať aj na PC (iba manipulácia so súbormi, nie pozeranie, to je šifrované).
Hmm, práve mi Copilot poradil, nech nedám len jeden adresár so 100tisíc+ súbormi, ale odporúča aspoň jednu vnorenú úroveň. Napríklad 100 knižníc v root a tam po 1000+ súboroch. Prípadne pridať ešte jednu vrstvu podknižníc. Sľubuje rýchlejší prístup a manipuláciu, tiež aj stabilitu systému oproti 100tisíc+ súborom v jednej knižnici.
To aj pre prípad, že filtrovanie prebehne v databáze a ja budem mať vždy už len smerník (fullname) pre vybraný súbor

[miroB]

Už som pochopil, že cache na disku bude súvisieť z thums.db
Prístup ku cache na disku sa rieši pomocou "CoThumbnailCache", teda práca s COM.
Ale v zásade tú vlastnosť (tvorbu Thumbs.db) chcem skôr cielene vypnúť pre moju pracovnú knižnicu, pretože chcem vlastné náhľady, predbežne v týchto veľkostiach:

• 320x240
• 640x480
• formát blížiaci sa 4K, možno menej, pre rýchle prezeranie na obrazovkách
• originál (jeho veľkosť môže byť 2, 10, ale aj 50MB)

Takže by to bolo 4 x 100 x 1000+ zbytočne generovaných thumbs vo Windows Explorer
Preto musím zakázať túto vlastnosť pre svoju pracovnú knižnicu. (Ostatné disky a knižnice svojho PC normálne používam, takže očakávam klasické správanie Explorera)
Pre Windows 11 Pro (iný systém v rodine nebude), sú dve možné riešenia ako zakázať tvorbu Thumbs pre vybranú knižnicu:

• Použitie Group Policy (gpedit.msc)
• Úprava Registry

Jednu z nich si vyberiem, ale musím ešte preskúmať. Tnetoraz som sa pýtal ChatGPT:)

[Radek Červinka]

Už som pochopil, že cache na disku bude súvisieť z thums.db

Ne, to byla moje cache, nic spolecneho s explorerem, kompletne v moji rezii.

[Jan Fiala]

Muzes to resit slozkami - miniatury / prohlizeni / velke (nepovinné, pokud velikost je vetsi a ty jsi vyrobil verzi k prohlizeni)
Pro rychly nahled se miniatury zobrazi okamzite, podle nazvu souboru (tvuj guid) pak muzes u sveho prohlizece zobrazit verzi pro prohlizeni nebo tu velikou, pokud je k dispozici.

[miroB]

Je pre mňa zaujímavé, že 100tisíc+ súborov v jednej knižnici je pre systém NTFS horšie ako 100knižníc a v nich cca 1000+ súborov.
Niektoré veci vyskúšam. Asi aj prípad s vyššou úrovňou vnorenia knižníc. Prípadne spravím pokus o uloženie do SQLite databázy (samostatná attached databáza len pre veľké obrázky). SQLite sa chváli vysokým výkonom až na úrovni súborového systému.
Neprogramiujem naplno, lebo ešte stále riešim byt a poriadok a len pomaly hľadám priestor pre prácu.
Keď mám čas plánujem si postup. A konzultujem tiež s ChatGPT a Copilot. ChatGPT sa nejak zlepšil za posledné mesiace.
Možno som prílš optimista, ale programovanie sa zdá byť minimálne zábavnejšie s pomocou AI. Možno príde časom aj zvýšená podpora pre lokálne NPU akcelerátory:)

Myslím, že nebude problém pozmeniť niektoré nastavenia keď už spracovanie dát rozbehnem.
Ako prvé sa mienim držať odporúčaní, potom môžem venovať čas aj testom s modifikáciami. Rozsah je cca 700+ GB (vstupné údaje) pri očakávaných  100tisíc+ unikátnych fotografií. Je veľa duplikátov a podobných obrázkov, za dlhé roky zberu. Nejaké pokusy nad konkrétnymi údajmi už mám za sebou tak nejde o krok úplne do vzduchoprázdna. Jediné, čo som vôbec nerobil je samotné zálohovanie (súbory s generovaným GUID názvami, resp. uloženie do databázy. To s tou databázou asi nebude dobrá cesta, ale pokus možno dám )

Fyzicky mám 2 počítače, starší s CPU Ryzen 3700X (2019) so 64 GB RAM (3400MHz), novší má Ryzen AI 9 HX 370, ale len 32 GB RAM LPDDR5X 7500Mhz. Novší má aj NPU s 50 TOPS - pre budúcu podporu AI. Podľa benchmarkov by mal byť ten novší o ca 30% rýchlejší.

Údaje pre výpočet a aj pre výslednú prácu budú vždy lokálne na porovnateľných SSD diskoch.

Pokúsim sa držať Delphi 10.2 Tokyo, aby som niekde s D 12.2 nenarazil.

Cieľom je aby sa dal výsledok pozerať na lacných MiniPC s Intel N100 a 16MB RAM. Výsledné údaje očakávam v rozsahu 300+ GB údajov po vyfiltrovaní. Budú na lokálnom SSD disku. Prezeranie bude založené najmä na viacvrstvovom filtrovaní.

Dám vedieť.

[František]

mozno trocha odveci ale ked som cital toto vlakno napadlo ma ze toto by ti tiez mohlo byt prinosom https://pctuning.cz/article/jak-jednoduse-na-lokalne-akcelerovanou-ai-ukazeme-co-umi-i-jak-ji-zprovoznit

[Radek Červinka]

Díky za info, právě lokální Ollama je prý velmi dobrá a takový CnWizards ji přímo podporuje, jako model qwen2.5-coder

[miroB]

Díky za info, právě lokální Ollama je prý velmi dobrá a takový CnWizards ji přímo podporuje, jako model qwen2.5-coder

Íiha.. A s týmto má niekto už nejaké reálne skúsenosti?
Zaujímavé..
Na prvý pohľad to nie je pre nováčika celkom transparentné.