Sur la vectorisation dans Asymptote

Tout ce qui concerne le langage Asymptote. Ce langage est utilisable sur le forum via les balises asy.
[participation réservée aux utilisateurs inscrits]
Règles du forum
Merci de soigner la rédaction de vos messages et de consulter ce sujet avant de poster. Pensez également à utiliser la fonction recherche du forum.
pluton

Sur la vectorisation dans Asymptote

Message non lu par pluton »

Bonjour,

ayant eu pendant un certain temps une méthode de travail savamment absurde pour la création de petits schémas en trois dimensions (3D studio max puis export vectoriel avec Deep Exploration avant une retouche dans Illustrator), je découvre Asymptote avec envie et espoir pour ses belles vues en perspective. J'aimais aussi l'extension 3D de pstricks (pst-solides3D) mais je l'utilise moins. Mes premières tentatives avec Asymptote montrent qu'en fait peu d'objets conservent vraiment leurs propriétés vectorielles lors de la création de fichiers eps ou pdf. Par exemple, le simple code issu de asy-3D.pdf :
cb5df3d4473ffef1b948408a79b5ee21298e71a9.svg
génère un cube dont les faces sont pixelisées (malheureusement dois-je dire) même si toutes les options utilisées poussent à une création graphique purement vectorielle. Dans la figure ci-dessus, seuls les traits sont vectoriels (et il semble que ce soit le cas en général pour des figures plus compliquées). Si je n'ai rien oublié, je pense comprendre que la versatilité d'Asymptote motive l'exploitation de procédures générales qui rendent difficile un export vectoriel. Cependant, pour des configurations simples comme les cubes (ou tout objet à facettes), l'export vectoriel est envisageable. Pour les intervenants de ce forum qui semblent assez bien connaître les auteurs de cette application, pensez-vous que ce type d'"amélioration" est envisageable à court terme ou bien n'est-ce pas du tout la voie suivie ? Pour aller un peu plus loin, ne serait-il pas possible d'entrevoir des exports complètement vectoriels en utilisant des outils comme les gradients vectoriels supportés par les formats eps ou pdf. Il existe des outils plus ou moins élaborés sur le sujet : je fais un lien ici vers une "feature request" (malheureusement plutôt mal formulée puisque la limitation évoquée doit être comprise du point de vue vectoriel uniquement) sur sourceforge :

http://sourceforge.net/tracker/?func=de ... tid=685686

Les liens url du message pointent vers une présentation sur cette idée de calculer automatiquement des gradients "vectoriels". Il me semble qu'Asymptote pourrait en tirer un large profit en éliminant tout pixel de ses créations. Merci pour vos commentaires. Mon point de vue ici est que conserver l'aspect vectoriel des graphique le plus longtemps possible est une bonne chose.
Fabrice Couvreur
Utilisateur éprouvé
Utilisateur éprouvé
Messages : 604
Inscription : samedi 18 août 2007, 01:55

Re: sur la vectorisation dans Asymptote

Message non lu par Fabrice Couvreur »

Bonsoir,
Simple question d'un utilisateur d'Asymptote :
pluton a écrit :génère un cube dont les faces sont pixelisée
comment s'en rendre compte ?
Je pensais, à tord semble-t-il, que le graphique était entièrement vectoriel.
Merci.
OG
Modérateur spécialisé
Modérateur spécialisé
Messages : 2293
Inscription : lundi 12 mars 2007, 11:20
Localisation : Rouen

Re: sur la vectorisation dans Asymptote

Message non lu par OG »

Bonsoir

Avec l'option render=0 et prc=false, la figure (pdf) ne me semble pas pixelisée, j'ai regardé avec acroread
et un zoom à 6400%.

Pour savoir si c'est pixelisé il suffit de zoomer et arriver à un certain seuil on voit des pixels qui grossissent
en même temps que le coefficient de zoom augment.

Pour la discussion sur la 3D, le rendu vectoriel, ouep rien n'est parfait. De toute façon avec des
objets compliqués (autre que des facettes) c'est totalement hors de portée (du point de vue calcul
et même du point de vue savoir faire). Avec des facettes, c'est jouable, il faut "juste" faire un tri
des facettes pour les afficher dans le bon ordre (algorithme du peintre) (et encore avec des facettes
non convexes il peut y avoir des ratés). Pour des objets simples du type cube, pyramide, etc
il y avait eu ici une discussion notamment avec Philippe Ivaldi, pour avoir les traits pleins
et les traits en pointillés, en modifiant polyhedron.asy.

Il y aussi une extension de Didier Comin http://melusine.eu.org/syracuse/asymptote/comin/


O.G.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

Bonjour,

la méthode le plus simple, c'est de zoomer le plus loin possible et d'attendre l'apparition de pixels. Si la pixelisation est très fine, il est possible
que ça prenne du temps ou même que votre éditeur ne soit pas assez puissant.

Sinon, ce que je fais en général, c'est que je compile mon code asymptote pour obtenir un eps que j'ouvre avec Illustrator ou Inkscape.
Ensuite dans l'éditeur, vous cliquez sur la figure qui contient la plupart du temps des objets groupés qu'il faut dégrouper. En fonction
des propriétés (vectorielles ou non) de chaque objet du graphique (la plupart du temps, de traits, des polygones, et des parties "pixelisées")
vous pourrez éditer (ou non) leur définition (couleur du trait, couleur des polygones). Pour l'image ci-dessus, vous verrez que les faces du cube
ne sont pas éditables alors qu'elles le seraient si elles étaient des polygones vectoriels. Le plupart des figures 3D créées avec Asymptote ne sont pas vectorielles.
Il s'avère, pour des configurations simples comme ci-dessus, que le caractère vectoriel pourrait être conservé sans trop de difficulté. Ceci dit, j'ai peut-être oublié quelques options puissantes dans le code.
Dernière modification par pluton le lundi 13 août 2012, 21:54, modifié 1 fois.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

rebonsoir,
Avec l'option render=0 et prc=false, la figure (pdf) ne me semble pas pixelisée, j'ai regardé avec acroread
et un zoom à 6400%.
je vais réessayer mais je pense que si, les facettes du cubes sont pixelisées. Par contre, les traits en "brown" sont bien des objets vectoriels.

Concernant la vectorisation, oui vous avez raison, ça n'est pas simple. Je ne sais pas si vous avez regardé la vidéo dont le lien est mentionné plus haut mais il existe maintenant des techniques avancées de vectorisation (à l'aide de gradients vectoriels) de photos pixelisées (par définition) et ça fonctionne vraiment bien. Je ne sais pas trop si c'est facile à mettre en œuvre par contre. J'imagine juste que ça pourrait être un module dans Asymptote : conservation de la méthode actuelle pour construire les graphiques puis vectorisation.
OG
Modérateur spécialisé
Modérateur spécialisé
Messages : 2293
Inscription : lundi 12 mars 2007, 11:20
Localisation : Rouen

Re: sur la vectorisation dans Asymptote

Message non lu par OG »

Re

J'ai regardé rapidement le papier (pas la vidéo).
Il y a une fonctionnelle à minimiser. Mais les auteurs ne précisent pas
le temps de calcul.
Pour le cas qui nous intéresse ici, il serait bizarre à partir d'une figure définie
mathématiquement (donc vectoriellement) de créer une version bitmap et
ensuite de la vectoriser.

O.G.
GMaths
Utilisateur chevronné
Utilisateur chevronné
Messages : 2042
Inscription : lundi 01 octobre 2007, 10:20

Re: sur la vectorisation dans Asymptote

Message non lu par GMaths »

OG a écrit :Avec l'option render=0 et prc=false, la figure (pdf) ne me semble pas pixelisée, j'ai regardé avec acroread
et un zoom à 6400%.
Je confirme qu'il n'y a pas de grossissement de pixel (cf. comparaison entre zooms à 300% et 6400%).
Image

Mais j'imagine que ce qui a troublé, ce sont les légers escaliers des arêtes alors que l'on n'a pas le problème avec le unitsquare3.

Mais les escaliers en question ne changent pas de taille en zoomant donc, pour moi, c'est bien du vectoriel.

Maintenant pourquoi cette moindre rectitude pour le unitcube par rapport au unitsquare3 ? Elle est plutôt là la question pour moi.

Image
OG
Modérateur spécialisé
Modérateur spécialisé
Messages : 2293
Inscription : lundi 12 mars 2007, 11:20
Localisation : Rouen

Re: sur la vectorisation dans Asymptote

Message non lu par OG »

Pour la moindre rectitude, rien à voir avec la 3D, en 2D c'est pareil. C'est du au pinceau
plus épais et au choix par défaut de linejoin(1).
Tu peux essayer linejoin(2)

O.G.
GMaths
Utilisateur chevronné
Utilisateur chevronné
Messages : 2042
Inscription : lundi 01 octobre 2007, 10:20

Re: sur la vectorisation dans Asymptote

Message non lu par GMaths »

OG a écrit :Pour la moindre rectitude, rien à voir avec la 3D, en 2D c'est pareil. C'est du au pinceau
plus épais et au choix par défaut de linejoin(1).
Tu peux essayer linejoin(2)
Je ne sous-entendais pas que la 3D soit en cause... mais quand on voit le bord parfait du trait épais, je comprends que l'on puisse être un peu déçu du léger effet d'escalier des traits définissant les faces du cube.
Et j'ai imaginé que cela pouvait être cela qui gêne pluton.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

erreur
Dernière modification par pluton le mardi 14 août 2012, 06:40, modifié 1 fois.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

bon, merci pour vos messages. J'ai enquêté un peu de mon côté et en effet, l'image ci-dessus est vectorielle mais elle contient beaucoup de choses inattendues. Déjà, lors de l'export en eps, la figure créée ne semble pas pouvoir être ouverte par des applications 64b sous windows 7 (il faudrait que j'essaie sous linux). : c'est assez bizarre et je ne suis pas du tout certain de "ma" conclusion. Ceci dit, en exportant en pdf, il est possible d'ouvrir le fichier dans Illustrator ou Inkscape.

1 - Sous Illustrator : les choses se passent assez mal. En fait, les faces du cube ne sont pas "sélectionnables" et sont de type "Non-native art" (je ne sais pas ce que ça signifie). Par contre les arêtes en couleur "brown" sont bien des "strokes" usuels et toutes leurs propriétés vectorielles sont accessibles (couleur, poignées de contrôle, épaisseur...) d'où le meilleur affichage graphique et le non crénelage relevé par GMaths.
Image


2 - sous Inkscape : après plusieurs cliques droits pour "dégrouper" les objets (chaque facette du cube est constitué d'un polygone de couleur accompagné de plusieurs masques de découpe (apparemment)), chaque facette est accessibles entièrement et il est possible de modifier sa couleur et sa forme (ici, la facette déformée verte).
Image

Le crénelage mentionné par GMaths et bien visible sur la figure n'est donc pas un problème de pixelisation mais a priori de superposition de plusieurs masques (dont on peut questionner l'utilité) dans le fichier vectoriel pdf : des conclusions identiques prévalent pour le fichier eps sous Inkscape. Quand ces masques sont éliminés, le crénelage disparait : c'est assez inattendu mais c'est apparemment ce qui se passe. Il se peut aussi que ça dépende de l'application d'édition du fichier : vous pouvez remarquer la différence au niveau de crénelage lors de l'affichage du cube dans Illustrator et dans Inkscape. Ce cube donc est bien vectoriel mais contient pas mal d'éléments assez nocifs pour un affichage de qualité. Ceci dit, pour des formes plus complexes avec gradients et lumière, la pixelisation dans Asymptote est bien là (enfin, je crois).

Initialement, je pensais que chaque facette serait un simple polygone pour lequel l'accès aux poignées de contrôle et à la couleur serait immédiat. Les choses sont plus compliquées mais pas insurmontables. Un peu d'édition dans Inkscape est quand même nécessaire pour un affichage parfait.
OG
Modérateur spécialisé
Modérateur spécialisé
Messages : 2293
Inscription : lundi 12 mars 2007, 11:20
Localisation : Rouen

Re: sur la vectorisation dans Asymptote

Message non lu par OG »

Bonsoir

J'avoue que je ne suis jamais allé aussi loin dans l'édition d'un pdf. Je savais que c'était du vectoriel
mais je ne sais rien de la structure des éléments graphiques d'un pdf. Visiblement le rendu dépend
du logiciel (ou librairie utilisée).
Pour une modification de la sortie d'asymptote, là c'est dans le code source (et pas juste les .asy)
et l'écriture des pdf.
Pour un dessin 2D a-t-on les mêmes "soucis" ?

O.G.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

Bonsoir,

je vais regarder les figures 2D plus tard mais normalement elles sont plus simples à mettre en oeuvre et requièrent probablement moins
de composants bizarres comme les masques qui en 3D semblent un peu limitants. Je suppose qu'ils sont présents pour une bonne raison.
Il faudrait demander aux auteurs ce qu'ils en pensent non ?
OG
Modérateur spécialisé
Modérateur spécialisé
Messages : 2293
Inscription : lundi 12 mars 2007, 11:20
Localisation : Rouen

Re: sur la vectorisation dans Asymptote

Message non lu par OG »

pluton a écrit :Bonsoir,

je vais regarder les figures 2D plus tard mais normalement elles sont plus simples à mettre en oeuvre et requièrent probablement moins
de composants bizarres comme les masques qui en 3D semblent un peu limitants. Je suppose qu'ils sont présents pour une bonne raison.
Il faudrait demander aux auteurs ce qu'ils en pensent non ?
Il est toujours possible de contacter John Bowman. Il est assez occupé et travaille sur Asymptote
par période. Sa page web se trouve aisément. Il m'a toujours répondu (plus ou moins longtemps
après l'envoi de mon mail) et toute contribution est bienvenue. J'avais fait quelques bricoles pour
la 3D il y a quelques années.

John a l'air d'être asymptote-actif en ce moment.

O.G.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

bon, d'accord, je vais peut-être le contacter quand les idées seront plus claires. Sinon, j'aimerais bien participer mais la programmation n'est pas mon fort malheureusement.
pluton

Re: sur la vectorisation dans Asymptote

Message non lu par pluton »

Re:
J'ai regardé rapidement le papier (pas la vidéo). Il y a une fonctionnelle à minimiser. Mais les auteurs ne précisent pas le temps de calcul.
Je ne sais pas si le temps de calcul est un problème. Il me semble que la qualité de l'image est à privilégier. En fait, une image vectorielle est souvent plus légère que
son pendant pixelisé. C'est ce qui me préoccupe. Que le calcul prenne une journée pour la version finale du document, pourquoi pas ? même si je pense que c'est assez rapide.
Ceci dit, il doit y avoir pas mal de chose derrière le calcul (choix des couleurs, positions des points de contrôle du gradient...)
Répondre