Timeline for Tiled Image Palettization Algorithm?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2019 at 11:06 | comment | added | Justin Olbrantz | Actually, that might not be true since we're just using the counts of each palette entry, and the actual colors for each subpalette could be recomputed once similar blocks are found. | |
| Feb 28, 2019 at 10:57 | comment | added | Justin Olbrantz | That's definitely a way of imposing a definite order. Though the fact that the distance between two points in the x-D index vector space will not necessarily be proportionate to the actual different between the colors for the two subpalettes means you could potentially end up with a centroid that has wildly different colors that the points away from the centroid. | |
| Feb 28, 2019 at 10:37 | comment | added | Simon F | That's why I thought assigning the count to the "tile pixel" would get around the ordering problem. Of course, having lots of "similar" colours in the original palette might work against this hence the uncertainty on the initial choice for M | |
| Feb 28, 2019 at 10:24 | comment | added | Justin Olbrantz | If I understand the proposal, this sounds like something I was considering initially, but I wasn't sure how to do VQ on aggregate vectors as the aggregate vectors could have many permutations of the same set of colors (which would prevent finding the proper centroids). E.g. for two color aggregates (11, 21, 31, 41, 51, 61) would be the same as (41, 51, 61, 11, 21, 31). | |
| Feb 28, 2019 at 9:53 | history | edited | Simon F | CC BY-SA 4.0 |
added 181 characters in body
|
| Feb 28, 2019 at 9:47 | history | answered | Simon F | CC BY-SA 4.0 |