Rilasciato Sigma Photo Pro 6.8.3

[Rino]

L'ho scaricato e funziona benissimo (iMac con M1) ed è più veloce e reattivo in ogni operazione.
Ho aperto e salvato vari X3F e X3I, tutti ben sviluppati ed ha recuperato meglio e con meno rumore una foto sottoesposta di un paio di stop, ma, dopo un'oretta di prove, quando l'ho chiuso, si è congelato ed ho dovuto fare un'uscita forzata dall'applicazione.

Può darsi che sia stato solo un caso, ma, in attesa di ulteriori verifiche, installatelo senza cancellare la precedente versione.

[edecapitani]

Ho visto l'avviso quando ho aperto spp ieri, oggi lo scarico, a maggior ragione dopo aver letto il tuo post

[Rino]

Stamattina l'ho usato di nuovo, questa volta coi giganteschi DNG della Sigma fp L e non ho avuto il benché minimo problema neanche in chiusura.

Molto gradevole l'impostazione "dorato caldo", purtroppo non disponibile per il Foveon. Foto scattata con fp L e nuovo Sigma 50/1.4 DG DN Art interamente sviluppata con SPP (ho usato Photoshop solo per ridurne le dimensioni).

[Joserri]

Grazie!


If you have “SIGMA Photo Pro 6.8.2” installed on your computer, please uninstall the software. It is not possible to install “SIGMA Photo Pro 6.8.3” properly if “SIGMA Photo Pro 6.8.2” is already installed. You need to restart the computer soon after this software is uninstalled. After finishing installation, please reboot your computer

[Rino]

Grazie!


If you have “SIGMA Photo Pro 6.8.2” installed on your computer, please uninstall the software. It is not possible to install “SIGMA Photo Pro 6.8.3” properly if “SIGMA Photo Pro 6.8.2” is already installed. You need to restart the computer soon after this software is uninstalled. After finishing installation, please reboot your computer

Non lo sapevo, grazie per la precisazione José. Fortunatamente sul Mac è più facile (a quanto pare non ci sono file sparsi nel computer) e non ci sono problemi a tenere tutte le versioni di SPP. Copincollo dal sito Sigma:

Installation (Mac)
Double-click the disk image of “SIGMA Photo Pro 6.8.3” and display the install dialog.
Drag the icon of “SIGMA Photo Pro 6” and drop it on the application folder. Then, the install process will finish.

[Met]

Installato SPP su un PC del 2014, con windows 11; negli anni ho aggiornato il vecchio HD con un SSD e installato una scheda grafica geforce GT 1030 (il minimo sindacale per gestire un monitor da 3840x2560 px) - sembra più reattivo della versione precedente. Con mio grande piacere.

[SierraVictor]

Installato su Mac Studio Max (32 Gb) per verifica. Sulle prestazioni non so che dire, non ho memoria di come girava sull'iMac Intel anche se mi sembra più veloce .Però una cosa ho notato: 12 gbyte di ram di sistema utilizzata nel complesso sono molti ma non escludo che la maggior parte siano strettamente dell'OS perchè più RAM c'è, più ne occupa lui di base. Su eventuali bug non mi esprimo perchè l'ho testato solo 2 minuti.
Esprimo però un parere personale e off-topic: la app in sè non è un gran che difficile da creare da zero essendo costituita da un'interfaccia banale e molte funzioni che altro non sono che equazioni matematiche. Applicare quindi quelle poche modifiche necessarie per lo switch intel-arm e avere la versione Arm/M1 (o M2) non lo vedo chissà quale sforzo. Non capisco, quindi, perchè non esista ancora una versione Arm. E il fatto che giri bene con Rosetta non può essene la giustificazione. (Ricordo che Rosetta è un ittimo ricompilatore ma resta pur sempre un palliativo con potenziali complicanze rispetto ad yna versione nativa).

[Tino84]

Io rimango ancorato alla 6.7.2, anche questa nuova versione non mi fa visualizzare l’immagine per la modifica, deduco sia una limitazione data dal mio MacBook + high Sierra e le nuove versioni di SPP 

[SierraVictor]

Io rimango ancorato alla 6.7.2, anche questa nuova versione non mi fa visualizzare l’immagine per la modifica, deduco sia una limitazione data dal mio MacBook + high Sierra e le nuove versioni di SPP 

Strano. Almeno fino alla 6.7.5 dovrebbe funzionare. È dalla 6.8 che la 10.14 compare come requisito minimo. Mi spiace.

[Rino]

Installato SPP su un PC del 2014, sembra più reattivo della versione precedente.

Decisamente più reattivo e veloce in tutto. La differenza con la precedente versione si avverte.
Dopo il congelamento alla chiusura della prima volta, è sempre andato benissimo.

[tik68mi]

Sembra un po' più veloce, sopratutto nell'aprire i jpeg/tiff ma anche gli x3f/x3i.
Grazie!

[tik68mi]

Che strano che su pc il processore e la scheda grafica vengano usati poco durante le elaborazioni, forse per questo è lento.
E peccato che non si possano fare modifiche su tutti i file insieme.

[andrea948]

Che strano che su pc il processore e la scheda grafica vengano usati poco durante le elaborazioni, forse per questo è lento.
E peccato che non si possano fare modifiche su tutti i file insieme.

[SierraVictor]

Che strano che su pc il processore e la scheda grafica vengano usati poco durante le elaborazioni, forse per questo è lento.

No, non è strano. Ci sono altri parametri di cui tener conto come il canale (bus) attraverso il quale i vari componenti comunicano: se non è sufficientemente ampio funge da collo di bottiglia. È per questo, tra le altre cose, che nei nuovi chipset Apple la memoria è condivisa tra CPU e GPU. Inoltre c'è l'incognita sw: non possiamo sapere quanto esso sia o meno ottimizzato. Come ho già detto altrove sono convinto che spp sia piuttosto penoso perchè, con l'hw che abbiamo oggi, mi sembra strano che certe operazioni siano istantanee su altri sw e percettibilmente lente in spp. Qui la differenza va ben oltre un fattore 3x dato dalle dimensioni dei file da gestire.

[Rino]

Come ho già detto altrove sono convinto che spp sia piuttosto penoso perchè, con l'hw che abbiamo oggi, mi sembra strano che certe operazioni siano istantanee su altri sw e percettibilmente lente in spp. Qui la differenza va ben oltre un fattore 3x dato dalle dimensioni dei file da gestire.

Se un programma è l'unico a tirare fuori il massimo dai suoi file proprietari, definirlo "Penoso" è eccessivo. Non voglio difendere nessuno, ma SPP fa il suo lavoro bene e lo fa senza fare i salti mortali in combo con altri software o adoperare quelli che fanno finta di sviluppare l'X3F ma si limitano ad aprire la foto JPG contenuta nell'X3F. L'unico che sviluppava bene l'X3F era Luminar nelle primissime versioni, ma poi hanno preferito lasciar perdere: la spesa non valeva l'impresa.
Certo, è più lento di tutti i programmi commerciali che possono venire in mente (per Bayer), ma - appunto - è un programma gratuito ed ha a che fare con il Foveon. Quando Sony e Nikon offrivano i loro software tipo SPP, erano peggio (lentissimi e pesanti, altro che SPP) e, non per niente, trattandosi di semplici Bayer, hanno avuto la possibilità di rinunciarci e prendere accordi con Capture One per una versione ridotta da offrire gratuitamente ai propri utenti.

[SierraVictor]

Mi riferivo solo alle prestazioni.

[tik68mi]

Che strano che su pc il processore e la scheda grafica vengano usati poco durante le elaborazioni, forse per questo è lento.

No, non è strano. Ci sono altri parametri di cui tener conto come il canale (bus) attraverso il quale i vari componenti comunicano: se non è sufficientemente ampio funge da collo di bottiglia. È per questo, tra le altre cose, che nei nuovi chipset Apple la memoria è condivisa tra CPU e GPU. Inoltre c'è l'incognita sw: non possiamo sapere quanto esso sia o meno ottimizzato. Come ho già detto altrove sono convinto che spp sia piuttosto penoso perchè, con l'hw che abbiamo oggi, mi sembra strano che certe operazioni siano istantanee su altri sw e percettibilmente lente in spp. Qui la differenza va ben oltre un fattore 3x dato dalle dimensioni dei file da gestire.

Sì il problema di ottimizzare i programmi nati anni fa con i nuovi hw esiste su tutti i sw, forse fan "prima" a rifarlo da zero.

[SierraVictor]

Che strano che su pc il processore e la scheda grafica vengano usati poco durante le elaborazioni, forse per questo è lento.

No, non è strano. Ci sono altri parametri di cui tener conto come il canale (bus) attraverso il quale i vari componenti comunicano: se non è sufficientemente ampio funge da collo di bottiglia. È per questo, tra le altre cose, che nei nuovi chipset Apple la memoria è condivisa tra CPU e GPU. Inoltre c'è l'incognita sw: non possiamo sapere quanto esso sia o meno ottimizzato. Come ho già detto altrove sono convinto che spp sia piuttosto penoso perchè, con l'hw che abbiamo oggi, mi sembra strano che certe operazioni siano istantanee su altri sw e percettibilmente lente in spp. Qui la differenza va ben oltre un fattore 3x dato dalle dimensioni dei file da gestire.

Sì il problema di ottimizzare i programmi nati anni fa con i nuovi hw esiste su tutti i sw, forse fan "prima" a rifarlo da zero.

Spesso non è poi così necessario. I sw fanno molto uso di librerie di sistema che pensano a gestire direttamente l'hw diverso. Temo che qui il problema sia un altro.

[tik68mi]

Non son esperto, vedo nei SW di rendering per esempio che ne stanno uscendo di nuove e veloci che sfruttano le GPU RTX con molti cores; o CPU con molti cores che non hanno SW che li sfruttino con dispendio inutile di watt e calore (e rumore delle ventole).
Un buon tuning pare aiuti in questo senso a sfruttare al meglio le componenti originale.

[SierraVictor]

Non son esperto, vedo nei SW di rendering per esempio che ne stanno uscendo di nuove e veloci che sfruttano le GPU RTX con molti cores; o CPU con molti cores che non hanno SW che li sfruttino con dispendio inutile di watt e calore (e rumore delle ventole).
Un buon tuning pare aiuti in questo senso a sfruttare al meglio le componenti originale.

Certamente programmare per una cpu piuttosto che l'altra presuppone approcci diversi ma l'hardware "molto basso" viene gestito in automatico. Per quanto riguarda il mutiprocesso non tutti i sw possono, per loro natura, sfuttare più cpu. Il rendering è il caso estremo di possibilità di poter splittare il lavoro su più cpu; all'estremo opposto abbiamo i motori di simulazione (aerei, treni ecc ecc) non possono che girare su una sola cpu. Nel mezzo, cito a titolo di esempio, sw come la codifica in h264/265 che sfruttano solo un certo numero di cpu (in questo caso circa 8 ) ed oltre ne utilizzano solo una minima parte.
Nel caso specifico di spp (& co) alcune funzioni - per loro natura - possono sfruttare una sola cpu e altre (di solito poche) possono sfruttarne più di una.

[tik68mi]

Non son esperto, vedo nei SW di rendering per esempio che ne stanno uscendo di nuove e veloci che sfruttano le GPU RTX con molti cores; o CPU con molti cores che non hanno SW che li sfruttino con dispendio inutile di watt e calore (e rumore delle ventole).
Un buon tuning pare aiuti in questo senso a sfruttare al meglio le componenti originale.

Certamente programmare per una cpu piuttosto che l'altra presuppone approcci diversi ma l'hardware "molto basso" viene gestito in automatico. Per quanto riguarda il mutiprocesso non tutti i sw possono, per loro natura, sfuttare più cpu. Il rendering è il caso estremo di possibilità di poter splittare il lavoro su più cpu; all'estremo opposto abbiamo i motori di simulazione (aerei, treni ecc ecc) non possono che girare su una sola cpu. Nel mezzo, cito a titolo di esempio, sw come la codifica in h264/265 che sfruttano solo un certo numero di cpu (in questo caso circa 8 ) ed oltre ne utilizzano solo una minima parte.
Nel caso specifico di spp (& co) alcune funzioni - per loro natura - possono sfruttare una sola cpu e altre (di solito poche) possono sfruttarne più di una.

Parlo di cores della stessa cpu, SPP sembra usarli tutti ma al 20% nel caso del mio portatile con intel 12ma gen. e ancora meno la GPU, seppur settata come dice Andrea, boh.
Per i render invece i cores delle GPU sono migliaia e infatti i render su GPU sono più veloci che su CPU, su SW abilitati (alcuni datati vanno solo su CPU però, sebbene di qualità).

[SierraVictor]

Si, nel mio modo di esprimermi cpu= cores, in quanto poco cambia. Per il resto non sempre demandando un calcolo alla gpu si ottiene di meglio (altrimenti non esisterebbero più le cpu). In poche parole le unità di calcolo di una gpu non fanno tutto quello fanno che le unità di calcolo delle cpu.

[tik68mi]

Si, nel mio modo di esprimermi cpu= cores, in quanto poco cambia. Per il resto non sempre demandando un calcolo alla gpu si ottiene di meglio (altrimenti non esisterebbero più le cpu). In poche parole le unità di calcolo di una gpu non fanno tutto quello fanno che le unità di calcolo delle cpu.

Sì, in SPP ho ricontrollato e usa "solo" alcuni cores (gli altri dice che sono disattivati anche se usati da altri SW) e GPU "solo" quando zoomma. Magari ci sono dei colli di bottiglia altrove. Comunque sviluppa benissimo l'ottimo foveon, è gratis e ci stampo pure senza rischi di perdere nulla.

[SierraVictor]

Si, nel mio modo di esprimermi cpu= cores, in quanto poco cambia. Per il resto non sempre demandando un calcolo alla gpu si ottiene di meglio (altrimenti non esisterebbero più le cpu). In poche parole le unità di calcolo di una gpu non fanno tutto quello fanno che le unità di calcolo delle cpu.

Sì, in SPP ho ricontrollato e usa "solo" alcuni cores (gli altri dice che sono disattivati anche se usati da altri SW) e GPU "solo" quando zoomma. Comunqie sviluppa benissimo l'ottimo foveon, è gratis e ci stampo pure senza rischi di perdere nulla.