Hello, I've just been
researching recursive gray-painting.
This inspired several ideas that would be useful and very very appreciated for large pixel art (>48x48). They don't translate exactly from Lojban so I'll also include the text of the ideas in Lojban
girska skavai .i skari jvinu cu vasru da'a skari po skavai semau ca skavai po sampli gusni cu frili sampli cu cu rufsu xutla cu jbinu.
Per-color priority for palette colors.
Which colors are visible in the palette view depends on a threshold; colors with priority > threshold are not displayed.
This is useful in conjunction with hotkeys to move throughout the palette. In grafx2 and Dpaint, I found that these hotkeys were less useful than they could be because they moved through the entire color set, whereas as I'm starting out, I want only say 2 or 3 of the colors in the ramp to lay down the basic shading, and to then refine that into 5 color shading, and then to refine that into 8 color shading.
'girska' translates literally as 'color group' so it means both palettes and ramps.
skavai zmiku .i jmina skavai po pagbu girska cu zmiku
Automatic assigning of color priority for color ramps.
My current idea of this is like a plasma fill.
Say you have a ramp consisting of colors
ABCDEFGHI
Priorities might be marked
ABCDEFGHI
032313230
That is, first the two endpoints, then a midpoint between them, then midpoints between those points, then midpoints between those points.
Lastly,
paint mode like 'quickshade' from Grafx2, except using the color-priority thresholding.
This mode would allow you to gradually refine your shading in an easily controlled way, much better than the 'step adjustment' mechanism present in Grafx2.
(as in Grafx2, would only affect the colors between pen 0 color and pen 1 color aka FGcolor and BGcolor)
leftclick == shade colors in the range [pen 0 color...pen 1 color] towards pen 0 color, rightclick == shade colors in the range [pen 0 color..pen 1 color] towards pen 1 color.
Shading effect would be calculated like this example:
Take the 'ABCDEFGHI' example above, say the threshold is set at 1,
so that the ramp is shown as colors AEI. And pen 0 color is A, pen 1 color is I,
Left-clicking on pixels of colors FGHI will subtract 4 from their index within the ramp -- eg.
I -> E, H -> D, G -> C, F -> B.4, because this is the distance between I and E.
Left-clicking on pixels of colors BCDE will subtract 4 from their index within the ramp -- eg.
E -> A, D -> A (CLIPPED), C -> A (CLIPPED), B -> A (CLIPPED) .
4, because this is the distance between E and A.
Left-clicking on pixels of color A will do nothing, since it is at one end of the ramp.
Rightclicking works similarly but opposite :
in this case,
A -> E, B -> F, C-> G, D -> H, E -> I, F -> I (CLIPPED), G -> I (CLIPPED), H -> I (CLIPPED), I == IIncreasing the threshold to 2, distance between all visible ramp colors would equal 2. Then
Leftclicking would shade
I -> G, H -> F, G-> E, F -> D, E -> C, -> D -> B, C -> A, B -> A (CLIPPED), A == A,and Rightclicking would shade
A -> C, B -> D, C -> E, D -> F, E -> G, F ->H , G->I, H -> I (CLIPPED), I == I.The increment used in these shading is dependent on the segment a color is in. When leftclicking, a segment includes a right endpoint and all colors between it and the left endpoint (and excludes the left endpoint)
. When rightclicking, a segment includes a left endpoint and all colors between it and the right endpoint (and excludes the right endpoint).
In either case, the increment is calculated as the distance between the left and right endpoints of the segment a color is in.
(hence, different segments may have different increments. This accounts for the fact that color ramps are usually not a linear blend between two colors, but may have disproportionately more bright colors, more dark colors, or more mid colors)
I think it needs some illustrative examples. I also think it could work even better than this description currently sketches it as.