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/SWIGProper 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.
# 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=markupCovers 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)
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.
# 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.
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:
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.
