Newsgroup: it.comp.grafica.photoshop
Titolo: [OT] Jpg e Luminanza

Ho letto lo standar di codifica delle jpg e mi sono imbattuto nella
Luminanza...
ora la domanda è prettamente di carattere tecnico e quindi su questo ng
potrebbe risultare ot... cmq la pongo lo stesso :-D
Nel codice esadecimale di una jpg
come identifico quale indici esprimo la luminanza di un singola area?
ovvero se volessi modificare manualmente il codice, aumentando la luminanza
di una determinata area dove e come dovrei andare ad operare?
Grazie a chi saprà rispondere :-)
Lok
--
.

 di una determinata area dove e come dovrei andare ad operare?
non penso di sapere la risposta, ma te la butto li lo stesso :)
Allora .. il jpeg e' un algoritmo di compressione detto "lossy", e pertanto,
per ridurre magicamente la dimensione finale del file non fa altro che
"buttare" dati dell'immagine.
Come? se non ricordo male a seconda del livello di compressione viene
"semplificata" l'immagine in funzione di aree di colore e luminanza simile.
Infatti, piu' comprimi e piu' si "sgrana".
Ora, se ho ben capito tu vorresti pigliarti un editor testuale, aprire il
file (binario..) e modificare a manina i valori di luminanza :')
A parte la difficolta' mostruosa .. dovresti prima essere in grado di
decodificare i "puntatori" che dicono dove zone simili di colore sono state
raggruppate e compresse, capire come sono descritti i valori rgb/cmyk per
singolopixel, e sapere cosa e dove scrivere per modificarli. Auguri.
Se ci riesci, fammi un fischio che sono curioso di venire a vedere di
persona :)
Domanda delle due di mattina .. non fai prima ad intervenire con un
programma di fotoritocco, che alla fin fine fa proprio quello che serve a
te? :')
Beh notte :)

 te? :')
non proprio... questa domanda fa parte di un progettino piu ampio il cui
scopo finale è la steganografia di informazioni in file jpg
benche esistano già programmi che li fanno non riesco ad beccare il
"come"... quindi dopo infruttuose ricerche in google sto iniziando a
chiedere in giro
Lok

 ha scritto nel messaggio
news:Twjqa.67873$DT4.2...@twister1.libero.it...

Se vuoi modificare la luminanza delle immagini ti comviene usare programmini
come Neat Image oppure plugin come Qunatum mechanic invece di agire sul
codice....

Ho come l'impressione che le specifiche che hai sottomano non siano scritte
tanto bene... Per caso ho sul comodino il libro di David Salomon "Data
compression, the complete reference" e, benchè non abbai ora il tempo di
leggere con cura il paragrafo sulla compressione jpg, gli ho dato una scorsa
veloce. Ricapitoliamo un'attimo grossolanamente i passi fondamentali della
compressione:
1) si converte l'immagine in uno spazio con due canali di crominanza e uno
di luminanza, operando poi su ogni canale indipendentemente
1a) i canali di crominanza, percepiti con meno "precisione" dall'occhio
umano, vengono sottocampionati.
2) ogni canale viene diviso in blocchi 8x8
3) ad ogni blocco si applica la DCT
4) si butta via informazione nello spettro della dct in base a parametri di
inizializzazione dell'algoritmo
5) si applica codifica RLE e Huffmann
6) si impacchetta tutto in un singolo file che include l'header con i
parametri di inizializzazione, che indicazo anche l'ordine in cui sono stati
processati i blocchi 8x8 dell'immagine
Ora, dal passo 3 in poi è chiaro che si perde ogni corrispondenza diretta
tra un "numeretto" che si può trovare nel bitstream (cioè nell'insieme dei
dati risultanti dall'applicazione dell'applicazione dell'algoritmo
all'immagine) e un pixel o una zona dell'immagine.
Di più, se anche tu volessi intervenire direttamente sui coefficienti della
dct (magari moltiplicandoli tutti per un fattore), perderesti questa
possibilità con il passo 5, che sottopone il bitstream a codifica Huffmann.
In conclusione: le prime, indispensabili cose da fare sono decodificare
secondo Huffmann e RLE (per poter accedere ai valori dei coefficienti dct
dei singoli blocchi) e fare un corretto parser dell'header (per sapere in
che ordine sono stati processati icblocchi, e quindi conoscere la posizione
nell'immagine dell'i-esimo blocco nel bitstream). A questo punto potresti
agire direttamente sui coefficienti dct (che,ti ricordo, sono approssimatati
e "distorti" a causa della compressione lossy effettuata al punto 4), ma a
meno che tu non voglia moltiplicarli tuti per lo stesso fattore, è
scondigliabile modificarli perchè i risultati sull'antitrasformata non sono
poi così prevedibili... quindi conviene antitrasformare. A questo punto fai
le tue modifiche e ricomprimi...
Ti faccio notare però che, se non ti basta agire sui coefficienti della dct,
sei costretto ad invertire il processo di compressione lossy, che poi dovrai
ripetere, perdendo quindi quasi ogni vantaggio che ha una modifica diretta
sul bitstream di fronte ad una decompressione-->modifica-->compressione. Ho
detto quasi perchè in effetti agendo sul bitstream sei in grado di operare
sul singolo blocco, limitanto ai soli blocchi da modificare l'operazione di
decompressione e ricompressione, e quindi riducendo la perdità di qualità
dell'immagine se i blocchi su cui operare sono realtivamente pochi.
Spero di essere stato chiaro e soprattuto di non aver tirato sfondoni... se
vuoi approfondire la discussione, avanti pure che la cosa è interessante!
Ciao
Giacomo

 chiedere in giro
vedi sopra, ma comunque auguri ancora :) psstt una curiosita' .. cosa
succede alle informazioni embedded in una jpeg, se un utente ignaro apre
l'immagine e la risalva da un qualsiasi applicativo?
Ciao!
--
           .: CoCo :.
   .: 
www.mechano.it
 :.
.: Illustrator Evangelist :) :.

 vuoi approfondire la discussione, avanti pure che la cosa č interessante!
concordo, non che mi servira' a qualcosa di pratico, ma la sete di sapere e'
sempre indice di salute :)


Ciao Giacomo :)
quando inizia cosě č pericoloso... dammi retta Giacomo, lascialo perdere
nella sua contorta follia..... :o)
/vd

 e' sempre indice di salute :)
Allora fatti aventi con dubbi, perplessità e curiosità, oppure aspettiamo di
sentire che ci dice Loky...
Ciao
Giacomo

 nella sua contorta follia..... :o)
Zitto, zitto... forse ho trovato uno che sopporta i miei post kilometrici, e
magari lo fa anche volentieri, e tu vuoi "rovinarmelo"! Altro che, devo
tenermenlo buono...  ;-)

 1) [Cut]
se devo essere onesto... il 40%  di quello che hai scritto è rimasto
"sfocato"... sarà la compressione lossy... O____O
e sempre onestamente penso mi manchino anche le basi informatiche per capire
a pieno quanto hai scritto... tuttavia FORSE una sana incoscienza potrebbe
sostituire le lacune tecniche...
Analizzando le source di alcuni programmini che fanno (in parte) quello che
dovrei fare io ho trovato che le modifiche alla jpg vengono ottenute
manipolando i coefficenti di fourier derivanti dalla prima fase di
compressione... ora questo tradotto in modifica del bitstream che senso
acquisisce? come individuo quei marker?
Inoltre sempre dando un occhiata a dei programmini ho trovato queste
spiegazioni, le riporto perchè inerenti (e perchè magari qualcuno che ne
capisce piu di me di algoritmi di compressione potrà spiegarmi
Operativamente c'aggia fà :-D)
"The trick used by this steganographic implementation is to recognize that
JPEG encoding is
split into lossy and non-lossy stages.  The lossy stages use a
discrete cosine transform and a quantization step to compress the
image data; the non-lossy stage then uses Huffmann coding to further
compress the image data.  As such, we can insert the steganographic
data into the image data between those two steps and not risk
corruption."
(il resto non lo copio al max se interessa lo mando in privato, altrimenti
il post già pensante assume dimensioni titaniche)
Risulta familiare come cosa? in pratica le modifiche (i dati steganografici)
possono e devono (per non corrompere l'immagine) essere inserite solo tra il
passo 4 e quello 5 ovvero dopo la compressione lossy e prima di quella
Huffman
(se non ricordo male la compressione huffman prosegue per blocchi identici
ripetuti... analizza il codice trova elementi ridondanti e li elimina
marcando tuttavia la posizione che verrà ricostruita in fase di
decompressione... quindi non altera le proprietà dell'immagine a differenza
della compressione lossy)
questo significherebbe che le modifiche se devono avvenire devono avvenire
in fase di compressione non sul bstream finale :-/ oppure ho capito male?
quindi dovrei riscrivere un programma di compressione jpg che si freezi tra
il 4 e il 5 inserendo un ciclo di modifica per poi riprendere la
compressione :-/
Lok
(inizio ad aver idea di essermi imbarcato un un progettino beeeeeeeeen al di
la delle mie capacità... in fondo ci sarà un motivo se sono a psicologia e
non ad informatica...) programmatori con le palle quadre che abbian voglia
di partecipare? :-P (so che è OT ma io la butto la :-P)


Vengono perse :-D
Proprio perchè la compressione lossy altera l'immagine... (o meglio altera
il bstream cercando di mantenere invariate le caratteristiche ottiche)
fondamentalmente la steganografia funziona in base al "l'immagine serve solo
a chi sa cosa farci..."
tuttavia c'è l'implementazione di dati su bmp dove eventuali risalvataggi
non alterano la sequenza nascosta (in quando mi pare l'unica forma di
compressione presente sia la Huffman).
sfortunatamente il formato bmp non è usabile :-/
Lok


Tra l'altro...
ero sotto la doccia e pensavo...
dall'ultimo post potrebbe sembrare che ci sia allontanati e di parecchio dal
tema del primo messaggio...
tuttavia (per chiarire il punto) il problema resta.
Come identifico i marker di luminanza (e per esclusione di crominanza) nel
codice bstream ora che abbiamo computato che con tutta probabilità si debba
lavorare sulla fase di compressione lossy prima della Huffman?
(c'è anche da dire che mi dovrei procurare un codice immagine non
"Huffmannizzato" giusto per creare una color map ... e dove lo accatto O_o)
Lok sempre più dubbioso...
dimensione possibile dati embedded [(h * L)/8]*2

 abbian voglia di partecipare? :-P (so che è OT ma io la butto la :-P)
Voglia potrebbe anche essere, tempo invece ho paura proprio di no! Per ora
accontentati del supporto morale...  :-)
Ciao
Giacomo

 dimensione possibile dati embedded [(h * L)/8]*2
Dimensione in cosa? Bytes? Vorrebbe dire 16 bytes per per blocco...
Ciao
Giacomo