Dépend de ce que vous entendez par...
- Meilleure
- Photo
- Modification
PHOTO
Matériau brut
Lorsque l'édition est impliquée, on veut commencer avec les meilleurs matériaux bruts. Cela signifie qu'il faut commencer avec toutes les données possibles sur l'image, ce qui signifie commencer avec un fichier brut, de préférence 14 bits par canal par pixel. (La plupart des images brutes n'ont qu'un canal par pixel, de toute façon, les exceptions étant les capteurs Foveon, et les capteurs Bayer "PixelShift" comme le Pentak K-3 II, le Pentax K-1, et le Sony α7R III).
Si l'on commence avec un JPEG JFIF, on a déjà perdu des informations du capteur.
- L'approximation de la transformée de Bayer, (BTA), ou l'approximation de la transformée X-Trans, (XTA), -non utilisée dans Foveon ni PixelShift- approxime la teinte, la saturation et l'intensité (HSL) pour chaque pixel. Dans les capteurs Foveon, La teinte et la saturation sont approximées, (bien qu'avec un algorithme bien meilleur que le BTA/XTA).
- Passer de 12 bits/14 bits entiers à seulement 8 bits entiers par canal par pixel, plus d'informations HSL sont perdues.
- Passer d'un codage couleur RVB pur à un codage couleur Y'CbCr 4:2:0 ou 4:2:2 fait perdre encore plus d'informations de teinte et de saturation.
Lorsque l'édition commence, les informations sont réapproximées pour reconstruire l'image, elle est éditée, puis enregistrée à nouveau, avec des pertes supplémentaires dues au même processus. Si l'on commence avec les fichiers bruts, la seule perte est la BTA/XTA ou l'approximation de Foveon. Cette perte ne se produit qu'une fois, est reproductible, et plusieurs options d'édition peuvent être faites avant que l'approximation ne soit effectuée.
En résumé, les meilleures applis pour l'édition de photos commencent par utiliser les fichiers bruts. Si votre application ne peut pas ouvrir les fichiers bruts, ce n'est pas la meilleure.
MONTAGE
Pipeline de travail
La Pipeline de pixels est l'ordre dans lequel vos actions énoncées sont appliquées à l'image. Comme certaines actions ont un effet sur d'autres, (et que certaines actions peuvent n'avoir aucun effet sur d'autres), l'ordre d'exécution est important. Si l'on modifie l'ordre d'exécution des actions sur l'image, il devient difficile d'obtenir des résultats précis.
Par exemple, les approximations de la transformation du réseau de filtres de couleur (CFA) approchent le HSL à chaque pixel. L'ajustement de la balance des blancs (WB) travaille pour décaler l'intensité de la couleur à chaque pixel en fonction de ce que devrait être la balance des blancs. Si la CFA-TA est effectuée en premier, la correction WB agit sur des couleurs supposées à chaque pixel, mais si l'ajustement WB est effectué en premier, alors la CFA-TA devient plus précise.
Le meilleur éditeur a un pipeline de flux de travail fixe (ou presque fixe, là où ça compte), de sorte que, quel que soit l'ordre dans lequel vous effectuez réellement vos ajustements, en interne, ils sont exécutés dans le bon ordre.
Pipeline de pixels à profondeur de couleur
Les éditeurs semblent travailler soit avec un pipeline de pixels en nombre entier de 8 bits (8-int), en nombre entier de 16 bits (16-int), en virgule flottante de 16 bits (16-fp) ou en virgule flottante de 32 bits (32-fp). Étant donné que la plupart des fichiers bruts commencent avec 12 ou 14 bits entiers par canal et par pixel, tout ce qui est inférieur à un pipeline de pixels de 16 bits est une perte d'informations. Puisque l'image finale sera (généralement) un JPEG JFIF de 8 bits/canal/pixel, un pipeline de pixels de 16-int peut sembler adéquat.
Problème du 16-int
Le 16-int fonctionne avec des valeurs entières RVB entre 0 et 65 536. Elles sont ensuite normalisées en valeurs RVB 8-int comprises entre 0 et 256, lors de l'enregistrement en JPEG JFIF. Le problème se pose lorsque le pipeline du flux de travail effectue un ajustement en cours de route qui envoie la valeur entière d'un canal au-dessus de 65 536 ou en dessous de 0.
Puisque la valeur ne peut pas être stockée dans un entier de 16 bits, toutes ces valeurs sont tronquées à ce moment-là à 65 536 ou 0, et les calculs effectués plus tard le long du flux de travail corrigeront toutes ces valeurs comme si elles étaient identiques. Lorsque le flux de travail est terminé, toutes les valeurs encore supérieures à 65536 ou inférieures à 0, seront tronquées à 65 536 ou 0, selon le cas.
Il en résulte une perte d'informations HSL le long du pipeline du flux de travail.
Solution en virgule flottante
Lorsqu'un pipeline de pixels de 16-fp ou 32-fp est utilisé, la couleur H,S, & L est représentée par des valeurs comprises entre 0,0 et 1,0, puis normalisée comme des valeurs comprises entre 0 et 256 lors de l'enregistrement en JPEG JFIF. Cependant, un nombre supérieur à 1,0 ou inférieur à 0,0 peut toujours être enregistré dans un 16-fp.
Si les limites, 0,0-1,0, sont dépassées à tout moment au cours du flux de travail, la valeur peut toujours être préservée, et les calculs effectués plus tard le long du flux de travail traiteront toutes ces valeurs comme différentes, en les ajustant en conséquence.
Lorsque le flux de travail est terminé, toutes les valeurs dépassant la limite peuvent être traitées de l'une des deux manières suivantes ; elles peuvent être tronquées à 1.0 ou 0,0 selon le cas, ou elles peuvent être normalisées pour les ramener toutes à une valeur comprise entre 1,0 et 0,0, en fonction de divers facteurs.
Les meilleurs éditeurs ont un pipeline de pixels à virgule flottante, et les meilleurs des meilleurs ont un pipeline de pixels 32-fp.
En bref, la meilleure édition se fait avec un pipeline de flux de travail fixe, et un pipeline de pixels 32-fp. Si votre application utilise un pipeline de pixels 16-fp ou ne dispose pas d'un pipeline de flux de travail fixe, ce n'est pas la meilleure.
Le meilleur
Le meilleur dépend vraiment de nombreux facteurs.
- Fonctionnement
- du berceau à la tombe, ou intermédiaire
- écran ou impression
- taille du support (écran NTSC/PAL/HD/FHD/UHD/etc, ou impression en portefeuille, 6×4in, 10×8in, etc.
- Plateforme (Mac OSX, IOS, Windows, Android, Chrome OS, Linux, BSD, etc.).
- Flux de travail
- Combien d'édition est nécessaire
- Délai d'exécution maximal
- Méthode de réception/livraison des images
Technologie d'assistance et autre compatibilité périphérique
En bref, le meilleur doit être adapté à toutes ces considérations pour ses besoins particuliers. Cela peut inclure une capacité de profil ICC complète, une disponibilité multiplateforme, une capacité d'importation/exportation de formats multiples, un agnosticisme matériel, etc. Si votre application ne fonctionne pas sur votre plateforme, ne convient pas à votre objectif, ne complète pas votre flux de travail ou ne gère pas vos périphériques, ce n'est pas la meilleure.
RECOMMANDATIONS
Mes choix ont été initialement motivés par mon choix de plateforme, Linux. Une fois ce choix fait, certaines options n'étaient plus sur la table. J'ai considéré DigiKam, DarkTable, RawTherapee, et LightZone.
En raison de mon flux de travail et de mes objectifs passés/courants, RawTherapee & LightZone ont été éliminés comme voulus. DigiKam a été mon premier choix, en raison de mon Workflow, mais, j'ai fait la transition vers DarkTable (avec Rapid Photo Downloader) car ① DigiKam ralentissait mon workflow sur l'importation d'images, et ② DigiKam avait (à l'époque) un pipeline de pixels 16-int, par opposition au pipeline de pixels 32-fp de DarkTable et RawTherapee.
Pour les retouches importantes, j'avais l'habitude d'utiliser The GIMP avec G'MIC, mais, comme The GIMP -préversion 2.10.x- utilisait un pipeline de pixels 16-int, j'utilisais Krita avec G'MIC, car Krita a un pipeline de pixels 32-fp. Il se peut que je fasse la transition pour revenir à The GIMP quelque temps entre maintenant et la version 3.2.x, puisque les lacunes mentionnées précédemment appartiennent au passé.
Si je fais la transition vers un appareil photo PixelShift, il se peut que je doive modifier mon flux de travail pour inclure RawTherape/DCRaw, ou remplacer DarkTable par RawTherapee, car RawTherapee/DCRaw sont actuellement les meilleures options pour le développement PixelShift sur Linux. J'utilise généralement Huggin pour l'empilement de mise au point et les panoramas.
TL;DR →
Pour mes besoins et circonstances ; ① entrée d'images avec Rapid Photo Downloader, ② Gestion des photos, développement brut, la plupart des éditions et des retouches, DarkTable, ③ empilement de mise au point/panoramas, Huggin, et ④ retouches majeures, Krita avec G'MIC ou The GIMP avec G'MIC. La sortie des images dépend entièrement des besoins et des circonstances du client, généralement un support optique, ou une clé USB.