Γενικες αποριες πανω στον DCT

[Thmmy.gr portal]

  Thmmy.gr portal
   Forum
   Downloads
   Ενεργ. Λογαριασμού
   Επικοινωνία
  
  Χρήσιμα links
   Σελίδα τμήματος
   Βιβλιοθήκη Τμήματος
   Elearning
   Φοιτητικά fora
   Πρόγραμμα Λέσχης
   Πρακτική Άσκηση
   Ηλεκτρονική Εξυπηρέτηση Φοιτητών
   Διανομή Συγγραμμάτων
   Ψηφιακό Καταθετήριο Διπλωματικών
   Πληροφορίες Καθηγητών
   Instagram @thmmy.gr
   mTHMMY
  
  Φοιτητικές Ομάδες
   ACM
   Aristurtle
   ART
   ASAT
   BEAM
   BEST Thessaloniki
   EESTEC LC Thessaloniki
   EΜΒ Auth
   IAESTE Thessaloniki
   IEEE φοιτητικό παράρτημα ΑΠΘ
   SpaceDot
   VROOM
   Panther
  

THMMY.gr Web

Helios_MultiScribbles2SMF Default ThemeSMFone_Blue

[Ανεβάζετε τα θέματα των εξετάσεων στον τομέα Downloads]

Είσαι πρωτοετής;... Καλώς ήρθες! Μπορείς να βρεις πληροφορίες εδώ. Βοήθεια για τους καινούργιους μέσω χάρτη.

Κατεβάστε εδώ το Android Application για εύκολη πρόσβαση στο forum.

Ανεβάζετε τα θέματα των εξετάσεων στον τομέα Downloads με προσοχή στα ονόματα των αρχείων!

[height=400]

  Όταν ανεβάζουμε φωτογραφίες στις Ανακοινώσεις και Έκτακτα νέα, βάζουμε τη μεγαλύτερη πλευρά 400 (width=400 ή height=400 ). π.χ. [img height=400 (κλείνει η αγκύλη) 

[Axel]

Εστω οτι εχουμε μια εικονα στην οποια θελουμε να εφαρμοσουμε DCT και στη συνεχεια να την επαναδημιουργησουμε χρησιμοποιωντας ενα ποσοστο μονο των DCT συντελεστων.

Ως γνωστο οι DCT coefficients προκυπτουν χωριζοντας την εικονα σε περιοχες 8x8 και εφαρμοζοντας στη συνεχεια DCT σε καθε μπλοκ. Ετσι προκυπτουν 64 συντελεστες για καθε μπλοκ.

Κατ'αρχην ειναι απαραιτητο να εφαρμοσουμε κβαντιση στους συντελεστες αυτους? Απαιραιτητο απο την αποψη οτι μειωνει πολυ τον αριθμο των bits που θα μεταδοθουν. Στην περιπτωση αυτη θα αυξανεται και ο αριθμος των υπολογισμων που πρεπει να γινουν και δεν ξερω κατα ποσο συμφερει αυτο οταν κανεις live streaming εικονων.

Γενικα οταν λεμε οτι θα επαναδημιουργησουμε την εικονα με ενα ποσοστο των DCT συντελεστων, αυτους τους συντελεστες απο που θα τους κοψουμε?

Και κατι ακομα, καταλαβαινει κανεις για ποιο λογο κανει οτι κανει ο τυπος στα 3 και 4? Ο κωδικας δε μου δουλευει σωστα ουτως η αλλως, πεταει ενα error "ByteComponentRasters must have byte DataBuffers" που οφειλεται στο 5. Ειναι σε Java με χρηση του JAI για την ιστορια.

Code:

1) do the DCT
// 'source' is given as a PlanarImage
ParameterBlock pb = (new ParameterBlock()).addSource(source);
PlanarImage image = JAI.create("dct", pb);

2) copy the pixels into an array
double[] dctData = image.getData().getPixels(0, 0, width, height, (double[]) null);

3) divide all Coefficients by 256.0
for (int i = 0; i < dctData.length; i++) {
dctData[i] = dctData[i]/256.0;
}

4) do a permuation of the color-bands
double[] dctmod = new double[dctData.length];
for (int i = 0; i < dctData.length; i=i+3){
dctmod[i+0] = dctData[i+2];
dctmod[i+1] = dctData[i+1];
dctmod[i+2] = dctData[i+0];
}

5) create a BufferedImage out of the coefficients
DataBufferDouble dbuf = new DataBufferDouble(dctmod, dctmod.length);
WritableRaster raster = Raster.createWritableRaster(image.getSampleModel(), dbuf, null);
BufferedImage bi = new BufferedImage(image.getColorModel(), raster, false, null);

6) perform IDCT
pb = (new ParameterBlock()).addSource(bi);
image = JAI.create("idct", pb);

[chggr005]

Κατ'αρχην ειναι απαραιτητο να εφαρμοσουμε κβαντιση στους συντελεστες αυτους? Απαιραιτητο απο την αποψη οτι μειωνει πολυ τον αριθμο των bits που θα μεταδοθουν. Στην περιπτωση αυτη θα αυξανεται και ο αριθμος των υπολογισμων που πρεπει να γινουν και δεν ξερω κατα ποσο συμφερει αυτο οταν κανεις live streaming εικονων.

Βασικά δεν αυξάνει και τόσο δραματικά τους υπολογισμούς...
Και ούτως ή άλλως, το live streaming αυτό ακριβώς προσπαθεί να κάνει: Να μεταδώσει λιγότερα bits για να κάνει οικονομία στο bandwidth με αποτέλεσμα φυσικά να κωδικοποιεί πολύ βαριά το βίντεο και να χρειάζεται υπολογίσιμη επεξεργαστική ισχύ για την αποκωδικοποίησή του. Είναι ένα trade-off μεταξύ bandwidth και επεξεργαστικής ισχύος που απαιτείται. Εάν έχεις μεγάλο bandwidth, τα μεταδίδεις όπως είναι και δεν δαπανάς επεξεργαστική ισχύ για να τα προβάλεις. Εάν όμως έχεις μικρό bandwidth, τότε θα πρέπει να μειώσεις την ποσότητα δεδομένων που στέλνεις. Γι' αυτό και κωδικοποιείς το σήμα. Η αποκωδικοποίηση απαιτεί μεγάλη επεξεργαστική ισχύ, αλλά έχεις γλιτώσει από bandwidth.

Γενικα οταν λεμε οτι θα επαναδημιουργησουμε την εικονα με ενα ποσοστο των DCT συντελεστων, αυτους τους συντελεστες απο που θα τους κοψουμε?

Αρχικά θα πρέπει να κρατήσεις μέρος των συντελεστών που βρίσκονται πάνω αριστερά. Αυτό το μέρος είναι ουσιαστικά ο DC όρος και οι χαμηλές συχνότητες απ' ότι κατάλαβα. Η περισσότερη πληροφορία βρίσκεται συγκεντρωμένη σε αυτούς του όρους, ενώ αυτοί που βρίσκονται κάτω δεξιά δεν παίζουν και τόσο μεγάλο ρόλο στην προβολή της εικόνας.

[JAs0n-X]

Θα συμφωνησω με τον Χρηστο.

Το bandwidth του Data Bus μας του επεξεργαστη μας κλπ ειναι κατα τι μεγαλυτερο απο το bandwidth της γραμμης μας.
Εξαλλου οι σημερινοι υπολογσιτες εκτελουν megaflops !
Επισης μην βλεπεις τους δικους μας κωδικες που θελουν 10 ωρες γιατι ειναι ξερω γω στο MATLAB και εχουν 1002 προγραμματιστικους πλεονασμους. Πιστευω σιγουρα μπορει να γραφτει πολυ καλυτερος κωδικας.

Οσο για το DCT με καλυψε ο Χρηστος. Ο DCT περιλαμβανει το συχνοτικο περιεχομενο της εικονας μας με την πιο χαμηλη συχνοτητα πανω αριστερα και την πιο υψηλη κατω δεξια.
Κοβοντας τους ορους υψηλων συχνοτητων δεν επηρεαζουμε πολυ την εικονα αν σκεφτεις οτι το ματι δεν τις πιανει και οτι παιρνουμε και μικρα μπλοκ που σημαινει οτι αν εχουμε μια μεγαλη μεταβαση φωτεινοτητας η οποια φυσικα θα χαθει αυτο θα γινει σε ενα μικρο μπλοκ.

[Axel]

Μολις καταλαβα οτι το σκεφτομουν με λαθος τροπο οταν ρωτουσα απο που να κοψω τους συντελεστες. Σκεφτομουν γενικα ολοκληρη την εικονα και οχι τα 8x8 μπλοκς. Επομενως οταν θελουμε να επαναδημιουργησουμε την εικονα με το 75% των coefficients παιρνουμε απο το καθε μπλοκ τους πρωτους 0.75x8x8 ορους και πανω σε αυτους εφαρμοζουμε κβαντισμο και Huffman, στη συνεχεια τους μεταδιδουμε και κανουμε την αντιστροφη διαδικασια.

Καπου θυμαμαι απο τα ΨΕΕ οτι οι οροι πρεπει να ειναι αναμεσα σε 0-255 και ισως γι'αυτο στον παραπανω κωδικα γινεται η διαιρεση με το 256. Δεν ξερω κατα ποσο παιζει ρολο ομως το ποσες bands εχουμε. Σε μια εργασια ο Μαδεμλης μας ειχε δωσει εικονα της Lenna η οποια ειχε και τα 3 καναλια ιδια, χμ.. Εξακολουθω να μην καταλαβαινω ομως τι κανει στο 4) ο παραπανω κωδικας.

Οι ετοιμες βιβλιοθηκες της java παντως ειναι πολυ πιο γρηγορες απο το δικο μου κωδικα (αν και δεν εχω δοκιμασει να τον κανω optimize η να εφαρμοσω καποιο FDCT). Το θεμα ειναι οτι δεν καταλαβαινω,για την ωρα, προγραμματιστικα πως θα επαναδημιουργησω την εικονα, πως θα εφαρμοσω δλδ IDCT ενω μου λειπουν καποια coefficients. Χμ, ισως να βαλω μετα μηδενικα στη θεση τους αφου μηδενικα υποτιθεται οτι ειναι?

Thanks και στους δυο.

[JAs0n-X]

Ναι εννοειται μηδενικα θα βαλεις εκει!! Αυτο ειναι φυσικα και το νοημα του lossy.

απο εικονα <-> DCT δεν χανεις πληροφορια.

Η πληροφορια χανεται αφαιρώντας στοιχεια του DCT και κβαντιζοντας αυτα που δεν αφαιρουνται.

[chggr005]

Καπου θυμαμαι απο τα ΨΕΕ οτι οι οροι πρεπει να ειναι αναμεσα σε 0-255 και ισως γι'αυτο στον παραπανω κωδικα γινεται η διαιρεση με το 256.

Πάντως οι όροι που προκύπτουν από τον DCT πάνω στην εικόνα δεν περιορίζονται στο 0-255, αλλά παίρνουν και μεγαλύτερες (θετικές) τιμές...

[Axel]

Η βιβλιοθηκη της Java για τον DCT ειναι οτι να'ναι. Θελει οι διαστασεις της εικονας να ειναι δυναμεις του 2. Σε διαφορετικη περιπτωση φροντιζει η ιδια να της κανει να ειναι τετοιες... Οι τιμες των συντελεστων αφου τους διαιρεσω παντως με το 256 βλεπω πως βρισκονται αναμεσα στα -128,128. Δεν εχω προχειρο και το matlab για να τσεκαρω τις εργασιες στα ΨΕΕ να δω τι γινοταν εκει γμτ. Επισης ακομα δεν μπορω να καταλαβω αν ο dct της java εφαρμοζεται σε 8x8 μπλοκς. Βλεπω οτι για εικονα 320x240 οι μεγαλες τιμες ειναι ανα 320 ορους...

[Netgull]

Οι δυνάμεις του 2 που θέλει υποθέτω ότι έχουν να κάνουν με το πως υλοποιεί τον υπολογισμό του, κάτι αντίστοιχο με το συμπλήρωμα με μηδενικά μιας σειράς για να εφαρμοστεί ο FFT. Για τα υπόλοιπα πραγματικά δεν έχω ιδέα, αλλά από ένα γενικό ψάξιμο σε wikipedia φαίνεται ότι το σε τι μπλόκ εφαρμόζεται και τι τιμές θα έχει εξαρτάται από την ψηφιακή αναπαράσταση της εικόνας (που εντάξει αυτό είναι ψιλοστάνταρ 8 bits/χρώμα) και το πρότυπο συμπίεσης.

[Axel]

Λοιπον εστω οτι εφαρμοζουμε στους συντελεστες DCT zig zag και στη συνεχεια κωδικοποιηση RLE. Ως εδω ολα καλα. Στην περιπτωση ομως που θελουμε να επαναδημιουργησουμε την εικονα με ενα ποσοστο των συντελεστων DCT κοβουμε τους τελευταιους συμφωνα με τη σειρα που εχει στο zig zag. Το θεμα ειναι αν αυτο το κοψιμο πρεπει να γινει πριν η μετα τον υπολογισμο των συντελεστων DCT.

Το λογικο ειναι να γινει πριν για να μειωθουν και οι υπολογισμοι οσο το δυνατον περισσοτερο. Το πιο απλο προγραμματιστικα ειναι να γινει το κοψιμο την ωρα που παραγονται τα συμβολα του RLE.

Ξερει ομως κανεις τι εφαρμοζεται στα σιγουρα γιατι δεν μπορω να βρω κατι?

[mademlis]

Το θεμα ειναι αν αυτο το κοψιμο πρεπει να γινει πριν η μετα τον υπολογισμο των συντελεστων DCT.

Δεν κατάλαβα τι θέλεις να πείς. Έχω το 8x8 block. Κάνω DCT, παίρνω zig-zag, κόβω πχ τα 10 τελευταία. Ποιο το πρόβλημα ?
Βέβαια, σε κάθε περίπτωση, καλό είναι να δείς αυτό με τα πρότυπα που αναφέρω πιο κάτω.

Επίσης όταν λες "Τι εφαρμόζεται" τι εννοείς ?
Γενικά ? κάπου συγκεκριμένα ?
Βασικά, καλό θα ήταν να μας πείς τι θέλεις να κάνεις.
Αν θέλεις να είσαι συμβατός με κάποιο πρότυπο, τότε πρέπει να ανατρέξεις στα specs του συγκεκριμένου προτύπου.
Θεωρητικά η δουλεία είναι
1) DCT, για καλύτερο διαχωρισμό του σήματος στις συχνότητες.
2) Κατάλληλος Κβαντισμός,
3) Κωδικοποιίηση εντροπίας [RLE + Huffman]
Και από όσο καταλαβαίνω την έχεις. Τα υπόλοιπα είναι θέμα συμβάσεων που υπάρχουν στα specs του κάθε προτύπου.

Πάντως, από ότι κατάλαβα έχεις μπλέξει σε προγραμμματιστικές χαζομάρες.
Ο FDCT στηρίζεται στον FFT, και συνεπώς, δουλεύει σε 2^Νx2^M εικόνες. Για αυτό εξάλλου και τον εφαρμόζουμε σε blocks 4x4 k 8x8.

[Axel]

Κοιτα κατ'αρχην τι θελω να κανω.

Εχω μια usb καμερα απο την οποια τραβαω φωτογραφιες ανα συγκεκριμενο χρονικο διαστημα. Τις περναω απο dct και στη συνεχεια zig zag και RLE (huffman δεν εχω υλοποιησει). Αυτο το κομματι ειναι ο server. Τα δεδομενα αποστελονται μεσω UDP σε εναν client ο οποιος κανει την αντιστροφη διαδικασια και προβαλει τις εικονες σαν video.

Τωρα στην περιπτωση που υπαρχει ελλειψη bandwidth για να διατηρηθει το framerate θελω να μειωσω τους dct συντελεστες που χρησιμοποιουνται. Ο ενας τροπος που σκεφτομαι ειναι αυτος που λες και εσυ παρακατω.

Δεν κατάλαβα τι θέλεις να πείς. Έχω το 8x8 block. Κάνω DCT, παίρνω zig-zag, κόβω πχ τα 10 τελευταία. Ποιο το πρόβλημα ?

Ετσι οπως το καταλαβαινω αν κανω αυτο που λες το μονο που μειωνεται ειναι ο αριθμος των bytes που αποστελονται. Ενω αν υπολογιζα μονο ενα ποσοστο των συντελεστων dct θα εχω συγχρονως και μειωση του χρονου που γινονται οι υπολογισμοι. Βεβαια δεν ξερω κατα ποσο αυτο εφαρμοζεται στη μεταδοση streaming εικονων.

Ουσιαστικα αυτο που κανω ειναι MJPEG.

Το JAI της java που αναφερω παραπανω το παρατησα μιας και ειχε διαφορα περιεργα και εγραψα δικο μου source τελικα.

Ευχαριστω για τη βοηθεια. Θα το κανω ετσι οπως το βλεπω τελικα.

Έχω το 8x8 block. Κάνω DCT, παίρνω zig-zag, κόβω πχ τα 10 τελευταία