AuthorTopic: I'm making a paint program, so useful tools, ideas and features required please  (Read 156509 times)

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Thanks Dex!  ;D

Yes, I still need to add anti-aliasing to some of the icons. It may mess up the programming based emboss effect though, will have to see!

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
A bit tired today, so I'm struggling for motivation. Still, I've got a few things done..  :)

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
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

Quote
Quote
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.

Quote
Quote
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

Code: [Select]
ABCDEFGHI

Priorities might be marked

Code: [Select]
ABCDEFGHI
032313230
That is, first the two endpoints, then a midpoint between them, then midpoints between those points, then midpoints between those points.


Lastly,
Quote
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 == I
Increasing 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.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Yes, I think illustrations are required! Or at least trying to read this in 5 minutes before I go back to work doesn't work!! ;)

:)

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
I've been working on the color tools. I decided that with some creative editing I could fit the basic tools in underneath the palette, so I now have 3 sliders (RGB), swap/copy, ramp, insert/delete and undo (not working yet). I want to see if I can put in another set of sliders as personally I find being able to use RGB and HSB (or another color space) very useful. It might end up a little cramped, but we will see how well it works (or not). :P

You will be able to change the current color space sliders and view (palette, color space selector) as well.

I take it the main color space selectors are the Hue X Saturation square with a vertical strip for the Brightness to the right and the Hue X Brightness (white to black) with Saturation to the right..?

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
Illustration:

urls for convenience here:
http://en.wikipedia.org/wiki/Scale_space
http://registry.gimp.org/node/11742

This picture should explain most of the 'automatic assignment of priority' and 'limit ramp colors based on threshold' ideas. Quickshade should be obvious if you have ever used grafx2, if not, I can explain that too.

Quote
I take it the main color space selectors are the Hue X Saturation square with a vertical strip for the Brightness to the right and the Hue X Brightness (white to black) with Saturation to the right..?
Not sure what you mean here. Are you talking about appropriate icons to use, or actual interfaces? In either case yes.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Ah! That's much clearer. Sounds very interesting, not sure how users would go about selecting the ramp 'values' though.

I'm trying to improve the GUI interface a bit more as it all started to feel a bit cramped and overwhelming. So, a bit frustrating at the moment trying to make it work and still use the space available in the best way.

Offline Conzeit

  • 0100
  • ***
  • Posts: 1448
  • Karma: +3/-0
  • Camus
    • conzeit
    • View Profile
    • CONZEIT
hope I didnt help send you in one of those cycles of self decrepation  ::) I still want to see how this comes out so sorry if my comments were off for the aproach you had, please keep at it and finish this project!  :y:

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
No, it's just I do get frustrated without teams of graphic designers to call on like Adobe can have! ;)

Anyway: I've tried to make the icons less eye-catching (or burning!), while making the lit/selected icons stand out more. I've also tried to emphasise the panel section headings so that people can see that and then look for the icons below rather than trying to make sense of a mass of icons.

I've been trying different looks for the last few days, but does this look better to everyone?
(EDIT: Updated Image)

« Last Edit: December 30, 2008, 09:03:29 pm by happymonster »

Offline surt

  • 0011
  • **
  • Posts: 570
  • Karma: +0/-0
  • Meat by-product
    • not_surt
    • http://pixeljoint.com/p/2254.htm
    • View Profile
    • Uninhabitant
Looking great :), but I think you've desaturated the icon colours too much now. Previous incarnation was fine for me.

Something to make it better: the colour sliders would be more informative if they were showing the colour gradient of each colour component. Then you get to preview the colour you are goning to select before you select it :o.
For example the gimp colour selector:


Ai's ramp stuff inspired this idea: a palette-tool/colour-select-mode which extracts all possible/practical ramps from the palette within given thresholds. Could also be a handy tool for testing the development of generic palettes.
So the colour select interface would be something along these lines (ptoing's):


Not sure if it's in alrerady on my list or not, but a simple colour consolidation assistance tool would be to sort the palette by reference count. So you can easily find and eradicate that one stray pixel of anomalous colour.

Also working on a mockup recently in GGale these things bugged me:
  • No easy way to toggle all grid functionality on/off (snap and display).
  • I wanted grid snapping when working with line painting, select and paste, but not when using the freehand painting tool (is snap ever of use with freehand painting?) or colour picker, which meant that I had to constantly toggle snap on/off. A respect-snap option per tool would be nice for this.
  • Having to box select each tile to copy, even aided by grid snapping, was annoyingly inefficient. The simplest of mockup tools would be two hot-key invoked commands: copy-grid-box-under-cursor, paste-to-grid-box-under-cursor. Maybe also with a size option to work with multiple tile features.

On a related note: Pixe needs a grid rendering option to draw the grid lines on the pixel boundary rather than on the pixel.
« Last Edit: December 30, 2008, 11:00:03 pm by surt »