Newsgroup: it.comp.java
Titolo: Passaggio C a Java: unsigned

Mi sono imbattuto ieri in uno strano problema di "dati sbagliati" 
passati da un modulo C ad un modulo Java.
Stamattina ho capito che il problema stava nel fatto che il C acquisce 
dati come unsigned char, mentre Java si aspetta dei byte che, 
correggetemi se sbaglio, sono signed (quindi, valori di partenza fra 
0:255 e valori di arrivo fra -128:127).
La domanda quindi e': come faccio la conversione fra i due tipi di dato? 
basta uno scaling lineare o c'e' una mappatura discontinua dei valori? 
ah, immagino che poi nella parte Java dovro' passare ad un nuovo tipo, 
per esempio short integer?
Grazie
CarMas

CarMas ha scritto:

Dipende chiaramente da come tu utilizzi questi dati passati.
Se si tratta di un semplice stream binario, poco importa se da una
parte lo vedi signed e dall'altra unsigned: sempre della stessa
mappatura di bit si tratta.
Altrimenti, la classe InputStream ha un metodo read() che non a caso
legge il byte come int compreso fra 0-255.
Spero di essere stato d'aiuto.

CarMas wrote:

no non cambiare tipo.. in java short e' considerato come un intero di 16
bit..
per la conversione ti consiglio un piu' banale..
c -= 128;
se la cosa non ti gusta nel senso che non desideri valori negativi puoi
usare (oltre short) char, ma sono sempre 16 bit..
-- 
none

 Dipende chiaramente da come tu utilizzi questi dati passati.
Si' scusa, in effetti non ho spiegato il background!
Il modulo C acquisisce immagini da una telecamera, la funzione nativa 
restituisce un unsigned char *, che in Java ho mappato su un byte[]; di 
fatto, si tratta di valori rgb che sono vincolati a 0:255.
Ora, il problema non si pone per le immagini a colori, nella costruzione 
di una Image o BufferedImage i valori (anche se negativi) vengono 
interpretati correttamente.
Il problema nasce con le immagini in gray scale: che tu ci creda o no, 
il metodo che Java mi fornisce (ColorConvertOp e seguente filter) ha 
delle prestazioni drammatiche... motivo per cui ho deciso di farmi la 
conversione a mano (si tratta in fondo solo di leggere triple di valori, 
fare tre moltiplicazioni e una somma). E qui ho avuto dei problemi, 
perche' coi valori negativi la mia "funzione di conversione" sbagliava 
palesemente, col risultato che l'immagine che generavo era piena di 
rumore e saturava in alcuni punti (guarda caso, in corrispondenza di 
pixel per cui avevo delle letture negative).
Diciamo che nel mio post precedente mi sono un po' fasciato la testa 
prima di essermela rotta, ho fatto un rapido controllo e ho verificato 
cosa succede ai byte quando assegni un valore fuori dal loro range.. 
quindi ho introdotto questa compensazione nella mia funzione e sono 
riuscito a risolvere!
Grazie per l'aiuto e scusa per il disturbo!
Saluti
CarMas

 usare (oltre short) char, ma sono sempre 16 bit..
Come ho risposto a Vincent Vega, mi servivano dei valori positivi... 
pero' ai char non avevo pensato. Per curiosita', cosa succederebbe se ad 
una funzione che si aspetta un byte passo un char?
Grazie!
Saluti
CarMas

 una funzione che si aspetta un byte passo un char?
[..]
non conosco bene java, ma penso che accada la cosa piu' probabile..
perdi gli 8 bit piu' significativi..
-- 
none

 una funzione che si aspetta un byte passo un char?
che non e' C e ti manda a cagare :)
potresti avere qualche problema con i confronti con le costanti, ovvero:
tu entra un valore unsigned X, java lo vede come un signed Y (quindi
potrebbe essere negativo). a questo punto se vai il confronto con una
costante che ha il valore X, il confronto fallisce.
X ----|JAVA|---- Y == X false
dove Y e' < 0
a questo si puo' ovviare troncando il bit del segno (supponiamo di usare un
byte):
X ----|JAVA|---- (byte)(Y && 0xFF) == X true