64 Values
Every pixel set becomes 7 values (size, inertia, mu (3 components), nu (3 components))
Every image has 4 pixel sets (total + 3 clusters)
All this is done in both spaces
Minus the duplicated size of the total set
Plus name
2 * 4 * 8 - 1 + 1 = 64 values to each image
Cleanup
- Properly refer to inertia and mu in ingest instead of XYZ
- Same fixes in nearest.js, make it easier to actually find the values needed
New values and logic
- Add cluster inertias
- Add nu metric/pointing vector to ingest
- Add cluster nus
- Record (non-outline) image size and raw cluster sizes instead of just percents
- Reorganize output, modify nearest.js reader to match
- Change logic of front-end
- Now the process is, select cluster > metric > scale > sort
- Clusters: Total, Cluster
- Cluster choice is according to a separately-specifiable metric + scale + sort, compared per pokemon
- Metrics:
- RMS: sqrt(I - 2q . mu + q . q)
- Mean of Angle: nu . q_hat
- Angle of Mean: mu_hat . q_hat
- Hue of Mean: mu_perp . q_perp
- Euclidean to Mean: sqrt((mu - q) . (mu - q))
- Chebyshev to Mean: max(abs(c) for c in (mu - q))
- Inertia: I
- Size: N
- Scales: None (1), Proportion (N_k / N), Inverse Proportion (N / N_k)
- hidden when not using clusters
- Sort: max vs min
- Now each tile has
- Name
- For each portion (whole + 3 clusters)
- Mu (hex + vec, also sets tile color)
- Inertia (I)
- Size (N) (render as proportion for clusters)
- Nu
- RMS (sigma)
- Whole angle (Theta)
- Mean angle (theta)
- Hue angle (phi)
- E dist of mean (delta)
- C dist of mean (C)
- 4 * 10 = 40 results
- Probably hide the metric results and focus on just mu and maybe sigma, but provide dropdowns
DB schema
jab rgb
total cluster 1 cluster 2 cluster 3 total cluster 1 cluster 2 cluster 3
name size I *mu *nu size I *mu *nu size I *mu *nu size I *mu *nu I *mu *nu size I *mu *nu size I *mu *nu size I *mu *nu