Convertir des images Pict en 4D 64 bits

Nous allons livrer notre prochaine version en 64 bits et nos utilisateurs risquent d’avoir des images pict dans leurs courriers. C’est possible de mettre à jour ces images ? La conversion ne sera pas possible directement dans 4D mais y’a un autre moyen ? Je croyais avoir vu des discussions sur le sujet mais je retrouve pas…

Bonjour Eric,

la conversion doit se faire absolument en 32 bits.
Pour cela, il y a plein de code sur le forum ou inug sur ce problème.
Sinon, il y a des outils comme une base de JPR qui le fait, ou bien QS_Toolbox qui exporte les images de la biblio pour en faire des PNG.
Patrick

Bonjour Patrick,

On est d’accord que je parle des images qui sont dans les datas des clients (et plus spécifiquement dans leur Courriers ex 4D Write devenus Write Pro). Sûrement qu’on aurait dû le faire avant mais on l’a pas fait… :disappointed:
Donc ma question était spécifiquement sur une exécution en 64bits. C’est le cas de la base de JPR ? Et de quelle base parles-tu ?

Merci

En 64 bit c’est mort, il faut effectivement le faire en 32 bit.
Éventuellement fournir un programme monoposte qui serait en 32 bit, juste pour ouvrir les anciens docs et les réenregistrer après avoir converti les images incluses :?:

Salut,$
ça va pas ça ?

http://forums.4d.com/Post/FR/32083063/1/32083064http://forums.4d.com/Post/FR/32083063/1/32083064>

A faire sur mac de préférence pour cause de bug windows

Bertrand, on parle des images incluses dans un document 4D Write ou 4D View ou autres zones de plug-in; on ne parle pas des images dans les formulaires, ni des images de bibliothèque d’image, ni des champs image… :wink:

Donc, non, ça va pas… :cry:

En fait, c’est même pire que ça vu qu’il a déjà converti ces zones en 4D Write Pro… :frowning:

: Manuel PIQUET

Bertrand, on parle des images incluses dans un document 4D Write ou
4D View ou autres zones de plug-in; on ne parle pas des images dans
les formulaires, ni des images de bibliothèque d’image, ni des champs
image… :wink:

Donc, non, ça va pas… :cry:

On est d’accord que je parle des images qui sont dans les datas des clients

Oui, mais lui il parle des images dans les courriers des clients donc je suppose qu’il parle des images incluses et pas simplement de champs images qui seraient utilisés dans le doc 4D Write.

Qui plus est, on peut encore trouver pire : des images stockées dans un doc 4D Write qui n’est pas stocké dans le data !!! :twisted:

Salut,

Manuel t’as bien résumé la situation : 64 bits => impossible.
La base de JPR concerne les images dans la bibliothèque.

L’affaire semble bel et bien compromise (il me semblait avoir vu passer qqchose à base lancer process externe !?).

A défaut, il y a moyen juste de savoir si le courrier contient des images dépréciées (je parle toujours en 64 bits bien sûr…)

Salut Eric,

J’avais posté du code, je ne sais pas si ça peut aider…

https://forums.4d.com/Post/FR/17329223/1/17329224#17329224

Sinon, tu peux faire un web service avec un 4D 32 bits. Il reçoit une image PICT et la retourne en ce que tu veux ;-)…

PS : et je crois que tu as encore en v17, un client et un serveur 32 bits… Tu peux faire un traitement de conversion qui ne se lance que si tu est en 32 bits.

A+

: Bruno LEGAY

PS : et je crois que tu as encore en v17, un client et un serveur 32
bits…
c’est la 4D v17r4, version “pivot” pour migrer de 32 à 64 - je risque pas de la mettre à la corbeille de sitôt.

Bonjour Bruno,

Voilà exactement ce que je cherchais ! Merci beaucoup pour cette méthode, on va regarder ça de près. Et effectivement, on avait envisagé sinon la solution du web service.

Si on peut faire quelque chose sans devoir jongler avec une version intermédiaire et qui règle définitivement l’affaire, ce serait vraiment bien…

Bonne journée…

Des nouvelles du front pour ceux que ça intéresse : grâce à la méthode de Bruno et en passant ensuite par un process externe qui permet de transformer le pict 64 bits en png, on a pu faire la màj de ces images Write. Ça utilise Quick Look donc ça ne marche que sur Mac mais ça devrait bien nous suffire. Mission réussie donc, c’est parfait…

Bonne journée

Quelques précisions s’imposent : :pray:

Ton process externe, il tourne en 32 bit ? tu parles de Quick look c’est quoi celui du système macOS ou d’un plugin 4D ? sous quel OS est ton client qui execute le process ?

Avec ces contraintes, tu arrives à deployer un systeme de mise à jour universel ou tu prends le parti de traiter le data chez vous et l’envoyer au client ? Quid des fichiers externes ?

Tu as raison d’être précis :wink: : suite à ton message, on a étendu nos tests et, à ce stade, ça coince sous Catalina, le lancer process externe bloque, on cherche pourquoi…

Pour ce qui marche et répondre à tes questions :
C’est bien le Quick Look du système. La méthode de Bruno permet de lire l’image en 64 bits mais, telle quelle, l’image n’est pas utilisable dans 4D. Trouvé par ailleurs sur le forum, on fait appel à Quick Look (qlmanage) qui permet de la transformer en png. On la réintègre et c’est bon.
Il est pour nous hors de question que cela passe chez nous, c’est donc intégré à la mise à jour faite au moment du lancement de la nouvelle version. Comme déjà dit, ça ne fonctionne pas sous Windows mais ça fonctionne bien sous Mac avant Catalina.
Nous ne gérons pas de fichiers externes, on ne s’en est donc pas préoccupé…

Des news quand on aura résolu (j’espère…) le problème Catalina…

Quick look doit (comme son nom l’indique ;-)) utiliser des bibliothèques de feu QuickTime pour gérer les images pict qui ne sont plus disponibles en 64 bit donc plus dispo sous Catalina…

J’ai pas compris dans ta réponse si ton client était exécuté en 32 bit ? Apparement non, c’est ça ?c’est l’execution sous Quick Look qui doit l’être, du coup plus fonctionnel en Catalina…

Oui, c’est bien ça, qlmanage ne gère pas les images pict. C’est finalement pas bien grave, nos clients Catalina vont du coup se retrouver comme les Windows, on les informera mais on ne mettra pas à jour. Au pire, pour qques clients qui auraient beaucoup de courriers avec beaucoup de pict, on sera toujours à même de traiter leurs courriers à postériori puisqu’à ce stade on n’a pas encore supprimé les anciens blobs 4D Write.

Pour ce qui est du client, oui, c’était le point de départ de la discussion, on est en 64 bits, 17 R5 en l’occurence, pour avoir la version la plus avancée du Write Pro.

Merci pour le retour d’infos. Tu voulais/pouvais plus attendre la v18 :?: