Fotografie mobila Options

[G e o r g e]

incep un nou thread ... fotografii facute cu telefonul mobil ... let us see your best shots





fotografiile nu au fost ajustate in nici o forma , sunt AS IT IS ...

LE : camera : sony ericsson : W880

[James Kilowatt]

Banuiesc ca functiile de care vorbesti sunt implementate hard si in placa grafica din PC-uri. Poate insa photomatix nu stie sa le foloseasca, si se bazeaza exclusiv pe soft si pe CPU.... altfel nu vad cum poate sa fie atat de lent in comparatie cu o prastie de smartphone care nu e nici pe departe the cutting edge of pocket computing .
Desi cum spuneam photomatix nici macar CPU-ul nu il incarca la 100%, si ramii zac nefolositi.

@Klm
Am incercat si cu raw si cu jpg la aceeasi rezolutie, insa nu e sesizabila diferenta de viteza, tot atat de lent se misca pe PC. Adica nu e lent la modul absolut, nu trebuie sa stau ore in sir ca sa faca o prelucrare, insa nu e instantanee ca pe smartphone, dureaza secunde bune.

Revenind la HRD-ul pursange, eu am un Nikon D5000 care stie sa traga 3 cadre in rafala unul dupa altul cu expuneri diferite. Insa NU stie figura de care spunea halbasus, sa traga 3 cadre intr-o singura deschidere a diafragmei.

Am incercat si cu un Iphone (4 cred) al unui coleg si functioneaza la fel ca chinezaria. Adica tot trage mai multe cadre (cel putin 2) pe care le recombina ulterior, si la iphone apar fantomele alea cand imaginea e in miscare.

This post has been edited by James Kilowatt: Sep 3 2013, 01:41 PM

[Mircea104901]

Banuiesc ca functiile de care vorbesti sunt implementate hard si in placa grafica din PC-uri. Poate insa photomatix nu stie sa le foloseasca, si se bazeaza exclusiv pe soft si pe CPU.... altfel nu vad cum poate sa fie atat de lent in comparatie cu o prastie de smartphone care nu e nici pe departe the cutting edge of pocket computing .

Setul de instructiuni este propriu fiecarui procesor. Instructiunile x86 difera fata de ARM. Ca sa nu zic de algoritmii din GPU-uri care sunt proprii (ex CUDA proprietate nVidia), dar a aparut alternativa OpenCL (care nu inseamna instructiuni proprii procesorului, ci un standard prin care se poate programa GPU-ul) care e implementat inclusiv in CPU-urile Intel de generatie noua. Deci, daca scrii un program in OpenCL va functiona si pe nVidia si pe AMD si pe Intel (cele care stiu), pe cand CUDA doar pe nVidia.
Mai mult ca sigur algoritmii din Mediatek-ul tau implementati hardware nu exista in setul de instructiuni x86. Si o emulare a lor nu va fi la fel de eficienta, mai mult ca sigur, decat cu resurse muult mai mari.

Iti mai dau un exemplu: in setul de instructiuni din Core2Duo nu exista instructiuni specifice de codare-decodare AES. i-urile au implementata aceasta functie (AES accelerat). In utilizare, i-urile spulbera Core2Duo la AES.

Acuma, diferentele de performanta intre programe depind de cat de apropiate sunt de codul masina. Cele mai indepartate si cele mai proaste ca performante sunt programele interpretate (gen VB din Excel). Cele compilate depind de compiler, dar oricum ai da-o nu vor functiona ca un program scris direct in cod-masina. Dar dezvoltarea de aplicatii multimedia in cod-masina ... e ca si cum ai incerca sa muti un munte cu lopata. Se poate, dar dureaza.
In general, aplicatiile noi sunt scrise in medii de programare, in care nu mai controlezi manual hardware-ul (gen alocare memorie, eliberare memorie, etc). Mediile astea sunt vizuale, in marea lor majoritate, pentru a usura munca programatorilor. Deci intre codul sursa si rezultatul compilarii mai exista o interfata generata de masina, tocmai pentru a putea gestiona resursele in mod automat (cum e la .NET CLR-ul). Ce mai conteaza ca aplicatia nu va rula optim, atata timp cat exista resurse hardware (putere procesor in crestere an de an, memorie la fel), iar executia ei satisface clientii?