Dipende da cosa intendi per...
- Migliori
- Foto
- Editing
PHOTO
Materiale grezzo
Quando si tratta di editing, si vuole iniziare con il miglior materiale grezzo. Questo significa iniziare con tutti i dati dell'immagine possibili, il che significa iniziare con un file grezzo, preferibilmente a 14 bit per canale per pixel. (La maggior parte delle immagini grezze ha comunque solo un canale per pixel, le eccezioni sono i sensori Foveon e i sensori Bayer "PixelShift" come la Pentak K-3 II, la Pentax K-1 e la Sony α7R III).
Se si inizia con un JPEG JFIF, si sono già perse informazioni dal sensore.
- La Bayer Transform Approximation, (BTA), o X-Trans Transform Approximation, (XTA), -non usata in Foveon o PixelShift- approssima Hue, Saturation, and intensity (HSL) per ogni pixel. Nei sensori Foveon, la tonalità e la saturazione sono approssimate, (anche se con un algoritmo molto migliore del BTA/XTA).
- Scendendo da 12-bit/14-bit interi a solo 8-bit interi per canale per pixel, si perdono più informazioni HSL.
- Passando da un RGB puro a una codifica colore Y'CbCr 4:2:0 o 4:2:2 si perdono ancora più informazioni di tonalità e saturazione.
Quando inizia l'editing, le informazioni vengono riapprovvigionate per ricostruire l'immagine, questa viene modificata, poi salvata di nuovo, con ulteriori perdite dovute allo stesso processo. Se si inizia con i file Raw, l'unica perdita è il BTA/XTA o l'approssimazione Foveon. Questa perdita avviene solo una volta, è riproducibile, e diverse opzioni di editing possono essere fatte prima che l'approssimazione venga effettuata.
In breve, le migliori app per il fotoritocco iniziano con l'utilizzo dei file raw. Se la tua app non può aprire i file raw, non è la migliore.
EDITING
Workflow Pipeline
La Pixel Pipeline è l'ordine in cui le tue azioni dichiarate vengono applicate all'immagine. Poiché alcune azioni hanno un effetto su altre, (e alcune azioni possono non avere effetto su altre) l'ordine di esecuzione è importante. Se si altera l'ordine di esecuzione delle azioni sull'immagine, diventa difficile ottenere risultati accurati.
Per esempio, il Color Filter Array (CFA) Transform Approximations approssima l'HSL ad ogni pixel. La regolazione del bilanciamento del bianco (WB) lavora per spostare l'intensità del colore ad ogni pixel secondo quello che dovrebbe essere il bilanciamento del bianco. Se la CFA-TA viene fatta per prima, la correzione del WB agisce sui colori presunti in ogni pixel, ma se la regolazione del WB viene fatta per prima, allora la CFA-TA diventa più accurata.
Il miglior editor ha una pipeline di flusso di lavoro fissa (o quasi fissa, dove conta), in modo che, indipendentemente dall'ordine in cui si fanno le regolazioni, internamente, esse vengono eseguite nell'ordine corretto.
Pipeline di pixel a profondità di colore
Gli editor sembrano lavorare con una pipeline di pixel a 8-bit interi (8-int), 16-bit interi (16-int), 16-bit in virgola mobile (16-fp), o 32-bit in virgola mobile (32-fp). Dato che la maggior parte dei file grezzi inizia con 12-bit o 14-bit interi per canale per pixel, qualsiasi cosa meno di una pipeline di pixel a 16-int sta buttando via informazioni. Dato che l'immagine finale sarà (di solito) un JPEG JFIF a 8 bit/canale/pixel, la pipeline a 16-int pixel può sembrare adeguata.
16-int Problema
16-int lavora con valori interi RGB tra 0 e 65.536. Vengono poi normalizzati in valori RGB a 8-int tra 0 e 256, quando vengono salvati come JPEG JFIF. Il problema sta quando la pipeline del flusso di lavoro fa una regolazione lungo il percorso che manda il valore intero di un canale sopra 65.536 o sotto 0.
Poiché il valore non può essere memorizzato in un intero a 16 bit, tutti questi valori vengono troncati in quel momento a 65.536 o 0, e i calcoli successivi lungo il flusso di lavoro correggeranno tutti questi valori come se fossero uguali. Quando il flusso di lavoro è completato, tutti i valori ancora superiori a 65536 o inferiori a 0, saranno troncati a 65.536 o 0, a seconda del caso.
Questo risulta in informazioni HSL perse lungo la pipeline del flusso di lavoro.
Soluzione in virgola mobile
Quando viene usata una pipeline di pixel a 16-fp o 32-fp, il colore H,S, & L è rappresentato da valori tra 0,0 e 1,0, poi normalizzato come valori tra 0 e 256 quando viene salvato come JPEG JFIF. Tuttavia, un numero superiore a 1.0 o inferiore a 0.0 può ancora essere memorizzato in un 16-fp.
Se i limiti, 0.0-1.0, vengono superati in qualsiasi momento durante il flusso di lavoro, il valore può ancora essere conservato, e i calcoli successivi lungo il flusso di lavoro tratteranno tutti questi valori come diversi, regolandoli di conseguenza.
Quando il flusso di lavoro è completo, tutti i valori che superano il limite possono essere trattati in uno dei due modi; possono essere troncati a 1.0 o 0,0 a seconda dei casi, oppure possono essere normalizzati per riportarli tutti a un valore compreso tra 1,0 e 0,0, a seconda di vari fattori.
I migliori editor hanno una pipeline di pixel a virgola mobile, e il meglio del meglio ha una pipeline di pixel a 32-fp.
In breve, il miglior editing è fatto con una pipeline di flusso di lavoro fissa, e una pipeline di pixel a 32-fp. Se la vostra applicazione usa una pipeline di pixel a 16 punti o non ha una pipeline di flusso di lavoro fissa, non è la migliore.
MIGLIORE
Il meglio dipende davvero da molti fattori.
- Scopo
- dalla culla alla tomba, o intermedio
- schermo o stampa
- dimensione del supporto (schermo NTSC/PAL/HD/FHD/UHD/etc, o stampa a portafoglio, 6×4in, 10×8in, etc.).
- Tipo di supporto (tipo di schermo, o carta, etc).
- Piattaforma (Mac OSX, IOS, Windows, Android, Chrome OS, Linux, BSD, ecc.).
- Flusso di lavoro
- Quanto editing è richiesto
- Tempo massimo di consegna
- Modo di ricevere/consegnare le immagini
- Tecnologia di assistenza e compatibilità con altre periferiche
In breve, il meglio deve essere adatto a tutte queste considerazioni per le proprie esigenze particolari. Questo può includere la completa capacità del profilo ICC, la disponibilità multipiattaforma, la capacità di importazione/esportazione di più formati, l'agnosticismo dell'hardware, ecc. Se la vostra applicazione non funziona sulla vostra piattaforma, non è adatta al vostro scopo, non è adatta al vostro flusso di lavoro o non gestisce le vostre periferiche, non è la migliore.
Raccomandazioni
Le mie scelte sono state originariamente guidate dalla mia scelta della piattaforma, Linux. Una volta fatta questa scelta, alcune opzioni erano fuori dal tavolo. Ho considerato DigiKam, DarkTable, RawTherapee e LightZone.
A causa del mio flusso di lavoro passato/attuale e dei miei scopi, RawTherapee e LightZone sono stati eliminati come desiderabili. DigiKam è stata la mia prima scelta, a causa del mio flusso di lavoro, ma sono passato a DarkTable (con Rapid Photo Downloader) perché ① DigiKam stava rallentando il mio flusso di lavoro nell'importazione delle immagini, e ② DigiKam aveva (a quel tempo) una pipeline di 16-int pixel, rispetto alla pipeline di 32-fp pixel di DarkTable e RawTherapee.
Per i ritocchi più importanti, usavo The GIMP con G'MIC, ma, dato che The GIMP -prima della versione 2.10.x- usava una pipeline a 16-int pixel, stavo usando Krita con G'MIC, dato che Krita ha una pipeline a 32-fp pixel. Potrei ritornare a GIMP tra oggi e la versione 3.2.x, dato che le carenze precedentemente menzionate appartengono al passato.
Se passo a una fotocamera PixelShift, potrei dover modificare il mio flusso di lavoro per includere RawTherape/DCRaw, o per sostituire DarkTable con RawTherapee, dato che RawTherapee/DCRaw sono attualmente le migliori opzioni per lo sviluppo PixelShift su Linux. Di solito uso Huggin per la messa a fuoco e i panorami.
TL;DR →
Per le mie necessità e circostanze; ① ingresso delle immagini con Rapid Photo Downloader, ② gestione delle foto, sviluppo dei raw, la maggior parte delle modifiche e la maggior parte dei ritocchi, DarkTable, ③ messa a fuoco/panorami, Huggin, e ④ grandi ritocchi, Krita con G'MIC o The GIMP con G'MIC. L'uscita delle immagini dipende interamente dai bisogni e dalle circostanze del cliente, di solito supporti ottici o chiavette USB.