PHP výběr obrázku na základě data vytvoření

[Wangarad]

Dobry den.
Mam trosku problem.
Zadanie: Kamera generuje obrazky s random nazvom. Potrebujem tieto obrazky nacitat do stranky podla casu ale jedine info co mam je len datum vytvorenia. Cele to musi byt v PHP. Popravde ani netusim ako vybrat subor na zaklade datumu vytvorenia. Vedel by niekto poradit ako na to? (tych obrazkov je tam denne cez 6000)

[Reklama]

[czipis]

https://www.php.net/manual/en/function.filemtime.php

nacist, seradit, zobrazit jenom tolik nejnovejsich kolik vas zajima

[Miroslav Šilhavý]

Asi by bylo víc na místě brát datum z IPTC / EXIF, než z filesystému. Tam stačí provést nějakou operaci, datum se cinkne, a celý mechanismus půjde do pryč. S IPTC / EXIF se z PHP pracovat dá.

Jiná věc je, že pročesávat 6000 fotek bude relativně výkonově náročné.

Osobně bych použil některý z nástrojů v příkazové řádce, které umějí EXIF / IPTC načíst a navrátit třeba jako json. V něm se pak dá dobře vyselectovat např. pajpou do databáze (postgresql). Bude to určitě rychlejší a efektivnější i spolehlivější, než to patlat v PHP.

[PanVP]

Máte 6000 krabic a hledáte červenou botu. Tj. prohledáte 6000 krabic, najdete tu krabici s červenou botou a pak znova?
Blbost, nemluvte do věcí, které neznáte. A chápete, jak velký cirkus by to s tou databází byl?

Takže postup číslo 1 - pomůžu si Ramdiskem - tj. disk v paměti!
PHP vezme obrázek, zobrazí ho a VŠECHNY OBRÁZKY SMAŽE... pak znova.... a znova.... a znova...
Obrázky pořád přitékají, tak to je v pohodě.
Na pozadí mi běží služba, která obrázky po minutě smaže, třeba něco jako:
find . -name "access*.log" -type f -mmin +15 -delete

Varianta:
PHP smaže všechny obrázky, počká, až se nějaký objeví, zobrazí ho a zase znova.
(Ten skript trochu blokuje, ale to je fuk.)
Opět doporučuji posílat data na Ramdisk.

Varianta:
PHP mi pustí pythlounový skrip, který mi připraví "tohlezobraz.jpg".
Klidně by tam mohla běžet i malá službička, která obrázky z kamery přijímá.
Pak by šlo dělat i docela pěkné vychytávky.

Řešení je celá hromada a žádné nepotřebuje databázi. Jo a složité souborové operace (hledání) jen zdržují.
Jistě vás napadne, jak to řešit elegantněji, než takhle.

BTW, tohle je úkol pro studenta druhého ročníku IT SŠ?

[Miroslav Šilhavý]

...

Já neřekl, ukládat data do DB, ale využít její schopnosti pracovat s JSON a datetime datovými typy.
Něco ve smyslu SELECT ... FROM (VALUES (json)). DB jsou na takové operace vybavené, zatímco v PHP to bude smyčka a slepenec operací.

Pokud lze obrázky po zpracování mazat nebo přesouvat, je samozřejmě nejlepší to, co píšete. To ovšem v zadání nečtu.

[Reklama]

[PanVP]

To ovšem v zadání nečtu.

Já zase v zadání nečtu, že není možné s obrázky pracovat na úrovni adresáře.
Takže opět obhajujete neobhajitelné.

A mazání samozřejmě nutné není, klidně se dají přesouvat někam na pevný disk nebo do jiného adresáře.
Dokonce se ani nemusí mazat, stačí je přejmenovat a ani se nemusí měnit přípona souboru.
Takže tu máme další řešení.
Starší soubory se prostě budou jmenovat původnínázev.uzjsemvidel.jpg

Snad všechno je lepší než dokola přehrabovat XY set nebo tisíc souborů.

[Miroslav Šilhavý]

Takže opět obhajujete neobhajitelné.

Nikoliv, pouze se snažím do zadání nedomýšlet to, co v něm není. Je tam hovořeno pouze o načítání.
Pokud je možno s nimi pracovat (přejmenovávat, přesunovat), je celý dotaz o ničem a špatně formulovaný.

Kód [Vybrat] Rozbalit

exiftool -d "%Y-%m-%d %H:%M:%S" -j -iptc:all * navrátí zformulovaný JSON se vším, co je potřeba. Datum, čas, jméno souboru a další. S JSON se pak můžete patlat v PHP, nebo na to využít nějaký další nástroj - třeba tu DB. Hotovo za dvacet minut, bez jediného ojebu v PHP.

Teď jsem si to zkoušel, 6000 jpegů (velkých - v průměru 1,5 MB) mi to na rotačních discích zpracovalo za 2:15.
U malých obrázků, případně na SSD (nebo ramdisku) to bude samozřejmě o poznání rychlejší.

[PanVP]

je celý dotaz o ničem a špatně formulovaný

  Jo tak 

6000 obrázků ... zpracovalo za 2:15

     
Tak dobře no Vyhrál jste 

Když se tam přidá stránka s odpočtem, kdy bude možné obrázek zobrazit, tak bezva.
A není trochu nevýhoda, že za ty dvě minuty tam přibude pár dalších obrázků?

[Miroslav Šilhavý]

je celý dotaz o ničem a špatně formulovaný

  Jo tak 

6000 obrázků ... zpracovalo za 2:15

     
Tak dobře no Vyhrál jste 

Když se tam přidá stránka s odpočtem, kdy bude možné obrázek zobrazit, tak bezva.
A není trochu nevýhoda, že za ty dvě minuty tam přibude pár dalších obrázků?

Aha, tak to jsem snad ani nepředpokládal, že by někdo chtěl on-the-fly dělat 6000 operací, ať už nad EXIFEM, nebo nad filesystémem. To je sebevražda. Tímto způsobem lze pouze získat data o tom, kdy vznikl jaký obrázek a pak s tím pracovat. (Uznávám, tady jsem naopak domyslel něco já)

[PanVP]

Aha, tak to jsem snad ani nepředpokládal, že by někdo chtěl on-the-fly dělat 6000 operací

Potrebujem tieto obrazky nacitat do HTML stranky podla casu ale jedine info co mam je len datum vytvorenia. Cele to musi byt v PHP.

Web + PHP ...alespoň ve mně DOST evokuje on-the-fly.

A protože tam přitéká nový obrázek evidentně co 14 vteřin, může být nejsnazším řešením třeba cronový task, který mění název souboru na požadované jméno.

Co by cronový task - spuštěný každých 14 vteřin - mohl dělat:
Zapíše (přípíše) do "tohleJeVlozene.html" text "Záznam TIME %h%m%s-%d%M%R" (soubor tak zároveň slouží jako log - super na ladění, protože vím, kdy mi vyplivla kamera nebo služba)
Podívá se do adresáře a pokusí se najít obrázek.
Pokud ho najde, přesune ho do adresáře "data" a jejich názvy vloží opět do "tohleJeVlozene.html"
PHP aplikace pouze vloží do stránky "tohleJeVlozene.html" a kromě toho nedělá vůbec nic.
Z mého pohledu to je další možnost a práce na pár minut 
...takže DALŠÍ možnost...

Ale odpadne tam možnost uvařit si kafe, než se těch 6000 souborů zpracuje...

[Miroslav Šilhavý]

...

Souhlas, těch řešení se nabízí víc.
Já bych třeba volil (osobní preference) zpracovávat to jednou za čas a mít v DB i uložené informace vyseparované z EXIFU. Task by pak neprocházel 6000 obrázků naráz, ale jen pár kousků, co přibyly. Pokud nebudou mít každý 1,5 MiB, jako jsem si zkusil já, tak to bude zase kratší.

Ono tuhle myšlenku můžeme rozvíjet do nekonečna, protože nemáme další informace. K zamyšlení taky je, jak bude vypadat adresář, pokud do něj jen přibývají obrázky a neubývají. Pak už bude jen samotné vylistování adresáře docela zdržující.

Pokud je možnost přesouvat na disku, pak bych nějakým taskem obrázky přejmenoval a do jména souboru dal informaci o času vzniku a rozhodil je do stromu podle dnů, případně ještě o level víc, podle hodiny.

[czipis]

pokud jde o prochazeni mtime nad 6000 soubory, tak jsem ted vyzkousel a na beznem SSD s ext4 to cele trva 0.06s

Kód [Vybrat] Rozbalit

foreach (scandir($dir) as $filename) echo "$filename " . filemtime($filename) ."\n";
coz mi neprijde jako cas na to uvarit si kafe...

Kód [Vybrat] Rozbalit

$ time php dir.php >/dev/null

real 0m0.060s
user 0m0.025s
sys 0m0.035s


EDIT: omluva, mel jsem to v diskovaych cache. po vysypani cache je to

Kód [Vybrat] Rozbalit

# sync; echo 3 > /proc/sys/vm/drop_caches
# time php dir.php >/dev/null

real 0m0.361s
user 0m0.040s
sys 0m0.135s


[Miroslav Šilhavý]

pokud jde o prochazeni mtime nad 6000 soubory, tak jsem ted vyzkousel a na beznem SSD s ext4 to cele trva 0.06s

Kód [Vybrat] Rozbalit

foreach (scandir($dir) as $filename) echo "$filename " . filemtime($filename) ."\n";
coz mi neprijde jako cas na to uvarit si kafe...

Kód [Vybrat] Rozbalit

$ time php dir.php >/dev/null

real 0m0.060s
user 0m0.025s
sys 0m0.035s


Tím získáte čas zapsání souboru na disk, ale to vůbec nevíte, jestli je čas vzniku fotografie. To se ukrývá v exifu.

[qelurg]

Pánové, v zadání žádná práce s obrázky (přesouvání, přeumenování) není, natož ve formě nějaké služby. Požaduje se jejich zobrazení pomocí php podle blíže neupřesněného času. Takže v první řadě je potřeba zjistit porle jakého času se to má posuzovat a zda to neběží na filesystému, který uchovává informaci create time nebo zda to má být oddolné proti modifikacím. Teprve pak lze navrhovat řešení, popř. zjišťovat další informace, jako je jak hluboko do historie, zda je to volitelné, zda je to single nebo multi, zda je možnost databáze.

[PanVP]

Máš pravdu soudruhu