I'm making a paint program, so useful tools, ideas and features required please

[happymonster]

Hi there,

I'm currently trying (for the 3rd time!) to make and complete a paint program for my own use (and anyone else who wants to use it too). I'm not 100% happy with any paint program I have tried.

This will be aimed at 3 aspects of art:
1. Low colour (palette based) sprites/tiles/art
2. True colour manipulation (nothing too advanced)
3. Good alpha mask/channel editing and support.

These are in order of importance as well. The program won't try to compete with photoshop, but will fill a niche for the 3 aspects I described above.

So are there any tools, ideas or features you have that I can make a note of? I'm looking for unique ideas that will be practical and useful and preferably aren't offered in any other program (besides the basic tools common to most paint programs). No guarantees I will use or implement any suggestions of course, but they may well prove useful!

[happymonster]

Hi,

Thanks for the suggestions..

1. I'm not sure how GIMP does it, but I do intend to add customisable keyboard shortcuts.

2. Definately - This is a very important aspect for me.

3. I'm afraid the interface won't be that flexible. I tried in the past to make a super flexible program and it just makes it all too much work to finish.

4. I would like to provide animation support, but it's not a priority for me at the moment.

5. Yes. Layers are planned.


Any other ideas or concepts that aren't in existing programs? Cool new tools or ideas that would be useful??

[happymonster]

Well, you must all be perfectly happy with your paint programs!

Or, of course you could be thinking this will never be finished. Which is a fair point, still brainstorming ideas and features is fun in itself and I do intend to finish the program this time..

What I can say so far is that it will work in either OpenGL/Direct3D, windowed or fullscreen at 1024 x 768 or greater sizes. The hardware acceleration helps with faster image magnification and layers. The higher the screenmode the better it looks though the interface is to some extent dynamic so it will expand in terms of spacing at higher screenmodes.

I'm going to add low-colour pixel specific tools and features as well as true colour stuff. Merging these two very different aspects is proving to be a tricky design!

[huZba]

A quick key for mirroring a selection/layer or the whole picture would be quite practical. I use it in photoshop all the time. Managing palettes is not very fluent in photoshop so I'm looking forward to this.
Also preview window that shows different zoom levels. Like where you can work on a 400% zoomed picture yet have another window with a 100% zoom.
There's probably more.... I'll try and track what I'm missing in photoshop the next time i make pixelart.

[surt]

I've got a list of random brainfarts for a mostly pixel-oriented raster editor here. If you can scavenge any sense from the unintelligible mess free to use it for your own ends.

[happymonster]

Xelados: I kinda think you misread my post. It will use either OpenGL or Direct3D and will work in either fullscreen or windowed.

Hu2ba: I do plan to have a mirror effect, and the preview mode will have zoom settings for the background canvas and for the zoom window itself (similar to Promotion).

Surt: Woo! There's a TON of great stuff there. It's going to take me ages to plough through those, but thanks a lot for these!!

[happymonster]

Update:

DONE:

Basic design and code skeleton implementation (over last few weeks). Using OpenGL/Direct3D in a window/fullscreen.
Load 256 colour BMP images.
Select pen colours from the palette and draw dotted and joined up freehand on the image at different brush sizes.

PARTIAL:

Canvas magnification (separate from zoom window magnification).
Scrolling with arrow keys (works, but need scroll bar GUI elements)

TODO NEXT:
Line, Box and Filled Box primitives.

[Ryumaru]

Any way this would be able to work on a mac? Id so give you thousands of cookies if it did.
I don't know if it's already implemented but a preset brush that is a 8x8 square would be awesome for doing tile work.

[surt]

Since you're using OpenGL (why bother with Direct3D as well?) canvas view transform is essentially free, so it'd be nice to have some tablet-friendly view rotation and wide-pixel-/mode13h-friendly pixel aspect ratio adjustment.

Also tablet-friendly view control would be nice. eg. middle-stylus-button drag panning, keyboard modifier plus stylus-button rotozoomer, etc.

[Raytheon]

a toggleable tilebox option where it shows you the boundaries of a box on an image


example you have a 64x64 image, and it shows you the boundaries of all the 16x16 boxes in it


if you dont get it i can just draw something up quick

[happymonster]

Ryumaru: The engine is cross-platform, so a Mac version is very possible. An 8 x 8 square brush will be available.

Surt: The engine already supports both OpenGL and Direct3D (I'm not writing the engine as well as the program). As for the tablet friendly view rotation, that's something I'll have to think about. I still need to put those ideas you made into some kind of order/priorities!

Raytheon: I know what you mean, that's something I had already thought of and planned for (in the Grid tool, as a show grid options.. with then an optional snap to grid button)

[surt]

What's this engine you speak of? It sounds strange to me to build a non-content-heavy app on top of a pre-built engine.

Also, are you planning on selling it or going freeware or FOSS?

[happymonster]

It's an engine that a friend has built himself over several years for his own (shareware games). As a consequence it has good support internally for memory images (from paletted to true colour), primitives, blits, as well as GUI elements and then 3D display, texture management, etc.. So it's going to be good for both games and utilities, albeit without the normal Windows/Apple/Linux GUI.

At the moment, I'm thinking of freeware.

I've finally had time to go through all those ideas you posted Surt and put them into an organised spreadsheet. I will add my own (and other people's) ideas to this and use it to keep organised on what needs doing. A lot of the ideas you posted I am not sure about, so I would be grateful if you could have a look at any of the '?' mark ones (autofilters are there) and see if you can explain a bit more about what you mean.

BTW: I've got a total of 176 entries once I added in all your ideas (!)

As you can see, I am quite serious about organising and using people's suggestions.

Here is the XLS spreadsheet:
www.funkemunke.com/ideas.xls

[surt]

Added more info on the ones I could make sense of Thing!

[happymonster]

Thanks Surt! I'll go through your comments and update those ones. I'll upload the new version what that's done, and I will add my own features and ideas to this as well.

Does anyone else have any ideas or features?

[32]

if possible maybe a simple quick canvas resize, like in mspaint (drag the corner of the canvas)

[happymonster]

Good idea 32! I've added this to the spreadsheet and gone through the updated entries from Surt and responded to those I can..
Now updated:

www.funkemunke.com/ideas.xls

[happymonster]

It's awkward to edit with OpenOffice compared to Excel, I'm used to Excel but don't have it at home.

DONE:
Box tools: box, filled box, square, filled square and draw types, A to B, or expanding box/square.

Also, a lot of engine work and reorganising done today. It's going well! I still need to update the spreadsheet with my ideas and use this to keep track of things though.
Groan!

[Conzeit]

I have one...it's sort of oriented to ease the addition of stuff like tattoos or different fur patterns (like tigerstripes) camouflage on sprites.

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.

Knowing that you've got the depth all taken care of, you proceed to create the equivalents of your original ramp in different hues. Say if you had 3 red colors originally, and you need to have gray and blue hues as well, you make 2 new ramps of 3 shades each, making sure the shades have similar lightness to your red ones.

This would make it much much easier to make characters with several different print patterns on their clothing, or if you mess up in the middle of putting the pattern on you dont have to re-trace your steps in undo, you simply change the hue information on it and nothing is lost.

This would all be handled internally, nothing would change in the end product, only in the inner process of coloring the sprites. You could even tell the program to for example use the same shade for the darkest red and blue shades for example, but if it turns out for whatever reason you can use more shades than you originally thought, you still have the separation of the two shades in the hue information, you just need to tell now instead of using that gnarly purple for your darkest blue and red hues, you'll have actual dark red and dark blue.

The people in SF3 obviously used this kind of tool, only to a much greater degree
http://www.zweifuss.com/colorswap.php?pcolorstring=IbukiPalette.bin&pcolornum=0&pname=ibuki/ibuki-jump.gif most evident in this particular animation. Oddly enough, even though they developed the tool they didnt take incredible advantage of it...as most people dont even notice it. obviously, it helped in making the Gill character posible since it would make it a simple matter of changing his hue information.

SF3 uses it in an even greater degree than I described, because if you pay attention closely...they do not only have different hue information for every part of the sprite, they have two totally different and separate palletes that go from the brightest color to the darkest color for every single frame. That is how they make their two lightsources, they have the normal sprite and the blue sprite, then they use some kind of tool to tell the painting program which part uses the blue hue, and which one uses the normal white hue.

if you think this could be of any use at all...I have an even more complicated idea about this...involving actually completely diferent shadings for each hue.....it would be useful for characters that have chromed armor and normal clothing...

[Rosse]

One useful feature would be a view-mode where you can select "normal" and "gray-mode". In "gray-mode" your image is displayed in grayscale, but the color itself is preserved. In programs like ProMotion or Photoshop, you must alter all your colors to gray to achieve a grayscale image. When you want your colorful image back, you have to undo your altered colors (or Palette in ProMotion). For that reason it's useful to have kind of a grayscale preview, which you can even pixel on and you can switch from "normal" (colorful) to "gray-mode" on the fly (colors are preserved while pixeling).

[happymonster]

Thanks for these! I will think about them at work today..

[happymonster]

I'm uploaded the updated spreadsheet. Not had chance to add my own feature list to those yet, but I'm still made progress on the design and programming today.

[VisMaior]

What language are you going to use? Will it be open source?

[happymonster]

C++, and it won't be open source. But will probably be free.

[happymonster]

In another thread dogmeat said he thinks a paint program only needs:

1. Palette ( ability to load up colors, save palettes and maybe some hotkey mechanism to switch colors )
2. Pencil ( just like mspaint, left click paints, right click paints, if I click my palette it grabs that color )
3. Eraser ( instead of an eraser, I think it would be more beneficial to have a transparency color in the palette tool, use that to erase to trans )
4. Layers ( Only need 2 layers for any kind of pixel art, to easily move stuff around or to save an old copy of something for comparison )
5. Select/move tool ( a select tool you can use lasso with right click, square with left click, use shift for uniformity )
6. I also think a hotkey/button to select whatever color your cursor is over while using the pencil tool would be better than an eye dropper.

I know there is one viewpoint with the artists that only the most basic tools are needed, especially for the 'purity' of pixel artwork. However I disagree and think there are a lot of features which are either not available easily or at all for palette based drawing programs, or just have never been implemented beyond ideas in people's heads. There are a lot of improvements IMHO that can be made to a paint program that are not being used even today.

[Ryumaru]

I think as long as artist has complete control over their pixels( colors and placement) then it's pure enough for me. You could add useful features that might not be for the purists but do make things quicker and if the purists don't want to use those features they wouldn't have to.

[happymonster]

I agree. That's the way I see it..

[Jad]

I think as long as artist has complete control over their pixels( colors and placement) then it's pure enough for me. You could add useful features that might not be for the purists but do make things quicker and if the purists don't want to use those features they wouldn't have to.

It's not that I want other features because I'm not a purist, in my case, it's just that I want the production tempo to be as high as possible so I can churn out good art quickly and make money for myself and happiness for my clients : D

Things like photoshop-esque masking/selection or color replacement tools help greatly with this, also dither brushes and the like. All of them are awesomesauce that makes things go a lot faster! Also dither gradient fill would be one of those things that can look real ugly if you misuse it but save you a lot of time when doing large-scale things. Et cetera.

[dock]

Another request for a mac version. There are a lot of people itching for a usable pixel editor on mac!

Try to copy Photoshop's shortcuts and main interface as much as possible, as it is regarded as the 'standard'. Things like zoom, scale brush, etc are in a lot of different programs now.

Please focus on a clean and modern user interface most of all, actually.

[Ryumaru]

I may be the only one on this boat but I like the interface to be as simple as possible. It's one of the main reasons that I still see ms paint at night instead of staying in bed with promotion. All I need is my pencil tool, fill tool, zoom, and palette to get started. Other things I like to bring up as I need them. Sometimes a program with so many tools on the tool bar and thousands of windows intimidates me and keeps me from making art.

[Akira]

I agree with Ryu. When I wanna get an idea down I usually scribble with paint. The load time is quick, it takes up a minimum amount of space on my screen, these things make it perfect for quick sessions. If I wanna flesh something out I'll usually switch to promotion. If I was going to use your program it would need to start quick, take up the smallest amount of screen space possible, and then be able to be extended in to something as functional as promotion.
One thing I hate is the "New Document" dialogues on promotion and photoshop. Paint is perfect in that it opens with a new document on start up. The canvas can then be resized easily to suit whatever size you want.

[surt]

One thing I hate is the "New Document" dialogues on promotion and photoshop. Paint [edited for accuracy] opens with a new document on start up. The canvas can then be resized easily to suit whatever size you want.

I agree with this. Minimal modality is key. Even if the canvas isn't the size the artist wants they can still get straight to painting and resize the canvas when it becomes a problem. You should never obstruct the artist for doing what it wants to do when it wants to do it without good reason. For example Paint requires the artist to switch to a different tool mode to pick a colour off the canvas after which the artist must again switch back to its previous tool mode while a better solution is to put colour picking on a mouse-button and/or key where it can be invoked instantly without interrupting workflow as found in GraphicsGale.

On a related note an unbounded canvas, such as found in Pencil, could be a good solution for this "just paint" ideal. I expect it is handled by tiling, only adding tiles as needed to fill the bounding box.

On a marginally related note being able to close your work session and resume it identically with all states restored (opened images, canvas view, window layout, tool context, selection state, etc.) at a latter time could be a very nice aid for the motivationally challenged artist.

[Ryumaru]

surt: you have a good point, but I think it might be a matter of opinion whether its better to have say the left click to draw and right click to pick colors rather than to be able to draw with color a with left click and draw with color b such as in paint.

[surt]

Ryumaru: I'm not disagreeing with you. When working on line-art or other two-colour art, not being able to paint different colours with both buttons becomes a hindrance. There's no reason you can't have it both ways though, for example: LMB - paint colour 1, RMB - paint colour 2, ctrl-LMB - pick colour 1, ctrl-RMB - pick colour 2

Ideally you could configure your workspace so you could have even more, attaching a separate tool and associated context (colour, brush, dither pattern, etc.) to any input event (keyboard, mouse, tablet, gamepad, etc. and combinations thereof), and so further reducing modality.

[Akira]

[edited for accuracy]

hahah! fair point.

I agree with full hot key configuration... but it should also work intuitively out of the box. This was my major qualm with graphics gale, although it was configurable, it was unintuitive to begin with. Hot keys should have logical default settings.

I hope I'm actually providing useful information here and not just being difficult

[happymonster]

Well, no one program will satisfy everyone unless it is so super flexible that it can be made to look and feel like anything. We've already seen some people here prefer MSPaint, others Photoshop and no doubt many here will like the Dpaint/Promotion evolution..

Since design by a committee wouldn't work with such different ideas, I will try to incorporate suggestions and features where possible, but the 'vision' (as such) for this program will have to remain with me and give me the final vote on what to do or what to leave out.

Hope people understand that..

[happymonster]

Well, it's the weekend so hopefully I will have more time to do work on this (after I fit my time around girlfriend and friends of course!)

Earlier we talked briefly about complexity, which is a good topic. While Mspaint has a pretty simple interface, photoshops is complex and daunting. Is there a way to have many features without introducing a complex interface system? Perhaps by only showing parts of the GUI that are necessary for the current tool? And by tucking away less commonly used tool features into a seperate 'advanced' (or something similar) option?

What are your thoughts on this? How do other programs like PSP, Photoshop, ProMotion, etc.. handle this?

[dock]

Photoshop Elements has an interesting approach at simplifying the user interface. For example, I think the options are more top-level, rather than buried, and slightly bigger icons by default. 

Looking at software such as iphoto, garageband might be a good idea, as apple's software is designed to be much more accessible by beginners than other developers.

[Jad]

You can always download the free version of graphics gale and poke about. It has fully customizable hotkeys, a good thing since you can scroll through it and check out what features are available.

I think graphics gale has a nice and simple interface, everything you need is there without looking too obscure, just sitting down and painting something is as easy as (or easier than) doing it in paint in my opinion! O:

[happymonster]

I used to have Graphics Gale in the past, but don't have it any more. I will check it out at some point for inspiration..

[happymonster]

DONE (since last list):

Dotted Draw, Free draw, Joined up draw (end point is connected to start point).
Line
Box, Filled Box, Square, Filled Square
Two box draw methods, Draw from corner to corner, or from centre to corner.
Bug fixs
Start of slider gui code.
Brush size 1-64 pixels with crappy slider (square size brush)
Smooth zoom in/out of canvas when the mouse is over it with the mouse wheel. (Thanks gfx hardware!)
Much internal design work for data structures and gui ideas.

[happymonster]

Just DONE:
Scroll around image if the middle mouse button is held down and the mouse is moved.

[surt]

Any chance of a build so we (I) can have a play? (If it'll run under Wine that is, sounds like you're using PTK as with Chaos Groove which I could never get to run on Wine.)

[happymonster]

It's not quite ready for a build yet I'm afraid.. I still want to get some basic functionality in there before releasing anything. I'll post more details and screenshots soon though.

The good news is it doesn't use PTK, but my friend Mike Welch's Blitwise engine (PC / Mac). So if you can get the demo versions of his games at blitwise.com to work then it should work ok.

[dock]

Is there something bad about PTK?

I've never used it, but people on the Indiegamer forum seemed to gush about it, and it sounds pretty good in general.

[happymonster]

It is good in general, but it does have some limitations like poor documentation and slow updates by the author.

[happymonster]

Can't sleep.. 

So, I've added the start of the palette selection of tools. The first thing I've added is 6 settings to display a palette of:
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 )

This makes the palette entries bigger for lower numbers of colours, which will make it easier to focus and select from for low-colour work.
I'm going to check other programs to see what other palette tools are offered, but off the top of my head I can think of swap, copy, ramp, undo and sliders for RGB & HSV. Any more?

[Frychiko]

Speaking of colour sliders, I would like to request Lab sliders if it's not a pain to add in. I much prefer Lab to RGB, HSV, HSL.

[Conzeit]

Speaking of colour sliders, I would like to request Lab sliders if it's not a pain to add in. I much prefer Lab to RGB, HSV, HSL.

seconded

Also...onion skinning, and animation preview running ALL the time...with options to loop it, reverse it...etc...BIG thing for me =)

Did my past feature suggestion make any sense? I know it can be hard to proces...certainly feels hard to explain

[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).

Conceit: Yes, I think I understood your suggestion, I added it to the spreadsheet. I will go through the suggestions and my own once I've got a bit more of the basic core done.
Onion skinning could be done with an offset layer and a standard opacity value (assuming sprites were grid alligned).

Animation is something I could do if a grid is set (but not snapped to) so that the program can find the frames easily, and then in one of the zoom modes the animation plays all the time in one of the zoom windows. Does that make sense?

[happymonster]

Oh I've found some info on how to convert from RGB to XYZ and from there to Hunter LAB or CIE L*ab..
So, this might be possible. I never knew there were so many colour schemes! 

[Conzeit]

LAB is somewhat like HSB only it naturally gravitates to pretty colors...heheh.

Did you ever feel like on the computer when you grab a blue and try to make it lighter it doesnt become ligther, but instead becomes a little purple? that never happens with LAB

I think I know what you mean about the animation preview.....I basically just want what I have on ggale :p

[happymonster]

Ok, I will see what I can do.

[happymonster]

DONE:

Added floating brush cursors.
Engine modifications to make things more flexible internally.
Added animation icon (still not happy with this) for animation support.
Many bugfixes.

I'm a little hesitant to post a screenshot because I know some people will not like how things look, or will want to try a build straight away (which is still not quite ready). I am open to feature ideas and change suggestions, but the basic look and design is now fixed. It is primarily free software for my own (and friend's use) after all!

Still I've posted a picture from my machine running in a window at 1024 x 768. It is able to run at different screenmodes and window sizes as long as the minimum size is 1024 x 768.

Some things to note from the picture:

Large palette area so no fiddly colour selection. This shrinks vertically at 1024 x 768 (as shown) to allow more GUI space. At higher screen resolutions the palette entries are square.
4 Pens: Left, right mouse button and left and right with shift (working)
Style: Black and grey GUI look with coloured icons. I'm going for this look so that the icons stand out but the main areas of black and grey don't overpower the main edited image.
As you can see it's primarily icon and text based with nearly everything happening in the large panel to the left.
Most operations will only take a few clicks, for example load is two clicks to bring up the file selector (Image->Load), Box and filled box are one mouse click, etc..
The GUI sliders are just placeholders and not displaying properly yet, but are usable in that you can select a brush size from 1-64 pixels in size.

http://www.funkemunke.com/Pixe.png

Well, be kind! 

[surt]

Looks promising, but I imagine the high saturation and contrast could really kill the eyes in short order, not to mention the colour polluting effects. A quick edit keeping the same style but making it easier on the eyes and retaining readability. I reduced the brightness of the icons by half and the saturation by a quarter and made the background quarter intensity grey.

I'm sure I've already mentioned this in my list, but in regard to palette tools I think good consolidation tools are very important and worth restating. The ability to sort colours based on any component in the supported colour spaces, the ability to similarity cluster within any of the supported colour spaces, and the ability to easily merge good consolidation candidates (eg. select multiple palette entries, hit key to merge) should do the trick.

Another nice palette feature could be the ability to split the undo stack into separate image and palette stacks. I often tweak some colours do some pixelling, then regret the colour changes and want to undo them, but can't without loosing the pixel work I've done since.

EDIT: Oh yeah. I tried a couple of the Blitwise demos with Wine, one worked fine, the other locked up on the loading screen. Not perfect, but not without hope either.

[happymonster]

Well, can't really say I like the greyed out version, although I understand the icons could be too vivid. Perhaps an option for pastel shades would be useful..
Thanks for the other suggestions. I will try to add them to the list.

I'm not very well today, but hope to feel better soon.
BTW: Which Blitwise demo didn't work?

[happymonster]

Well, I was hoping for a little more response.. Perhaps it looks too different to other paint programs, people aren't so keen on yet another paint program?
I'll still keep plugging away anyway!

[Jad]

Sorry guy : D

Anyways, yes, pastels please, that'd be great. I really want some pastels.

Right now the environment isn't very art-friendly, the blackness and bright colors make it hard to imagine making pixel art that doesn't look like llamatron, so some greyness and pastels would help greatly with that.

Doesn't look too different, but it does make me think about odl computar days. O:

[happymonster]

Fair enough. I will have it as an option at least..

[Ryumaru]

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!

[happymonster]

Well, the icons will probably just be tiles in one large PNG image, so there would be nothing to stop people from doing better versions than what I am able to do.
The same goes for the font (although the sizes will be fixed).

[happymonster]

Ok, what about this. The colours used at the moment are not hardcoded, but stored in a internal colour palette. If I make that external using normal palette load/save .PAL formats then people can use different colour schemes at will. Throw in a couple of background gui colours and they could alter the background elements too.

In that case, would anyone like to help with a mockup of different colours? You are artists after all, and maybe some of you are designers too!

[dock]

I have to admit, I was expecting something more conventional. ^^;
I like to have multiple documents open at once so I tend to prefer a regular window-based setup. Just now, for example, I had my different loops open in different windows in photoshop whilst I animated.

I agree with Jad, this doesn't strike me as somewhere I'd like to work, especially in relation to swapping between other software that I use during the task.  I loath Zbrush because of its very custom GUI, and unfortunately I can't imagine myself using this in its current incarnation because of the fruity GUI.  It makes more sense in zbrush, LightRoom and Aperture (software which works in full screen mode) because you're working on something very big and detailed. The opposite seems true of pixel art, where I tend to prefer my windows small to medium size.

I think I expected something closer to Microangelo: http://www.microangelo.us/icon-tools/icon-editor-example.asp

[happymonster]

Fair enough. I know it won't be to everyone's tastes.. I did say that it wouldn't use the normal OS gui originally though.
It's still early days anyway, It will probably start to look much better with people's input here.

[happymonster]

Alright.. What about this? Does this look better to you? Are the icons still too bright?

http://www.funkemunke.com/Pixe_2.png

[Jad]

Great, that's an awesome improvement right there! At least it made me stop thinking about llamatron whih is a very good thing if you don't your userbase to go crazyballs.

I'd make a mockup with the same functionality sometime but that's a biggie, really. Should finish my secret santa pic first (:

[happymonster]

Good. I think the lines on the interface help divide it up more anyway. Although I still miss the high contrast look for the icons.
Any other suggestions if you haven't for time for a mockup/edit?

[happymonster]

Slight embossed effect on the icons.. Thoughts?
http://www.funkemunke.com/Pixe_3.png

[Kazuya Mochu]

you might wanna be carefull with a too dark background since it will automatically make people create darker artwork since it will look brighter with a dark hud. just a heads up, maybe it wont even matter.

I dont know it anyone said this, but it would be awesome if there could be an instance funcion. where you could have one tile, like a terrain tile for example, and have that be instanced several times, and as you changed one, you'd automatically change the others.

Kaz

[happymonster]

Kazuya: Good point. I suppose that the opposite is also true, especially with very white interfaces like Apple OS X.. I'm just not that great a fan of too bright grey in a GUI (such as seems the default for OS's nowdays).

For your idea, I think Surt suggested something similar with a tilemap option? The idea that you can alter a tile and see the results in a tilemap in real time?

[Jad]

Changable color for the background of the workspace part would be nice, actually O: Especially if transparent colour would show up as the same, that way you don't need to make huge sprites to see how it looks against different backgrounds.

A little redundant though.

I'll be sure to try it out when you've got something tryable (: I admire your effort lots <3

[Ryumaru]

This is really shaping up man. :]
Did you say the window will be resizable?
My thoughts are just echo's of the others: changeable background colors and the tile thingy
Also, I like the embossed icons :]

[surt]

Both of the new screens look a magnitude improved and I'd be quite happy with either, also it looks plenty conventional to me, not much different from my GGale setup.

If you wanted a simple MDI without going with child windows you could use a simple split view system which could allow views of different canvases or multiple views of the same canvas. Even with a limitation of two panes you could have your reference image or preview in the spare pane, or have a DPaint/GrafX2 style zoom pane.

Even if you are to restrict the view to one image at a time it'd be nice to be able to have multiple images loaded and easily switch between them (that's how I usually work in MDIs anyway).

I think Kazuya's suggestion is more along the lines of what Pro Motion has (can't reach the site to get the name of the feature), where duplicated parts of the image (as delineated by the grid) are tracked and any change to one part propagates to all its duplicates, whereas I was suggesting an integrated tilemap editor (though I may have mentioned both). Either tool would be sufficient (both would be even better ). Pro Motion's solution should be easier to integrate into a straight paint tool however, needing no user interface beyond grid settings (which I'm sure you'll already have anyway) and a toggle.

I'm guessing from the "Layers" button that layer controls modally replace the "Box Options" panel. For me, I like my layers always at hand so: 1. I can tell that I'm editing the right layer; 2. I can easily toggle layer visibility; 3. I can easily switch the edit layer.

Nit-picky: for UI simplicity you could replace each of the box option pairs filled/unfilled, square/free, corner-to-corner/centre-to-corner with a single toggle button each.

I also put in my vote for themeable colouring.

[NaCl]

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.

[Jad]

Seriously, a selection function mimicking photoshop would be GOLDEN

Like you could fill a layer with a dither pattern (dither/transparent), then hide it, select it to paint autodither, etc.

Or select an area of one single colour and being able to paint in that area after you've started doing it as well. (as opposed to graphics gale's color replacement where you can only work on the colour that is currently on-screen. This function is great as well, though.

[happymonster]

Ryu:
The window will be able to set to different sizes in a configuration file. Not sure about real-time resizing, don't think the engine will support that yet.

Surt:
Thanks! I intend to have (at the least) a split screen DPaint/Promotion setting in the Zoom options.

I fully intend to support multiple images and being able to switch between them.

I understand what you mean about the layers, there is an issue of GUI space, I'm rapidly running out of that for 1024 x 768! Also, I have some special ideas for layers which will make things much easier. I'm not going into detail here because I'm worked it out in my head, but need to implement it to see if it would work.

The thing with three toggles for the box options is that to go from an unfilled box to a filled square would take two clicks (one for each of the first two toggles), whereas now it can be done with one click. Because there aren't that many box options I think it's best to have all the options readily available.

Jad:
I'm not sure what you mean about the layer, dither pattern, selection idea. Could you explain that a little more please?

[happymonster]

BTW:

I said the engine was cross-platform and could be used with OpenGL/Direct3D, well there is a chance that this program will be available for Windows, Mac and Linux.

[surt]

Crude mockup for low space consumption layer access: http://surtspixels.googlepages.com/Pixe_edit.png
Layers are accessed via layer bar above canvas.
To select layer left-click on preview icon.
Selected layer is highlighted.
To toggle layer visibility of layer right-click on preview icon.
Invisible layers are greyed out.
Layer name displays on tooltip, or names of all layers unfold vertically below preview icons when mouse hovers over layer bar.

This should allow quick access were one would need it.

[TrevoriuS]

I'm slightly reluctant of the hue gradient in the tool icons... I generally favour clear representations ,that are absolutely in no way appealing and therefore not distracting.
Taking 96,96,96 grey for the toolbars, default 128,128,128 for transparancy/workspace background (but have it changeable). Then you cna create light grey, or with a hint of colour, and black icons.

Further: sliders, loads of sliders for colour editing

[Jad]

Setting loop points between two frames of animation would be gold, I just realized O:

[happymonster]

Surt: Thanks a lot! That's given me a few good ideas. I suppose that extra row won't encroach on the canvas area too much.. I'll have to think about this!
I appreciate you taking the time to make a mockup for me. Thank you.

TrevoriuS: If I use an external palette for the GUI you will be able to set the colours however you want..

Jad: Good idea.

I've been a bit under the weather this week, but just starting to feel better. In the mine time I have updated and uploaded the ideas spreadsheet to reflect some of the tools that are planned and some that are already done:
http://www.funkemunke.com/ideas.xls

[Conzeit]

it looks pretty good. but I have to admit it'd be a pretty big adjustment if I cant switch between windows while working on this....

I have a suggestion for something like the tile thing that was already said, but from an angle of animation.

the idea is simply to handle tiles somewhat like the "objects" in flash, so that if you for example have the sprite's head which will repeat troughout his run sequence, it wont be stored 5 times, instead it will be the same head, and if you change it in one frame it gets updated in all the others.

make any sense?

[happymonster]

When you say windows, do you mean between this and other programs? Because it will run in windowed mode..

If you mean between other images, then you will be able to change the main view to different images ala Promotion.

If you mean true multiple windows in one canvas then that is a bit more tricky!

[happymonster]

Yesterday I sat down and got the first part of the image/layer system implemented. Low level pointer work in C is not my thing (I'm more of a idea guy), but after some frustration I got it working ok. I've updated the ideas.xls file.

I need to get the second half of the layer system working, then I can work on the layer options gui section at some point..

[happymonster]

A lot more of the layer system now in. Will have to start thinking about the design of the layer system soon..
Have a good night everyone!

[Conzeit]

I meant between urs and other programs...I'd be just fine  (I hope!)

it's awesome that you got this going and are consistant about it.....I wish I could lend you some programming muscle. Would it be totally weird to go to random oldschool/indy game forums to ask for help ? I remember very clearly MadGarden had an idea for a pixelart program project of his own (he wanted to employ vectors in a pro-pixeling way...and I have to say the idea sounded pretty cool)) maybe you can grab him off GDC or something....?

[happymonster]

Thanks!

I'm happy to work on this myself, I've never had much luck from trying to work with other people.
When it's a bit futher along perhaps people could help with the icons, fonts and palettes though!

Right, off to work..

[happymonster]

More progress made today. It's starting to come together now. However, I am kind of designing things on the go so some parts will surely change. I'm still moving main tools around and things like that.

I am leaning towards putting the tools in a external data file so that it's easier to customise things (and cleaner code wise). Of couse, it won't be totally customisable because the tool icons still need to call certain internal functions, but it should help. That will be a bit of work though, so not doing that quite yet.

So much to do!

[happymonster]

* Added basic ACO (photoshop palette) loading from the palette tool options (as long as the palette data is in the RGB colorspace).

I'm going to look at using an external palette (probably from an image file so people can play with the colours in the image) for the gui next.

[happymonster]

Ok, I'll be using something like this:


Which you can play with the palette for and that will affect the palette used in the program when it's loaded.

NOTE: The icon colours here are at the brightest (the highlight on the icons), the base colours and the shadow shade will naturally be darker. The colour is also added to the underlying panel gui colour (part of the emboss process).

I'd add more colours and image bits as the program develops. Please feel free to play with this and see if it works ok or not..

Thanks,
Richard

[happymonster]

Started adding the external colours to be used in the gui (taken from the image file).

[TrevoriuS]

I see you lack some replies haha, I like that you're making this with our input, and I'm sure I speak for most people that posted here, that we're all awaiting testable results. Thanks for keeping me (us?) posted on the results and achievments you have, and please keep going at this pace   

[happymonster]

Looking at the number of views I assume people find this thread interesting at least!!

[happymonster]

* updated gui image as more colours added..

[happymonster]

Today I'm making the text routines used for displaying help, status info, more flexible and easier to 'write for'.
Also done some more designing earlier.. my head now hurts!

[happymonster]

* More flexible text routines are now in.
* All colours use the external image/palette now.

Working on doing proper scrollbars now/next..

[Jad]

Being able to use transform functions more advanced than scale and rotate would be awesome. To skew images would be really nice!

[happymonster]

True. I'll have to add those ideas to my ever-growing list.. 

[television]

This sounds sorta hard to make, but it's something that would really suit my interests.

How about being able to add extensions to the program?


Sorta like firefox.

[happymonster]

I think that would be too hard for me to make I'm afraid (especially when I am doing this on my own!)

[television]

Yeah, I didn't really expect you to be able to do something like that. (Regardless, this is turning out to be very awesome)


How about a "preview" of your piece when you're zoomed in instead?

[TrevoriuS]

The only way to do that easily, is having it opensource ;P

Being able to use transform functions more advanced than scale and rotate would be awesome. To skew images would be really nice!

Pleaaase make sure all these features have direct input options. Recently been doing stuff in flash, and skewing something at exacatly 45 degrees was a hell to do (about 20 tries on a super zoomed in level per object)



Don't double post uselessly. Use the edit button instead. - Panda

[happymonster]

A bit tired tonight, but getting some work done on making the image loading work in a cleaner (and proper) way.

If I can get that working then I'll add save (using existing loaded images filepath), to enable basic loading, editing and saving.

[happymonster]

Ok!

After some very strange corruption issues due to errors in the engine's save bmp code, it is now working! You can load 8-bit uncompressed BMP's, edit and save them.
This was more complicated because previously the load was converting the image to a true colour format, so palette info was lost. Also the save flattens all the layers, so it's more complicated than just outputting from one image.

But load and save (albeit limited) makes it feel more like a proper paint program now!

[happymonster]

Mostly doing Christmas shopping and wrapping today..

However I did get time to fix a few bugs, disable canvas clipping to edges which improves zooming and makes scrolling less constrained.
Improved smoothness of zooming.

Added more flexible text gui elements for use with scrollbars, sliders, variable displays, etc..

I still need to work on scrollbars (hate gui stuff!), and perhaps adding basic RGB sliders for the colour palette options should be next?
What do you think?

[happymonster]

Added RGB sliders in color options (tool options for color icon). You can move them left and right and they move position and the value to the right changes, but they don't actually do anything with regard to a color change at the moment.

I won't have room to have sliders for all the colour spaces, but I do like it where you can see both RGB and HSV at once, so what I'm currently thinking of is having RGB + Additional colour space which you can set (HSV, LAB, etc..)

What do you think?

[surt]

I still need to work on scrollbars (hate gui stuff!)

Personally, I would drop scroll bars altogether.
While they do provide a visual indication of the view's position in the canvas they don't naturally work with a panning beyond the canvas edge or a rotatable, tilling or unbounded canvas, if plan to use any of those. The user should know their image enough to have an idea of where they are based on the view anyway.
If you plan to have a preview pane, then that can beter provide the view positioning info anyway.
Mouse panning strikes me as more natural and comfortable.

I won't have room to have sliders for all the colour spaces, but I do like it where you can see both RGB and HSV at once, so what I'm currently thinking of is having RGB + Additional colour space which you can set (HSV, LAB, etc..)

That sounds quite sufficient to me, so long as the colour can be easily tweaked in-between strokes.

The colour icon doesn't look too informative, maybe the tried-and-true ye-olde-days wooden palette? Also, you misspelt colour. 

[happymonster]

Hi Surt,

I can see what you mean about the scroll bars, but since I need sliders for things like RGB/HSV then I might as well use them as well so other people feel more comfortable.

I agree the colour icon doesn't look great, I tried doing a normal wooden palette design but couldn't come up with anything I liked.. Want to give it a go (2 colours, 32 x 32 pixels)?

I am british so 'colour' is the natural spelling to me, however the engine has color (american authors!) and so I'm trying to stick with the american spelling to avoid typo errors in the code!

[happymonster]

Ok, RGB sliders now update the colour in the palette, in the pen colour boxs, and in the image.

Unfortunately updating in the image is very slow at the moment, I need to try to optimise the getpixel layers function..

[happymonster]

Optimised color changing in image dramatically. The greater the area to change the slower it is, but on my average PC it changes a 1024 x 1024 area at around 15 fps (roughly). Most colour changes will be for much smaller areas and so will effectively be real time.

[questseeker]

I admire the idea of competing with, e.g., Grafx2 (http://code.google.com/p/grafx2/) and I'm waiting for a test release.
Meanwhile, some questions and comments on assorted entries of ideas.xls. First installment:

Palette support

The colour-related features in ideas.xls suggest that you have a colour-first approach: the user paints in colours and the palette as a bunch of colours that have been computed and/or picked among all RGB or HSV possibilities.
But there are already too many tools of this kind, and a more useful pixel art tool should have a palette-first approach: the user paints in palette entries, each entry in a small palette is meaningful (do you support naming palette entries?) and its actual colour is a more volatile detail that belongs in the final rendering step of the image.

Some advanced features:

• Do you want to support different palette entries with the same colour? Example application: some normally different dark colours might become all black or dark grey for a low light palette version, without irreversibly collapsing the details of half the image into a solid area.
• Palettes might be fixed (e.g. EGA, CGA, C64 hardwired colours; or funny Pixelation challenges) or changeable or mixed (e.g. Windows): do you support palettes where specific entries are "protected" and others free to change?
• Do you support general two colour palettes (good), or only black & white (bad) or neither (unacceptable)? And what about palettes with arbitrary numbers of entries, not only powers of two, which can be represented in PNG files without wasting space and are supported by GIMP?
• Do you plan to support multiple colours per palette entry (or, if you wish, "parallel" palettes)? One might edit once and see different colour variants of the image in separate preview panels, which would be extraordinarily useful for recoloured sprites or for experimentation.
• Along the same lines, there can be an explicit export step from the semantically rich "project" to one or more "products" in stupid file formats. For example, editing with all the convenience of a palette and exporting 32 bit RGBA or explicitly indicating palette indices for the output (e.g. for games that use their hardwired palette anyway or that look at magic palette indices to define maps from an image).

[happymonster]

Hi Questseeker,

Thanks for the feedback and questions. I will try to address them:

The program will work in both a truecolour and an 8-bit palette mode. In a paletted mode then the colours can be changed without losing any image detail (i.e. you could have several blacks if you darkened the palette.

I have not currently thought about protected or locked palette entries. You will be able to grab palettes from other images and remap colours, or load from photoshop ACT file palettes.

Do you support general two colour palettes (good), or only black & white (bad) or neither (unacceptable)? And what about palettes with arbitrary numbers of entries, not only powers of two, which can be represented in PNG files without wasting space and are supported by GIMP?

I'm not completely sure what you mean here, but as the program support upto 256 colours in a palette mode, you can set a two colour palette easily if you want too..


It will be able to load/save PNG files, so I assume it will be able to do custom number of colours (upto 256). This is not something I have looked at yet though..

Do you plan to support multiple colours per palette entry (or, if you wish, "parallel" palettes)? One might edit once and see different colour variants of the image in separate preview panels, which would be extraordinarily useful for recoloured sprites or for experimentation.

That's a good idea! Not sure how easy that would be to implement or for the user to manage multiple colours though..

Along the same lines, there can be an explicit export step from the semantically rich "project" to one or more "products" in stupid file formats. For example, editing with all the convenience of a palette and exporting 32 bit RGBA or explicitly indicating palette indices for the output (e.g. for games that use their hardwired palette anyway or that look at magic palette indices to define maps from an image).

Again, sorry I'm not quite sure what you mean. Can you clarify please?

[happymonster]

* Added HSV sliders (which work)
* Made zoom magnification amounts use a single slider instead of different zoom factor icon buttons. Works much better now.

(I'll try to add the latest things and update the spreadsheet tomorrow), there are always things to do!

[questseeker]

Along the same lines, there can be an explicit export step from the semantically rich "project" to one or more "products" in stupid file formats. For example, editing with all the convenience of a palette and exporting 32 bit RGBA or explicitly indicating palette indices for the output (e.g. for games that use their hardwired palette anyway or that look at magic palette indices to define maps from an image).

Again, sorry I'm not quite sure what you mean. Can you clarify please?

The "project" the user edits doesn't correspond directly to the final image files: there can be a choice of alternative outputs (the automatically recoloured versions I proposed, or transparent images composited on different backgrounds, or the same image in different file formats, etc.) or some degradation that require the Pixe documents and the usable image files to be quite different.
"Stupid" file formats in common use cannot represent everything the program needs, and in many cases they have limitations: no palettes (forcing collapse of palette indices and usually removal of palette information), no transparency (forcing compositing of transparent images on some background) or binary transparency (unavoidably losing information from the alpha channel).
If you are bold, automatic dithering and colour quantization could be used to convert from the original colour to a specified output palette or to a reduced colour depth format (multiple previews and outputs would make trying out different compromises much easier).

[happymonster]

Ok. Well I will have my own file format which supports layers (similar to photoshops). This will be a master file format so no information is lost.

It sounds like what you want is a True Colour Format with Alpha channel support and palette entries too. This is certainly possible, but I can't quite grasp the benefits..

I would like to add things like colour remaping and quantization. Obviously that's more complicated to add, but would be nice.

[happymonster]

Added:

* HSV sliders now update if RGB are changed, and vise versa.
* Simplified palette gui section by removing RGB & HSV text and making RGB values appear 'dynamically' (see below) and re-ordering 4 pen layout to be symmetrical.
* "Pix-e" text in top left now fades out and is replaced by information on colour index in palette and RGB values when cursor is over colour in the palette, OR in the canvas.
* Colour underneath mouse cursor when in canvas area of screen is highlighted by a white square in the palette.
* Palette logic code now correctly uses the palette view x and view y mode so you can now view and select from a palette of 4-256 colours.
* Brought bottom line co-ords and help text to top of screen (replacing file name info). This unifies the X and Y info with the RGB values to the left and keeps the eye's attention fixed in top left of the screen where the most important objects are (RGB values, XY, palette entries and main tools).
* Shrunk bottom border, which will now just contain horizontal slider for image view X and border to the right will contain vertical slider for image view Y.

[9_6]

Can you only pick colors through sliders like in graphics gale?
If so, how about an actual color selector like in photoshop or paint or any other painting program? Would be much more intuitive than dealing with raw rgb values.

Also will this support animations?

[happymonster]

You will be able to pick colours from either sliders of colour selectors like in Photoshop.

I will try to support animations to at least a basic level.

[happymonster]

Added:

• Pen ID colours (i.e. the borders around the pen colours below the palette entries and around the appropriate palette entries) are now read from the external palette and image.
  
• Button gfx (little mouse button graphics) now use these pen colours as well instead of being fixed.
• Help text is now coloured according to button colours to reinforce association and provide more visual information of button->action based on colour.
• Eyedropper mode #1 - click on pen box, then either on the palette or the canvas to set that pen to a new colour. Right mouse button cancels.
• Eyedropper mode #2 - Holding down control (this will be user selectable in future) when over canvas will change your cursor to an eyedropper. Pressing a button combination now lets you store that colour in the appropriate pen.

No more comments, or feedback? 

[happymonster]

Added:

• Right mouse button on pen 1 will swap with pen 2
• Right mouse button on pen 2 will swap with pen 1
• Right mouse button on pen 3 will swap with pen 4
• Right mouse button on pen 4 will swap with pen 3

Latest screenshot (editing Pixe's icons in Pixe itself..):
www.funkemunke.com/Pixe_5.png

[9_6]

Looks quite useable already.
I didn't read all posts here so I don't know if it's already implemented but how about a 100% preview like in graphics gale?
If you do animation it could also play all frames in an endless loop which is graphics gales best feature imo.

Also can you move the canvas outside of the window kinda like in the newer photoshops when in fullscreen mode?
Life gets so much easier if you can and -at least it looks like that- it's easy to implement...

Also pressing space should be the hotkey for the picture mover.
The lack of that (you couldn't even map it to space since it has to be that useless menu) and the movement which is restricted to the window is what makes graphics gale feel kinda retarded compared to photoshop...

[surt]

• Eyedropper mode #1 - click on pen box, then either on the palette or the canvas to set that pen to a new colour. Right mouse button cancels.

So it is blocking? Don't like the sound of that. Wouldn't it be better to have an active "pen box" on which various actions are performed, such as pick-to-active, (it's still modal, but at least it isn't modal and blocking) and how else are you going to use the colour sliders for different "pen boxes"?

Otherwise it's looking and sounding quite nice.

Also pressing space should be the hotkey for the picture mover.

That I disagree with. While its extra size is convient as a result of it the space-bar has the down side of extra springs to push against and a generally poor feel which makes any other key a better candidate IMHO (I hate games that use space for fire, or platformers that use it for jump). Customisability would satisfy both opinions for better goodness.

The lack of that (you couldn't even map it to space since it has to be that useless menu) and the movement which is restricted to the window is what makes graphics gale feel kinda retarded compared to photoshop...

That I agree with. Similarly strokes being restricted to the view area has a good share of retardedness.

[happymonster]

9_6:

You will have various 'split' window options with each having it's own zoom setting (as in promotion)

Also can you move the canvas outside of the window kinda like in the newer photoshops when in fullscreen mode?

I've not seen the latest photoshops, but you can move the canvas outside of the window at the moment (if it's completely out you can't move it any further away from the start)

All hotkeys will be (when implemented) user-definable.

Surt:

It's only blocking in that you can't draw or select a colour without the eyedropper functionality being used. You can still use all the tools, sliders change to different tool optionsm etc.. Is that what you meant? Are you talking about having a seperate pen colour for colour option settings (and not pen 1?)

As for the scrolling issue:
Bear in mind that at the moment you can hold down the middle mouse button and move the mouse to scroll the view (This works in all drawing operations too).

[9_6]

Also pressing space should be the hotkey for the picture mover.

That I disagree with. While its extra size is convient as a result of it the space-bar has the down side of extra springs to push against and a generally poor feel which makes any other key a better candidate IMHO (I hate games that use space for fire, or platformers that use it for jump). Customisability would satisfy both opinions for better goodness.

Do you use graphic programs?
Almost all of them do that and you get used to it pretty quick.

Hell, even simple oekaki programs have space=scrolling.
While I agree with you that space is not the best key to map jumping in a precision jumping game to (although it works just fine in any egoshooter) it's pretty much standard for scrolling in graphic programs.
If I wanna move the picture up, I keep space pressed and just drag that thing up. Nothing wrong with space here.

All hotkeys will be (when implemented) user-definable.

Another detail that might be worth mentioning would be that the previously used tool should be automatically selected once the scrolling-button is released so you would not have to press space *scroll* b *draw* space *scroll* b*draw* e*erase* etc. all the time.
I know it's canon and you're probably already doing it but if you don't, things become tedious.

[happymonster]

You won't have to press another key to re-select a draw tool after scrolling..

[happymonster]

I'm going out tonight, so it would be good if some of the many people who read this thread .. would help with ideas, features and maybe even better fonts and icons!
SHOCK HORROR..

[happymonster]

Well! Looks like I'll have to do everything on my own.. 

Here's the start of the Grid options. You can currently set different sizes, turn it on or off and the lined grid will appear instead of whatever transparent colour is set (need to make this selectable). You can load and save images and the grid isn't saved, but is there to help with sprites/tiles.

Still need to add checked grid, snap to grid, fit to grid, etc.. But it's workable already to a certain extent.
(MODS: If this is too big, please change to a link.. It displays fine here for me with sliders, but not sure of the policy.. Thanks!)

[AlexHW]

id suggest an option for a more minimalized gui, something more compact(to save screen real-estate for the actual canvas)(smaller icons), with options of hiding/revealing different pieces of the gui. maybe mousing over something reveals a dropdown menu type thing for stuff..
for example, brush sizes could be reduced to one button which when hovered over reveals the choices.. same with the grid options, etc.. and the botton you hover over could change to show the current choice etc..
i dont know if these have been mentioned before

[happymonster]

Sorry Alex, it's a little late to try to redesign the whole GUI now. The whole design is built around a fixed width vertical panel which has different sections for different tools and options. I hear what you are saying about expanding buttons, but it wouldn't fit in with the design style IMHO when I have the space available to have a seperate icon for a different tool/option.

The icons might be bigger than normal, but when I compare it to Photoshop with all the layer/palette windows options open I think isn't that bad!

[AlexHW]

well, i dont see the advantage of having it larger just for the sake of it. there are plenty of reasons a minimal non-obtrusive gui would be preferable and better.
this is the new approach nowadays. having it clunky as yours just makes it feel outdated and ameteur.


edit: also, you should expect the user interface to change as you develop a program such as this. its not possible to predict how exactly it should be in the beginning. so having the attitude that its too much of a hassle to change it now isnt good in my opniion, course  this is your project, so you;re free to do it how you want. im just giving my opinion.

[happymonster]

Alex, I have changed things. But I said at the beginning that some things will stay the same and that the GUI is probably one of them.
I have incorporated suggestions regarding colours and features and I have changed the GUI in some ways since starting.

However I am not now able to going to scrap the entire GUI to make it use the kind of interface you describe. It would be too much work and I wouldn't be happy with the interface myself anyway.

As for the large icons, they are large because a) they are easier to select and b) as screenmodes get larger and larger they will be needed over small icons.

To answer your questions in more detail. I can now click on an icon, have the options open up and then click again on one of the tool options. To do the same with expanding icons I would need to move over a tool icon and wait a second or two and then select another icon. It just seems less efficient to me to have to wait.

Also, photoshop which is an industry standard has probably got this kind of layout for a lot of people:

That is actually a smaller canvas area than I have now..

[happymonster]

Added:

• Checked grid option
• Grid offset X & Y values
• Grid Brightness slider

[happymonster]

Alex:

I apologise if I came over rude or aggressive/defensive.. I just honestly believe that this approach will work for myself and other people more than other GUI styles.

Thanks,
Richard

[happymonster]

Added:

• Checker grid pattern
• Snap to grid
• Fit to grid (to keep lines, boxes and grabbing brushes within a tile boundary) - was on Personal Paint on the Amiga.
  
• Grid co-ords, look at the top right and you will see the x, y and 'tile' number for this square on the grid. Useful when doing games and tile work.
  

[flaber]

Hey,
so i havent gotten a chance to read this whole thread yet, since its numerous pages long..
but ill still suggest a few things.
sorry if they have already been mentioned.

for color selection; one thing that i really like, and use with most programs i can is numerical values.
In MSpaint, and Corel Painter IX, both have color sliders as well as Hue, Sat, Lum numerical options.
I choose most of my colors, and have memorized color combinations off of their number values. So I dont know if you have this included.. or if its just straight sliders. I seem to spend way too much time playing with sliders than need be.

atleast one transparency that you can set to any color, like in MSpaint. Nothing even fancy, with different percentages of transparency. Just full or not.

Layers. Layers would be super beneficial. And again, not even necessarily have to worry about it being at different opacity percentages. Just plain layering, nothing fancy. For such things as tracing sketches, or for pattern experimenting.

For colors.. If you could have a finished image.. and color slider the whole thing.. Not sure what the proper term is, but you can do it in Painter IX, and photoshop. Where you adjust all colors together, so their ratios are all the same, but changing together.. So you can turn the whole thing red, or blue, or green, etc.

Lastly, which goes along with Alex
is I like a clean workspace. The programs I use are MSpaint (which already has nothing to it..), Corel Painter IX, and Adobe Illustrator. With Painter IX and Illustrator I like to try and have as least as possible options and featurs open.
As I need something Ill pull it open from the top, and then close its window after.. or minimize it.
So, Im not saying anyting fancy like mouse over options.. or minimizing each section.. But if you could turn things on or off.
And access it at the top bar. MSpaint has this option under View. I refer to that, because that seems to an industry minimum standard.

Just my few suggestions. sorry if these are all repeats, or if you have these done already.

[happymonster]

Hi Flaber,

Thanks for the comments!

The sliders do have values which you can see, and at the moment you can see RGB & HSV sliders and values when you change a colour.
It will indeed have layers.. (The core code is already in there)

I can understand your feelings about GUI space, but one thing I perhaps haven't explained clearly is that this program will (eventually) have a multitude of different options and tools. As such I do need to have a bit of GUI space, and I find it cleaner to have that space fixed than in a system that has some tools take up a small amount of work space and others a lot more work space.

Also, I am not a GUI programmer, my skills in this area are basic as I am better at graphical tricks and ideas. Still, I hope people do like using the program once they have gotten used to it. It might seem more familiar to people who grew up on DPaint and Personal Paint on the Amiga.

[happymonster]

Added:

• Added Ellipse/Circle tool options.
• Added symmetrical (and quite optimised) hollow and filled ellipses and circles.
• Hollow ellipses and circles use brush thickness.
• Filled ellipses and circles work in the same way as in DPaint and Promotion.

[flaber]

well thats fair.
your doing this just as a side project.
And if GUI is out of your realm, thats fine.
im interested to see a demo.

Also - the one last other thing that I forgot to mention would be nice.
would be simple gif animation compiler.
a simple animation option would be absolutly prime.

[happymonster]

Can you explain what you mean by Gif Animation compiler? Do you mean an option to save an animated gif from loaded images/frames?

[happymonster]

Added:

• Basic Fill tool

[Larwick]

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.

[happymonster]

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

[happymonster]

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

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

[flaber]

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.

[happymonster]

Full screen? Hmm.. it should be windowed! 
Can you try pressing F7 and see if it switches between a windowed/fullscreen mode?

[TrevoriuS]

-does switch, but at startup it's fullscreen. also, it stays on top when focus is lost. get rid of that!
-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

[Jad]

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!

[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

[Ai]

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

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)

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.

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.

[Ai]

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.

[Ai]

SF3 uses it in an even greater degree than I described, because if you pay attention closely...they do not only have different hue information for every part of the sprite, they have two totally different and separate palletes that go from the brightest color to the darkest color for every single frame. That is how they make their two lightsources, they have the normal sprite and the blue sprite, then they use some kind of tool to tell the painting program which part uses the blue hue, and which one uses the normal white hue.

if you think this could be of any use at all...I have an even more complicated idea about this...involving actually completely diferent shadings for each hue.....it would be useful for characters that have chromed armor and normal clothing...

Are you thinking like a separate channel for each hue?[1] Or what?

(IMO, you'd be better off using the word 'ramp' where you use 'hue', since 'hue' also refers to a property of individual colors)




Another idea: thresholded gaussian blur (as a filter-brush type thing). The idea here is not to blur exactly, but to smooth the shapes without changing the pixel colors.
This is kind of apropos to the 'interface morphology tool' in that it would work on the interface between two colors.
I used a two-step process amounting to this recently when I had some partly lumpy regions that really should have been smooth. This is particularly useful if you've just rotated or skewed the image, it tends to get odd stick-outy pixels where you really don't want them.

[Conzeit]

* 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 never really thought about it in the sense that we'd extrapolate the exact brightness trough lab colorspace X/Z cordinates or something like that...mostly because I am an artist and I've never been able to stand coding..so I dont have that thought set...I think your skillset gives you the capability to understand it with better metaphores in color theory and coding, but you tend to understimate the usefullness of just letting the end user customize things 

Ideally, I think it should just be a way of handling palletes that is ramp-oriented. That is so that when as you said there are ramps of diferent length than the "baserampsize" it is the user that decides how exactly they match up...because no matter how accurate LAB or whatever is it just doesnt know what you're going for.

Say you have the sprite's clothes, then you have his metal armor...and his hair or whatever.


 You know that his hair has two extra shadow tones, while the armor has two extra highlight tones...you just scroll the two ramps so they overlap in the way you know they should (excuse the hideous pallete....:p)

In practice I guess the program would handle the tones from ramps with greater length as duplicate pallete entries (anything past the brightest red color will still be handled as the brightest red) but the idea would be that the program would only do it in a internal file format which would 'know' which are the duplicate entries, and you'd be able to export the file with clean single entries.

Now, suppose you wanted to add the extra shadow tones to the metal as well, but you dont want to add any extra tones
you just tell the program to use the two hair shadow tones for that, we already do that but we've no way of recording that those two entries in the ramp although the same tone as the ones in the hair one, are from the metal ramp. The idea would be to fix that...so that if suddenly it turns out that your game is going to a new platform that allows 2 more shades (or more likely you just decide to feck the limitations) it isnt a mess to recolor.

The whole third dimension view to it when adding multiple light sources ( I wonder if light sources is correct..more like chromatic filters..heh) sounds very smart.


And you are totally right about the 2bit fuck up. Although familiar with the term and the concept, I dont often use it so I fucked up even though I knew 1 bit is 0s and 1s  should just man up and say two colors lol.

[surt]

Tried the build.
Wine kept complaining about DLL's, so I booted into windows () and it ran fine though full screen as the others mention.
Things I noted:

• When zoomed and using a one-pixel brush the brush isn't correctly placed on the pixel the cursor is over.
• With grid fit on the ellipse snaps a pixel too short on each axis with stretch and a pixel too long with expand.
• The inverted panning is yech!
• Slow zoom is yech!

Otherwise quite nice, runs nice and responsively, stroke samples very smoothly.

[TrevoriuS]

• When zoomed and using a one-pixel brush the brush isn't correctly placed on the pixel the cursor is over.

I don't seem to have this :O

• The inverted panning is yech!

Nah, this is natural, you're just used to the wrong

[happymonster]

Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

I'll try to write more tonight, but got to go to work now.

[Frychiko]

It's coming along very nicely, feels very slick and I like the animation in the GUI (fading text). The whole app just barely fit on my netbook screen! (1024 x 600). Keep it up!

[surt]

I don't seem to have this :O

For me it's by about half a vertical pixel. Horizontal looks right.

Nah, this is natural, you're just used to the wrong

Not according to GraphicsGale, Gimp and Blender. AFAIAC if the canvas is moving and the cursor is moving they should be moving together, if the cursor was locked I could live with inverted panning (see Transport Tycoon).

Cursor locked panning would be nice as an option anyway, as then you can pan off mouse mickeys, rather than cursor displacement, and not be window limited.

[Jad]

Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

I'll try to write more tonight, but got to go to work now.

Don't be disencouraged, save all these resourceful replies and use them later if the need arises! I'd say what you've got going is super cute (yes, pixel software can be cute), so go ahead and take the suggestions you can work with and DON'T FEEL PRESSURED! I'm super impressed with what you've got!

[surt]

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

A good argument for using an existing widget toolkit, no?

[Ai]

Woah! Far too many comments to reply to..

I will just say before I leave for work that the reason I failed to finish two previous paint programs was because I got bogged down in trying to make a super flexible GUI design. I am good at graphical programming tricks and effects, but very poor at GUI and other low-level stuff.

As such, as I have said several times now, I CANNOT make a GUI that would rival photoshop, promotion, etc.. To try would just lead to the project being abandoned. I know my own strengths and weaknesses.

You might be able to play to them better if you use a GUI toolkit that's already made. This does not obligate you to have lots of light gray. http://www.clutter-project.org/ for example, is OpenGL based, fast, and the license doesn't require you to release your sourcecode. And they seem to like darker appearances

[Ai]

I never really thought about it in the sense that we'd extrapolate the exact brightness trough lab colorspace X/Z cordinates or something like that...mostly because I am an artist and I've never been able to stand coding..so I dont have that thought set...I think your skillset gives you the capability to understand it with better metaphores in color theory and coding, but you tend to understimate the usefullness of just letting the end user customize things 

s/extrapolate/interpolate

Basically it's because not every ramp is going to end and start on the same brightnesses, we need to know how each destination ramp maps onto the base ramp. Your idea of what would need duplication is slightly different from mine.

Yeah, as a programmer who cares about UI, I try pretty hard to minimize the requirement for customization.
Every additional customization increases the amount of confusion around a program geometrically

Ideally, I think it should just be a way of handling palletes that is ramp-oriented. That is so that when as you said there are ramps of diferent length than the "baserampsize" it is the user that decides how exactly they match up...because no matter how accurate LAB or whatever is it just doesnt know what you're going for.

Say you have the sprite's clothes, then you have his metal armor...and his hair or whatever.


 You know that his hair has two extra shadow tones, while the armor has two extra highlight tones...you just scroll the two ramps so they overlap in the way you know they should (excuse the hideous pallete....:p)

So just to be clear, this is your 'more complicated idea'? Explicitly-known ramp ends so you can visually offset them so they line up appropriately?
Actually, that is complicated. And surprising -- apparently I misunderstood your original, simpler  idea, because what you describe above is in my understanding not compatible with the above
(because in order for the simpler idea to work (single master ramp mapped to multiple maybe shorter ramps), you basically have to have the equivalent of that offset information anyway

In practice I guess the program would handle the tones from ramps with greater length as duplicate pallete entries (anything past the brightest red color will still be handled as the brightest red) but the idea would be that the program would only do it in a internal file format which would 'know' which are the duplicate entries, and you'd be able to export the file with clean single entries.

Oh I see, you're aiming for just a drawing tool, not also to be able to do strongly controlled colorswaps like I guessed you meant SF3 did. Maybe they didn't have such a thing.

Anyway there's some real benefit to exporting it with duplicate entries, and I would count the result as clean..
What I was thinking is like this:
1. Measure the brightness of the first and last color in the 'base' ramp
2. Normalize the destination ramps according to  this (measure their endpoints in order to do this)
3. Allow the user to override the brightness that the end colors of destination ramps are considered as.
4. Nearest-neighbor 'interpolate' and extrapolate each destination ramp so each ramp maps in a fairly reliable way to the original ramp.
(it's trivial to recover the without-duplicates version, providing you store the 'endpoint brightnesses' information with the ramps. duplication is just so ramp-swapping is just a quick matter of copying a tiny chunk of data.)

Now, with this scheme, you could always make sure that all of the colors in your ramps were accounted for, there might be duplicates before or after the original ramp contents (or even during, since the ramp might be stretched.),
and you would always be able to do ramp swapping in a snap. (normally, palette swapping is a snap but not ramp swapping. This is just because the ramps differ in length.)
Let me demonstrate:



It's nothing mind-blowing, but it does make sure a) you only have to do a single lot of shading and b) every ramp can be used in place of any other ramp for that sprite.

Now, suppose you wanted to add the extra shadow tones to the metal as well, but you dont want to add any extra tones
you just tell the program to use the two hair shadow tones for that, we already do that but we've no way of recording that those two entries in the ramp although the same tone as the ones in the hair one, are from the metal ramp. The idea would be to fix that...so that if suddenly it turns out that your game is going to a new platform that allows 2 more shades (or more likely you just decide to feck the limitations) it isnt a mess to recolor.

Oh right. yes, that's kind of problematic. I've been working on that too, it's fairly involved though, I have
'Master palette', 'Resource Ramps', 'Rendering Ramps', 'Rendering palettes'
we're talking about 'Resource Ramps' here (ordered lists of indices into the master palette, basically).
'Rendering ramps' are, roughly, formulae for combining and resampling ramps; 'rendering palettes' are just ordered lists of references to rendering ramps (with possible uneven spacing, but that's only of interest for CGing), which render into normal palettes (among other things.)

I've suggested a simplified version for OHRRPGCE over here:
http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php?title=Talk:Plan_for_256_color_sprites&curid=5027&diff=18503&oldid=18502

[/quote]
The whole third dimension view to it when adding multiple light sources ( I wonder if light sources is correct..more like chromatic filters..heh) sounds very smart.
[/quote]
It sounded better originally.. but basically, you had just described a new 3-dimensional colorspace..
Not very like RGB, LAB, HSL, Yiq, etc but nevertheless, same basic idea. Lightness Ramp Palette -- LRP colorspace. 

Two colors is good.

[happymonster]

To answer a few key posts:

Conceit

the whole HUD feels just WAAAAY WAAAY too big, way excessive for the few tools you have

No need to shout.. 

It has a few tools now, but it won't in the future as it will have a lot more. Hence why the space is reserved until most of the tools are in there and then I can reorganise things.

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.

I never said I was a pixelartist! I'm a poor artist who likes to play with gfx and techniques. I like the little descriptions, but I suppose they might be unneccessary after a while.

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.

Your right, but I'm not an artist..

For everyone who has commented on the GUI, Icons, etc.. Do you want to help me with some new icons, fonts, designs, mockups to show me what you mean and to help me in general? If not, then don't expect me to be able to achieve what you'd like on my own!  There must be some good artists and graphics designers on here after all. 

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.

You can use the normal left and right mouse button drawing or hold shift to draw with another two colours (useful when you are wanting to draw using 3 or 4 colours and don't want to keep changing the current pen colour from the palette or with a dropper on the canvas)

Ai:

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)

I am thinking of moving towards a more data driven design with configuration files. It's just that this is the kind of low level work with which I can lose motivation and get frustrated. This time I want to get a lot of the program in there before trying to refine things. It might be a bit backwards and inefficient, but I'm not a classically trained programmer.

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

I did look at that.. you are obviously a very intelligent guy and have thought about things like this deeply. The maths you refer to in your posts sadly goes over my head.. 
For this particular point I am thinking of having several icon tabs where you can select from a range of colour selection methods, i.e. sliders, colour box, etc..

You might be able to play to them better if you use a GUI toolkit that's already made. This does not obligate you to have lots of light gray. http://www.clutter-project.org/ for example, is OpenGL based, fast, and the license doesn't require you to release your sourcecode. And they seem to like darker appearances Smiley

True, but I'm not too good at using other libraries as I get frustrated quickly with setting them up and using them properly (especially Object Orientated ones).

Jad:

THANK YOU!
I must admit I was feeling pretty discouraged when I saw some of the C&C. While a lot of it is valid, please remember that I'm doing this as a hobby, I'm not a professional programmer and I'm not trying to sell it! 

Finally, mockups showing me a better GUI, icons, fonts, design etc would be welcome.. I'm sure some of you always wanted to do your own designs for a paint program! I'm not saying I'll use them, but it might help me.

[happymonster]

Ok, I've updated the zip file. I don't know it the new program file will open up as a window now, I hope it does. I've also added a Pixe_desktop.exe in there which tries to open a window the full size of the desktop - the taskbar and title bar. No idea if it will work for you though!

[Ai]

You can use the normal left and right mouse button drawing or hold shift to draw with another two colours (useful when you are wanting to draw using 3 or 4 colours and don't want to keep changing the current pen colour from the palette or with a dropper on the canvas)

I think you'll need to monitor this and make sure it isn't YAGNI (You Ain't Gonna Need It), especially considering you do (or will, presumably) have keys to move to next or previous color. IMO it might be more obvious to provide a shortcut that swaps the first two colors with the (otherwise unknown and not shown) second two colors and vice versa.

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)

I am thinking of moving towards a more data driven design with configuration files. It's just that this is the kind of low level work with which I can lose motivation and get frustrated. This time I want to get a lot of the program in there before trying to refine things. It might be a bit backwards and inefficient, but I'm not a classically trained programmer.

This makes me wonder if you write unittests for your code. If not, consider it -- Test Driven Development solves a lot of the motivation problems with anything where you can't obviously see or interact with the result. (such as.. pretty much anything that's not UI:)

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

I did look at that.. you are obviously a very intelligent guy and have thought about things like this deeply. The maths you refer to in your posts sadly goes over my head.. 

Thank you; If the math goes over your head I've not explained accurately.
There is no specific math inherent in it. My setup assigned a formula to each cell, but it needn't be so customizable,
it could be hard-coded and still be effective; so the only math involved is in calculating each cell's color
(interpolation, hue offsetting, etc..)

For example, as cells you could include:
(where i say 'first color' I mean the color you draw with on the left button without shift.)
* the two next and two previous colors in the current ramp (relative to first color), 
* 4 steps of interpolation between first and second color ie (aXXXXb)
* 4 versions of first color with saturation offset (two more, two less)
* 4 versions with increased/decreased lightness (whether you treat lightness as L of LAB, L of HSL, or V of HSV is up to you)
* 8 versions with various color-theory relationships to the first color (counterpart, contrast, triad, tetrad)

Thus, a somewhat different calculation is used to choose each cell's color, and is applied each time the foreground/first color changes (eg. clicking on a color to select it in the table of cells modifies the fore/first color, so all cells including that one must then be regenerated).
The only other very important part of that mockup I showed is really being able to swap between colors by clicking on the fore or back color
(it's designed for 2 colors, but you could modify that scheme to work for your 4-color setup)

For this particular point I am thinking of having several icon tabs where you can select from a range of colour selection methods, i.e. sliders, colour box, etc..

Yeah; I just meant, if you implement a relative color selector such as the one I described earlier and above, there's much less need for sliders.

You might be able to play to them better if you use a GUI toolkit that's already made. This does not obligate you to have lots of light gray. http://www.clutter-project.org/ for example, is OpenGL based, fast, and the license doesn't require you to release your sourcecode. And they seem to like darker appearances Smiley

True, but I'm not too good at using other libraries as I get frustrated quickly with setting them up and using them properly (especially Object Orientated ones).

At this point I have to ask whether you seriously think that, in the writing of a paintprogram, you can avoid writing and debugging enough GUI code that your frustration surpasses the frustration of setting up and using a premade GUI library. If you do, your frustration must be astronomical.

Finally, mockups showing me a better GUI, icons, fonts, design etc would be welcome.. I'm sure some of you always wanted to do your own designs for a paint program! I'm not saying I'll use them, but it might help me.

Mm, I have a few of those, relating to palette/ramp editing, plus some other ideas from my own pixel software I'm working on. You are welcome to those. If you PM me with an email address, I can send you the entire SVG (300k, mostly of text), or you can wait and I'll take a few captures of some areas and post them here.

[happymonster]

Just got back in after seeing friends before Christmas. No time to reply properly, but I will just say that for the 4 pen colours thing I don't think it's overkill. After all it's completely transparant to the user if he/she doesn't want to use the extra two pens. In the situations where it would be useful, they always have the option.

*Added fill to colour (which if you fill with the left mouse button will only stop when it hits the colour in the right mouse button pen - useful for filling to outlines, etc..)
* Made zoom steps multiply, ie. x1, x2, x4, x8, x16, x32, x64. Much faster, but less precision. Not sure if it's too low..

[Ai]

Just got back in after seeing friends before Christmas. No time to reply properly, but I will just say that for the 4 pen colours thing I don't think it's overkill. After all it's completely transparant to the user if he/she doesn't want to use the extra two pens. In the situations where it would be useful, they always have the option.

It's only transparent if it doesn't occupy any screen space when not used.

*Added fill to colour (which if you fill with the left mouse button will only stop when it hits the colour in the right mouse button pen - useful for filling to outlines, etc..)

Interesting -- essentially 'binary fill'.

EDIT - Oh! This inspired an idea, so I fired up IPython and SciPy and tested it.

Higher order floodfilling -- eg. 12-way, 20-way.

12-way : dither fill, less invasive.  Fills most regular dithering in one click.
Queues pixels to fill like normal 8-way fill:

Code: [Select]

###
#.#
###
[code]

then checks the locations shown as *
[code]
  * 
 ###
*#.#*
 ###
  * 
and may queue them for filling if
a) the pixel is of the seed color
b) the immediately adjacent pixel (which has already been checked) is NOT of the seed color

I already have a slow implementation of this myself, available on request.

20-way : dither fill, more invasive. Fills even irregular dithering in one click.
Queues pixels to fill like 12-way fill,

Code: [Select]

  * 
 ###
*#.#*
 ###
  * 
Then checks the locations shown as !

Code: [Select]

!*!
!###!
*#.#*
!###!
 !*!
and may queue them for filling if
a) the pixel is of the seed color
b) the immediately adjacent two pixels (which have already been checked) are NOT of the seed color
(I also have a slow implementation of this)

(original image by me)
This is what they look like. each weird color represents one N-way floodfill.
First the original is shown, then the 12-way floodfill, then the 20-way floodfill.
You can see that 20-way does a more comprehensive fill, while also jumping around corners more.

another example:
(original image by Riva)

I think a lot of people around here would appreciate that kind of tool:)

EDIT2: Checking your ideas.xls, you actually have that general idea, without the specifics or testing shown here.
that thing is huge and intimidating

* Made zoom steps multiply, ie. x1, x2, x4, x8, x16, x32, x64. Much faster, but less precision. Not sure if it's too low..

Well, personally I think x3 is important (x128 is not so important, I would just like it). I like the idea of a sequence like this:
[1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128]

And it would probably be easier to have a precomputed lookup table of zoom levels rather than computing them in real time, and just have internal_zoom as an integer value from 0.. (length_of_zoom_lookup - 1). That'd also make it pretty easy to experiment with different zoom steppings.
[/code][/code]

[Ai]

Just spotted this in the ideas.xls:

AA layers - Layers store colour sum and weight sum seperately for better quality alpha mixing and AA

I think I 'get' the motivation behind this, and it might be fulfilled by simply blending correctly (that is, when calculating a mix between two colors A and B, convert from standard gamma-encoded sRGB to linear RGB before doing the calculation.). I think this idea is simply motivated by the weird unpredictable AA that blending in a gamma-encoded space causes (if not, Surt, feel free to enlighten me). I would guess you already had gamma-correctness on the list, but you don't. Solving this should also improve the state of #49, 'simple rgb average, real as perceived'

[questseeker]

Ellipses are awful. Rounding the center to pixel centers and radius to whole pixels, so that even sizes are impossible, is even worse than rounding incorrectly.

[happymonster]

[1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128]

Yes, I was thinking of doing something like with a look up table. Just not had chance to implement it yet..

I like the flood fill testing, but I have an idea which might work better? Instead of testing horizontally and vertically like you do now (when most flood fills use horizontal or vertical spans) why not match the source pixel to ones in a target pattern? That would allow you to fill in custom dither pattens, as well as small patterns and potentially shapes that have previously been filled in with a pattern from a brush. Finding the XY offset for the pattern might be a bit tricky, as would trying to automatically find repeating patterns.

What do you think?

It's only transparent if it doesn't occupy any screen space when not used.

True again! But it's only two small pen gfx..

Ellipses are awful. Rounding the center to pixel centers and radius to whole pixels, so that even sizes are impossible, is even worse than rounding incorrectly.

Er.. thanks!  ProMotion seems to work in the same way.. Can you give me an example of how to do it?

[happymonster]

Right, the windowed->fullscreen thing was apparantly an engine issue. I think we've fixed that in the latest uploaded zip file.

I've also added the zoom look up table feature using this set of values:
1, 2, 3, 4, 6, 8, 10, 12, 16, 24, 32, 48, 64, 96, 128

It works nice for me when zooming, what do you think?
I've also updated the spreadsheet to reflect some of the features which have been implemented in the last week or so.

Any more ideas on the gui designs from the dissenting voices then?

[happymonster]

Alright.. I've been messing around tonight with an analysis of the GUI of different programs. I know that some people that tried Pixe would have been looking at it in fullscreen modes, so it would have looked bigger than running in a window.

I'm made a comparison here:
http://www.funkemunke.com/Pixe_GUI_work.png
(900k file)

As you can see it's not actually that bad compared to other programs in terms of GUI space (the panel in Pixe is the total GUI space, so less width than the tools + layer panel stuff in photoshop). However an analysis of Photoshop CS, Photoshop Elements, GIMP, Texture Maker etc, seems to reveal a standard icon size of around 24 x 24 pixels (compared to the 32 x 32 in Pixe). Photoshop and Photoshop Elements actually use a size which is slightly shorter in height than width for its icons which makes sense for a vertical arrangement of tools.

In terms of width, Pixe is 256 pixels across, which some people here have complained about. Photoshop and Texture Maker use more GUI space in terms of width (with gui sections combined), but perhaps some of the effect is more psychological. Maybe the 75% size panel with 24 x 24 icons works better for most people..

Things to note: Texture Maker has the most complex GUI and uses a more fixed width style (like I am using) but with collapsable GUI sections. How well do these actually work? Sometimes I find them confusing, maybe that could be an option for the GUI if I can manage to do it?

I love the pixel perfect bold 8-pt tahoma font that Texture Maker uses. The lower class character gfx helps in all of these programs. Something I could add to soften the look?
 

[Ai]

I like the flood fill testing, but I have an idea which might work better? Instead of testing horizontally and vertically like you do now (when most flood fills use horizontal or vertical spans) why not match the source pixel to ones in a target pattern? That would allow you to fill in custom dither pattens, as well as small patterns and potentially shapes that have previously been filled in with a pattern from a brush. Finding the XY offset for the pattern might be a bit tricky, as would trying to automatically find repeating patterns.

What do you think?

It would certainly fix the 'invasiveness' problem inherent in 20-way filling.
(the 20way filling was deliberately 'a generic fill for most dithers' so the user could get a good result without needing to configure which patterns to search for; so 20-way fill actually copes with a lot of custom dither-patterns already.)

One of the things you didn't mention is that usually dither patterns come in groups, so matching to one of several same-size patterns is probably a more realistic use.

I've actually tried to do that before, but have a much better idea of how to do it now.
the alignment issues.. I think it requires a two-pass approach:

Preparation:
 1. Generate a binary mask for the entire image, which is True where the pixel matches seed color.
 2. Initialize a 'matched' array (uint8) to 0 (1 == pattern 0 matched , 2 == pattern 1 matched..)
 3. Calculate hashes for each of the patterns being matched

Execution:
 1. SCARY. But mainly, treat the current location as upper-left, then hash that rectangular area of the seed-mask and compare it to each stored hash. Don't try to match areas where >= half of the pixels have already been matched.
If it matches a hash, store the result in a temporary list, and keep searching with different offsets.Inspect each item in the list for best 'suitability', which tries to minimize the amount of neighbouring True pixels in the seed-mask, and mark the best area.
 2. Try to match any remaining areas where one or more unvisited True pixels in the seed mask remain.
If the area is partially visited, prefer matching one of the already-matched patterns listed in the matched array.
(possibly need to support matching a partial pattern.. eg for the left side of the picture, if the leftmost 2x4 are unmatched and the next 4x4 is matched, need to match just the half of the pattern that fits on the picture.)

Obviously that isn't a floodfill; I find it a bit difficult to think how to constrain it in the usual floodfill way.

A variation on that scheme can be used to convert dither patterns -> some solid color.

Just for fun, I have a really simple dither-detection aka high-frequency noise detection algorithm that is relatively immune to XY offset.

1. Move in steps of 2 pixels along y,x axes
2. Calculate an average for the 4 2x2 squares at offsets (+0,+0), (+1,+0), (+0,+1), (+1,+1)
3. If the averages are all equal and the pixels are all equal, continue the loop at the next position.
4. Check those 4 averages against each other. each pixel is included in 3 of them, and
    if the averages that a pixel is included in all match, that pixel is marked as dither.

Your GUI isn't really as big as I thought. What's that toolbox labelled 'icons 27x25'?

[happymonster]

Just off to work, so can't responsd properly..

I think there is an easier way to do the fill, will try to talk about that this evening (my time)
The 27 x 25 icons are from Photoshop Elements.

[happymonster]

Here's a test using a 75% size (192 pixels in width, 24 x 24 icons). Please ignore the pixel resized icons, this is just a test for the size. As you can see the top part of the GUI is in the new size. Does this look better?

http://www.funkemunke.com/Pixe_GUI_test1.png

[Ai]

As you can see the top part of the GUI is in the new size. Does this look better?

Definitely! If you don't plan to put anything in the gaps between pen colors, I suggest expanding them so the spaces are half their current size.
The 'I: 0' confuses me. is that supposed to indicate the color under the mouse cursor currently?

Just off to work, so can't responsd properly..

I think there is an easier way to do the fill, will try to talk about that this evening (my time)

Excellent. I had an idea it could be done with convolution, but my convolution-fu is weak . I look forward to hearing what you think.

[questseeker]

Ellipses are awful. Rounding the center to pixel centers and radius to whole pixels, so that even sizes are impossible, is even worse than rounding incorrectly.

Er.. thanks!  ProMotion seems to work in the same way.. Can you give me an example of how to do it?

You might round both the center (or corners) and the radius to half pixel increments in both directions if the zoom factor is 2:1 or bigger (i.e. if these fractions correspond to distinct cursor positions).
Alternatively, you could have one or two switches or tool states to align ellipses either to the "cracks" between pixels or to pixel centers (at any zoom levels).

[happymonster]

Questseeker: I'm sorry, I don't understand. Are you talking about fractional (i.e. aliased) pixels?

Ai: The i stands for the palette index. Not enough space to put the full word..

As for the fill, well I was thinking that you could ask the user to select the start fill point in an area where the 'full pattern' is visible. So they don't fill in a corner, or narrow section.
Then we could start by assuming that as it's a pattern fill we will have a minimum of 2 x 2. So we could start by scanning that area, and then increasing the width until the pattern starts repeating. If the patterns repeats X times completely in the width dimension then we can pull it back to the original size. (This would help with larger dither patterns that have small repeated area). If we then did the same in the Y dimension, we could probably reasonably 'grab' a dither pattern and maybe other patterns too. Then we can fill any repeating pixels based on the grabbed pattern.

[happymonster]

Ok. I've been working on making the GUI better and smaller in the last few days. Although I like the large look it seems clear that I am the minority and that it will stop me having so many options available at once. I don't want to lose motivation and interest because of getting bogged down in a GUI, but I have worked to improve things.

Changes:
Using bold 7 point Tahoma font which I really like and is smaller than the font used before.
Removed icon 'text' below to save space.
Redrew most icons to fit into 24 x 24 in size. Spacing is the same so they don't appear so cramped.
Removed two icons from tools and shrunk the width by 32 pixels (now 224 pixels).
Made sliders smaller in width and height and repositioned some to see how it looks like.

Now I can have sections open for palette, layers, brush, tool options all at the same time I think. I'm still working on the look.. What do you think? Better?

Screenshot:

[Ai]

Questseeker: I'm sorry, I don't understand. Are you talking about fractional (i.e. aliased) pixels?

Ai: The i stands for the palette index. Not enough space to put the full word..

Yes, sorry -- I knew that, what I was trying to ask is, why is it 0? none of the pens appear to be set to #0, so I asked whether it was showing the color index under cursor in the image. (I have the same question about the white dot in the palette)

Maybe you could show a tooltip when the user mouses over that 'I R G B' area, to avoid this kind of confusion.

As for the fill, well I was thinking that you could ask the user to select the start fill point in an area where the 'full pattern' is visible. So they don't fill in a corner, or narrow section.
Then we could start by assuming that as it's a pattern fill we will have a minimum of 2 x 2. So we could start by scanning that area, and then increasing the width until the pattern starts repeating. If the patterns repeats X times completely in the width dimension then we can pull it back to the original size. (This would help with larger dither patterns that have small repeated area). If we then did the same in the Y dimension, we could probably reasonably 'grab' a dither pattern and maybe other patterns too. Then we can fill any repeating pixels based on the grabbed pattern.

Oh, I see! That's a pretty good reason for limiting it to 1 pattern at a time

What do you think? Better?

*far* better!
* much cleaner icons, and the font is indeed wonderful.
* looks less thrown-together, more coherent.
* Consider making your scrollbars taller if you have the space
   (or make just the scroll handle taller. IMO while scrollbar size is not so important, having a large scrollbar handle is quite important.)

[happymonster]

Thanks!

Yes, the I refers to the palette index (not a pen), so if your mouse is over a pixel of index colour 1 in an image, it will show 1. The white dot will only appear when you are over an image and marks the index colour for each reference.

I'm going out today, so no time to reply in more detail (maybe this evening, my time).

[surt]

You might round both the center (or corners) and the radius to half pixel increments in both directions if the zoom factor is 2:1 or bigger (i.e. if these fractions correspond to distinct cursor positions).

For stretch-from-centre ellipse drawing snapping the centre-point to the nearest pixel-centre/pixel-edge in each dimension would be my preferred solution, with a centre-preview-cursor so you don't have to gauge it by eye. I can't see much need for sub-pixel accuracy beyond that in a pixel editor.

happymonster: Questseeker means that you cannot draw an ellipse an even number of pixels wide or high. It only allows odd sizes. I expect this is why ellipses don't work with the grid fit option also.

[Ai]

They don't seem to grasp I'm not a GUI expert programmer

I say that your insistence on writing your own GUI handling (which is not required in order to have a custom look) amounts to a statement 'I am a GUI expert; Or I'm prepared to become one, because I'm going to invest a lot of time in GUI coding' [1]. 
To me, this is a case of actions contradicting words. In my understanding, someone who makes an undertaking like writing their own GUI is either fairly experienced with UI or so inexperienced with GUI that they do not understand the scope of what they are undertaking.


[1] it's not that you'll need to write a lot of code.. but it tends to take a lot of tweaking. Based on the size of GTK+ (26mb total .c + .h files),
you might end up writing 101k .. 406k of GUI code to complete this.
For comparison, Grafx2 does it's own UI and has about 300-400k+ of GUI code, 400-500k+ if you include all the text used in the GUI (statusbar tips, button names, help, etc.).

[happymonster]

Thanks Surt I think I understand.

Ai: I tend to be happy to program to solve something if I think I can solve it. With things like using OO gui libraries I just get frustrated very quickly and don't want to continue.
Also, people here do seem to think I can do everything with this program.

[happymonster]

I'm trying to work out the best way of doing the palette/palette options. Obviously I only have a limited amount of space so it will probably be some kind of icon tab system where you can select different ways of picking a colour.

That seems the be what other Programs do.

BTW: I've seen several screenshots of GIMP with absolutely massive GUI boxes for tool options, palette's, layers, etc..
And you all had a go at me!! 

[Ai]

I think I understand the following. Let me explain:

Seriously, a selection function mimicking photoshop would be GOLDEN

Like you could fill a layer with a dither pattern (dither/transparent), then hide it, select it to paint autodither, etc.

Has nothing to do with selection IMO; anyway this is talking about cloning ala clone/stamp tool, AFAICS.

Oh, idea!

* picking a dither pattern off the image, by which I mean the pattern, not the colors; In gimp I can select a rectangle, copy it, and use 'clipboard pattern' to paint with that exact pattern with those exact colors. But what I really want is to paint with that exact pattern with the current FGcolor where the pattern mask is TRUE, and where the pattern mask is FALSE, have no effect (ie treat those pixels as transparent when drawing).

Or select an area of one single colour and being able to paint in that area after you've started doing it as well. (as opposed to graphics gale's color replacement where you can only work on the colour that is currently on-screen. This function is great as well, though.

This is like stenciling (not the automatic by-color variety, though. the idea is just to be able to make a selection and then painting operations are limited to within the selection.)

I've seen several screenshots of GIMP with absolutely massive GUI boxes for tool options, palette's, layers, etc

Sure, the thing is that they are strictly optional. In GIMP, it's perfectly possible and pretty easy also, for your toolbox to be just 64 pixels wide. It is true that GIMP has so many dockable dialogs [1] that people tend to go overboard with them.
For example, I have a 'pointer' dialog (which does things similar to your 'I R G B' display, just more comprehensive;
it has two displays so you can see CMYK and RGB values at the same time for example, plus the bounds of the selection mask and the current cursor position.), which I haven't actually used in ages and should get rid of; but, it's docked as a tab and therefore effectively only occupies 32x32 of screen space, so I don't tend to think it is important enough to remove it.

[1] here's a brief list: ToolOptions Layers Channels Paths UndoHistory Brushes BrushEditor Gradients GradientEditor Patterns Colors Palettes PaletteEditor Colormap Tools Pointer SelectionEditor Fonts Buffers Images DocumentHistory DeviceStatus Navigation Templates ErrorConsole Histogram  (total 26 dialogs)

Personally, my toolbox + dockbook put together is wider than Pixe's; 256 pixels wide with a 360x57 gap below the toolbox and a 200x187 gap above the dockbook.
http://img.photobucket.com/albums/v449/neota/sshots/gimpscreenshot.png

Minimum dock width is 240px in Gimp, customizable by theming (I have 200px as my minimum). So yes, you do have GIMP beat in default toolbox size.

[happymonster]

That does look like a heavily modified version of GIMP! 
Have you actually done your own paint program as well though? Got any screenshots of that?

It seems like the dockable / tabbable system seems the best solution to the fact that there is never enough space to have all the options on screen!
It's harder for me because I'm not sure how much space I need for some of the tools (effects, layers, etc..) until they are implemented.

Thanks for the explanations Ai, I think I've got those now..

[Ai]

That does look like a heavily modified version of GIMP! 

Hehe, not modified at all, just a different theme and changing the preferences (and running with LANG=eo (Esperanto) internationalization.).
Not one line of code is different. (you should be aware that's GIMP >2.6[1] though)
The default dock configuration is actually smaller than mine, because it has the dockbook attached to the bottom of the toolbox, which
sort of obliges you to have the icons laid out in a tiled rectangle, so there is no 'dead space'
(I prefer my dead space in the corner though, cause the image navigation icon/tool appears there when an image window is behind)
(but GIMP also has the fg/bg indicator there, which is IMO not very useful, so I turned it off)

The rest of the differences are down to the Window Manager I use('awesomeWM'; that is actually it's name.), which has a single bar at the top and no titlebars, X's, or other miscellanea stuck onto windows, just a 1px outline.

[1] by 2.6+ I mean the latest development version, only hours old.

Have you actually done your own paint program as well though? Got any screenshots of that?

Hmm, no. I have done a very modest paint program which fitted in a single C file, intended as a game-embedded graphic editor.
Also a palette editor that was rather well qualified to explain the phrase 'a sledgehammer to crack a walnut' (I haven't seen a palette editor as powerful since, maybe ProMotion palette editor might qualify. It was not very carefully thought out, though; basically everything I could think that might be useful jammed in there with a hamster (I do not joke, there was a bouncing hamster.))


My current approach, as you may have guessed from the design 'doc' I sent you, is centered on my GIMP extension 'GPixMint'.
Once GEGL gets to be nice and fast, I may review the possibility of making my own paint program.
(GEGL is already amazing in a 'the future is already here; it's just not very evenly distributed' sort of way; the amount of cool new technology getting into it is quite amazing, and it's really carefully thought out and good at doing what it does (evaluating graphs of image operations))
For now, the way I can attach new functionality to GIMP via the GPixMint macro system as easy as sneezing, is reasonably sufficient for my needs. I write comprehensive libraries (eg PixLab) for use with Python so my actual macros can be expressed in 2-20 lines each.

It seems like the dockable / tabbable system seems the best solution to the fact that there is never enough space to have all the options on screen!
It's harder for me because I'm not sure how much space I need for some of the tools (effects, layers, etc..) until they are implemented.

I've heard that 3dsmax's interface uses rollovers -- that is, a dialog turns into a little rectangle which you can rollover to roll out the contents. I don't particularly like that idea.
It also implements panning of GUI via middle-dragging (that is, middle-click+drag), which is very nice indeed (also found in Blender, in which it allows Blender to have an astounding array of options without being rude to the user by taking up too much space.)

[happymonster]

I doub't use GIMP myself but it sounds like with your ability with Math that the GIMP plug-in system is the best solution for you in testing out your ideas.

It also implements panning of GUI via middle-dragging (that is, middle-click+drag), which is very nice indeed (also found in Blender, in which it allows Blender to have an astounding array of options without being rude to the user by taking up too much space.)

I thought of doing that myself, or maybe using the mouse scroll wheel in the gui to scroll up and down would be better..

Doing a whole paint program can be pretty intimidating. Especially when you have a lot of ideas that would be useful but are not in other programs (Like yourself and Surt also have).

[happymonster]

Right! NEW version up, just in time for Christmas.. 

http://www.funkemunke.com/Pixe_Demo.zip

Changes since first release:

• Implemented new gui style with smaller width and greatly reduced height of dialogs
• Made mouse wheel scrolling for zooming in/out easier and faster
• Hopefully made the program start in a window rather than switch fo fullscreen - F7 should still switch between the two modes
• Corrected (or improved) mouse/draw position at large magnification sizes. This issue is related to gfx card drawing of textures at high magnifications
• Added start of palette based icons, so user will be able to select colour from different methods, or do palette manipulaton, i.e. copy, swap, ramp, etc..(not fully implemented yet of course)
• Reorganised grid icons to have No Grid, Lined Grid and Checked grid on left rather than right. This is more consistant with the icons in Box & Ellipse
• Made the text clear about grid co-ordinates in text dispay for cursor when mouse is over the canvas
• Added Circle and Diamond brush shapes to the normal Square brush shape
• Optimised drawing with Square and Diamond brush shapes to be faster
• * Drawing with a very large Circle brush may be a bit slow as it currently draws a circle for each point..
• Added brush sizes 1-8 (pixels) as presets with a small slider underneath to select from 1-64 pixels in size
• Added support for odd and even circles/and ellipses when drawing in stretched mode. Expanded mode still uses old system
• Circle brushes can now also have an odd or even size
• Fixed fill so it works properly with grid
• Made grid be redrawn properly when mask colour (currently 0) is drawn
• Made brush cursors not be present when drawing filled box/square or ellipse/circle
• Made mouse stay in one position when panning with middle mouse button held down
• Fixed a crash when loading BMP images if the image wasn't on a muliple of 32 pixels in width or height

Well, I hope people are finally starting to find it useful.
Merry Christmas!!!!!

[happymonster]

Oops! Found a few bugs.. now fixed:

Image save bug which sometimes left black areas at edge of image - fixed.
HSV sliders not being updated after dropper used - fixed.

Please re-download if you intend to save images with Pixe.

[surt]

This build fixes all the problems I mentioned for the last one. Nice.  (well still slow zoom, but doesn't seem as bad, so tollerable)

A couple of things that bug me though:

• In windowed mode, can't resize the window. And similarly window shows a maximise button, but won't maximise.
  
• Can't zoom out beyond 1x. While not useful for pixel editing as such, can be useful for navigating large spritesheets, tilemap mockups etc.

[happymonster]

Thanks Surt! I could add a slider for zoom speed as well as let you zoom out beyond x1 (that might be better as an optional button though, as it could easily get annoying with some kinds of work).

The windowed/maximise button thing is an engine issue. I will try to look at that with my friend, but that's not completely within my control.

[Ai]

Thanks Surt! I could add a slider for zoom speed as well as let you zoom out beyond x1 (that might be better as an optional button though, as it could easily get annoying with some kinds of work).

Personally, I think stopping zoom at 1x and requiring the user to start zooming again after a short timeout would be effective to avoid the effect I think you're talking about (accidentally passing below the 1x mark)

So to be clear, what I mean is, what level you can zoom to depends on what level you are currently at;
if zoom > 1, you can zoom all the way down to 1 before the timeout takes effect (or zoom in; the timeout wouldn't take effect). If zoom < 1 (i'm envisioning negative zoom as a swapping of numerator and denominator -- so -1 = 1/2, -2 = 1/3, -3 = 1/4, -4 = 1/6) then you can zoom all the way up to 1/1 before activating the timeout (or zoom out; the timeout wouldn't take effect)

hmm, that wasn't very clear. What I mean is to activate a timeout when the user wants to pass from the 'smaller-than-actual-size' zooms into 'larger-than-actual-size' zooms and vice versa. During the timeout, zooming away from the threshold would reset the timeout and zooming over it would have no effect.

[happymonster]

I think I got what you meant Ai and that's a good idea..

[surt]

What exactly is the problem with zooms at less than one? If the user zooms further than they intended they can always zoom back. And I certainly don't like the sound of another unecessary delay. That's the problem with changing zoom currently.

A few more minor things:

• The sizing of the circle and square tools only takes into account the x-axis of the cursor. The min of the abs values of both axes would be nicer.
• Also with circle and square with stretch-from-corner one can only draw to the upper-left and lower-right quadrants.
• Panning doesn't scale with zoom, always moving the same number of image-space pixels for a mouse motion, so as you zoom in further it gets harder to control.

[Ai]

Surt: My idea, if implemented correctly, will reduce the need for a delay, and make things work better without 'overshooting'. When I'm editing pixel art, I almost never mean to zoom < 1. Combined with an 'invert zoom' command (2x zoom -> .5x zoom, 3x zoom = .3333..x zoom, etc), this could work much nicer than any existing solution, and it's quite uncomplicated.

[happymonster]

The delay wouln't have to be big.. What I could do is make it that you can't scroll below x1 magnification until the wheel mouse is left untouched for a few frames. This would stop accidental scrolling and you'd just have to scroll the wheel again to go below x1.

Well, these are just thoughts at the moment anyway.

I'm now starting to rip out some of the hardcoded GUI related stuff and put things in a more modular and data driven system. It won't be completely flexible as certain tools need functions to be called, but it will make it easier to save positions, variables and change layouts from data.

I wanted to get the latest demo out there before doing this though..

[happymonster]

The gui panels for the basic primitive tools (draw, line, box, ellipse and fill) are now all in and working via external data files.
I still need to add support for other GUI objects like text and sliders to do some of the other more complicated gui panels.

[happymonster]

Still making progress, although nothing visible yet as it's a lot of internal data/gui work.

[Ai]

Not me. Although I am of course caught up in preparation.

I've made the kind of posts that you've made here, in your last 4 posts, and nobody responds to them as a rule.
They're like non-sequitours. For myself, I've found that if there is something exciting (in a generally understandable sense -- I mean eg. spline
interpolation is pretty nifty, but hardly anyone knows much about it here.) and some aspect I can show to be a major benefit, I might get responses. Otherwise I just put it in my git commit-log.

Personally I am not in a position to test Pixe, since it doesn't yet run on Linux. If that changes, I shall certainly try it.

Suggestion: PoTrace support, for better auto-AA of single-color regions. Unless you actually vectorize things in your AA filter, it is always going to have less quality than a good tracer like PoTrace (with the tradeoff of staying slightly truer to the lines)
I've implemented this myself, by shelling out to potrace, connecting to its standard input and output to feed input image in and get output image, and requesting '--pgm' output format.

http://potrace.sf.net

Probably not so realistic suggestion: 2d inverse kinematics (IK). Usable for getting consistent proportions when animating, and
determining when a pose is physically impossible. Sort of like a stick figure, without gravity but with tension between line joints and adjustable proportions. (I was thinking that eg.. if the user resizes the head to match their character, the proportions of everything else should be scaled to keep the same proportion; and if they really want to adjust proportions (eg big head) they can do that with say ctrl+drag)
With a base skeleton according to some of the figures here: http://realcolorwheel.com/human.htm )
Yeah, complicated idea. Even if it didn't have IKA or proportion adjustment, just the ability to rotate the component lines without changing their length, that could be an effective animation aid.

[happymonster]

True. I like playing with routines rather than the math, but it's the same kind of interesting puzzle that appeals to both of us I think.

I think the stick figure idea is too ambitious for me to try I'm afraid.
I have seen that real color wheel before (kind of reminds me of the Atari 8-bit palette). How useful is something like that for pixel work?

[happymonster]

On a whim, I brought a Watcom Bamboo today (I got some money for Christmas, so that was a christmas present to myself). I'm finding it hard to use as a mouse, but freehand drawing (I tested it in Pixe) is much smoother and easier.

[Ai]

True. I like playing with routines rather than the math, but it's the same kind of interesting puzzle that appeals to both of us I think.

Eh, from my POV the routines are the math, yeah. It's a computer, not a routiner

I think the stick figure idea is too ambitious for me to try I'm afraid.

I tried to make it as simple as possible; just proportional and non-proportional movement of vertices, plus moving the figure as a whole.
There are rigid-body physics libraries like Chipmunk[1] that can handle the rest of the calculations

[1] http://wiki.slembcke.net/main/published/Chipmunk

Think I'll have a go at a framework for it myself.

I have seen that real color wheel before (kind of reminds me of the Atari 8-bit palette). How useful is something like that for pixel work?

If your paint program supports LAB, 'real color wheel' is not particularly useful (redundant versus LAB). 'real color wheel' is also only real under particular conditions (that wheel looks like it's intended to simulate normal sunlight)

Yeah, it's a bit too easy to drag accidentally with a tablet -- enough that GIMP has introduced a 'Lock Tab' function to prevent people throwing their docked dialogs around accidentally. Still IMO it's far far better for general UI navigation, especially if you use applications in a way that means the same UI element always ends up on the same place on screen. Very zippy.

[happymonster]

Eh, from my POV the routines are the math, yeah. It's a computer, not a routiner

I disagree. Because you have a maths background you think in terms of mathematical algorithms to solve graphical problems.
Since I don't have that background I think in terms of how to solve graphical problems through routines, without recourse of advanced mathematics.
(This has disadvantages, but also advantages)

Anyway.. Merry Christmas Everyone!!!!!!

[32]

On a whim, I brought a Watcom Bamboo today (I got some money for Christmas, so that was a christmas present to myself). I'm finding it hard to use as a mouse, but freehand drawing (I tested it in Pixe) is much smoother and easier.

I also got one of these, are you using the drivers that came packaged (i assume your dual booting windows to test pixe, but they may have linux drivers on their website)? the ones that auto installed made the pen work like a mouse, the cd driver works much more like a drawing pad, i find it quite easy to use as a mouse (except getting icons on the corners of the screen )

I haven't tried pixe yet ( i tried downloading it but it was going at like 50b/s and then it stopped downloading, i might try again tomorrow) but it looks great so far

[happymonster]

Hiya,

I only have Windows here, but I did install the drivers from the CD. As far as drawing I'm really impressed with the pad so far.
Maybe there are things I can tweak to make the mouse like movement easier for me.

Merry Christmas!

[Ai]

Eh, from my POV the routines are the math, yeah. It's a computer, not a routiner

I disagree. Because you have a maths background you think in terms of mathematical algorithms to solve graphical problems.
Since I don't have that background I think in terms of how to solve graphical problems through routines, without recourse of advanced mathematics.

Apples and Oranges.
You're talking about how you think about it and hence think to use it. I'm talking about what it actually does; it's function is to compute, and even today, computers don't really have the notion of subroutines or functions; these are all programming-language abstractions over the CPU's ability to 'jump 60 bytes forward' or 'jump to absolute address 0xffff5080'.

AFAICS, the totality of my maths background is that I enjoy maths I know very little advanced maths (polynomials and splines), and don't even know some standard maths (what to do with sine/cosine to draw a circle, for example; or anything beyond very basic algebra)
So, a bit baffled

[happymonster]

Well, it doesn't really matter..

Still progressing with Pixe today (fitted around Christmas of course!)
I'm been working on getting all the functionality of the recent demo version in there via the new external gui data systems. Then I can start to add new tool options and new GUI parts as well.

[happymonster]

Thought I'd provide a visual update..

The fileselector is currently broken whilst I'm converting the GUI to use the external data, and I haven't yet converted the palette options. Most of the other GUI panels are now in.

I've added 9 preset brush options which use an external data file for the size and shape values (so they can be changed externally). I tried icons at 24 x 24 with 8 x 8 spacing, and at 16 x 16, but the first looked too big and the last was too small for my liking. So I'm using 24 x 24 icons with no spacing which seems about the right balance to me, and still allows me to provide a visual guide to the various small brush presets (including the pixel arrangements for each brush). You can alter the shape and size of the brush if you want larger sizes..

Speaking of which, I've rewrote the slider code and they now have proper left and right working arrow buttons (haven't done the vertical sliders yet).

The GUI panels can now be changed in size, colour and position (so you could have the brushes at the bottom for example) by altering the external files.
These are still things to do, but most of that is now done.

I plan to have GUI space for layers, and a workspace (for custom brushes and the various images to be edited) at the bottom of the GUI panel. Larger window sizes will allow more gui space for some of the GUI panels as well.



 

[Dex]

I just wanted to stop by and let you know you're doing a great job with this program, it's something I could never imagine doing!

Also, the edges of a few of the tools look jagged. Maybe clean em' up?

I'm really diggin' your work here. G'luck!

[happymonster]

Thanks Dex! 

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!

[happymonster]

A bit tired today, so I'm struggling for motivation. Still, I've got a few things done.. 

[Ai]

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

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,

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.

[happymonster]

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

[happymonster]

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

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

[Ai]

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.

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.

[happymonster]

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.

[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! 

[happymonster]

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)

[surt]

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

[Ai]

Ah! That's much clearer. Sounds very interesting, not sure how users would go about selecting the ramp 'values' though.

If you mean priorities, in the example, the user didn't need to assign any, they were automatically assigned by a variant of a plasma algorithm.
The way the algorithm works is IMO demonstrated completely by the pattern of colors becoming available as priority raises

Of course, to get full benefit of the power provided, the user might need to do such adjustments. One way, inspired by the way my Pixlab library allows extra channels, is to treat these values as extra channels, and allow the user to switch from RGB selection to HSV selection to P??  * selection. P channel could also optionally be used to determine the importance of colors in color reduction (with 0 being most important)

(presumably ? ? would be letters representing other channels, i'm sure there are some)

OTOH, if you mean adjusting the current active priority, I envisioned that bound to shift+{] or ctrl-[].

[Ai]

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.

This is possible -- I've tried it! It's quite demanding in terms of making a system that does it well.
Some things it needs:

 * sane color system (standard sRGB is right out. so is linear RGB, probably, and of course so is HSV/HSL/HWB/what-have-you-variant of hue-something-something. XYZ might be possible, I know LAB works, and LCH might work even better, YCbCr or YiQ might have some value (I haven't really played with them much))

 * graph algorithms. Essentially, we are building a graph with colors as nodes, and each node connected (directionally) to every other node which satisfies the threshold. We then need to iterate through the graph with the constraint that we move monotonically (ie. either always brighter, or always darker). The iteration is like iterating over multiple trees, and each subtree produces multiple output ramps.

EDIT: actually, we only ever need to move in one direction (say brighter). We can just store the output in reversed order if the user wants that.

 * a reasonable display method. Even for quite small numbers of source colors, the number of output ramps can become quite large.
    Might be helpful to partition the ramps (eg ramps including color1, ramps including color2, ramps 3..5 entries long, ramps 4..8 entries long..)
   
For example, supposing you have a simple single ramp of length 4. the number of ramps of length >=2  equals 2**4 - (4  + 1) = 11 including the original ramp. Supposing instead that you have 4 ramps of length 4 in which every color in a given position is similar enough to the neighbouring colors that it can be between any two colors, this is (calculated through brute-force with my function iterate_ordered_permutations:) 608 ramps totalling 1996 entries, with 256 of those ramps having the full 4 colors per ramp (also 256 of the ramps have 3 colors, and the remaining ramps of length 2 number 96).

This is actually close to an best-case. I've calculated some statistics using a graphing library, and with a set of 16 colors randomly assigned intensities 0..32,  the total number of entries in the result ranges from 10000 to 26623 entries (65535 being the maximum for an input set of 16 colors -- (2**16) - 1) with about 120 edges in the graph on average.

With a threshold of 2 (that amounts to 1/16th of total intensity, which implicitly limits ramp length to <= 16) we get from 3167 ... 13823 entries,  with average 111 edges.(There are more possible ramps as the ramps become longer, btw.. so the largest ramps occupy most of that space.). doubling it to 4 (1/8th of total intensity, limiting ramp length to <= produces 539 .. 1439 with average 96 edges

threshold = 6 (effective max ramp length == 5) produces 259...923 entries with average 82 edges. This is approaching the realm of reasonableness.

Now, lets see what happens when I increase the number of source colors by 1.    384..881 entries, avg 88 edges
If I double the number of source 'color's to 32 (and double the threshold to compensate),    2552... 4979 entries, avg 330 edges
If I reduce threshold to 4 (4/64 intensity step, max ramp len = 16), we get : 354815 ... 1892735 entries, avg 450 edges.
With threshold = 5 (5/64 intensity step, max ramp len = 13), we get : 148031 ... 602111 entries, avg 440 edges.


We should divide these figures by about 3, since the threshold would most likely be expressed in units of delta-E
http://www.colorwiki.com/wiki/Delta_E:_The_Color_Difference#Delta-E_1976 which will involve three criteria (each of the LAB color channels)

and these figures are still fairly ludicrously large after that. You're only safe from being overwhelmed if you're looking for a short ramp (<= 6 colors), since for each increment of ramp length, number of possible ramps balloons hugely.
One good point is that it's computationally undemanding for typical numbers of input colors: we must compare all colors with all other colors to create the graph; with 256 input colors this is only 32640 color comparisons. then we must iterate through all nodes recursively, rejecting paths that are only one point long, and storing paths as they terminate (or as we finish processing a branch node, we store the path leading up to it but no further). This may require 2 * sum_of_path_lengths (the often huge number I've calculated several times above, eg. 148031..602111) bytes of memory.

EDIT:
I have an algorithm to do this. It does everything except actually store the results -- currently it just counts tree sum_of_path_lengths by accumulating the lengths of all subpaths.
The color comparison/thresholding and building the graph is trivial.
the current implementation of path length calculation looks like:

Code: [Select]

def lengths (graph, node):
    """Return the lengths of the paths originating at node.
   
    Graph must not be circular.
    """
    successors = graph.successors (node)
    count = 1
    if len (successors) == 0:
        return 1 # just ourself
    for succ in successors:
        count += lengths (graph, succ)
    return count
Then the overall counting code just sums the result of calling this on every node (omitting nodes that have no successors, ie. length = 1).
with a slight change of parameters, this could be readily adapted to store results.



This idea needs more work. Perhaps by specifying colors that must be in the output ramp, you could reduce the number of outputs sufficiently.

One other thing -- a sample colorization would be essential for previewing ramps. Using some carefully-picked grayscale images to demonstrate what the ramp will look like.

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

Thanks for mentioning this!!!
It inspired this idea for tile reorganization, where you can click on a number of tiles to copy them collectively.
(sort of like a tilemap-chunk brush)

[happymonster]

Thanks guys! Some good ideas here which sadly I haven't got time to respond to (off to work today). I already had planned to do something like a tile copy mode which would be VERY useful I think.

As for the saturation, I'm still trying to find a balance, and I'm sure things will change. But I think it is looking better every time I do a visual redesign (compared to the earlier screenshots).

[surt]

My insufficently thought out and untested (so almost certianly fubar) very-high-level algorithm for ramp extraction:

• Use the user specified thresholds to perform similarity clustering (should have this already anyways for the clustered palette view).
• Build a tree rooted on each cluster.
• Then for each node create children based on thresholds and curve-fitting (probably just within a error of linear should be fine for most purposes) using cluster bounds. Guts go here.
• Then from any/all cluster sequence construct a ramp or ramps fitting the user selected criteria (most even distribution, smoothest sequence, best fit per cluster, etc.).
• For more complex ramp curves (think piecewise linear splines) construct them in a seperate pass or interactively with bidirectional construction trees.
• Option for fixed-width or linearized ramp display (dithering optional).
• For practical operation would probably be far to slow to be usable in real-time, so it'd probably need to be maintained in a parallel process, marking as dirty and partially rebuilding on each palette change.

Idea: if you've got a massive list of ramps to wade through something nice to have could be a "scratch palette" to which the user can dump ramps/colours they are currently working with for easy access.

Thanks for mentioning this!!!
It inspired this idea for tile reorganization, where you can click on a number of tiles to copy them collectively.
(sort of like a tilemap-chunk brush)

Thanks for mentioning this!!!
It inspired this idea for tile reorganization, where you have a "smart" tileset reordering tool.
It acts like any standard list view widget, allowing drag-and-drop reordering and cutting-and-pasting of individual ranges tiles and ranges of tiles within the tileset image.
Add tile flow direction options to grid settings and your just about done with the gui for it.
Also add an option to let you maintain tile indices when resizing the tileset image would make the tool more complete.

Ai's recursive ramp subdivision idea and my morphological interface painting idea could work nicely together, so that on each stroke auto pick the mid-point colour in the ramp between the two interfacing colours (interface nearest to cursor position, only search within brush bounds).

A matter of taste: square swatches in the palette (option would be nice).

Another small idea: in tile editing mode, option to filter palette by colours in the tile (and get colour count for tile).

[Ai]

My insufficently thought out and untested (so almost certianly fubar) very-high-level algorithm for ramp extraction:

• Use the user specified thresholds to perform similarity clustering (should have this already anyways for the clustered palette view).
• Build a tree rooted on each cluster.
• Then for each node create children based on thresholds and curve-fitting (probably just within a error of linear should be fine for most purposes) using cluster bounds. Guts go here.
• Then from any/all cluster sequence construct a ramp or ramps fitting the user selected criteria (most even distribution, smoothest sequence, best fit per cluster, etc.).
• For more complex ramp curves (think piecewise linear splines) construct them in a seperate pass or interactively with bidirectional construction trees.
• Option for fixed-width or linearized ramp display (dithering optional).
• For practical operation would probably be far to slow to be usable in real-time, so it'd probably need to be maintained in a parallel process, marking as dirty and partially rebuilding on each palette change.

That certainly cuts down the amount of ramps to sort through. OTOH, you've traded visual quantity for user interface complexity,
which is something I'm fairly leery of. After I wrote my post before, I thought it would be better to offer iterative revision... that is, start out offering the user 2-color ramps; if they like one, they can click on it and progress to seeing 3-color ramps related to it.. then 5-color,...
(and I guess right-click to back up if they think they made a bad choice)
IMO this avoids both issues by offering the user only a meaningful amount of choice, and iterative-revision interfaces in my experience are very fast and obvious to use. It also exploits the fact that short ramps are the least numerous in any possible set of ramps.

GIMP 'filter pack' plugin has a good example of the kind of UI I mean.
http://docs.gimp.org/en/plug-in-filter-pack.html  (see figure 15.202)


Also, your algorithm is sort of like a bastardized octree quantization implementation in it's basis ,  so you might want to check out
http://en.wikipedia.org/wiki/Octree
(SciPy (www.scipy.org) also has clustering and vector-quantization tools which are good for prototyping this kind of algorithm, including a K-d tree implementation which is a generalization of an octree.)

Using octrees can make this kind of quantization very fast, actually. A majority of color reduction algorithms use octrees.

Idea: if you've got a massive list of ramps to wade through something nice to have could be a "scratch palette" to which the user can dump ramps/colours they are currently working with for easy access.

Thanks for mentioning this!!!
It inspired this idea for tile reorganization, where you can click on a number of tiles to copy them collectively.
(sort of like a tilemap-chunk brush)

Thanks for mentioning this!!!
It inspired this idea for tile reorganization, where you have a "smart" tileset reordering tool.
It acts like any standard list view widget, allowing drag-and-drop reordering and cutting-and-pasting of individual ranges tiles and ranges of tiles within the tileset image.
Add tile flow direction options to grid settings and your just about done with the gui for it.

actually that's weird, cause I thought of that and then I thought .. 'but how would you get it to not f*** up the order of the existing tiles?'
The flow options address that nicely (you'd need two, I think.. one for x axis flow and one for y axis flow? not completely clear here)

Also add an option to let you maintain tile indices when resizing the tileset image would make the tool more complete.

Ai's recursive ramp subdivision idea and my morphological interface painting idea could work nicely together, so that on each stroke auto pick the mid-point colour in the ramp between the two interfacing colours (interface nearest to cursor position, only search within brush bounds).

A matter of taste: square swatches in the palette (option would be nice).

Another small idea: in tile editing mode, option to filter palette by colours in the tile (and get colour count for tile).

[happymonster]

Interesting discussion, even if it's over my head! But have fun guys, rock the world!

I looked at the screenshot of Pixe at work and it seems very dark on that monitor. Looks like that Gamma was different than on my machine. Does it appear too dark for everyone else? (I know that's rather subjective!)

BTW: Have a great New Year!

[surt]

That certainly cuts down the amount of ramps to sort through. OTOH, you've traded visual quantity for user interface complexity,
which is something I'm fairly leery of. After I wrote my post before, I thought it would be better to offer iterative revision... that is, start out offering the user 2-color ramps; if they like one, they can click on it and progress to seeing 3-color ramps related to it.. then 5-color,...
(and I guess right-click to back up if they think they made a bad choice)
IMO this avoids both issues by offering the user only a meaningful amount of choice, and iterative-revision interfaces in my experience are very fast and obvious to use. It also exploits the fact that short ramps are the least numerous in any possible set of ramps.

I don't see why the interface need be any more complex than a few selection criteria and a list to scroll through. While I don't personally like the idea of an iterative refinement interface for this (I just want a palette of ramps) theres no reason you couldn't use one to refine the thresholds.

actually that's weird, cause I thought of that and then I thought .. 'but how would you get it to not f*** up the order of the existing tiles?'
The flow options address that nicely (you'd need two, I think.. one for x axis flow and one for y axis flow? not completely clear here)

Well flow direction for each axis as well as axis priority so that's three options to be complete.

I looked at the screenshot of Pixe at work and it seems very dark on that monitor. Looks like that Gamma was different than on my machine. Does it appear too dark for everyone else? (I know that's rather subjective!)

Intensity looks fine to me, but then I'm a darkness-fancier. Just the saturation AFAIC.

[happymonster]

Intensity looks fine to me, but then I'm a darkness-fancier. Just the saturation AFAIC.

Actually I've refined the design somewhat, and altered the saturation slightly. Unfortunately my stupid webhost is down, else I'd post a screenshot.
Suffice it to say I think I've improved things and I've incorporated your suggestion Surt for a row of Layer 'icons' above the canvas. I can fit 20 - 32 x 32 icons in there and 4-5 layer tool icons in a 1024 width window/screen mode. So that's quite nice..

If my webhost comes back online I'll post a pic.

[happymonster]

Here's Pixe (my version, not uploaded yet), running in maximum windowed size in a screenmode of 1280 x 1024:
http://www.funkemunke.com/Pixe_12.png

I think it's taking shape.

[surt]

Saturation level is better, but I still think it could be turned up just a touch.

Palette tools above the palette is an improvement and more consistent with the rest of the gui.

I'm curious to see how the layer bar will pan out, and also have an idea for an animation interface to go with it (I'll post a mockup once I've got a more fully featured screen to hack up as I probably can't explain it very well textually).

Good stuff.

EDIT:
Talking about specialized tilemap tools earlier, this might be another good use to put the secondary pane to.
Have the standard image view in one pane (or better yet a dedicated tile list view/mode/tool/whatever) with the ability to select a tile from the image which is then displayed/edited in the other pane as though a discrete image (with of course options for tiled view and wrapped editing).
Could also be used for irregularly sized sprites (using the usual methods of extraction: from regions bounded by a key colour or defined in an external text file or, better yet, defined in app).

[happymonster]

And I've improved things since the last update already.. And more big ideas in my head for the palette stuff. It's a continual process of (organic?) evolution.

The tile map idea is REALLY nice! I will add that to the spreadsheet and try to update it this weekend.
Cheers!

[happymonster]

I would like people's opinion on this.. I've been playing around with the palette view and I was wondering what you think about this optional palette view.
Basically as you can see, the palette width is halved, and the colour space selector (which ever kind) will be shown on the right. The black space below is where a horizontal brightness gradient will go.

I know the palette entries become quite small, but you will be to able to make the entry sizes bigger (and show less colours) in the colour options.
The advantage of this is that you can do both colour changes, and palette manipulation/comparison at the same time.

The colour space shown here is 112 x 112 (and the GUI panel has a width of 224 pixels), so that's over 12,000 colours before adding a brightness dimension. Do you think it's too small to use or ok?

[surt]

So long as it's optional, then it's a good thing.
I've don't think I've ever used a paint program which allowed simultaneous access to selecting a palette index and selecting a colour for that index from a planar colour selector, usually it's through a modal dialog which equals bad, so this is a very nice feature.
Ideally one would be able to cycle between three modes: palette only, planar colour selector only, both together.
I do think it's somewhat small as is, but give the user the ability to size the panel (and as a result its contents), then the responsibility is on their shoulders.

A small matter of ergonomics: given the user should be picking colours from the palette more often then from the planar colour selector, putting the palette on the right should reduce mouse travel somewhat.

In case you missed them in amongst the cruft :

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 .
For example the gimp colour selector:

A matter of taste: square swatches in the palette (option would be nice).

[Helm]

I personally don't think I've chosen a color from the planar selector for pixel art in years. I make my colors by choosing a value and then adding a hue and saturation to that value on the fly later on. I don't think a lot of pixel artists waste a lot of time with visible colorspaces like that, they just take up space.

[happymonster]

Well, two different opinions there on how pixel artists work.. Hehe..

Surt: That's a good point about putting it on the right, I will do that. And yes I was thinking about a off, half-size, full size option.

I will also add gradient style colour sliders in the future.
As for the square swatches, That will make the palette smaller in full-size mode, but could be an option..

[happymonster]

Ok. Color Space Variation 2 (Hue x Brightness), with the palette on the right and square swatches. A gradient bar would go underneath for the saturation (probably all the way across the panel).

[surt]

I make my colors by choosing a value and then adding a hue and saturation to that value on the fly later on.

I would think a planar colour selector as configured previously, with intensity separate from hue and saturation, would be perfect for just that situation.

Well, two different opinions there on how pixel artists work.. Hehe..

Well, I don't actually use planar colour selectors at all (in graphics gale it's locked in a modal dialog), but I can see their merit, particularly for pixel artists who may not yet be fully comfortable with the colour space, and I probably would use it if it was no hassle.

Ok. Color Space Variation 2 (Hue x Brightness), with the palette on the right and square swatches. A gradient bar would go underneath for the saturation (probably all the way across the panel).

Will it be possible to select different configurations of components on the planar colour selector? I think all HSx component configurations have some potential merit.
Do you really need to put the third component on the planar selector as well? You've got sliders for all three components (or six if you want to do RGB on the planar selector) just below (and maybe move the colour contexts out of the way to above the palette, and swap the positions of HSx and RGB sliders to reduce mouse travel).
The square swatches are so much prettier. 

[happymonster]

Will it be possible to select different configurations of components on the planar colour selector? I think all HSx component configurations have some potential merit.

Yes, I will have the Hue x Sat, and Hue x Lum as already shown as well as Sat x Lum. There will also be some more colour views to choose from (harmonies, etc..)

Do you really need to put the third component on the planar selector as well? You've got sliders for all three components (or six if you want to do RGB on the planar selector) just below (and maybe move the colour contexts out of the way to above the palette, and swap the positions of HSx and RGB sliders to reduce mouse travel).

That's true.. the only thing is if the sliders are in something like a Lab colour space I suppose.

I really want to have the palette entries a bit bigger than this, (as well as showing colour view), but I don't think I can do it and keep them square without shrinking the color view space..

[surt]

thing is if the sliders are in something like a Lab colour space I suppose.

How about having the secondary sliders and the planar selector always work within the same colour space?

A small thing: it'd be nice to be able to pick the numeric colour space representation of your choice: byte, unit, percent, hex.

[happymonster]

Ohh.. now you're starting to make it complicated! 

[Ai]

I have to agree with Helm, strongly, here. The whole intent of my relative color selector was to avoid the circus of planar color selection. You might say the maths goes over your head, happymonster, but it's about as simple as the planar selector you show there.
(the only bit that made it look complicated was the formula input. but all cells could be precoded and it could still be far more productive than planar selection).
Another way to describe it is as like the picture in the link I gave before:

figure 15.202 in
http://docs.gimp.org/en/plug-in-filter-pack.html

Having a color selector like that allows the artist to tweak all 3 dimensions of the color quickly
(whatever you view those 3 dimensions as being .
I'll try to illustrate again, better (and simplified to the minimal level)



All that's involved here is interpolation.
* The left 4 hue entries interpolate between pen 0 hue and minimum hue (==0); the right 4 hue entries interpolate between pen 0 hue and maximum hue (==360)
* The left 4 value entries interpolate between pen 0 value and minimum value (==0); the right 4 value entries interpolate between pen 0 value and maximum value (==100). The rightmost entries of 'value' are identical because the color is already at maximum value.
* The left 4 saturation entries interpolate between pen 0 saturation and minimum saturation; the right 4 saturation entries interpolate between pen 0 saturation and maximum saturation. pen 0 color was already at max saturation, so the rightmost 4 entries are identical.
* the 8 entries in the 'interpolate' line interpolate between pen 0 color and pen 1 color
* the 8 entries in the 'interpolate old' line interpolate between pen 0 color and last selected color (which was 'ba2d1d'; An option to insert a block of color in a post would be handy about now
* pen 0 color and pen 1 color blocks are purely for illustrative purposes.
* every cell must be updated after clicking on a color to pick it, since all cells are relative to pen 0 color.

NOTE: this is different from sliders in that it's entirely relative, where sliders are absolute. Hence you can see on the left side of 'hue', it slowly becomes red, since the pen 0 color was orange, only 30 on the hue scale,  whereas on the right it changes very quickly to cover the range 30..360

The reduced amount of computation required for relative color selection would also make LAB-based color adjustment perfectly feasible in realtime.

[happymonster]

Another possibility:

If I make the palette area larger, but square in ratio with square swatches and the icons either side (maybe 160 x 160 instead of 224 x 112 / 112 x 112). Then if you pressed a key/button the colour space view would appear below and replace the contents of the Brushes/Tools windows. This would let you do larger colour editing, but stop you doing drawing at the same time..

It's difficult to decide what is best to do really.

[happymonster]

AI:

Interesting idea. I'm not sure how intuitive that is for me being new to the idea.
Please don't forget, you will be able to select different colour views (7+) so something like this could be one of them..

Of course if I throw in every idea then I might as well have the whole GUI dedicated to palette tools!

[Ai]

I make my colors by choosing a value and then adding a hue and saturation to that value on the fly later on.

I would think a planar colour selector as configured previously, with intensity separate from hue and saturation, would be perfect for just that situation.

The thing is that a planar color selector gives you about 37 times more choices than you can realistically comprehends, just for one color dimension. For a full 3 dimensions, thats 37^3 == 50653 times more choice than is meaningful. Having the full range of choices is useful and good, and seeing them all at once is not

[surt]

Just experimenting with the layout.

I'm sure it takes up considerably more vertical space than you want, I just scaled it up to fit the horizontal space available.
Minor variation with colour space indicators for all four colour contexts.
And of course the colour plane should be rendered with the value of the third component.

EDIT:

...
NOTE: this is different from sliders in that it's entirely relative, where sliders are absolute. Hence you can see on the left side of 'hue', it slowly becomes red, since the pen 0 color was orange, only 30 on the hue scale,  whereas on the right it changes very quickly to cover the range 30..360

Non-linear colour sliders are a nice idea, the discretization not so much.
Ideally they wouldn't just be two split linear ranges, as usually you want to tweak the colour by a small amount (and your hue example certainly doesn't allow that), but a single, continuous, nicely steepening curve over the whole range (any ideas of a good function for that?), so you can make changes of any granularity.
User interface might not be so nice though: you don't want the curve changing as you push the slider, so it'd probably require a confirmation stage.

The thing is that a planar color selector gives you about 37 times more choices than you can realistically comprehends, just for one color dimension. For a full 3 dimensions, thats 37^3 == 50653 times more choice than is meaningful. Having the full range of choices is useful and good, and seeing them all at once is not

I don't get this. At all. Colour's require comprehension? I should expect having a continuous surface to be ideal for locating a desired colour as one's eyes can just follow the local gradient towards what they are searching for.

If I make the palette area larger, but square in ratio with square swatches and the icons either side (maybe 160 x 160 instead of 224 x 112 / 112 x 112). Then if you pressed a key/button the colour space view would appear below and replace the contents of the Brushes/Tools windows. This would let you do larger colour editing, but stop you doing drawing at the same time..

Why not just alow the regions to collapse/expand as necessary and let the user pan the panel if they insist on having more expanded regions than their screen resolution can handle?

[Ai]

EDIT:

...
NOTE: this is different from sliders in that it's entirely relative, where sliders are absolute. Hence you can see on the left side of 'hue', it slowly becomes red, since the pen 0 color was orange, only 30 on the hue scale,  whereas on the right it changes very quickly to cover the range 30..360

Non-linear colour sliders are a nice idea, the discretization not so much.
Ideally they wouldn't just be two split linear ranges, as usually you want to tweak the colour by a small amount (and your hue example certainly doesn't allow that),

It certainly does allow that.
Choose two colors, then pick from the interpolation between them. That's what the 'interpolation old' is for.
I usually do the second, as using interpolation in this way is extremely approachable and intuitive 'i want a color that's 50% between color a and color b' -- easy to understand, right.. the entire dialog centres on the main interpolation ramps, hue/sat/val are just ways to poke them around in a broad sense.
This dialog design comes from actual experience using my own relative-colorselector (which simply looks at the painting color and background color, and sets painting color = 50% mix of painting and background color using LAB colorspace.)

but a single, continuous, nicely steepening curve over the whole range (any ideas of a good function for that?), so you can make changes of any granularity.

You can, in fact, make changes of far finer granularity than all existing planar or slider based selectors that I know of.
One of the reasons that I designed this system for pixlab is that there is no limit to its precision.

The thing is that a planar color selector gives you about 37 times more choices than you can realistically comprehends, just for one color dimension. For a full 3 dimensions, thats 37^3 == 50653 times more choice than is meaningful. Having the full range of choices is useful and good, and seeing them all at once is not

I don't get this. At all. Colour's require comprehension? I should expect having a continuous surface to be ideal for locating a desired colour as one's eyes can just follow the local gradient towards what they are searching for.

The local gradient is precisely what prevents you from finding an accurate match; our eyes (and IMO our minds in general) work relatively.
All that presenting, say, 256 choices does is allow you to remain confused and vague about what you want. Discreteness allows iterative, quick refinement of a selection, in a very similar way to a binary search, and this is primarily because the cost of considering each color is low.
A continuous scale has potentially infinite cost.

[happymonster]

Surt: Thanks for that! I think it does take up too much space vertically, but it's definately given me some ideas. Thank you for taking the time to mockup that off, I do appreciate it!

In fact since most of the time people will be selecting colours from a palette (rather than changing them), I thought about this variation:


Larger palette area, square swatches, and keeping sliders horizontal below. It does take up a bit more space than before, but not too bad overall. Of course, this means that any of the half palette / half colour view areas will not be square, but I also like the square swatches.

What do you think?

AI: Thanks for explaining that in more detail. I didn't realise about the interpolation part being so important. One question, do you picks pen 0 with left mouse button and pen 1 with the right mouse button? The issue I have with that is it would mean it would make it more complicated to select a colour when you naturally have two pens to draw with (or 4 in my case).

[happymonster]

And in a half/half mode:


I've rotated the colour view so Luminance is twice as big as the hue dimension (as Luminance is more important).
The colour space still seems bigger overall than the two squares approach.. Thoughts?

[surt]

I suppose I could suffer rectangles this far. 
Looks like it'll work.

[happymonster]

Not exactly a ringing endorsement!

It seems to work so far, I'm still refining things continually of course..

I have a question about the GIMP colour sliders. I take it you click on the slider and that becomes the new value/colour. Does this mean you can't have precise control over the values? I.e. there are no slider arrows..?

[surt]

There are no slider arrows, but you can step through with mouse wheel or spinbox.

[Ai]

AI: Thanks for explaining that in more detail. I didn't realise about the interpolation part being so important. One question, do you picks pen 0 with left mouse button and pen 1 with the right mouse button?

If you are talking about my current workflow, I pick pen 0 with ctrl-leftclick. If i want to pick pen 1, I use the 'swap colors' shortcut then ctrl-click (I've bound it to the key next to the key which is bound to interpolation.). The swap key is important in this, cause it allows me to correct when i go too far. In conjunction with eyedropping, I can use this to quickly mix any number of colors in virtually any proportion. This dialog is designed to provide the same abilities in a more immediately approachable way.
(although, Skalle agreed to test my software, and he was surprised how natural and simple the interpolate + swap colors teaming is. I really look forward to when I get all my ducks lined up to release GPixMint.)

The issue I have with that is it would mean it would make it more complicated to select a colour when you naturally have two pens to draw with (or 4 in my case).

it's actually designed for 2 pens. I didn't try to adapt it for 4 because I don't understand how 4 pens is going to work, really.
I thought for instance in color selectors, you would have to use leftclick, rightclick, shift-leftclick and shift-rightclick to select the color for different pens, and this would have to be global throughout color selectors?

I take it you click on the slider and that becomes the new value/colour. Does this mean you can't have precise control over the values? I.e. there are no slider arrows..?

On the rare occasion I use it, i 'current position' indicator. You can click, that does indeed become the new value/color.
You can also enter numbers directly for each channel or use the up/down buttons next to them.
(though personally, if I want precise control I tend to end up entering a hex color)

[happymonster]

Is there any chance you will have a test Java/Python app online so I can test your colour dialog idea? (I don't have GIMP)
It's hard to visualise without using it I guess.

Thanks for the info on the colour sliders guys..

[Ai]

Is there any chance you will have a test Java/Python app online so I can test your colour dialog idea? (I don't have GIMP)
It's hard to visualise without using it I guess.

Nope (i don't even have an offline one. I only have the current implementation which doesn't use a dialog at all.)
The best I can do is making a video of my current usage. I don't know anything much about java, and python cannot be used in an 'interactive application' sense online. Of course I can make a mockup application, it would be in Python with PyGTK and run offline.

[happymonster]

Please don't go to any unneccessary effort on my behalf! I just wondered if there was already something available..

[happymonster]

If you are only using 128 or less colours, you can alter the palette size so the entries are still square and still have a colour view to select from:

[happymonster]

Hmmm... One problem with the previous varient is that the palette area does seem a little big, and it does take up a little bit more GUI space vertically than I would liked.

Now if I shrank the palette area by 32 pixels, then I could push the pens to the right, put the sliders on the top, which would make it look a bit more symmetrical horizontally and save about 64 pixels. The only issue is that even with the palette gridlines off it starts to get a bit cramped in half/half mode..

Here's a rough image of what it would be like:


Thoughts on which works best so far?

[surt]

At that size it's the same as the GGale palette which is usable but I certainly wouldn't go any smaller.

The half-size palette (how often does a pixel-artist use full 256 colours after all?) with full-size swatches looks fine.

[happymonster]

I take it you are referring to the last pics Surt?

[surt]

First comment is in regards to the latest, second comment could go with either.

[happymonster]

I've done some experimenting, but the new look ends up looking a little bit too cramped for me..
So, I've gone back to using the old look for now.

I think it's time to stop tweaking for a while and add some more functionality.

[happymonster]

Ok, Here's the latest version to test:
http://www.funkemunke.com/Pixe_Demo.zip

Please note: I have not yet redone the fileselector to use the external GUI system, so there is no proper load / save. However.. the program will try to load 'untitled.bmp' at the start and save to this file at the end. With this and the external data used for the GUI and variables you can now exit and then continue where you left off the next time you start the program (I think this was Surt's excellent suggestion?). It works very well and does help make things nicer.

This should hopefully now run in a maximised window on the desktop and has a lot of changes underneath the surface. It also uses the new GUI look which helps a lot IMHO.

So, yes, there is still a lot missing. But I think it's now getting quite usable. The next things I want to add is undo/redo and basic brush cut/paste functionality.

[happymonster]

I've also updated the ideas spreadsheet a little:
http://www.funkemunke.com/ideas.xls

[surt]

The maximize, restore and resize work fine for me now.

The colour selectors work very nicely too, but I'm not so keen on the colour space view options submenu, I'd rather just have two buttons on the same level (looks to be room for it), one to cycle between the view modes and one to cycle between the colour planes.

A couple more minor ideas:

• Preview the colour change on the canvas when the mouse hovers over a colour plane or slider.
• An option to pick the nearest existing colour from palette when selecting a colour from a plane or slider.

[happymonster]

Hi Surt,

Yes the palette GUI still needs some more work. But, I think I need to add more functionality like undo/redo & brushes first. I'd rather not spend too much time on one aspect when other things still need implementing.

Those ideas are good.

BTW: If you press Escape it does a quick save and exit.. Useful if you are supposed to be at work!

[surt]

I've uploaded a windows build of my most recent prototype (this thread inspired me to hack around with the code some), to demo the canvas transformations I mentioned earlier in the thread (rotation mainly).
You can get the build here (I hope I included all the necesary shared libraries, source there too).

To demo:
Open an image (new image is broken).
MMB drag to pan canvas.
Ctrl-MMB drag to zoom canvas.
Shift-MMB drag to rotate canvas.
Ctrl-Shift-MMB drag to rotozoom canvas.
Mousewheel to zoom canvas.
Shift-Mousewheel to rotate canvas.

Nevermind the widepixels, just there for testing.

Maybe this'll convince you to include canvas rotation. 

[happymonster]

Thanks for the app.. It works ok for me.
I may support canvas rotation at some point in the future. But there is other stuff I want to focus on first.

[happymonster]

I'm currently working on the Undo/Redo functionality, but I've also been thinking ahead to the Brush section.

I don't have the latest version of ProMotion, but am I correct in thinking that it can only handle one custom brush at a time? (I.e. A brush selected from the canvas) I can't remember how many DPaint on the Amiga could handle, but I know that Personal Paint could deal with upto 9 different brushes.

Graphics Gale, PSP and PhotoShop seem to use the selection based idea I think (where you define an area, rather than cutting/copying automatically).. Does GIMP do it the same way?

Is this correct? I'm just planning out the design for Pixe's user brushes..

[happymonster]

Dpaint days...



(Just a test..)

[Ai]

I'm currently working on the Undo/Redo functionality, but I've also been thinking ahead to the Brush section.

I don't have the latest version of ProMotion, but am I correct in thinking that it can only handle one custom brush at a time? (I.e. A brush selected from the canvas) I can't remember how many DPaint on the Amiga could handle, but I know that Personal Paint could deal with upto 9 different brushes.

Graphics Gale, PSP and PhotoShop seem to use the selection based idea I think (where you define an area, rather than cutting/copying automatically).. Does GIMP do it the same way?

Dunno what cutting/copying 'automatically' amounts to. However in GIMP you can make brushes from the selected pixels, so probably yes.
GIMP also has a 'clipboard brush' which allows you to paint directly with the current clipboard contents

Personally my experiences with GIMP have led me to think that a bank of 3 brushes that I can cycle through by keyboard is about right.

I really like the dpaint-ish test gui!! It's far more clear and readable. IMO the old bevelling effect drew too much effect to specific icons (which had a lot of edges)

[Helm]

I don't have the latest version of ProMotion, but am I correct in thinking that it can only handle one custom brush at a time? (I.e. A brush selected from the canvas) I can't remember how many DPaint on the Amiga could handle, but I know that Personal Paint could deal with upto 9 different brushes.

Promotion has a Brush Container panel in which you may store a very large number of brushes.

[happymonster]

Dunno what cutting/copying 'automatically' amounts to

In Dpaint/Promotion you can cut out a brush and the selection disappears automatically and you can then draw with the brush, or manipulate it.

Photoshop, PSP, Graphics Gale, etc.. keep the selection in place so you can either manipulate the pixels directly, or copy to a brush.

Promotion has a Brush Container panel in which you may store a very large number of brushes.

Ah! Thanks Helm.. Found it now.

I really like the dpaint-ish test gui!! It's far more clear and readable. IMO the old bevelling effect drew too much effect to specific icons (which had a lot of edges)

Trying to come up with a nice theme is a total nightmare!
It might be easier just to offer different options to suit different people. But personally I would like to have one nice theme that everyone pretty much likes.

Today I realised that there are a few nasty bugs in the fill tool, so I need to fix that. Undo/Redo is almost done though..

[Ai]

In Dpaint/Promotion you can cut out a brush and the selection disappears automatically and you can then draw with the brush, or manipulate it.

Photoshop, PSP, Graphics Gale, etc.. keep the selection in place so you can either manipulate the pixels directly, or copy to a brush.

The Dpaint way is clearly a big advantage, so I just implemented it for GIMP. Thanks for the idea

Trying to come up with a nice theme is a total nightmare!

Personally I think, with the dpaint-ish GUI, having white scroll-arrows rather than black helps readability.
You also might want to go somewhere like http://www.gnome-look.org and see what themes are popular that you also like, take some hints from them.

[Helm]

You can also remove the cut brush from the art and have it as a selection in ProMotion if you select it holding the right mouse button down.

[happymonster]

Helm, do you mean cut the brush out of the image, as you would with Dpaint?

[happymonster]

Well, fixing the bug with the fill is proving more interesting than I thought!
Hopefully I will get that and Undo/Redo working by the end of the weekend though.