nouvelle version de mosaïc ortho4xp

[atanorr]

Oui, grand merci Peter, je cherchais à savoir comment travailler sur les 4 claques d'un coup

Envoyé de mon SM-G955F en utilisant Tapatalk

[Dobro]

bon je suis obligé d'abandonner mon projet

j'ai bien fait mon code qui lit le contenu d'un dossier d'images Jpg, et Assemble les images en une grande images ...
sauf que ... si le dossier a trop d'images , mon code se trouve bloqué par la limitation a 32000 pixel de windows ....

je comprends pourquoi Oscar est passé par le pnm .....le texte ne connaît pas de limite !

[atanorr]

C'est pas évident, disons que le meilleur que puisse éventuellement nous faire oscar ou toi, c'est de reprendre son code mosaic, et d'en faire un code en sortie tiff de maximum 4 go, perso ça représente 1/16 ieme de tuile environ, donc un mosaic sortie en TIFF directement sur 1/16 ieme de tuile. Pas de choix ou même pnm car le convert avec le xnconvert prend quelques secondes, ne te casse pas la tête pour une grande photo, j'ai testé Peter également.

, donc une immense photo pnm, sans faire planté gimp sur Windows lorsque tu veux sauvegarder, donc photoshop sauf si tu sait repasser de l'extension psb à pnm et inversement il n'y a pas de meilleur alternative que de rester sur malheureusement une taille max de 4Go en TIFF après 1 mois de recherche, d'avis etc..

Envoyé de mon SM-G955F en utilisant Tapatalk

[Peter092]

+1

Et merci @Dobro d'avoir essayé

[Dobro]

oui , je ne désespère pas de trouver une soluce.... Merci a toi

[papet30]

Bonjour à tout les guru's,
lecteur assidu de vos échanges sur ce fil, bien que béotien du sujet je suis intéressé par les résultats que vous recherchez.
Donc ma question : la perte d'information du changement de format de pnm à jpeg est-il incompatible avec les post-traitements par gimp ou photoshop que vous souhaitez?
Merci.

[Dobro]

il n'y a pas de perte lorsqu'on passe de pnm a jpg ....
d'un point de vue Strict !

le pnm est une ecriture Ascii des pixels ...
si tu part d'un Raw ou d'un bmp ou d'un jpg , tu n'aura aucune perte une fois passé en pnm
tu n'aura qu'une representation ascii de l'image d'origine....

en fonction de ça , un pnm peut avoir une representation d'une perte lié au format de depart
si on passe d'un jpg a un pnm , on aura les artéfacts du jpg dans le pnm (pnm n'est pas un format compressif , donc il n'ajoute pas de perte, mais n'enleve rien non plus .)

par contre effectivement, si on passe d'un jpg ->pnm---> jpg on aura une perte lié a la recompression en jpg ...d'un jpg ....
mais le passage par le pnm, ne change rien en lui meme ...


le probleme soulevé ici c'est de pouvoir retoucher une grande image qui serai l'assemblage des petites images 4096x4096 des dossier de tuiles
ainsi en retouchant une seul grande image, on pourrai mieux voir ce qu'on fait ...
au contraire de ce qui se fait actuellement , retoucher les petites images 4096x4096 individuellement
ce qui n'offre pas une super visibilité ....

probleme , une grande image (donc un assemblage des petite image des dossier de tuiles ) represente une image
d'une taille tel , que meme windows (et la plupart des OS ) ne peuvent pas gerer !! (Trop gros )

reste la possibilité de couper cette grande image en morceau .... bof...
reste la possibilité de reduire la grande image .... la traiter .... et la redecouper en "resizant "les morceaux.... mais possible de gros probleme de flou

bref... on est mal , on est mal LOL


c'est dommage car mon algo d'assemblage fonctionnait bien
la preuve :

[atanorr]

Oui la seule solution créer 1/16 de tuile, je vais refaire un tuto correct car j'ai oublié de vous montrer comment gérer le contraste sur ma vidéo d'une seule manœuvre

Envoyé de mon SM-G955F en utilisant Tapatalk

[papet30]

il n'y a pas de perte lorsqu'on passe de pnm a jpg ....
d'un point de vue Strict !
par contre effectivement, si on passe d'un jpg ->pnm---> jpg on aura une perte lié a la recompression en jpg ...d'un jpg ....
mais le passage par le pnm, ne change rien en lui meme ...
........c'est dommage car mon algo d'assemblage fonctionnait bien

Bonjour Dobro,
J'ai bien compris que je ne gagnerais rien (au contraire ) a passer par une conversion pnm>jpeg avant traitement dans gimp pour ensuite exporter en pnm pour pouvoir "splitter" avec Mosaic et retrouver les jpeg's modifiées.
j'ai donc assemblé ma tuile en 4 quarts de 3,2 Gb chacun, je charge les .pnm dans gimp je traite et je splitte les pnm résultants avec Mosaic.
Mais là avec la manip Mosaic j'ai bien jpeg-->pnm-->jpeg avec la perte que tu évoques ci-dessus.

Question : ton assemblage de jpeg's pourrais tu le faire en quarts de tuile, traiter les quatre morceaux en jpeg dans gimp, mais il faudrait alors pouvoir déassembler les fichiers résultants, on aurait alors aucune conversion.

Ca pourrait marcher et aurait-on vraiment un intêret?
Merci

[atanorr]

Perso 1/4 de tuile c'est 12 giga... En zoom 17.. De jpeg vers pnm, j'ai exactement 3,4 go sur 1/16 de tuile..

Envoyé de mon SM-G955F en utilisant Tapatalk

[atanorr]

Je pense que tu as certainement travaillé sur une tuile avec une île ? Avec du blanc partout ?

Envoyé de mon SM-G955F en utilisant Tapatalk

[atanorr]

C'est même plus, 13 go pour 1/4 de tuile..

Envoyé de mon SM-G955F en utilisant Tapatalk

[atanorr]

Où alors en zoom 16?

Envoyé de mon SM-G955F en utilisant Tapatalk

[papet30]

Je pense que tu as certainement travaillé sur une tuile avec une île ? Avec du blanc partout ?

Envoyé de mon SM-G955F en utilisant Tapatalk

Bonsoir,
pardon je n'ai pas précisé je travail sur des tuiles en ZL16 donc 4 fois moins lourdes qu'en ZL17.

[Dobro]

Question : ton assemblage de jpeg's pourrais tu le faire en quarts de tuile, traiter les quatre morceaux en jpeg dans gimp, mais il faudrait alors pouvoir déassembler les fichiers résultants, on aurait alors aucune conversion.

Ca pourrait marcher et aurait-on vraiment un intêret?
Merci

pouvoir ,oui , on peut, sauf que ...
soit on travail en Ram (comme la plupart des executables) et là on se retrouve confronté a un probleme de taille , imagine une 20 aines de giga (en voyant court et sans compter le prg )
dans une Ram de 16 ... (certains ont 32 , mais ça change pas grand chose, le system d'exploitation en prends aussi )

et on se retrouve avec un PC Gelé ... dans le meilleurs des cas car le debordement se fera sur la VRam donc sur Disque dur ....

soit on travail sur Fichier , donc en acces direct To Disque ... plus lent, mais faisable , en passant par un format qui supporte de depasser les fameux 30.000 pixels !. limite de la plupart des formats sauf (le pnm et le Tiff)

bref , Oscar avait trouvé la voie a suivre ...

avec mon code , pour pouvoir generer le contenu complet d'un dossier de tuiles dans une "grande image" , je suis obligé de reduire les images 4096x4096 au format (4096/4)X(4096/4)
sinon l'image de sortie est trop grosse pour etre ecrite !


ps: je n'ai pas testé de sortir en Tiff ..... seulement en Bmp, en Jpg, en Tga , en Png ... sans succes .... :o)
j'essaierai en Pnm , mais je n'aurai rien de mieux que Mosaic de Oscar ...