[jacphoto]

Nouvel utilisateur d’Affinity Photo 2, je souhaite réduire le poids de lots de photos destinées à être affichée sur des écrans (PC, Smartphone, tablette, télévision).

La réduction du poids des fichiers vise à permettre un affichage assez rapide avec une connexion internet de qualité « raisonnable » tout en conservant une assez bonne qualité de visionnage sur écran et à limiter l’espace occupé sur le cloud où elles sont stockées.

Les photos avant retouche proviennent de deux sources, un scanner de négatifs et diapos 24x36 Nikon Coolscan V avec une résolution de 4000 dpi et une définition de 5043x3733 pixels et un appareil photo EOS 350 D numérique fournissant des RAW et des JPG avec une résolution de 72 dpi et une définition de 5184x3456 pixels. Mais après des recadrages intentionnellement non proportionnels aux dimensions initiales les dimensions résultantes peuvent varier

Je réalisais précédemment ces opérations avec une ancienne version de Photoshop Elements et accessoirement d’autres logiciels, et j’avais réduit le poids des fichiers autour de 1 Mo souvent en dessous en diminuant la définition pour passer la plus grande dimension à 2560 pixels et réglé la résolution à 96 dpi.

Je n’ai pas encore trouvé la méthode pour faire cela avec Affinity de façon automatique.

Comme il s’agit de lots de photos je me suis tourné vers la fonction de traitement par lots. Le premier écueil est qu’il semble impossible de définir la nouvelle taille cible en pixel pour la plus grande dimension de chaque photo, si on spécifie une valeur de taille dans le champ L elle s’applique à la largeur même si la plus grande dimension est la hauteur. Les logiciels précédemment utilisés me permettaient de préciser la taille souhaitée pour la plus grande dimension.

Si on utilise une expression telle que w/2 dans le champ L et de « nouveau traitement par lot » et que l’on décoche conserver les proportions, la saisie est acceptée mais ce n’est pas exactement ce que je cherche, je veux normaliser la plus grande dimension de chaque photo quelles que soient sa dimension actuelle et son orientation. En examinant les expressions proposées dans l’aide il me semble que l’expression w*2560/max(w, h) devrait faire cela mais sans qu’aucune erreur ne soit signalée elle n’est pas acceptée et aucun redimensionnement n’est effectué.

Par ailleurs dans le traitement par lot je peux bien demandée une compression jpeg un peu plus forte, 85 dans mon cas, mais je ne peux pas demander une modification de la résolution en dpi avec rééchantillonnage.

Pour arriver à cela j’ai pensé à créer une macro exécutée lors du traitement par lot par exemple en enregistrant le redimensionnement d’une photo avec « redimensionnement du document », mais dans ce cas il faut spécifier des dimensions fixes qui s’appliqueront à toutes les photos et donc en déformeront certaines si elles ont une taille ou une orientation différente. Si j’utilise l’expression /2 dans le champ largeur de « redimensionnement du document », elle est reconnue mais le calcul et fait immédiatement et l’expression est remplacé par la valeur pour la photo courante ce qui fit que le calcul ne sera pas appliqué à chaque photo du traitement par lot si j’enregistre cela comme macro. Par ailleurs les expressions w:2 ou w*2560/max(w, h) n’est pas non plus reconnue dans cette fonction.

Enfin dans le cas où j’arriverais à faire enregistrer l’expression dans la macro issue de ce redimensionnement, j’aurais alors deux rééchantillonnages l’un dans la macro de redimensionnement et l’autre dans la fonction traitement par lot ce qui ne milite pas pour une qualité résultante optimum.

Le plus simple serait bien entendu de permettre de redéfinir la résolution en dpi dans la fonction de traitement par lot.

Enfin si ma formule de normalisation w*2560/max(w, h) n’est pas reconnue quelle formule faut-il utiliser pour redimensionner la largeur en la multipliant par le rapport entre 2560 et la plus grande dimension de la photo ?

Désolé pour cette longue explication et merci d’avance pour votre aide.

[ch22]

...l’expression w*2560/max(w, h) devrait faire cela mais sans qu’aucune erreur ne soit signalée elle n’est pas acceptée et aucun redimensionnement n’est effectué.

Si, il y a bien une erreur détectée. Ci-dessous un bout de copie d'écran (fortement agrandi)


L'anomalie correspond au rouge, c'est la virgule dans max(w,h) qui ne passerait pas. Le diagnostic d'erreur (rapporté par l'infobulle quand on ramène la souris sur la case dure d'oreille) prétend Caractère inattendu 
 
Selon la façon dont on tape, l'erreur se déplace. Par exemple :


Là, le diagnostic me disait Nombre d'arguments incorrect. Ah ? Bon...

Bref, il y a un problème avec l'implémentation de l'expression max (...). Également pour min(...), même combat. Quand ce sera réglé, je suggèrerais d'opérer en deux temps
(i) un premier redimensionnement basé sur la longueur
(ii) un deuxième basé sur la hauteur, à diminuer si le premier a donné une valeur trop grande. S'il ne faut pas dépasser 2000,  il faudra mettre min(H, 2000) dans la case H 

J'ai quand même une interrogation de fond avec les expressions : comment traite-t-on l'info d'unité (des px ? des cm ?)


 

[jacphoto]

Merci ch22 de te pencher sur mon problème.

Je ne vois pas la même chose que toi, peut-être une différence de version Affinity. J'utilise la version 2.0.4






En ce qui concerne l'opération en 2 temps c'est effectivement un palliatif qui devrait marcher mais si je comprends bien cela entrainera deux rééchantillonages de suit pour certaines images ce qui dégradera probablement un peu plus leur qualité.

Si au lieu de largeur et hauteur Affinity demandait la largeur et la longueur en considérant que la largeur est la plus grande dimension de la photo quelle que soit son orientation le problème pourrait de traiter en une passe sans même recourir à une expression plus ou moins supportée.

En ce qui concerne l'unité utilisée effectivement je ne vois pas où on peut le spécifier, mes essais qui avaient fonctionné constituaient à diviser la taille par ce qui marche quel que soit l'unité.

Un nouvel essai en spécifiant une valeur absolue comme 2650 montre qu'il considère que c'est exprimé en pixels. Je ne sais pas pourquoi.

Quand à la possibilité de modifier la résolution en dpi dans ce traitement par lot le problème reste entier.

[ch22]

Quelques éléments de réflexion supplémentaires :

1 - En attendant que les fonctions max() et min() soient réparées — ou qu'on explique comment s'en servir —, dans le cas où on ne compare que 2 arguments, on peut les remplacer par
     max(w, h) = h + (w-h)*roundup((w-h)/(w+h))    
     min(w, h) = w + (h-w)*roundup((w-h)/(w+h))
(la fonction roundup donne l'arrondi à la valeur supérieure. Ici, elle donnera 0 si w<h, ou 1 si w h)

Ces expressions sont acceptées et correctement exécutées dans la sous-fenêtre Transformer avec l'outil Déplacer. Malheureusement, cet outil ne fait qu'une homothétie dans un calque, sans réduire les dimensions du calque. Il faudrait que ces expressions soient acceptées dans les cases de saisie des tailles dans diverses fonctions du logiciel (redimensionnements, recadrage, exportation), mais ce n'est pas le cas actuellement : ces cases ne reconnaissent tout simplement pas les variables de document w et h

2 - Je m'interrogeai sur les problèmes d'unité dans les calculs. Effectivement, le logiciel est sensible aux dimensionnements : "w" et "h" sont des longueurs en px, tandis que "2000" est un simple nombre, sans dimension. Pour le rapport "w/2000", le logiciel suspecte que ce 2000 est un nombre de pixels, mais il n'en est pas certain et il refuse de trancher.  Si on veut en faire un nombre sans dimension, il faudra écrire "w/2000px"

[ch22]

Le coup de massue final ?

Je connais maintenant l'expression qu'il faut inscrire dans les cases largeur et hauteur de la fenêtre Transformer pour ramener une image (monocalque) à des dimensions prédéfinies et ce qu'il faut faire ensuite pour recadrer l'image à ces dimensions (tout simplement "attacher le canevas"), ça s'enregistre sans problème dans une macro... et ça ne fonctionne pas.

Pour ne rien cacher, l'expression elle-même pour réduire une image au format 1920x1080 pour une projection en format HD est
*((1920px/w) +((1080px/h)-(1920px/w) )*roundup(((1920px/w) -(1080px/h))/((1920px/w) +(1080px/h))) )
Je peux expliquer s'il y a des curieux

Ce qui se passe est que la macro n'enregistre pas l'expression elle-même dans le dialogue de la sous-fenêtre transformer, mais son résultat au moment où on enregistre cette macro. 
Amen ?

[jacphoto]

Ce qui se passe est que la macro n'enregistre pas l'expression elle-même dans le dialogue de la sous-fenêtre transformer, mais son résultat au moment où on enregistre cette macro.

Et oui il faudrait que l'évaluation de la fonction ne se fasse pas lors de la saisie mais lors de l’exécution de la fonction pour que le réemploi dans une macro destinée à être appliquée à un traitement par lot soit utile