Sto giocando un po 'con l'elaborazione delle immagini e ho deciso di leggere su come la quantizzazione del colore ha funzionato e dopo un po' di lettura ho trovato Algoritmo di modifica del taglio mediano modificato .
Ho letto il codice dell'applicazione C nella libreria Leptonica e ho trovato qualcosa che pensavo fosse un po 'strano.
Ora voglio sottolineare che sono lontano da un esperto in questo settore, non sono un matematico, quindi prevedo che tutto questo mi viene in mente non comprendendo tutto e non che l'implementazione del l'algoritmo è del tutto sbagliato.
L'algoritmo afferma che vbox dovrebbe essere diviso lungo l'asse più lento e che dovrebbe essere diviso usando la seguente logica
The largest axis is divided by locating the bin with the median pixel (by population), selecting the longer side, and dividing in the center of that side. We could have simply put the bin with the median pixel in the shorter side, but in the early stages of subdivision, this tends to put low density clusters (that are not considered in the subdivision) in the same vbox as part of a high density cluster that will outvote it in median vbox color, even with future median-based subdivisions. The algorithm used here is particularly important in early subdivisions, and 3is useful for giving visible but low population color clusters their own vbox. This has little effect on the subdivision of high density clusters, which ultimately will have roughly equal population in their vboxes.
Per il gusto dell'argomento, supponiamo di avere una vbox che siamo in fase di suddivisione e che l'asse rosso è il più grande. Nell'algoritmo di Leptonica, alla riga 01297, il codice sembra eseguire il seguente
- Fai scorrere tutte le possibili variazioni di verde e blu del colore rosso
- Per ogni iterazione si aggiunge al numero totale di pixel (popolazione) che si trova lungo l'asse rosso
- Per ogni colore rosso riassume la popolazione del rosso corrente e dei precedenti, quindi memorizza un valore accumulato, per ogni rosso
nota: quando dico "rosso" intendo ogni punto lungo l'asse coperto dall'iterazione, il colore effettivo potrebbe non essere rosso ma contenere una certa quantità di rosso
Quindi, per fare un esempio, supponiamo di avere 9 "bidoni" lungo l'asse rosso e che abbiano le seguenti popolazioni
4 8 20 16 1 9 12 8 8
Dopo l'iterazione di tutti i bin rossi, la matrice partialsum conterrà il seguente conteggio per i bin menzionati sopra
4 12 32 48 49 58 70 78 86
E totale avrebbe un valore di 86
Una volta fatto, è il momento di eseguire l'effettivo taglio mediano e per l'asse rosso questo viene eseguito sulla riga 01346
itera sui contenitori e controlla la somma accumulata. E qui c'è la parte che mi tira fuori dalla descrizione dell'algoritmo. Cerca il primo contenitore che ha un valore maggiore di totale / 2
Non totale / 2 significa che sta cercando un bin che ha un valore maggiore del valore medio e non il mediano ? La mediana per i suddetti raccoglitori sarebbe 49
L'uso di 43 o 49 potrebbe avere un enorme impatto sul modo in cui le caselle vengono divise, anche se l'algoritmo procede spostandosi al centro del più grande lato di dove il valore corrispondente era ..
Un'altra cosa che mi imbarazza un po 'è che la carta ha specificato che il bin con il valore mediano dovrebbe essere localizzato, ma non menziona come procedere se c'è un numero pari di bidoni .. la mediana sarebbe il risultato di (a + b) / 2 e non è garantito che nessuno dei bin contenga quel numero di abitanti. Quindi questo è ciò che mi rende cosa che ci sono alcune approssimazioni in corso che sono trascurabili a causa del modo in cui la divisione prende effettivamente parte al centro del lato più grande del contenitore selezionato.
Scusa se è stato un po 'prolisso, ma volevo essere il più bravo possibile perché mi ha fatto impazzire per un paio di giorni;)