| inviato il 01 Maggio 2024 ore 10:14
“ 7.1s per esportare un file da 24mpx della z6 con DeepPrimeXD è notevole! ;-)
per raffronto, un Rayzen 5 5G con gpu integrata, ci mette circa un minuto per esportare un file da 24mpx della mia R6II, sempre più propenso a prendere una 4060...Sorriso
PS non capisco invece i 5.6s in High quality, il mio con gpu integrata è immediato (nessuna attesa)...bò „
Tempo fa ne avevo parlato: l'high quality usa le OpenCL, e l'ottimizzazione non è poi così significativa (meno di un fattore due sul mio sistema), quindi se hai una CPU performante puoi essere molto veloce anche con una GPU lenta. Addirittura quelli di DXO scrivono che viene avviato un benchmark, e se le OpenCL risultano più lente l'opzione non è disattivabile.
DeepPRIME è un nuovo motore, progettato probabilmente avendo in mente il GPU computing.
Prime un tempo era solo da CPU non so ora. |
| inviato il 01 Maggio 2024 ore 10:15
“ progettato probabilmente avendo in mente il GPU computing „
Puoi anche togliere il "probabilmente"!  |
| inviato il 01 Maggio 2024 ore 10:15
@Vito Serra
Grazie per il riscontro
@Gian Carlo F
Provo con Bridge, voglio vedere anche con il Viewer di Sony ... |
| inviato il 01 Maggio 2024 ore 10:29
“ Ecco, e qui casca l'asino!
A livello di programmi uso principalmente DxO PL 7 + FP 7 + Nik 6 e Capture One Pro, saltuariamente Luminar Neo, con tutti il problema è quello che poi vedo con il visualizzatore di immagini (FastStone Viewer 7.8), cioè immagini più chiare di quelle che vedo direttamente dal programma di elaborazione, c'è qualche regolazione che devo fare su FastStone oppure è fisiologica interpretazione del sw di visualizzazione? „
@NoPhotoPlease
Il discorso può essere complicato o semplice, dipende tutto da dove devi usare la tua immagine.
Avendo un file originale di partenza in RAW le strade sono veramente tante, ma alla fine visto che conta il risultato sarebbe opportuno percorrere una strada dove almeno lo spazio colore sia lo stesso.
Se il tuo scopo è visualizzare su monitor usando (FastStone Viewer 7.8) devi avere la possibilità di mantenere almeno lo spazio colore, se ci sono delle differenze quando guardi le immagini le differenze dipendono da come (FastStone Viewer 7.8) elabora le immagini e poi le ripropone.
Visto che è un visualizzatore potrebbe essere che genera delle anteprime che usa per formati diversi e quindi usa metodi di riduzione e/o ingrandimento con diverse interpretazioni.
Non conosco (FastStone Viewer 7.8) la mia è solo una supposizione.
Quindi, se devi usare il file per la stampa non userei (FastStone Viewer 7.8) come riferimento visivo.
Photoshop nel caso della stampa offre la possibilità di simulare la prova di stampa usando il profilo colore dello stampatore che dovrebbe differire a secondo del tipo di carta usata.
Però ripeto è una simulazione, ci si arriva vicini ma non è una cosa assoluta.
buona luce...
|
| inviato il 01 Maggio 2024 ore 10:29
“ Alle volte, visualizzando i jpg su C1 (sviluppati con DxO ) mi sembrano più saturi, ma forse è una mia percezione, non ho mai approfondito „
@Gian Carlo F, sarò invornito ma non riesco ad aprire i file sviluppati con DxO su C1! 
Aiuto! |
| inviato il 01 Maggio 2024 ore 10:33
“ Mi spiace contraddirti, ma non può essere così. I due processi utilizzano una strategia simile a quella del rendering nei giochi, con una minima parte gestita dalla CPU e la maggior parte gestita dalla GPU. Ne ho una dimostrazione matematica „
Non mi sono spiegato bene, l'elaborazione di un'immagine comprende una parte gestita dalla CPU e poi il DP gestito dalla GPU. Un solo processo ha dei tempi morti, quando lavora la CPU la GPU è inattiva e viceversa. Con 2 processi si coprono i tempi morti e si ottimizza l'impiego dell'hardware. Più di 2 processi non è detto che porti a miglioramenti perchè la gestione della schedulazione di più processi che si contendono una risorsa peggiora le prestazioni è infatti sui mio pc con Ryzen 7 - 8 core, RTX 3060 e 64Gb
12 foto da 45mpx, DP XD
1 Processo : 2 49s
2 Processi: 1 50s
4 Processi: 1 58s
Questo è il grafico, nella prima parte 1 processo, nella seconda 2 processi. Nota nella prima parte i buchi nella GPU che coincidono con i picchi della CPU
|
| inviato il 01 Maggio 2024 ore 10:52
“ @Gian Carlo F, sarò invornito ma non riesco ad aprire i file sviluppati con DxO su C1! Confuso
Aiuto! „
devi importare nel catalogo di C1 la cartella con i tuoi jpg, la mia percezione probabilmente dipende dal fatto che C1 genera una anteprima nel catalogo e la pompa un po'.... non ne sono sicuro che succeda eh |
| inviato il 01 Maggio 2024 ore 10:52
@Ivo6767
Grazie per il tuo contributo!
Non stampo, visualizzo solo a monitor 4K calibrato, i JPEG li salvo in sRGB, i TIFF in Adobe RGB (per elaborazioni con la Nik6).
Di base con DxO lavoro con il loro spazio "Wide gamut", con Capture One AdobeRGB, più i relativi profili ICC dedicati alla fotocamera |
| inviato il 01 Maggio 2024 ore 10:57
“ @Gian Carlo F
Ciao,
In questa frase dicevo quali sono i programmi che uso,
e quindi non sono associati al LAB.
Quando ho parlato del LAB era in riferimento dei risultati finali per la visione (monitor Stampa)
I due concetti erano in due post diversi.
Se estrapoli alcune parole di un post e poi dai una risposta inerente al post successivo sembra che ho detto che il LAB si può usare con programmi dove non è previsto.
Ho diviso apposta il concetto LAB e il concetto Prezzi e Programmi che uso,
li ho divisi apposta per non portare in errore l'interpretazione, ma vedo che non è bastato.
Buona luce a tutti. „
si... eri stato chiarissimo ed avevo inteso bene, volevo solo evidenziarlo a chi non ha dimestichezza con i vari software, colpa mia che sono stato troppo sintetico
|
| inviato il 01 Maggio 2024 ore 11:01
“ devi importare nel catalogo di C1 la cartella con i tuoi jpg, la mia percezione probabilmente dipende dal fatto che C1 genera una anteprima nel catalogo e la pompa un po'.... non ne sono sicuro che succeda eh „
Ok, grazie, smanettando c'ero arrivato da solo!
Comunque questo è quello che ho notato:
- Image Viewer di Sony, nessuna differenza con i file elaborati con DxO
- C1 nessuna differenza con i file elaborati con DxO
- FastStone Viewer immagini leggermente più chiare, minor saturazione? maggior luminosità? |
| inviato il 01 Maggio 2024 ore 11:08
Hai abilitato il color management in Faststone ?
Io uso Acdsee e XnView MP, in entrambi le foto sono identiche a come si vedono in DXO o Affinity sia quelle sRGB che AdobeRGB
Quando esporta in sRGB DXO non include il profilo ma setta solo il flag Exif per dire che l'immagine è sRGB può anche darsi che FastStone non lo gestisca correttamente |
| inviato il 01 Maggio 2024 ore 14:20
“ Hai abilitato il color management in Faststone ? „
@Giampaolo64 sì, sì, certo! Comunque è una lieve differenza, ne ho approfittato per chiedere lumi visto il commento di Ivo6767, che è un utente competente e preparato.
Grazie del tuo intervento, sempre utile e competente anche tu ... come altri che adesso non sto a menzionare!
|
| inviato il 01 Maggio 2024 ore 18:58
“ Non mi sono spiegato bene, l'elaborazione di un'immagine comprende una parte gestita dalla CPU e poi il DP gestito dalla GPU. Un solo processo ha dei tempi morti, quando lavora la CPU la GPU è inattiva e viceversa. Con 2 processi si coprono i tempi morti e si ottimizza l'impiego dell'hardware. Più di 2 processi non è detto che porti a miglioramenti perchè la gestione della schedulazione di più processi che si contendono una risorsa peggiora le prestazioni è infatti sui mio pc con Ryzen 7 - 8 core, RTX 3060 e 64Gb
12 foto da 45mpx, DP XD
1 Processo : 2 49s
2 Processi: 1 50s
4 Processi: 1 58s
Questo è il grafico, nella prima parte 1 processo, nella seconda 2 processi. Nota nella prima parte i buchi nella GPU che coincidono con i picchi della CPU „
Ora è chiaro e ragionevole |
| inviato il 01 Maggio 2024 ore 19:04
Tenete conto che, proprio da teoria accademica, l'estremizzazione della parallelizzazione, se applicata a contesti di elaborazione che non nascono già - inizialmente - per questa strada architetturale, porta a miglioramenti minimi, irrisori o addirittura peggioramenti già oltre gradi di parallelismo piuttosto bassi.
Se invece il contesto SW è fatto in partenza per essere parallelizzato all'estremo, ovviamente più nodì/processi/thread/task ci sono e meglio è: non con miglioramenti esponenziali o quadratici, chiaramente, ma molto più evidenti che nel caso precedentemente ipotizzato.
È il discorso dei giochi che faceva Blade prima: per ora vanno principalmente di forza bruta sul single thread, o su pochi thread/core: quando sarà sdoganato magari un nuovo paradigma e faranno giochi che sfruttano anche tanti core in modo efficace, si "stapperà la botte"; e credo ci si arriverà, altrimenti Intel, con i l'architettura ibrida "P-core + E-core", avrà preso una cantonata bestiale.
Arm in questo ho idea sia sempre stata un passo avanti ad x86_64 (vedansi le architetture dei SoC dei cellulari, da sempre ibridate fra core a clock maggiore e core a clock minore). |
| inviato il 02 Maggio 2024 ore 10:51
“ Tenete conto che, proprio da teoria accademica, l'estremizzazione della parallelizzazione, se applicata a contesti di elaborazione che non nascono già - inizialmente - per questa strada architetturale, porta a miglioramenti minimi, irrisori o addirittura peggioramenti già oltre gradi di parallelismo piuttosto bassi.
Se invece il contesto SW è fatto in partenza per essere parallelizzato all'estremo, ovviamente più nodì/processi/thread/task ci sono e meglio è: non con miglioramenti esponenziali o quadratici, chiaramente, ma molto più evidenti che nel caso precedentemente ipotizzato.
È il discorso dei giochi che faceva Blade prima: per ora vanno principalmente di forza bruta sul single thread, o su pochi thread/core: quando sarà sdoganato magari un nuovo paradigma e faranno giochi che sfruttano anche tanti core in modo efficace, si "stapperà la botte"; e credo ci si arriverà, altrimenti Intel, con i l'architettura ibrida "P-core + E-core", avrà preso una cantonata bestiale.
Arm in questo ho idea sia sempre stata un passo avanti ad x86_64 (vedansi le architetture dei SoC dei cellulari, da sempre ibridate fra core a clock maggiore e core a clock minore). „
Corretto, ci sono altri spunti di riflessione. Non sempre è possibile parallelizzare i calcoli a piacimento, anche se mi riesce difficile pensare ad un esempio pratico (ho pensato all'estrazione dei frame bidirezionali dell'mpeg, ma anche li ci si può lavorare). I giochi, quando AMD ha introdotto i primi processori dual core, erano rigorosamente single thread.
Inoltre, la strada del multicore è stata una scelta obbligata quando, a metà degli anni 2000, lo scaling tecnologico ha cominciato ad impattare solo l'area ed i consumi, ma non la frequenza operativa. Basti pensare che fra il 1984 ed il 2004 si è passati dai 20 Mhz del 386 ai 3.8 GHz del Prescott, ma nel 2024 siamo fermi a 6 Ghz.
Guardando l'architettura Intel di ultima generazione, in un paio di articoli ho notato che:
- l'area di un processore E è 1/4 di quella di un processore P
- sfruttando anche l'hyperthreading del processore P, la sua capacità di calcolo risulta essere circa il doppio di un E
Pensate quindi al core I9, che ha un prezzo tutto sommato abbordabile. Ha 8 processori P e 16 processori E. Da quanto detto sopra, sarebbe più conveniente mettere, nella stessa area, 48 processori E. Il problema è che questo andrebbe bene per per server o workstation di rendering, più in generali per applicazioni con un multithreading effciente o un multi-processing spinto. Ma per le altre applicazioni una architettura del genere sarebbe penalizzante. Sembra che i giochi sfruttino al massimo 8 core, non è un caso che Intel abbia scelto questo numero per i processori P, e AMD condivida la cache verticale del suo 7950Z3D solo con 8 core. |
|
Metti la tua pubblicità su JuzaPhoto (info) |
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
