Reprise du message précédent :
Bah je sais pas à vrai dire, comme je veux des nombres je me suis dis que int ça irai très bien ...
 
skelter pourquoi quand j'utilise ta methode mes "128" ce transforment tous en "-128" ?

 
tu veux faire quoi exactement, tu veux lire quoi dans ton fichier ?

Oubli du test de retour de malloc.

 
Alors ce que je veux c'est enregistrer un à un les octets du fichier bmp dans un tableau
Les 6 premiers octets d'une part, pour avoir la taille totale du fichier
Le reste d'autre part pour pouvoir faire les modifications que je veux effectuer dessu.
 
 
Et escusez moi de mon ignorance mais qu'est-ce qu'un "test de retour de malloc" ?

l'allocation peut echouer, dans ce cas malloc retourne NULL, c'est un cas a prendre en compte (comme quand tu testes le retour de fopen)
 
 

 
tu veux dire que tu veux lire 6 octets que tu dois interpreté comme un entier ? tu es sur que c'est 6 octets ?
 

 
tu connais la structure du fichier ?

Ce code sert à 'lier' la création du bloc mémoire et son usage. Si la valeur de size est modifiée, la modif s'applique automatiquement à la création et à l'usage, ce qui garanti le bon fonctionnement. C'est de la programmation 'intelligente' qui rend le code 'auto-démerdant'.
 
 

Justement, non. Ton ignorance est dangereuse. Tu te lances dans des manipulations compelxes mettant en jeu des fichiers, de la mémoire, et ce, sans connaître les bases du langage C.
 

 
Je te conseille de te former. Je pense que ce cours 'jeune et ludique' te conviendra : Cours de C (Laisse tomber la partie SDL pour le moment)

Ouai m'enfin le seul test de retour de malloc que je connaisse :

Ne change rien à mon soucis du "-128" ...

 
Nan c'est 4 octets, mais ce sont les 3,4,5 et 6ème octets donc je copie les 6 premiers
Et oui je connais la structure du fichier, les 54 premiers octets forment l'entete, et après chaque pixel est codé sur 3 octets :
en premier vient l'octet pour coder le bleu, ensuite le vert puis le rouge, puisqu'on travail en 24bits.
Chaque octet code donc une composante RVB comprise entre 0 et 255, et je dois réccuperer chacune des composantes de chaques pixels pour appliquer la DCT voilà
En gros toute la partie traitement de l'image de mon programme est terminée... le seul soucis, et le plus gros, c'est que je ne sais pas comment stocker les octets dans un tableau. Enfin je suis près du but mais il y a toujours ce problème de "-".

se renseigner sur char et unsigned char me semble une bonne idée

En fonction des indications de taille contenues dans l'entête du fichier BMP, définir un tableau dynamique de unsigned char, puis le charger avec fread() et les bons paramètres...
 
Pas de difficultés particulières.

Nan mais jusque là ça marche ... mais pourquoi ai-je "-128" au lieu de 128 dans tout mon tableau ?

Salut.
Un truc qui me paraît bizarre, c'est copier un fichier dans un tableau. Pourquoi ne pas le maper dans l'espace d'adressage du processus, en utilisant mmap()?
Ca ferait exactement ce qu'il veut, puisqu'il aurait accès aux éléments par un tableau (par un pointeur, mais l'arithmétique est identique).

se renseigner sur char et unsigned char me semble une bonne idée    

Il est bien de type unsigned char comme déjà indiqué ? Et comment tu fais pour visualiser ce -128 ? Si tu utilises printf(), il faut utiliser le bon formatteur et le bon cast... La valeur peut être correcte, mais mal convertie par printf().
 
 
 

 
Merci pour ce conseil j'ai vu, j'ai lu et ça marche

 
Parce que ton "char" est signé par défaut.  
La plage d'un char signé va de -128 à 127 dans cet ordre:

• de 0 à 127 puis de -128 à -1

La plage d'un char non signé va de 0 à 255 dans cet ordre

• de 0 à 127 puis de 128 à 255

Etant donné qu'en binaire, le codage de 128 et de -128 est le même, soit 10000000; si ce code est affiché par une fonction où tu lui dis "je te donne un nombre non-signé" ta fonction affichera 128. Si tu lui dis "je te donne un nombre signé", elle affichera -128. Même remarque pour toute valeur allant de 128 à 255; tu auras à l'écran leur homologue négatif allant de -128 à -1...
 
Si tu veux savoir la raison de ce codage si bizarre, c'est pour que l'addition de deux nombres opposés fasse toujours 0
-128    =  1000 0000
 128     =  1000 0000
Somme = 1 0000 0000 mais comme un char ne fait que 8 bits, tu perds le premier "1" par dépassement et tu te retrouves avec 0000 0000 soit 0
 
PS: Comment connaître le codage binaire d'un négatif: tu prends le nb positif, tu le codes en binaire, tu inverse chaque 0 et chaque 1 et tu rajoutes 1 au résultat
128 = 1000 0000
inv =  0111 1111
inv + 1 = 1000 0000 = -128

 
attention, le fait que char soit signé ou non n'est pas fixé par le standard, c'est dependant de l'implementation

D'où le ton "char"... Mais c'était peut être involontaire. La piqûre de rappel n'était pas inutile...

 
Euh oui. Ce que j'ai voulu dire, c'est "dans ce cas, apparemment, les char sont considérés signés"
J'ai utilisé un raccourci syntaxique qui peut prêter à confusion - Merci d'avoir rectifié...

désolé j'avais pas percutter pour le "ton" , enfin maintenant c'est dit et c'est pas plus mal de le preciser

Oui, j'ai tout à fait involontairement dit un truc correctement parfait    

Pourquoi tu n'utilises pas un langage de plus haut niveau?
c'est juste pour tester les algorithmes, a la limite tu t'en fous un peu des performances.
C'est dommage de 'perdre' autant de temps sur les bases du C alors que ce n'est pas vraiment le sujet de ton TIPE.
Si plus tard tu veux faire du C, il te suffit d'integrer une école d'info, voir même dans les généralistes ya des cours de C

Faut voir la geule des cours aussi  

 
Je suis en prépa intégré dans une école d'électronique... En fait mon TIPE devait porté sur la compression en hardware... mais mon prof nous a soulé pour qu'on fasse sur le software, avec à l'appuie un programme codé en C... en clair j'ai rien choisi. En plus c'est pas avec les 2h d'info par ans que je vais apprendre qqch dans cette école

Si tu fais du hardware tu peux pas le faire en ASM ?