NSImage et Tiger...
Mala
Membre, Modérateur
Hello, tout le monde. Bon après une longue abscence, je me remets un peu dans mes projets d'astronomie. :fouf):
Je viens de migrer sous Tiger et horreur mes softs de traitement et d'acquistion ne marchent plus sous 10.4!!! Par exemple, toutes les images que je gère dans SLDriver ( http://www.poisson-lune.com/pages/astro/pages_anglais/SLDriver.html ) sont complètement décalées sous Tiger...
La même image chargées sous 10.3.9 s'affiche parfaitement. Les informations semblent bien traitées mais c'est l'affichage (transfert de ma matrice de travail vers une NSImage) qui semble merder.
J'ai bien regardé du côté de la création de mon NSBitmapImageRep...
Mais je vois pas trop ce qui cloche. j'alloue bien une matrice avec 3x8bits par pixel en non planair et sans couche de transparence.
Si quelqu'un a une piste, je suis preneur.
Je viens de migrer sous Tiger et horreur mes softs de traitement et d'acquistion ne marchent plus sous 10.4!!! Par exemple, toutes les images que je gère dans SLDriver ( http://www.poisson-lune.com/pages/astro/pages_anglais/SLDriver.html ) sont complètement décalées sous Tiger...
La même image chargées sous 10.3.9 s'affiche parfaitement. Les informations semblent bien traitées mais c'est l'affichage (transfert de ma matrice de travail vers une NSImage) qui semble merder.
J'ai bien regardé du côté de la création de mon NSBitmapImageRep...
// Create the RVB representation
ImageRep = [[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:NULL
pixelsWide:ImageCPLUSPLUS[ImgIndex]->RetournerLargeur()
pixelsHigh:ImageCPLUSPLUS[ImgIndex]->RetournerHauteur()
bitsPerSample:8
samplesPerPixel:3
hasAlpha:NO
isPlanar:NO
colorSpaceName:NSCalibratedRGBColorSpace
bytesPerRow:3*ImageCPLUSPLUS[ImgIndex]->RetournerLargeur()
bitsPerPixel:3*8];
Mais je vois pas trop ce qui cloche. j'alloue bien une matrice avec 3x8bits par pixel en non planair et sans couche de transparence.
Si quelqu'un a une piste, je suis preneur.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Est-ce que tu as enregistré ta représentation dans un fichier pour la regarder ailleurs et vérifier que le problème vient bien d'elle ?
[tt]
[[ImageRep TIFFRepresentation] writeToFile:@MonFichier atomically:YES];
[/tt]
Voici donc un petit projet sous Xcode 2.1 avec son source et qui illustre bien le phénomène...
http://www.poisson-lune.com/downloads/tmp/test.zip
C'est juste une petite routine qui prend en entrée une image (pour les tests: jpeg, 24 bits, sans transparence) puis la réduit à 50% de sa taille d'origine histoire de faire une manip sur la matrice d'entrée.
Voici le code de la routine
Pour mon projet de test, dans l'interface on a 2 boutons. Le premier charge une image d'un iMac G5 en 864x540 en la réduisant à 50%. Le deuxième bouton charge une image d'un amas globulaire M13 en 3360x2245 et fait de même.
Sous Panthère, aucun problème. Sous tiger, pour l'iMac c'est Ok mais pour M13 badaboum... ???
Je commence à me demander s'il n'y aurait pas un bug lié à la taille des images sous Tiger. :crackboom:-
Et pourquoi ne pas utiliser :[tt][sourceImage drawInRect: NSMakeRect(0, 0, resizeWidth, resizeHeight) fromRect: NSMakeRect(0, 0, originalSize.width, originalSize.height) operation: NSCompositeSourceOver fraction: 1.0];[/tt] Hein ?
Il parait que tu peux même utiliser [[NSGraphicsContext currentContext] setImageInterpolation:NSImageInterpolation{None, Low, High}] pour choisir le type d'interpolation utilisée lors de la réduction
Parce que là en plus ta méthode elle risque de faire des trucs bizarres sur les bords de ton image... et puis il y a des trucs tout faits, pourquoi s'embêter ?
Allez, un exemple trouvé à chaud sur google :ici
Merci AliGator mais c'est juste à titre d'exemple pour illustrer le problème.
OS X ne gère que du RVB. J'utilise notamment des images encodées en LRVB 40bits dans mes programmes.
De plus, j'ai constaté de nombreux trucs très casse bonbon en faisant confiance aux routines Obj-C pour la manipulation d'images. Du genre une image en RVB 48bits est directement transformée en RVB 24 bits sans te demander ton avis dans certaines routines (je pense par exemple à un simple setImage dans une NSImageView).
Il me semble avoir lu un truc sur Core Image où la taille max des images était de 2048 pixels de côté. Si c'est lié, bonjour la régression par rapport à Panthère. :-\\
http://lists.apple.com/archives/cocoa-dev/2005/May/msg00169.html
Merci pour la piste c'est exactement ça. Donc, depuis Tiger lorsqu'on initialise le bytesPerRow de sa NSBitmapImageRep on a absolument pas la garantie du résultat... ???
Avec mon image de 2050 pixels de côté, je me retrouve avec 2069 pixels par ligne. En dessous de 2048, le problème ne semble pas se poser.
Apparement, le fait de ne plus avoir systématiquement les lignes d'octets alignés au niveau mémoire permet d'accélérer l'affichage.
A côté de ça, j'ai découvert une autre "régression" sous Tiger. Avant sous Panthère il était possible de récupérer les infos d'entête d'un fichier TIF (largeur de l'image, hauteur, nb bits par pixel, etc) avec un simple "initWithContentsOfFile" qui ne s'encombrait pas à charger tout le fichier. Cela allait donc très vite. Maintenant, sous Tiger mon même programme met plusieurs minutes pour récupérer ces infos (pour une centaine d'images TIF 48 bits de 47 Mo).
D'un côté on optimise et de l'autre on poubellise ce qui est bien. Merci Appoule...
Par contre, il va falloir que je reporte cette modifs dans mes applis.
Mais je ne comprends tout de même pas ce qui ne va pas à la base. Quand je lis:
Moi cela me laisse supposer que si on met le "bytesPerRow" à 0, on a pas la garantie que les lignes de pixels seront alignées en mémoire. Et si on l'initialise par contre on est tranquile. Hors dans les faits je constate que ce n'est en fait pas le cas sur de grosses images puisque dans mon exemple je l'initialisais bien. >:(
Donc au final, pour moi ça m'a tout l'air d'un bug ou alors il y a erreur d'interprétation. En attendant, toujours est-il qu'au final, j'initialise le bytesPerRow mais que je le récupère tout de même dans mes boucles afin d'être sûr d'avoir la bonne largeur en octets de mon image.
Ce qui me donne comme modif (indiquée en italique gras) sur mon exemple du départ: