THMMY.gr

   /*Here is a brief description of how Theora handles motion vectors:
     Motion vector components are specified to half-pixel accuracy in
      undecimated directions of each plane, and quarter-pixel accuracy in
      decimated directions.
     Integer parts are extracted by dividing (not shifting) by the
      appropriate amount, with truncation towards zero.
     These integer values are used to calculate the first offset.

     If either of the fractional parts are non-zero, then a second offset is
      computed.
     No third or fourth offsets are computed, even if both components have
      non-zero fractional parts.
     The second offset is computed by dividing (not shifting) by the
      appropriate amount, always truncating _away_ from zero.*/

There are always either one or two offsets computed. In the two-offset
case, the two samples are averaged (with truncation towards 0 or
-infinity... all sample values are positive so they're equivalent) to
form the predictor.

Some examples, all in 4:2:0 mode (decimation in both X and Y directions
in the U and V planes):

(-1,-1) in the Y plane produces two offsets: (0,0) and (-1,-1)
(-2,-2) in the Y plane produces one offset: (-1,-1)
(-1,-2) in the Y plane produces two offsets: (0,-1) and (-1,-1)

(1,2) in the U plane produces two offsets: (0,0) and (1,1)
(3,4) in the U plane produces two offsets: (0,1) and (1,1)
(4,4) in the U plane produces one offset: (1,1)

Θέωλ να ρωτήσω κάτι επειδή δυστυχώς έχασα και αρκετά μαθήματα. Για την συνάρτηση Εκτίμησης Κίνησης τι αλγόριθμο πρέπει να χρησιμοποιήσουμε? Υπάρχουν πολλοί αλγόριθμοι αναζήτησης blocks για motion estimation. Ανέφερε στο μάθημα τι θα χρησιμοποιήσουμε? Το πρότυπο του Theora δεν το ξεκαθαρίζει...

Ας επιβαιβεώσει κάποιος που την έκανε την συνάρτηση.

Μήπως υπάρχει κάτι νεότερο πάνω στην συνάρτηση εκτίμησης κίνησης που θα χρησιμοποιήσουμε?

Θέλω να κάνω δύο ερωτήσεις.Μπορούμε να κανουμε δικές μας συναρτήσεις .m που να τις καλουν οι συναρτήσεις της εργασίας ή πρέπει ολόκληρη η υλοποίηση να γίνει μόνο μέσα στις συναρτήσεις που αναφέρονται στην εργασια?Δεν είμαι σίγουρος αλλά στο μάθημα νομίζω οτι αναφέρθηκε οτι όταν καταλήξουμε σε κάποιο motion vector πρέπει να συγκρίνουμε την ενέργεια του motion vector με την ενέργεια του MB για να αποφασίσουμε αν πρέπει να το κωδικοποιήσουμε κι αν δεν κάνω λάθος είπαμε για παράδειγμα μία εικόνα η οποία π.χ. αποτελειται κατα μεγάλα τμήματα από το ίδιο χρωμα.Αν όλα αυτά βγάζουν νόημα σε κάποιον μπορεί να μου τα εξηγήσει κι εμενα??

περισσότερα για το θέμα βρήκα εδώ: www.poynton.com/PDFs/Merging_RGB_and_422.pdf    :D
εξηγεί και γιατί το Y βρίσκεται στην περιοχή 16-235 και όχι 0-255

Εάν δεν το είδατε, ανέβηκε νέα εκφώνηση, και οδηγία για την vlc...

ΕΡΩΤΗΣΗ ΤΩΡΑ....

Στη σελίδα 3 κάτω από τον τύπο που δίνει τους blockCOEFFS λέει..
Οι τιμές που βρίσκονται εκτός του διαστήματος [-580,580] αποκόπτονται..

Αυτό τι σημαίνει?

το       -600 ας πούμε γίνεται -580
και το   600 γίνεται                580???

Στη runLengthFrame λέει ότι η συνάρτηση υλοποιεί μόνο το 1ο βήμα..

"Με βάση τα παραπάνω κατασκευάστε τη συνάρτηση υπολογισμού των συμβόλων μήκους διαδρομής tokens για τους κβαντισμένους συντελεστές DCT, υλοποιώντας το βήμα 1"

Δηλαδή αφού βρούμε τα tokens...

κάνουμε διάταξη με αύξων αριθμό ti ή όχι?
Εγώ κατάλαβα ότι χεστήκαμε για την αναδιάταξη, οπότε δουλεύουμε μόνο με τον πίνακα 7,38..

Κανένας για επιβεβαίωση ή διάψευση?

Γνωρίζει κανείς αν η εργασία μπορεί να γίνει το καλοκαίρι για να δώσει κανείς το μάθημα το Σεπτέμβρη?

Παίδες με την εργασία την παλεύετε?

Εγώ πλέον φοβάμαι ότι ο χρόνος δεν αρκεί με την καμία, όπως και κάτι άλλοι φίλοι..

Έχω ακόμα motest kai vlc..

Vlc πάλι καλά που με φώτισε και την άφησα για το τέλος..αφού άλλαξε η εκφώνηση..
Motest το debugging δεν έχει τέλος..
Μιλάμε για λιώσιμο ωρών..ρεκόρ ως τις 11 (πρωί)..και αφού καλημερίζεις τους πάντες, τους λες και μια καληνύχτα και την πέφτεις :p..

Στον κβαντισμό τα BM,DCSCALE,ACSCALE τα δίνουμε εμείς?Οι πίνακες BM,DCSCALE,ACSCALE που υπάρχουν στο πρότυπο είναι ενδεικτικοί?

Ανάλογα με το ti πρέπει να επιλέξεις αρχικά το HG με το οποίο θα κάνεις κωδικοποίηση. Για DC οι πίνακες του HG είναι 1...16 για AC όλοι οι υπόλοιποι. Αν π.χ θέλεις να κωδικοποιήσεις μια τιμή από τους πίνακες 1...16 ψάχνεις να βρείς σέ όλους αυτούς που έχει μικρότερη αναπαράσταση σε bit και επιλέγεις ανάλογα. Για DC είναι εύκολο για AC όμως τα πράγματα δυσκολεύουν γιατί πρέπει για όλους τους συντελεστές να βρεις τη μικρότερη αναπ.σε bit, σε ποιο index πινάκων δηλαδή και όποιο Index δίνει μικρότερο άθροισμα αναπαράστασης για όλους τους AC συντελεστές να το κρατήσεις. Το  δικό μου πρόγραμμα κάνει γύρω στα 3 δευτερόλεπτα να το υπολογίσει.

Ρε σεις παίδες, τα extra_bits των tokens πού χρησιμοποιούνται; Αφού μετά παίρνουμε μόνο το token_value και το ti, σε τι χρειάζονται τα extra_bits; Επίσης, στην vLC το ti γιατί είναι πίνακας και όχι τιμή; Ακόμη, στα ορίσματα εισόδου της vLC λέει token αλλά μετά λέει tokenValue...

1)πινακες 7.33 και 7.38, για διαφορετικα extra bits οριζονται διαφορετικες παραμετροι των token values.
2)To ti τιμη ειναι για την vlc.
3)token value εννοει

To +4 και το -4 έχουν και τα 2 Token Value 14 αλλά διαφορετικά extra bits. Για διαφορετικά extra bits υπάρχουν πολλές περιπτώσεις με ίδιο token value. Π.χ. + - 3,4,. ή 69 έως 580 ->0000000000 ... 0111111111.

Εννοεις οτι βρισκεις huffman tables(htiL και htiC) διαφορετικους για το καθε μπλοκ;
O αλγοριθμος σελ.95 νομιζω οτι οριζει κοινους πινακες για ολο το frame.

Ναι κι εγώ αυτή την απορία έχω!Γιατί αν πρέπει να το κάνουμε γα κάθε block, δε θα υπάρχει πλήρης αντιστοιχία luma και chroma blocks,σε περίπτωση που έχουμε υποδειγματοληψία χρώματος!Έτσι δε θα μπορούμε να έχουμε htil και htic για κάθε block, εφόσον κάποια luma δε θα έχουν chroma!
Ας με διαφωτίσει κάποιος παρακαλώ!

Βασικα νομιζω οτι το διατυπωνει λαθος εκει που εξηγει την vlc, για αυτο και το μπερδεμα.
Απο τον αλγοριθμο σελ.95 φαινεται ξεκαθαρα οτι τα hti διαβαζονται μονο δυο φορες, για ολο το frame.
Αλλωστε αν εδινε διαφορετικα για καθε μπλοκ, θα πρεπει να εδινε είτε htiL είτε htiC, οχι και τα δυο, αφου καθε μπλοκ ειναι είτε L είτε C. 

Νομίζω οτι έχω κάνει το λάθος της δεκαετίας, αν μπορεί κάποιος να με διαφωτίσει στο εξής...Όταν γράφει NBS θεωρούμε οτι τις πρώτες θέσεις μέχρι 4*NMBS τις παίρνουν τα Luma και τις υπόλοιπες τα Cr blocks και τέλος τα Cb blocks??

Kάτι που θα ήθελα να ρωτησω είναι το εξής:

υπάρχει συναρτηση στο matlab που να μου μετατρέπει ένα string σε πίνακα με την εξής μορφή: 100 σε 1 0 0.
Η συνάρτηση str2num ή str2mat μου το μετατρέπει σε πίνακα με ενα μονο στοιχειο, το 100 και όχι 1,0 και 0. Μήπως ξέρει κανείς να με βοηθήσει?

Για σένα το 100 είναι πίνακας 1x3 με char. Αν Β το όνομα του πίνακά σου, πάρε τον ανάστροφο Β' (3x1), τρέξε την bin2dec
και πάρε τον ανάστροφο του αποτελέσματος. Δηλαδή
bin2dec(B')';

ΚΑΤΑΡΑ!! που θα έλεγε κι ο Cabamaru.Να φανταστώ αυτό ισχύει και για τα MV κλπ ε?δηλαδη πρώτα τα MV των Luma μετά των Cr και μετά των Cb...γιατί εγώ τα έβαλα π.χ. για PF=0 συνεχόμενα των 4 Luma στο καπάκι του 1 Cr μετά 1 Cb και μετά ακολουθούσαν τα άλλα 4 των Luma του επόμενου MB κλπ.Μάλλον αυτό δεν είναι σωστό ε?για το bin εγώ έβρισκα πρώτα τον δεκαδικό και μετά με την εντολή bin = bitget(uint8(dec), 3:-1:1) για 3 bit π.χ. σου έδινε τον πίνακα με κάθε bit ξεχωριστά.

Κατ'αρχάς, για άγνωστο σε μένα λόγο, σύμφωνα με τις ανακοινώσεις στο eTHMMY δεν είναι μονο htil και htic αλλά htil_AC htil_DC htic_AC htic_DC... Αυτό που λες εγώ το έκανα κρατώντας για κάθε token ένα struct με token_value, ti, extra_bits και bi για το block στο οποίο ανήκουν. Μετά, αν bi<=4*NMBS τότε LUMA, αλλιώς CHROMA...

Τα δικά μου προβλήματα είναι τα παρακάτω:
Τα tokens που προκύπτουν από την συγχώνευση των EOB δεν έχουν ούτε ti, ούτε bi.. Με ποιο κριτήριο τα κατατάσουμε? Πώς διαλέγουμε πίνακα; Προς το παρόν έχω πάρει απλά παραδοχές..

H huffmandeco2 απο το eTHMMY σας δουλεύει;

H huffmandeco2 απο το eTHMMY σας δουλεύει;

Ας μου απαντήσει κάποιος στο εξής απλό ερώτημα: Στο tokenStream πώς ακριβώς γίνεται η αλληλουχία των bits; Τα extra_bits μπαίνουν στο stream?