lecteur de VECTEURS
ZANTAR2054
Membre
Bonjour à tous,
Je cherche un moyen de lire un vecteur sur mon application iOS.
En effet les images sont simples mais elles sont trop volumineuses avec des matrices, l'iPhone manque de puissance.
Comme toutes mes images ont été crées sur illustrator, j'aimerai les exporter en vecteur (eps par exemple)
Si quelqu'un avait un début de piste.
Je cherche un moyen de lire un vecteur sur mon application iOS.
En effet les images sont simples mais elles sont trop volumineuses avec des matrices, l'iPhone manque de puissance.
Comme toutes mes images ont été crées sur illustrator, j'aimerai les exporter en vecteur (eps par exemple)
Si quelqu'un avait un début de piste.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Au final les graphismes vectoriels sont toujours rastérisés (transformés en bitmap) pour pouvoir être affichés. ça prend du temps, sur n'importe quelle machine. Tu ne gagneras pas en réactivité en utilisant du vectoriel, au contraire. Peut-être faut-il utiliser des bitmaps d'une taille plus raisonnable plutôt.
Si tu veux vraiment lire du vectoriel " pour réduire la taille de ton appli " Quartz gère le PDF (voir du côté de CGPDFContext... je ne connais pas les détails, jamais utilisé).
Sinon, on trouve sur le net des parseurs de SVG.
Oui c'est bien un problème de puissance.
c'est irréalisable en matrice, car je veux pouvoir zoomer sur l'image (sans pixéliser ::) )
Ajouter un lecteur PDF pourrait être une solution.
Mais je V chercher du coté de Quartz.
Merci pour les infos
Si c'est effectivement un problème de puissance au sens où le GPU n'est pas assez puissant pour faire le rendu de tes images, alors utiliser le vectoriel ne fera qu'empirer les choses puisque comme dit Céroce, à un moment donné ton image vectorielle devra de toute façon être rasterisée en une image bitmap, et que cela demande du calcul (bien plus de calcul que de plaquer un bitmap pré-rasterisé à l'écran !!)
Si c'est un problème de texture trop grande parce que l'image que tu veux dessiner est trop grande et de trop haute résolution et ne tiens pas en mémoire, c'est un problème d'espace (à la fois sur le disque et en mémoire puisque charger une image aussi grande en RAM n'est pas forcément possible sur mobile où la RAM est limité).
Et dans ce cas le vectoriel peut aider au niveau de l'espace disque utilisé, mais nécessitera plus de puissance au niveau rasterisation et ne sera pas forcément adéquat pour une image zoomée (comment savoir si telle forme vectorielle, comme un cercle ou une polyligne, doit être rasterisée " car une fois dessinée elle sera visible dans la zone dessinée/zoomée qu'on appelle le cliprect " ou si on peut ne pas la rasteriser (car le cercle est totalement à l'extérieur du cliprect et donc qu'il ne sera pas visible ? Ou alors tu dessines tout et bonjour la puissance GPU utilisée inutilement)
Si c'est ce dernier cas que tu as (une image trop grande et trop haute résolution pour être chargée en RAM), il faut utiliser le mipmapping et le tiling sur ton image (cf session 104 de la WWDC'10). C'est à dire utiliser des images déjà rasterisées (cela gagne du temps de précieux temps sur la phase de rendu, et également de la puissance CPU, par rapport à utiliser une image vectorielle où les perfs de ton appli se dégraderaient le temps de rasteriser le tout) mais découpées en "tiles", en plusieurs petites images, et à des résolutions différentes, et gérer le zoom en utiliser les parties de ton image (les tiles) avec la bonne résolution selon le zoom. Exactement ce que fait par exemple l'application "Plan" (Google Maps) de ton iPhone. Pour cela, CATiledLayer est ton ami.
L'utilisation d'un parseur SVG et la gestion du format vectoriel n'a d'intérêt que si tu crées une application de dessin, qui doit savoir lire des fichiers SVG et exporter à ce format un dessin que l'utilisateur a fait, auquel il va rajouter des formes lui-même, ou pouvoir les déplacer, etc. Si ton image est fixe, l'intérêt est fortement limité et la conséquence risque plutôt d'être une dégradation des performances (à cause du temps de rasterisation) qu'autre chose (qui se verra surtout lorsque tu vas scroller ou zoomer sur ton image et qu'il devra tout re-rasteriser)
Par contre, je persiste à parler d'image matricielle.
et non pas de bitmap => qui est le format d'image matricielle de Microsoft.
png, jpeg, tiff et gif sont d'autres formats.
MIPMAPPING & TILING
C'est intéressant pour Google Earth, lorsqu'on zoom sur des photos.
Pour zoomer sur mon image composée de carrés et des textes, c'est une méthode trop lourde.
(Avec des temps de rafraà®chissements pas très agréable pour l'utilisateur)
Oui il faudrait RASTà‰RISER comme illustrator lorsqu'il m'affiche des vecteurs sur mon écran LED.
Alors parseur SVG ou Quartz ? ???
Quand je parlais de "bitmap" je parlais d'image rasterisée.
Bon, moi qui ai travaillé dans le domaine du traitement d'image, je n'ai jamais entendu le terme d'image matricielle prononcé/utilisé, maintenant c'est vrai que si on regarde, c'est le terme français correspondant à "image bitmap" ou "raster image" en anglais, mais bon c'est un peu comme le terme "mâchouillon" qui est le nom officiel de l'accadémie française pour désigner un chewing-gum, terme français que pourtant personne n'utilise lol.
Par contre on utilise en traitement d'image très souvent le terme "matriciel" mais pour faire référence à des traitements de l'image par des matrices de convolution ou autre. En pratique le terme "matriciel" est plus souvent utilisé en référence aux matrices mathématiques (filtrage matriciel, convolution matricielle, matrice de transformation d'une image, etc) qu'aux "matrices" au sens "grille de points", d'où la confusion.
Mais bon le principal c'est qu'on parle de la même chose. Ce que toi tu appelles "image matricielle" nous on l'appelle "image bitmap" (au sens large, le JPG et le BMP et le TIFF et le PNG et même le PPM sont des formats représentant des images bitmap, par opposition au SVG ou EPS ou PDF qui peuvent contenir des images vectorielles). Dans les deux cas ce sont des images déjà rasterisées et non des images vectorielles à rasteriser au moment du rendu, donc.
Si tu souhaites vraiment traiter une image vectorielle (bien que le temps de rasterisation d'une image vectorielle soit plus long que le traitement de tiles, surtout avec CATiledLayer qui est fait pour ça, mais bon ça dépend de ton usage), en effet c'est un parseur SVG ou Quartz et du rendu de PDF qu'il te faut.
SI tu n'as pas d'utilité particulière de fonctionner avec le format SVG (ce format peut être utile car il est ouvert et te permet de générer, avec ton appli, des images à ce format, utile pour une appli de dessin vectoriel par exemple), et que l'affichage d'une image vectorielle fixe (que tu ne vas pas modifier) te suffit, je te conseille d'utiliser Quartz.
A la limite même pour commencer et faire simple, une simple UIWebView dans laquelle tu affiches ton PDF ça marche très bien (une UIWebView est certe faites pour afficher du HTML, mais sait parfaitement afficher un PDF directement, et est souvent utilisée pour cela, il y a même des indications pour cela dans la doc)
Mon programme iPocket Draw affiche des dessins vectoriels (format de données personnel).
Il peut importer des photos et la version en cours de validation peut importer des pdf.
J'ai fait quelques essais sur des gros fichiers pdf avec les exemples SimpleTiledScrollExample et ZoomingPDFViewer qui utilisent les CATiledLayer mais je trouve également que ce n'est pas la panacée.
Effectivement le scrolling et le zooming réagissent immédiatement mais peuvent afficher une image partielle ou à basse résolution qui ensuite est mise à jour à retardement. Cela est déroutant.
Avec un dessin direct comme je fais actuellement sans CATiledLayer, l'attente est visible au moment du scrolling et zooming mais avec une mise à jour quasi immédiate ensuite de l'image.
Je parle de fichiers contenant plus de 100000 objets vectoriels simples.
Peut-être qu'OpenGL est plus rapide. Je n'ai pas testé.
Les routines de dessin ne sont pas aussi simples et complètes que Quartz.
On m'a également parlé des CAShapeLayers mais une recherche sur internet m'a permis de découvrir que certains ont trouvé une forte baisse des performances à partir de 200 CAShapeLayers donc je n'ai pas poussé plus loin avec mon exemple à 100000 objets...
Mais il est vrai que l'iPhone et l'iPad ne sont pas (encore ?) aussi puissant qu'un Mac.