Problème redimension Image

Bonjour à tous,

j'ai fait le design de mon application au plus grand format, c'est à dire:

XHDPI
Vertical = 960 * 320/160 = 1920px
Horizontal = 720 * 320/160 = 1440px

Ensuite on m'a conseiller le logiciel suivant (http://code.google.com/p/9patch-resizer/) pour redimensionner pour les 3 autres grandes tailles.

J'ai donc un image qui fait 1440px de large (tout l'écran) et de 580px de haut, donc quand je la passe dans le logiciel elle devrait faire 720px de large pour HDPI(car (480*240)/160) mais elle fait 1080px de large. Je ne comprend pas donc. Le logiciel a-t-il un problème ?

Je vous remercie

Non tu as du te tromper quelque part. Il n'y a pas un rapport de 2 entre XHDPI et HDPI mais plutôt un rapport de 4/3 (1,33...)

XLarges : 960dp x 720dp
Larges : 640dp x 480dp
Moyens : 470dp x 320dp
Petits : 426dp x 320dp

Quand on convertit en pixel cela donne:

LDPI
Vertical = 426 * 120/160 = 319.5px
Horizontal = 320 * 120/160 = 240px

MDPI
Vertical = 470 * 160/160 = 470px
Horizontal = 320 * 160/160 = 320px

HDPI
Vertical = 640 * 240/160 = 960px
Horizontal = 480 * 240/160 = 720px

XHDPI
Vertical = 960 * 320/160 = 1920px
Horizontal = 720 * 320/160 = 1440px

On est d'accord la dessus non ? Un image qui fait 1440px de large en XHDPI doit faire 720 en HDPI ?

Non, justement. D'après le site de google :

Une icone doit être de cette taille : http://developer.android.com/guide/p...s_support.html
http://developer.android.com/images/...-densities.png
36x36 for low-density
48x48 for medium-density
72x72 for high-density
96x96 for extra high-density

Donc c'est normal ce que le logiciel me donne comme dimension ? car je comprend pas là...

Oui pour moi le logiciel redimensionne correctement.
En fait dans tes calculs, je pense que tu as fait une erreur. La taille de l'image d'origine étant fixe on obtient :

Pour une image de 470 * 320, les dimensions sont les suivantes :
LDPI
Vertical = 470 * 120/160 = 319.5px
Horizontal = 320 * 120/160 = 240px

MDPI
Vertical = 470 * 160/160 = 470px
Horizontal = 320 * 160/160 = 320px

HDPI
Vertical = 470 * 240/160 = 960px
Horizontal = 320 * 240/160 = 720px

XHDPI
Vertical = 470 * 320/160 = 1920px
Horizontal = 320 * 320/160 = 1440px

Mais es-ce que j'ai bien fait de développer la version XHDPI en 1920*1440 alors ou alors il aurait fallu le faire dans une autre taille ?

Es-ce que 1080 de large n'est pas trop grand coup pour les version HDPI ?

Tout dépend de ce que tu veux faire.
Si tu veux une image qui remplisse l'écran, ça n'est pas utile d'avoir une image si grande.
Eclipse te permet de visualiser le rendu de ton layout avec plusieurs configurations (Nexus S, Xoom, ...) depuis le layout Editor. Alors fait tes tests et regarde ce qui colle le mieux.

Je souhaite avoir un bon rendu peut importe la taille de l'écran. On m'avait dit de développer pour la plus grande taille (donc 1920*1440) et après utiliser cet outil pour générer les images concernant les autres écrans.

Ne faut-il pas faire ça alors ?

En gros comment si prendre alors pour avoir un bon rendu sur tous les téléphones, il faut bien développer le design pour 4 tailles différentes ? Faut peut être les faire à la main selon ces tailles alors:

LDPI
Vertical = 426 * 120/160 = 319.5px
Horizontal = 320 * 120/160 = 240px

MDPI
Vertical = 470 * 160/160 = 470px
Horizontal = 320 * 160/160 = 320px

HDPI
Vertical = 640 * 240/160 = 960px
Horizontal = 480 * 240/160 = 720px

XHDPI
Vertical = 960 * 320/160 = 1920px
Horizontal = 720 * 320/160 = 1440px

et donc ne pas utiliser l'outil que j'ai mentionné dans mon premier poste ?

Ben normalement la meilleure solution est de faire chaque image à la bonne dimension en essayant tous les types de résolutions.
Mais l'approche la plus simple est d'utiliser le logiciel que je t'avais conseillé.
Pour des icônes de boutons ou d'ActionBar, le logiciel est un très bon compromis.

Je pense que tu confonds "dpi" et "taille en pixels"....

Le "dp" sert à indiquer une taille qui sera toujours identique visuellement (pas relativement à l'écran, mais par rapport à la taille d'un doigt) partout sur tous les devices.

Tout dans le système est organisé en "dp" (que ce soit l'ActionBar, la Notification Bar: 10dp, la taille du texte...).


On considère qu'une tablette de 10" en 16/9, c'est 1280dp x 720dp (ce qui fait partie des "xlarge" puisque supérieur à 960dp x 720dp qui est la version 4/3)
Un téléphone "normal" (pas comme le Note par exemple), c'est 320dp x 480dp


La conversion en pixel dépend du hardware (de l'écran lui même) et pour le coup introduit la notion de ldpi/mdpi/hdpi/xhdpi ....
Une tablette 10" LDPI aura donc une résolution de 960x540
Une tablette 10" MDPI aura du 1280x720 (base)
Une tablette 10" HDPI aura du 1920x1080
Une tablette 10" XHDPI (genre le nouvel iPad) aura du 2560x1440

C'est là que le 9-resizer va agir: à partir d'une résolution en XHDPI, fournir la MEME image (même taille en dp donc) pour les résolutions inférieures...
Si tu pars d'une image en 1440px de large, tu auras les résolutions 1080, 720 et 540

Quand on veut faire un bouton, tout va bien, le bouton fait la même taille (en dp, relatif au doigt / texte) que partout ailleurs.... On fournit donc juste les 4 versions et basta.

Quand on veut faire du "fullscreen" (background), ça ne va plus... car la taille de l'écran entre en jeu ....

Essai sur les tailles croisées avec les DPI...

Code:

---

1 2 3 4 5 6 7 8

TAILE SMALL NORMAL LARGE XLARGE (base en dp) 426x320 480x320 640x480 960x720   LDPI 320x240 360x240 480x360 720x540 MDPI (base) 426x320 480x320 640x480 960x720 HDPI 640x480 720x480 960x720 1440x1080 XHDPI 852x640 960x640 1280x960 1920x1440

---

Donc, il faudra bien 16 versions de la bitmap pour être parfait...

Merci pour cette réponse très complète nicroman. Merci également à Simonmarky qui s''investi beaucoup également sur ce forum.

En gros j'ai fais un desgin en 1920*1440 sur photoShop et j'ai découpé le design. Je pensais qu'en utilisant le logiciel j'allais pouvoir viser tous les écrans de manière optimisé. C'est quand même un truc du fou de développer pour 16 versions.

Il doit bien y avoir un compromis quand même pour être bon un peu partout et ne pas en faire 16 non ?

Comment faîte-vous ? Vous faites les 16 versions ?

Que me conseillez-vous maintenant que j'ai mon design dans cette dimension, dois-je le refaire dans une autre taille, garder celui-ci mais... ?

Merci pour vous conseils.

Non mais un design se fait en "dp".... jamais en pixels....
Tu n'as besoin des pixels qu'excessivement rarement....

Là si j'ai bien compris c'est pour un background.... Outre la complexité par la suite de se positionner par rapport à ce background, c'est le seul cas complexe pour gérer les tailles d'images.

Sinon, pour un splash screen, on ne fournissait que les versions MDPI (dans "drawable" directement donc...), et en 2 tailles... LARGE / NORMAL.

Je n'ai jamais fait de background en pixels.

Je dois être vraiment perdu là, désolé de ne pas comprendre.

Mais "dp" n'est pas une unité possible sur photoShop. Quelles sont les deux tailles dont tu parles normal et large ?

Pourraîs-tu récapituler comment faire un design (si sa te dérange pas), avec les tailles, combien de tailles différentes faire etc...

J'avoue que je suis vraiment perdu, désolé encore une fois

Tout est là:
http://developer.android.com/guide/p...s_support.html

Mais je vais essayer de résumer (va devenir un tuto si ça continue ;) )

Afin de bénéficier justement de tous les types de d'écrans possible (avec des résolutions et densités de pixels variables), les framework récents (et même HTML) ont laissé tomber les mesures directes en pixels. Cette approche fait partie de la notion de "fluid layouts" qui permet d'adapter la présentation au canvas (comme la lecture du forum ici), à l'inverse du "fixed layouts" qui force le canvas à s'adapter à la présentation, quitte à la cropper ou à l'inclure comme une vidéo letter-box, comme l'édition de la réponse dans le forum).

Une seule notion, l'interface s'adapte au hardware... Ainsi, un texte doit toujours rester lisible (avoir la même taille visuelle), ou encore un bouton doit toujours être accessible de la même manière (taille du "doigt")... Pour ce faire, le système utilise les "dp" (ou "dip"= device independant pixels, ou density-independant pixels même si pixel n'est pas le terme approprié).

Ainsi, tout dans le système est relatif à ces "dp".

La raison est simple: imaginons que j'ai programmé pour un device des premières générations (120dpi, 320x200 px)... J'ai un bouton qui fait la moitié de l'écran (soit 2cm environ, 100px, 133dp)... Si je le définit en pixels, que se passera-t-il sur mon device dernière génération (360dpi, 1920x1080 px) ? Il fera 7mm !!! Impossible à toucher avec un doigt correctement.
Si je le définit en "dp", il fera toujours 2cm (et 100px) sur mon vieux device, et toujours 2cm (accessible pareillement, avec ses 300px).

Mais il y a d'autres manières de mesurer de manière indépendante de l'écran: (http://developer.android.com/guide/t...html#Dimension)
Les "pt" (points) qui sont 1/72eme de pouce.
Les "in" (pouces)
Les "mm" (millimetres)

La taille du texte peut être choisie dans les préférences du système... les "sp" permettent de prendre automatiquement en compte celle-ci... "sp" = "dp" modulo les preferences... La taille par défaut des textes sont de 14sp (petit), 18sp (normal) et 22sp (larges), c'est à dire 14dp, 18dp et 22dp si l'utilisateur n'est pas passé en mode accessibilité....

La seule unité à éviter c'est "px" (pixels hardware). Bien sur il est toujours possible de définir les tailles en vrais pixels ("px"), mais "2px" peuvent très prendre 4 fois plus de place visuellement entre un écran de faible densité et un écran de très grande densité.

Donc grosso modo, la règle d'utilisation est toujours la même:
"sp" pour tout ce qui est du texte (TextApperance, etc.) "dp" pour le reste.
Eventuelllement "mm","in","pt" (qui sont identiques entre eux) vu que 1in=72pt=25,4mm... Attention toutefois... 1in est normalement 160dp sur un vrai hardware, ce n'est pas le cas sur l'émulateur ! Voilà pourquoi on évite en général "mm","in" et "pt".

Maintenant... à propos des "bitmaps"... Car l'unique soucis est sur celles-ci ! (les drawables peuvent être vectoriels, et là plus de problème). Le but est de faire coller des bitmaps d'une certaine taille (en pixels) dans une view en dp...

Solution 1: Forcer la taille de la vue (ImageView) en "dp", et utiliser les options de redimensionnement interne (scaling). Avec en contrepartie, une résolution affreuse dans le cas du upscaling, et un floutage en règle pour le downscaling, sans compter l'utilisation abusive de mémoire... Cette option n'est pas très grave pour un background par exemple, là ou elle devient génante c'est si la bitmap contient des bordures (il n'y a rien de plus moche qu'une grosse bordure baveuse due à l'upscaling d'une jolie bordure ombrée, ou une bordure invisible à cause du downscaling), ce qui est le cas de 90% des boutons. C'est probablement la solution à privilégier pour l'affichage d'une "image" (icone, background...).

Solution 2: Utiliser les 9-patch qui permettent de redimensionner intelligemment une bitmap "simple" (bord-contenu-bord). C'est ni plus ni moins qu'une manière d'optimiser le scaling d'une bitmap (avec 9 régions scalées différemments). A noter qu'il existe aussi les 'n-patch' (qui permet de définir un nombre variable de régions "non-scalables"), mais pas supporté par Android, sans passer par une classe "custom".

Solution 3: Proposer au système de choisir une bitmap différente (et donc une taille en pixels différente) en fonction de la densité de pixels... Avec 4 "buckets": ldpi (~120dpi), mdpi (~160dpi), hdpi (~240dpi) xhdpi (~320dpi). Mais attention, dans ce cas, il faut laisser le système redimensionner automatiquement la vue qui contiendra la bitmap (pas de width/height fixe donc), sinon, scaling et donc aucun interêt à cette solution.


Maintenant, concernant la "taille de l'écran"... Celle-ci n'est interessante (dans 99% des cas) que pour adopter telle ou telle approche de l'interface... Par exemple, sur un écran avec 800dp de large, au lieu d'avoir une activité de selection dans une liste, et une activité de détails de la selection, on peut avoir une seule activité avec la liste à gauche, et les détails à droite (les paramètres Android fonctionnent ainsi).
Donc là aussi, le choix de la ressource (le layout en général) peut se faire en fonction de 4 buckets: small (~426dp x 320dp), normal (470dp x 320dp), large (640dp x 480dp) et xlarge ( 960dp x 720dp).
A noter qu'il faut aussi se palucher la notion d'orientation dans ce cas (640dpx480dp en portrait donne autant de largeur q'un 470dpx320dp en landscape).
Aussi il est préférable de simplement notifier que la ressource doit être utilisée si la largeur de l'écran est supérieur à X dp: par exemple "w720dp" va dire, "si la largeur de l'écran est de 720dp (ou plus) utilise cette ressource"...

Donc le "dessin" d'un layout se fait en dp/sp... ensuite les bitmaps intégrées devront l'être en fonction de leur rôle: un background n'aura qu'une bitmap redimensionnée par le système (comme c'est un background c'est forcément de base flou, donc peu sujet aux artefacts de redimensionnement), une image (l'image d'un contact par exemple), pour voir sa vue redimensionnée par le système en fonction de 4 ressources dépendant de la densité, un bouton pourra utiliser le 9-patch (ou le vectoriel).

Tout d'abord un grand merci à Nicroman qui se donne du mal sur ce forum.

J'ai compris les concepts que tu souhaites faire passer, le problème c'est qu'il y a une chose que je comprend pas. Tu dis qu'il faut oublier les pix, mais je ne comprend pas comment sur photoShop on peut faire des images avec la taille en dp, on est bien obligé sur photoShop de bosser avec le pixel non ?

Donc ce que je pensais c'est faire 4 design avec les 4 tailles suivantes:

LDPI
Vertical = 426 * 120/160 = 319.5px
Horizontal = 320 * 120/160 = 240px

MDPI
Vertical = 470 * 160/160 = 470px
Horizontal = 320 * 160/160 = 320px

HDPI
Vertical = 640 * 240/160 = 960px
Horizontal = 480 * 240/160 = 720px

XHDPI
Vertical = 960 * 320/160 = 1920px
Horizontal = 720 * 320/160 = 1440px

Forcément en pixel car on ne peut pas faire une image de 960*720 dp sur photoShop, je la fait donc en 1920*1440 et après j'aurai fait 3 autres design en 960*720px, 470*320px et 320*240px, une fois que j'ai découper tous les design et que je l'ai met dans des dossier respectifs, le system les repasses en dp avec la règle d'or et j'ai un design plus ou moins adapté à tout type d'écran.

Es-ce que je me trompe ?

Encore merci à toi nicroman pour le temps que tu passes à expliquer des choses :)


EDIT: Au vu de ce tableau:

http://www.restomaniak.com/media/Capturetableau.PNG

N'est il pas suffisant de développer en small - ldpi c'est à dire 426dp*320dp (avec 120dp), en normal-mdpi c'est à dire 470dp*320dp (avec 160dp), en normal - hdpi, c'est à dire en 470dp*320dp (avec 240dp) et enfin en normal -xhdpi c'est à dire 470dp*320dp (avec 320dp) ?

Si je fais ces 4 design j'aurai un design parfait sur les 4 couples tailles écrans - densité traité et une résultat satisfaisant sur les autres ?

Bon attends...

Je crois qu'on ne se comprend pas en fait.... Tu veux faire quoi exactement sous photoshop ? A quoi va te servir ta bitmap (en pixels) de 2680x1440 ?
Peut-etre pourrais tu nous montrer des exemples ?

Dans ma tête:

On ne fait pas un "design" d'UI sous photoshop... sous photoshop on fait des bitmaps, et éventuellement un "mockop" qui n'a pas grand chose à voir avec l'implémentation finale... (comme un site web fait sous photoshop histoire de montrer au client, implémenté en HTML après).

Le design c'est:
* l'organisation des layouts ("div" dans HTML) entre eux, taille des textes, couleurs des fonds, bordures, séparateurs... Cette opération se fait dans les ressources "layout" "drawable" (vectoriels), "color",... Indépendamment de toute taille de pixel, et en "dp"/"sp". Photoshop ne sert à rien ici.
* l'aspect visuel de certains éléments graphiques (checkbox, boutons,...): photoshop permet de pondre une version en xhdpi.. La taille de l'écran ne sert à rien. On utilise en général les 9-patch, et l'utilitaire 9-resizer permet d'obtenir les autres résolutions (pour hdpi, mdpi et ldpi).

A aucun moment dans ce qui est au dessus, on a besoin de la taille de l'écran et des dpis en même temps.
L'unique moment ou on peut en avoir besoin c'est pour un splash-screen, ou encore un background... Dans les deux cas, il n'est pas très important d'avoir une super définition.

Effectivement nous devons pas être sur le même longueur d'onde ou du moins on a pas le même définition du mot design.

Ce qui est dans le structure (c'est à dire fichier xml) tout est finit, j'ai utilisé très peu de dp, car j'ai quasiment tout fait avec "wrap_content" ou "fill_parent" et en jouant avec la propriété "layout-weight".

Maintenant ce que je souhaite faire c'est habiller celà, c'est à dire mettre des background au bouton, mettre un background au layout principal de l'activité etc... Dans ce cas les images que je vais mettre en background je vais devoir les faire avec photoShop.

Il est important parfois d'avoir une bonne définition car si par exemple je veux une banière (image) qui fait toute la taille de l'écran en largeur et qui contient du texte, car par exemple c'est pas un texte qui va changer donc je ne prend pas soin de l'écran, mais il est intégrer directement à l'image.

EDIT: De plus la taille est importante car si j'ai des boutons en wrap_content, ils vont prendre la taille du background si l'image de fond est plus grande que le contenu du bouton non ? C'est à dire qu'il faut faire en sorte de donner un taille en dp à tous les éléments ?

Bon... ben on arrive finalement à la dernière phase de mon long message ;)

Pour les boutons, il y a deux choses: le "background", et le "foreground". Dans un bouton "wrap-content" le foreground décide de la taille... le background ne rajoute que des "marges" (si il en définit). Ensuite le background est scalé dans la taille finale.

Dans le cas d'un bouton "classique", le foreground c'est du texte, donc défini en "sp" (histoire de suivre les préférence de l'utilisateur). Le 'wrap-content' va utiliser la taille du texte modulo les marges internes au background... C'est là qu'on utilise un 9-patch (pour le background) ou du vectoriel (encore mieux). Dans le cas du 9-patch, on commence en général par la version xhdpi... (on peut travailler en "inch" sur Photoshop avec une résolution de 320dpi) et on utilise 9-resizer pour faire les résolutions inférieures du 9-patch (ou soit même sous photoshop, au choix).
Personnellement, je garde le fichier psd sous le coude, et je pond la version mdpi moi-même histoire de l'intégrer comme "version par défaut" dans l'interface, ensuite, je fournit les version à d'autres résolutions si besoin.... (c'est rarement le cas pour un 9-patch).

Dans le cas d'un bouton "icone", le foreground c'est une image, donc provient de bitmaps définies en 4 "saveurs" (ldpi, mdpi, hdpi, xhdpi). C'est là ou on peut vouloir définir une taille pour le bouton en dp ... Le background est toujours en 9-patch ou vectoriel.

Ensuite, pour les "fenetres" (les layouts quoi), le background est toujours déconseillé car il distrait l'utilisateur. Après c'est question de gôut, je sais que certains aiment bien les effets "acier brossé" et autres... Toujours est-il que si il y a un background, il faut pouvoir laisser l'utilisateur le choisir peut-être... Dans tous les cas, le background ne doit pas avoir de hautes-fréquences, sinon c'est vraiment dérangeant, et de ce fait peut être en basse résolution sans aucun problême....

Pour le cas de la bannière avec texte intégré, c'est une plaie... D'abord parcequ'il va falloir pondre une version par langage ! Ensuite parcequ'il ne suivra pas les choix de l'utilisateurs quant à la fonte / taille à utiliser.
Déjà la notion de bannière est difficile à intégrer dans Android.... En haut ? c'est la barre de titre et de notification des téléphones, En bas ? c'est l'ActionBar... A gauche/droite ?

Ok merci encore à toi pour ces explications (je commence à en voir le bout, c'est bon signe). Pourquoi quand je met une un texture en background d'un bouton il prend la taille de la texture (donc plus la texture est grande plus le bouton est grand) alors que tu me dis que c'est foreground qui décide de la taille ?

EDIT: Ah non c'est bon en faite.