Portage logiciel graphique depuis Visual Studio C++
regatta
Membre
Bonjour,
je recherche des informations pour porter un logiciel de focus stacking (augmentation de la profondeur de champs à partir d'une pile de photos) depuis windows.
Ce logiciel est disponible sous la licence GNU (combine ZM) et utilise la librairie fftw3.
Voici quelques questions, n'ayant pas l'habite des traitements graphiques :
Merci pour vos tuyaux pour partir dans une bonne direction et déterminer si cela est réalisable !
Cordialement
Regatta
je recherche des informations pour porter un logiciel de focus stacking (augmentation de la profondeur de champs à partir d'une pile de photos) depuis windows.
Ce logiciel est disponible sous la licence GNU (combine ZM) et utilise la librairie fftw3.
Voici quelques questions, n'ayant pas l'habite des traitements graphiques :
- le logiciel source utilise des structures et unions pour mémoriser les éléments des image : faut-il conserver ce mode ou plutôt passer par des classes ?
- la gestion de nombreuses images fait que le logiciel windows ne gère en mémoire qu'une partie des données et stocke les autres sous forme de fichiers : comment gérer sous mac de grands volumes de données ?
Merci pour vos tuyaux pour partir dans une bonne direction et déterminer si cela est réalisable !
Cordialement
Regatta
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Les bibliothèques existe-elle en open source et sur Linux ?
Le logicielle tourne-il sur linux (sans émulateur) ?
Le portage sur Mac peux être réalisé en utilisant X11 dans un premier temps.
Pour répondre à tes questions, il est possible d'utiliser des structures et union sur mac ainsi que l'utilisation de fichiers pour stocker les données.
Tout ce que tu peux faire en C standard est faisable en Objective-C qui est une extension objet du C.
Pour X11, je suis moins enthousiaste. Cela reste quand même une solution.
Le programme n'existe pas sur linux donc pas de X11.
La question sur les structure et union est plus sur la manière optimale de gérer des images et des traitements sur ces images, que sur le fait de pouvoir les utiliser.
Je pensais à utiliser des classes de Cocoa à la place de structure (NSData ?).
Le code source en Visual Studio n'a que quelques classes de base de windows : xxxDoc, xxxView et les classes pour les fenêtres de dialogue.
Doit-on utiliser les structures (pour des questions de performance) ou peut on utiliser des classes sans dégrader les performances.
Pour ce qui est de la gestion mémoire avec beaucoup de données à traiter (100 images de 2520 * 1920 par exemple) je ne connais aucun exemple expliquant la manière de procédé.
En espérant être plus clair sur mes questions.
Programmer des traitements en C devrait être plus rapide à l'exécution que d'utiliser des classes. Pour des cas très particuliers ont peut même remonter à l'assembleur (parfois très galère!).
Ensuite, NSData et structures ne sont pas équivalents: une structure est un assemblage défini de variables ou constantes alors que NSData est une classe dont la zone de stockage de données n'est qu'une suite d'octets sans rôle particulier.
Pour traiter un grand nombre d'image, les logiciels font souvent ça image par image. Par exemple dans Graphic Converter il y a un traitement d'image par dossier. Le traitement est appliqué à toutes les images d'un dossier et les résultats sont mis dans un nouveau dossier.
my 2 ¢
La question n'est pas "est-ce que je dois utiliser les structures" mais "est-ce que j'ai des libs compatibles OSX" voire "est-ce qu'on a pas mieux"
Je vais regarder ImageKit pour voir ce qu'à fait Apple.
Pour les libs compatibles OSX, j'ai compilé fftw3 pour mac (cette librairie est celle utilisée dans la version windows), mais c'est en C.
Pour des suggestions de librairies compatible OSX, je suis preneur
(mais moins efficace !)
http://www.heliconsoft.com/animation/Krebs_fly1/index.html
Toutes les photos sont combinées en une seule, mais avec une bonne profondeur de champ !
Par contre, l'utiliser implique de comprendre les algorithmes et de les reprogrammer entièrement, car Core Image utilise un langage dérivé d'OpenGL Shading Language pour définir ses propres filtres.
Dans l'optique d'un portage de la version Windows, cette démarche est donc proscrite; à ce propos, utiliser des structures et des pointeurs n'a rien de sale, mais il se peut que le logiciel d'origine n'ait pas été écrit dans l'optique d'être porté: il serait très dépendant du modèle d'organisation de la mémoire imposé par Windows et donc difficile à convertir au Mac. Difficile de répondre sans étudier le code.
Je n'ai pas trouvé d'exemple d'utilisation en Objective C !
Pour l'instant, je décortique le code source (pas développé pour un portage) pour en comprendre l'organisation et voir comment porter cela en Objective C.
Effectivement, j'ai laissé tombé l'utilisation de CoreImage, n'étant pas un spécialiste du traitement graphique et les méthodes standards ne répondent pas au besoin.
Merci pour cette réponse qui me rassure quant à l'utilisation de coreImage !
Faut revoir les bases même des notions de langage de programmation alors. Parce que l'Objective-C est une surcouche du C.
Une struct, ou même une déclaration genre "struct BUFFER buffer[]", c'est pas "du C et C++ sous windows" ou "pas de l'Objective-C". C'est du C, point barre. Le C c'est du C, que ce soit sos Windows, Mac, Linux ou autre.
Bon après il y a des variantes de C (C99, C Ansi...) mais les différentes entre ces variantes sont plutôt subtiles, en tout cas une syntaxe aussi basique que "struct BUFFER buffer[]" est commune à toutes les variantes " c'est une base de la syntaxe du C en général depuis ses débuts " et surtout, ces variantes n'ont rien à voir avec le fait que tu sois sur une plateforme Win/Linux/Max
Après, l'Objective-C c'est une surcouche du C, donc tout ce que tu peux faire en C tu peux le faire en Objective C
Donc quand tu parles de tes notions de C... sous Windows, dans ce contexte de comprendre la syntaxe du langage, ça n'a pas trop de sens. Quant au fait de trouver un exemple d'utilisation en Obj-C bah suffit de prendre un exemple en C puisque l'Objective-C en est une surcouche.
Bah heu que tu utilises CoreImage ou pas (bien que l'utiliser permettrait d'optimiser les traitements), la question est surtout de savoir si tu as une lib fonctionnant sous OSX qui permet de faire la même chose que celle utilisée par ton soft sous Windows.
Si tu en as une faut voir comment adapter l'API. Sinon, bah t'es dans la merde (vu qu'il te faudra la développer toi-même).
Ensuite, commence par porter la partie métier avant de porter la partie vue. Car si tu as que la partie métier au moins tu pourras par exemple la piloter en mode console au pire, et puis la vue ne sera pas grand chose à porter quand tu auras le métier de fonctionnel. Alors que si tu portes la vue mais qu'au final tu n'arrives pas à porter la partie métier parce que tu ne trouves pas de lib équivalente, t'auras plus qu'à tout jeter.
Pour la librairie utilisée sous windows (fftw3), elle est disponible en open source et est déjà recompilée ; donc pas de problème de ce coté !
La partie vue ne me pose aucun soucis (une fenêtre d'affichage de la première image chargée et une fenêtre qui indique le traitement en cours) car j'utilise les classes Cocoa.
Mon problème actuel est lié à des erreurs de compilation sur du code pour accéder aux composants d'un des éléments du tableau de structure.
La question est de savoir si mes restes de connaissance en language C (syntaxe avec & ou * avec des structures) sont en cause (sans doute) !
Je suis preneur de tout exemple montrant la gestion des tableaux de structures (et en objective C si le compilateur est susceptible ou attend une syntaxe particulière ).
.
Bah pour on tableau de struct, c'est pareil. Tu remplaces [tt]int[/tt] par [tt]struct BUFFER[/tt] et le code ne change pas : donc si tu as un [tt]struct BUFFER buffer[/tt] ça va donner : .
Après tu manipiles ta [tt]struct BUFFER[/tt] comme n'importe quelle struct. Si par exemple elle est définie comme : Bah pour accéder à width tu fais comme n'importe quelle structure (et ça qu'elle vienne d'un tableau ou pas ça change rien :
Que ce soit des struct, des int, ou des double ou autre, les tableaux en C marchent toujours pareil, struct ou pas ça change pas le principe.
La structure déclarée dans le .m
La méthode utilisant la structure
Le code en commentaire est le code de gestion des threads en C++ remplacé par du code GCD
L'erreur de compilation 1 est : Expected identifier '(' before '[' token
L'erreur de compilation 2 est : Expected expression before 'dft1_params'
Je suis avec xcode 3.2.6 (64 bits).
Une idée pour me débloquer ?
Je dois bien avoué que j'ai pas mal perdu en C classique.
J'imagine que le symbole : ^ a pour rôle de créer la valeur attendue par la méthode addExecutionBlock (je me rappelle qu'on utilse cet opérateur pour inclure des sortes de pointeurs sur les fonctions).
Si c'est le cas, n'est-il pas possible de le créer au préalable et d'ensuite l'appeler plus classiquement [dft1BlockOperation addExecutionBlock:data] ?
Enfin, c'est ce que je ferais.
Sethy
Par contre @regatta : le code que tu nous as copié ne compile pas, même en C.
Il compile peut-être en C++, mais l'Objective-C est une surcouche du C, pas du C++.
La preuve j'ai copié/collé uniquement ceci dans un fichier que j'ai nommé "struct.c" et j'ai essayé de le compiler (donc en C pur, pas d'Objective-C là dedans) et il me sort la même erreur :
Y'a un truc que je trouve pas clean dans ta déclaration : un typedef normalement ça s'utilise pour déclarer un type.
[tt]typedef declaration_complete_du_type nom_court_du_type[/tt]
Exemple : Avec ça tu peux utiliser le type "s_toto" au lieu d'utiliser le type "struct toto", c'est plus court et lisible (et c'est le but de typedef, rendre le code plus lisible en donnant des noms plus explicites à des types complexes)
Or là tu mets, à la place du nom court, une déclaration qui ressemble à une déclaration d'une variable de type tableau, avec [tt]dft1_params[32];[/tt]. Ca veut dire quoi ta déclaration ? Que du déclares un type qui s'appelle "dft1_params[32];" et équivaut à une structure ? Mais un type ça n'a pas de "[]" !
Si tu veux déclarer un type nommé dft1_params_type, puis une variable dft1_params_var qui représente un tableau de 32 objets de ce type, il faut écrire : Ou alors tu n'utilises pas le typedef et utilises directement le vrai nom du type : Ou encore si tu n'as pas besoin de manipuler le type proprement dit plus tard, tu peux déclarer directement le type (ta struct) en même temps que tu définis la variable : Mais dans ton code tu fais un mix des deux et je t'avoue que même si c'est peut-être valable en C++ (et encore j'en suis pas sûr) ça me parait trop litigieux et pas clair de savoir ce qui est exactement déclaré pour être acceptable.
Question syntaxe, c'est la syntaxe des structures C qui est simplement étendue aux classes C++.
Donc, sans le savoir, regetta a peut être utilisé des avancées C++ liées aux structures, qui ont transformé sa structure en classe C++ et qui sont donc de facto inconnues en C.
Sethy
Sachant cela, vous identifierez tout de suite (pensez mot-clé class = mot-clé struct) ;
déclaration :
défintiion :
PIXEL étant une union.
En objective C, la déclaration sous la forme
résout le problème
J'avais fait beaucoup de tests et donc laissé le typedef par erreur !
Merci pour votre aide
Ca m'a l'air vraiment pas objet et bien bas niveau (voire crade) ton code d'origine...
Pas de commentaires et deux classes de base Windows (Document et View) et des boà®tes de dialogue.
Mais pour ce qui est de la puissance du programme, c'est le meilleur dans le genre !
Le code est libre mais difficile à suivre pour un débutant en traitement d'images