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

Offline Larwick

  • 0011
  • **
  • Posts: 738
  • Karma: +1/-0
    • Larwick
    • http://www.pixeljoint.com/p/3794.htm
    • View Profile
    • Artstation
I think a color replacer with different brush sizes would be useful. I GGale I can't figure out how to get a color replacer larger then one pixel. Very annoying sometimes.

On this topic, i wondered whether it'd be possible to have a colour replacement tool that simply replaces one colour on the entire image with another of your choice. AnimationShop 3 has this and i find it extremely useful.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
I can't think of a technical reason why that can't be done. The hardest thing would probably be organising where the tool went!

BTW: I'm trying to get an ALPHA demo version out later today.. :)

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
OK!

I've built a v0.2 ALPHA version. Please can you test it and see if it works on your system? A PC and Windows is required at the moment!
I've greyed out the tools and tool options which don't work at the moment.

PLEASE, PLEASE, PLEASE bear in mind this is an early ALPHA version and a lot is still missing!!  ;D

Things to bear in mind:
Image->Load (Select a 256 colour uncompressed BMP)
Image->Save (Will save using the previously loaded image filename, or use 'untitled.bmp')
Control held down activiates pen dropper mode
Shift held down makes drawing with the left mouse button use pen 3 and the right mouse button use pen 4
Mouse wheel when over the canvas will zoom in / out. (You can also alter the slider in the Zoom options)
Holding down the mouse middle button (mouse wheel button on some mice) and moving around will scroll, as will the arrow keys

Please let me know if it works ok for you! Remember it's in an early state! :)
http://www.funkemunke.com/Pixe_Alpha_V0_2.zip

Offline flaber

  • 0010
  • *
  • Posts: 312
  • Karma: +0/-0
  • Captain.
    • View Profile
ya, all i meant was to build an animated gif file from loaded frames.
but i saw on the alpha version i tried you have a button for animation. So im guessing you have that figured out.

Color system is alittle bit different, and would take time for me to get used to. The HSV. but thats more me than you. It still the same idea as the HSL im used to. so thats not bad.

The only other thing - is I dont like it opening full screen.
Id still like to be able to see my task bar, and switch between programs easily without closing it with escape button.
otherwise looking good.

Offline happymonster

  • 0010
  • *
  • Posts: 455
  • Karma: +0/-0
    • View Profile
Full screen? Hmm.. it should be windowed!  ???
Can you try pressing F7 and see if it switches between a windowed/fullscreen mode?
« Last Edit: December 14, 2008, 07:03:40 pm by happymonster »

Offline TrevoriuS

  • 0011
  • **
  • Posts: 550
  • Karma: +1/-0
  • Pixels... everywhere!!
    • View Profile
-does switch, but at startup it's fullscreen. also, it stays on top when focus is lost. get rid of that! :P
-in for example the BOX options: you have options for the drawing result, and the drawing method, these are 2 sections, which may need a hint for them being 2 separate options, as that was unclear now
-somehow grid opens only with right mouse button
-grid fit doesnt seem to work, or rather, i dont know what it should do, but it has no effect as far as I could see
« Last Edit: December 14, 2008, 08:07:25 pm by TrevoriuS »

Offline Jad

  • 0100
  • ***
  • Posts: 1048
  • Karma: +0/-0
    • View Profile
Just wanted to pop in and say (omg wtf a mod ass-patting? well, if any, that's gonna be jad) that it's looking smooth and nice O:! I'm gonna try it out some more and give feedback later! Anyways, felt a lot nicer than what the screenshots implied, good stuff!
' _ '

Offline Conzeit

  • 0100
  • ***
  • Posts: 1448
  • Karma: +3/-0
  • Camus
    • conzeit
    • View Profile
    • CONZEIT
the whole HUD feels just WAAAAY WAAAY too big, way excessive for the few tools you have. Funny how being a pixelartist you'd go for bigger fonts and bigger icons instead of smaller...keep em regular size...and give us an option to disable the descriptions..eventually we should know everything by icon. BTW what's with the 2bit icons? I think that's hurting your ability do describe the tool easily a bit...you have to rely on thicker/thinner full/dotted line to convery things you could easily convey otherwise trough contrast in colors.

The HUD should always take as least space as posible and draw as little attention as posible...kinda feels like you're letting the artist get in the way of doing a purely functional HUD.

I dont see the necessity of having the tool options visible at all times...I'd rather to summon it when I need it like in most programs. That space would be better occupied by a layer menu or a preview.
I also found it confusing in tools like elipse or box where  there was more than one thing to chose from. It wasnt inmediately obvious that there was more than one thing to configure, I think it needs some separator, or a clearer contrast between the chosen option and the unchosen ones.

Actually, there's no reason whatsoever why it should take so much space. You could simply have 3 buttons. FILLED, BOX and STRETCH. It would take up half the space.

You can deactivate FILLED and it turns into OUTLINED, you deactivate STRETCH and it turns into EXPAND,  you deactivate BOX and it turns into SQUARE (BTW I'd rather have fixed ratio vs free ratio as in photoshop than box/square)...then if you have more than two options make it a dropdown menu.
The pallete also doesnt need to be nearly that big...look at Ggale. I also dont understand why I cant modify the colors in my pallete easily. I hope that's something you just havent added yet.

What's with having four chosen colors? in practice they seemed to work just like regular foregrond/background colors, expect two extra colors were chosen...I think I just didnt understand that feature at all.

I dont understand why all the functions like save/load are stuck at the same "tools" toolbar...I guess it's something I can get used to but it's kinda weird...is there any posibility at all that eventually you'd let us make our own tool boxes and place them around however we want (like Ggale) and switch icons between them however we want (like firefox?)

Sorry for being a nitpick..heh. Everything sems to be working fine...I'm just judging this as if it were a replacement for my current be different for what seems fullfill no purpose in my eyes

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
Quote from: happymonster
it won't be open source. But will probably be free.
I admit I am puzzled by your continued reluctance to utilize the tremendous people-resources that opensource makes available to you. Even releasing under a restrictive license (eg. allows the reader to view and modify the source, but not to release changed versions themselves) would tremendously benefit your software simply because every line of code in your (ambitious!) program is a potential bug, and 'any bug is shallow given enough eyes'.

That's all though; I'm not asking for an explanation, I just felt that needed to be said.

Development suggestion: Use version management if you aren't already! Distributed version control systems such as
Git (http://en.wikipedia.org/wiki/Git_(software) ) allow you to do virtually all of their operations without any need to be online, and when you mess up badly, they save you. Especially with something like Git, where day-to-day operation
is as easy as falling off a log.

Suggestion: Relative color selector rather than slider-based
(in the style of what I posted @ http://www.wayofthepixel.net/pixelation/index.php?topic=922.msg80524#msg80524). In combination with number-entry fields for when you truly need to get some exact specific color, this should allow sliders to become irrelevant.

Suggestion: Programmatic interface (like a scripting commandline). Because GUIs are severely un-expressive (they trade expressiveness for obviousness). This is the most realistic way to avoid having a bloated GUI imo -- allow your GUI to only show the commonly used options, and allow the user to express complex combination of commands and options using a command line. Python, Ruby, or Lua are all pretty painless in this role (with Python being the more powerful and Lua being the simplest to write bindings for)
EDIT: I see you nixed this in the 'ideas.xls', saying 'see #5'. But IMO this has very little to do with macro recording. Macro recording  == a hell of a lot of work. Language interface == a bit of work, most of which can readily be automated via SWIG[1]; basically just wrapping the functions and data that you already have in a sensible way.
You can see this demonstrated in eg. the fact that GIMP has had a scripting interface for AGES, but still doesn't have macro recording.

[1] http://en.wikipedia.org/wiki/SWIG

Quote from: happymonster
Proper LAB support needs more than 8-bit's per colour channel which will prove a problem. What about YUV / YCrCb would that be good enough? (I don't really know much about LAB). Smiley

Actually no, for LAB support you just need to allow adjustment with floating point accuracy, you don't need to store floats.
Remember in this instance the LAB support would be basically just a transformation of the sRGB colorspace, so, as I have found in my experience, it's fine to store colors in sRGB.

People might prefer L*ch(ab) better than LAB, though. It's just a polar transform of the AB channels of LAB
so that C represents 'saturation' (chromaticity) and H represents hue.
Code: [Select]
# python code
    c = sqrt (power (a, 2) + power (b, 2))
    h = arctan2 (b, a)
    # now you have C as a length and H in radians. If you want h in degrees, it might be wise to clip it first like
    # h = h % (pi*2)
    # % means modulus in Python

I personally find it creates more interesting ramps than LAB (which creates more interesting ramps than HSL, which creates more interesting ramps than HSV, which creates more interesting ramps than RGB)

BTW, the conversion formulae on wikipedia seem to be correct, just be careful when looking for example code.
A lot of code is dodgy. For a well-tested reference implementation, see http://svn.gnome.org/viewvc/gimp/trunk/app/base/cpercep.c?revision=19628&view=markup
Covers the relevant bases:
* make sure gamma-adjusted (ie standard sRGB) data is linearized before converting to XYZ
* convert to XYZ space using a matrix that accounts for the appropriate white point (D65 is a good default)
* convert to LAB, treating the linear segment of the formula correctly.
* account for the relevant white point when converting LAB->XYZ
* ditto for XYZ->RGB
* data consistency (sRGB->LAB->sRGB conversion reliably equals the original color exactly; I've tested this up to 1/1048576.0 accuracy.)

I've ported it to Python+NumPy and simplified it; if you want to look at that, PM me; it is IMO a lot clearer than the GIMP code (which uses #ifdef and friends rather freely)


Quote from: happymonster
4 colours ( 2 x 2 )
8 colours ( 4 * 2 )
16 colours ( 4 x 4 )
32 colours ( 8 x 4 )
64 colours ( 8 x 8 )
256 colours ( 16 x 16 )

That's a formula. well no, but it may as well be.
Code: [Select]
# written in python, should be fairly obvious how to translate to C++
approximate_nbits = log (palettesize, 2) + .5 - 1e-15;
rounded_nbits = round (approximate_nbits)
colors_per_row = rounded_nbits
approximate_nbits = log (palettesize / float (colors_per_row), 2) + .5 - 1e-15
rounded_nbits = round (approximate_nbits)
colors_per_column = rounded_nbits
If you did that, you could support any size palette without needing any settings at all, since you can always know the real size of the palette.

Quote from: Conceit
You all know how when you are making a sprite you usually make a choice at one point in time when you say, "i'll have 3 tones per ramp for this one" and then you proceed to shade everything and interrupt your shading every time you are going to color a different section of the sprite (for example you are done shading the blue parts and you're starting the red ones) this makes it very hard to add any sort of complicated patterns over the skin/fabrics of the character.

The idea is that the depth itself, the lightness is handled in a single ramp. that way you make a single value/lightness pass.

Yeah, I've been working on this kind of idea for a while now.
Notes:

* You have to use LAB colorspace to obtain brightness measurements of the colors in the base and target ramps. Otherwise, you FUBAR the brightness in inconsistent and unpredictable ways.
* This method is best thought of as sampling over a 2d color-grid, where X is brightness, Y is color, and
   colors may repeat on some scanlines (where less colors than base ramp length are used)
   The method I was working on for CGing would allow sampling at fractional coordinates (ie. between colors / color ramps). What you describe only allows integer coordinates.

* the 'two lightsources' trick can be thought of as a third (albeit binary) dimension to the sampling.
   So you have something like a 17bit format here :). Of course, typically it'd be more like 3 + 3 + 1 = 7 bits (ramp of <= 8 brightnesses, <= 8 different ramps, 1 bit for palette toggle)
   Which leads me to think that this kind of thing might be doable as mainly an adjunct to palette editing.
   recoloring mode could just look at base ramp length and current drawing color to recolor pixels.
   essentially:
Code: [Select]
   targetramp = int (FGcolorindex / baserampsize)
   sourceramp = int (pixel[y][x] / baserampsize)
   pixel[y][x] = (pixel[y][x] - (sourceramp * baserampsize)) + (targetramp * baserampsize)
  
  You might not like the duplicate palette entries that occur for ramps shorter than baserampsize,
  but IMO that is the job of either the saving code or external optimization software to fix
  (you might not want to optimize them out anyway, if you want realtime ramp swapping)


I had an idea and chose to reserve it, but if you're going to make options, maybe you could enable it so that the artists could create their own? Such as creating their own icons to implement and tool box borders and such. that would really be something I don't think i've seen before!
Heh, is in both GIMP and mtPaint, actually (they both use GTK+ gui library, which is themeable, including icon themes.)
I've got all my GIMP icons in greyscale, for example.

« Last Edit: December 15, 2008, 12:50:24 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile
BTW what's with the 2bit icons? I think that's hurting your ability do describe the tool easily a bit...you have to rely on thicker/thinner full/dotted line to convery things you could easily convey otherwise trough contrast in colors.
s/2bit/1bit/g

I think people tend to think '2 bit ---> 2 colors', heh.


« Last Edit: December 15, 2008, 01:40:53 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.