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.

[happymonster]

Ok.. I think I've fixed the fill bug.

Undo/Redo is nearly done..

Something else I've been thinking about. The tool icons are currently 24 x 24 pixels in size with a gap of 8 pixels (So an icon is drawn every 32 pixels). With the GUI width of 224 pixels this lets me fit in 7 icons in a row (instead of the 8 I had in the old large version). Now.. if I reduce the gap to 4 pixels then I can fit 8 icons in again, but it does look a bit cramped.

So I don't know whether I will really need the 8 icons across yet, and if I do I don't want to redraw all the icons at a late stage. So I'm wondering whether it would be best to draw icons in something like 20 x 20 now?

Photoshop's tools seem to average around 16 x 16 (some are bigger), but none seem much more than 20 x 20. The second column of icons is 26 pixels after the first.
The small icons windows uses in their office programs like Excel are around 16 x 16 pixels (maximum for nearly all) with a spacing of 23 pixels.

Well, just thinking about it at the moment.. We will see!

[Ai]

Over at gimp-brainstorm (http://gimp-brainstorm.blogspot.com/)
someone just posted this
http://gimp-brainstorm.blogspot.com/2009/01/colour-selector-on-canvas.html (first picture)
and i thought 'that's such a good idea; it totally owns all other methods of selecting colors from a palette.' Seriously, if you can do something like this, it would solve a lot of problems including the 'palette space limitation' one.

[Helm]

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

Yes

[happymonster]

Well, the idea of the selector is interesting, but I don't think it would work so well here. In a paletted mode, you want to see the image if possible when altering colours, so the colour wheel would obscure most of the image. As would the palette wheel selector.

I've had some free time at work today, so I've redrawn the icons for the new smaller size of 20 x 20! I can now fit 8 icons horizontally again and they look uber-cute..

I'll try to finish off the undo/redo and fix some more things for a release this weekend.

[happymonster]

Ok, First of all I want to make an apology..

At the start of this project, people stated that the GUI and icons were too big, the colours too bright and the contrast too great. Although initially reluctant, I then started the process of improving the colours and contrast, but was more resistant to alter the GUI. This was because I was worried that I would get bogged down with the GUI section and lose motivation.

However.. After comparing the latest version to first early screenshots I have to say that you were all right. It does look far better now, and the smaller GUI will let me add in many more features at the same time.

So I apologise for being stubborn at the beginning, I think I couldn't quite see the wood for the trees as such.

And, so Thank you all for your invaluable C&C, and ideas so far!! I hope they continue..

[happymonster]

Added:

• New 20 x 20 pixel non-embossed icons
• Readded non-canvas coloured backround
• Added small mini font sized icons for Brightness and Zoom sliders (instead of a letter or text)
• Made the colour of the co-ordinates white and the descriptor (x, y, grid x, grid y, etc..) grey. This makes the values easier to see at a glance
• Made palette changes using palette tools (copy, cut, ramp, insert, delete) show the effect in the edited image (oops!)
• Hopefully fixed fill bug
• Added Infinite image drawing Undo/Redo (still need to add separate palette undo/redo)
• Readded Left mouse button / Right mouse button tool defaults, i.e. empty box / filled box when clicking on tool icon (These now use external data, so can be user-edited)

[happymonster]

Added:

• Palette box uses grey lines as outlines around swatches if an entry is too dark for black lines to be seen
• Co-ordinates when drawing boxes, lines, ellipses now start from 1 x 1, instead of 0 x 0, to make it easier to judge widths and heights
• Co-ordinates now can be drawn with negative numbers again
• Ellipses and boxes had become badly broken, now hopefully completely fixed so should be pixel perfect
• Sub-pixel accuracy when drawing ellipses/circles in an Expanding draw mode. Now can have radiuses of odd as well as even values
• When drawing squares or circles then the maximum width and height variable is used so the cursor is always on an edge, ala ProMotion
• Brush cursor on/off/crosshair now uses external data variable
• Added Dpaint style inverse crosshair (full image width and height - unlike ProMotion) for when drawing filled shapes or a fill tool

All these are little things which greatly improve the feel and functionality when working on an image.

[happymonster]

Screenshot:


Latest demo for testing purposes:
http://www.funkemunke.com/Pixe_Demo.zip
 

[Conzeit]

No need to apologise! I think many of us know how much of a pressure it can be to work on something all by yourself, so I think we can understand when changing some things feels like just a bit too much.

I'm way past satisfied just seeing you can change your mind when you see someone else is right =) all the more amped to keep watchin' on this one!

[happymonster]

Thanks! 

[surt]

Things:

• The cricle/ellipse from-centre sizing is wierd when draging the shape out. The diameter goes from 2 to 1 to 4 to 3 to 6...
• Don't get any even sizes with from-centre sized squares.
• Colour doesn't update when dragging on the planar colour selector.

Starting to get quite usable now, just need layers, a Linux build and screen-space panning yet. 

[happymonster]

The cricle/ellipse from-centre sizing is wierd when draging the shape out. The diameter goes from 2 to 1 to 4 to 3 to 6...

Oh! I don't get that, it goes from 1, 2, 3, 4, 5, etc.. on mine. I'll have to take a look at that again.

Don't get any even sizes with from-centre sized squares.

Yes, I still need to add this.

Colour doesn't update when dragging on the planar colour selector.

I need to add this too, which really will need code to seperate the gui from the drawing operation (so the gui doesn't slow down too much).

Brushes next..

[happymonster]

Ok..! I DO get the bug on mine, seems I broke something just before release.. DOH!
I've also seen another bug I need to fix.

Oh well, the next version will be fixed.

[happymonster]

I'm going to be working on some core features like user-brushes next (including some things I've not seen in other programs). So updates might not be as frequent.

[happymonster]

And indeed, working on brushes and other stuff is taking a while. Plus I've been a bit tired the last few days and not felt like programming.

Hopefully I'll feel like doing a little more once the weekend approaches!

[aregon810]

it dont work for me if i try to test it out =/

[happymonster]

Sorry to hear that. Can you give me any more details? What happened when you ran it? What is your system, etc?

[happymonster]

Ok, I have a question about layers. As you can tell from the image, I will be using icon images for the layers (much like is used in Photoshop, GIMP, etc..) Those icons seem to be around 32 x 32 pixels in size. But, how useful are the icons in telling what one thing is? I normally only use the text description myself with no more than 3 or 4 layers.

So, I was just wondering if 32 x 32 icons will be too small to be useful? Or what size is a minimum for a preview icon..

Any ideas from your own experiences?

[Live-Dimension]

I'm not sure if this has been said or not. I'm not going to go through the entire topic to find out.

However, GraphicsGale has a way of making selecting the anti-aliasing colours very easy.
You simply select two colours and use "Make Graduation" on them which fades each colour between the selected colours much like a gradient.
Since it's in the pallete it's simply to use.

Here's an (extreme) example.
R = Red,
B = Blue,
P = Purple.
0 = Random Color

Original Pallet
R 0 B

I select R and B, keeping 0 between them which then I use "Make Graduation".
So now it's like this.
R P B
The middle colour is 50% R, 50% B.

I could go like this.
R 0 0 B
"Make Graduation"
R RP BP B
Middle Colours:
75% R 25% B,
25% R, 75% B.

It just makes anti-aliasing soooo much easier, as you don't have to guess, nor do you have to calculate the average RGB values for each colour.

[surt]

Ok, I have a question about layers. As you can tell from the image, I will be using icon images for the layers (much like is used in Photoshop, GIMP, etc..) Those icons seem to be around 32 x 32 pixels in size. But, how useful are the icons in telling what one thing is? I normally only use the text description myself with no more than 3 or 4 layers.

So, I was just wondering if 32 x 32 icons will be too small to be useful? Or what size is a minimum for a preview icon..

I'd say I work mainly off the layer order rather than preview or name (I rarely even bother naming layers), so I'd be quite happy with just an index number, but I expect the more arty-farty visual-types would be put off by that.

GGale uses 28^2 previews. I find the GGale previews little better than useless, but that is due to the image scaling method used (GGale uses nearest-neighbour sampling) more than their size. I'd suggest using either an area-average sampling or a non-transparent-favouring area-mode sampling might be interesting/useful (never actually seen it used, maybe for a good reason, but should work very nicely for line-art).

Another way to make the limited pixel count more useful would be to just preview the bounds of the non-transparent pixels, so a small sprite on a large transparent background won't get lost.

One thing GGale does is stretch the image to fit the preview, disregarding aspect ratio.

Live-Dimension : I think that's a safe bet. I don't think I've ever used an indexed-mode paint program that didn't have that feature.

[Ai]

Live-Dimension : I think that's a safe bet. I don't think I've ever used an indexed-mode paint program that didn't have that feature.

Yes, although most of them do it quite wrongly; even most dedicated palette editors do it wrongly. For example, a correct 3-step graduation between intensity 0 and intensity 255 is NOT [64, 128, 192] but rather [137, 188, 225], because a proper interpolation is linear in the visual relationship of the intensities, and standard RGB is nonlinear in that respect.
Interpolating HSV/HSL also only makes proper sense when you derive the HSV/HSL values from linear RGB values.
So, it's worth mentioning as a suggestion: correct interpolation.

The formulas for converting between linear and standard sRGB, after they are converted to floats in the range [0..1]

when intensity < 0.0031308
  result = 12.92 * intensity
otherwise
  result = (1.055 * (intensity ^ (1.0 / 2.4))) - 0.055

when intensity <= 0.04045
  result = intensity / 12.92
otherwise
  result = ((intensity + 0.055) / 1.055) ^ 2.4

Using linear rgb can also improve other things, like the antialiasing filter and well... anything that combines colors mathematically to create a new color, really.

Using the above formulas, you can see that standard rgb values 64, 128, 192 are not on a straight line through the middle of the range 0..255, but on a curve along the bottom of the range 0..255; 64, 128, 192 convert to linear RGB intensities 13, 55, 133.

an example of the difference that correct interpolation can make:

top row is incorrectly calculated (interpolating through standard RGB), next row is correctly calculated (interpolating through linear RGB).
the rest of the rows just illustrate interpolation through other colorspaces.

[happymonster]

Surt:

Another way to make the limited pixel count more useful would be to just preview the bounds of the non-transparent pixels, so a small sprite on a large transparent background won't get lost.

Yes, I was thinking of this too. I think I will have to try a few things and see what works and what doesn't.

Incidentally.. What's this? Large icons with small text underneath, tabbed option panels, yet it's new MS software? How Ironic!!
http://www.geekpedia.com/gallery/fullsize/Microsoft%20Excel%202007%20Black.jpg

[happymonster]

I'm making progress on adding user brush support.

I've added 8 brush preview thumbnails underneath the brush shapes and slider in the Brush Options panel. I was wondering whether I should put it to the right of the layers at th top of the screen, but conceptually it makes more sense to have it next to the normal brush presets & shape/size controls.

The preview is a quick pixel resize for now. I will look to improve this later, but it's not too bad now.

You can currently copy an image and have the preview update, although you can't use the brush for drawing yet. I'm going to need to change the cursor/brush code for the user-brushes. SIGH! It's all a lot of work..

[happymonster]

Things are still progressing.. even if this thread has gone quiet!

[Conzeit]

that pixel resize preview thing doesnt sound bad to me at all, after all it's just a brush! unless there's some internal programing problem with it I dont see why u should worry about that...

[happymonster]

I'd just like it to look better in the future.

[happymonster]

In the last few days I've been doing a lot of reading of various blogs regarding user-interface design, icon designs, and other such material to do with creating GUI's.
I think I've read all of the articles on: http://blogs.msdn.com/jensenh/pages/table-of-contents.aspx, which describes the design and implementation of the Ribbon in MS Office 2007.

I've not actually used the ribbon, and I'm not saying I agree with all their decisions or the visual style, but I found the process fascinating to read up on.

Accordingly, I've done some actual proper design work (GASP!) using Excel as a kind of graph paper + colours + lines + fonts.

I came up with 6 major design themes using the GUI elements in Pixe. I then analysed these and came up with one that from a user interface point of view should require less mouse movements and less precision to reach the major elements as well as visually being more organised and lined up. This was actually quite different from the first decision I mocked up, but has proven the best choice (IMHO).

I've now been mocking up a design to fix some of the minor elements a bit more. But I will now start the process of altering the design layout in Pixe to fit the new design. In some ways it won't be too different, in other aspects it will be different than what I've shown before. Overall, I think it will help in terms of productivity and the 'feel'.

[blumunkee]

Make sure to read this as well. It's a good read, although I personally think balance and convenience should have (slightly) higher precedence over minimalism.

Are you left handed? I was wondering because all the panels are docked on the left side of the canvas. I'm right handed and it feels more comfortable having my UI to the right.

Also, I won't beat around the bush. The 4 pen colors thing is a Bad idea. With a capital b.

[Souly]

I like to collaborate and so from time to time I use OpenCanvas, a CG art program with multi-user connection
And doing a google search I was un-able to find a decent open canvas type program specifically for pixel art.
The problem I had with open canvas was you were just each given a different layer, you were un-able to erase or really properly add onto the other person's sketch.
If that makes sense.

Anyways, I'm proposing the idea for multi-user connection on one canvas if at all possible.

Obviously you're still working on the pixel aspect of it, but yeah just an idea.
Not even sure if it's already been mentioned can't seem to find anything by searching the thread.

[happymonster]

Some good points in the document you posted blumunkee.. Though I wish it was more modern, and not just concerning text based window systems.

Can I ask why people think the 4 pens idea is a bad idea? The specific reasons? Do people think it will be too confusing, or take up too much space?
It is optional if people use the extra two pens at the moment, and I believe MSPaint lets you use a 3rd pen?

Souly: It's a good idea, but that is beyond by abilities at the moment I'm afraid!

[happymonster]

Forgot to say, I am right handed. I know Dpaint had a right sided interface, but since then programs like Photoshop, PSP, Promotion, feature a left sided interface, so I've got used to those.

I'll add a right sided interface option anyway..

[Ai]

Can I ask why people think the 4 pens idea is a bad idea? The specific reasons? Do people think it will be too confusing, or take up too much space?
It is optional if people use the extra two pens at the moment, and I believe MSPaint lets you use a 3rd pen?

MSpaint is better not mentioned in a thread about a serious pixeling/graphics program IMO.

my reasons:
* yes, it's confusing
* we have two hands, in which we could hold one drawing implement each; a pencil has two ends, one for drawing and one for erasing. The metaphor breaks down when the number of pens > 2.
  'swap colors' becomes meaningless, and the equivalent 'cycle colors' is not anywhere near as obvious in it's effects.
* the lack of a good metaphor makes learning harder.
* it would probably take up too much space, in the sense that it would be using space but the user would not utilize or refer to it.

Of course I think new experiments are good, and it's true that I'm simply used to 2 colors; so I think it would be most reasonable to allow the user to enable 4 pens rather than 2, and have this switched off by default (presumably the 2 colors would expand to fill the freed space, which would be appreciated as the current 4 are too small imo)

[happymonster]

MSpaint is better not mentioned in a thread about a serious pixeling/graphics program IMO.

Well, that's an emotional argument, rather than a logical one..

I don't really know if the two pens - two hands analogy is correct. It seems more a case to me that most mice had two buttons..
It just seems that someone who is constantly switching from one colour to another and back again (either via a palette or an eyedropper) could benefit from a 3rd or 4th pen.

[blumunkee]

Photoshop, Promotion, and it's ilk have a thin bar on the left of the canvas for selecting tools. All the other controls get docked to the right of the canvas. I consider that a right handed interface.

My gripes with 4 pen colors boils down to 2 issues:

1. It's foreign – If I pick up any other graphics app I can reasonably expect it to have two colors. When I saw the screenshot of the UI, I was confused. I had to read your posts for an explanation of their use, and I had to reason out how and why I would need them. All in all I found it non-obvious and non-intuitive. Not offensively so, mind you. But it still felt foreign.

2. It's a solution to a non-problem – I have never once say down in front of a pixel editor and felt the need for more pen colors. I think this mirrors the issues the Office developers faced when they sat down and made guesses about what the average user wants and doesn't want, without any actual feedback from the users. It seems like a feature that in theory sounds like it would be useful, but in practice is not useful, or is even detrimental.

My ideal workflow is one which has a quickly accessible color picker and key bindings to increment and decrement the current palette index. This makes it easy to both grab an existing color from the canvas and to move through my organized color ramps without having to mouse over to the palette. The only time I need to defer to the actual palette is when I am modifying colors or reorganizing my palette. It is of utmost importance that I can navigate about my palette while keeping my cursor, and my concentration within the canvas, not in the ancillary panels.

Have said that, if you really think 4 pen colors will be a genuine boon to pixel artists, implement it. I'll be the first to happily admit that I was wrong if it improves my art.

[happymonster]

I understand what you are saying, but it is something that I have found myself wishing for, even if other people haven't necessarily!

I will see how well it works in tests. Perhaps just a 3rd color pen activated using a keyboard key instead of a mouse button would be better. As with everything else here, it develops rather organically as you can see..

[Akira]

I often feel the need for more pen colours. Often my sketches start off as three or four colour pieces to lay volumes down and I can't help thinking that it'd be nice if i had a hot key to use another pen colour. When i'm in promotion this problem is solved by the colour cycling hotkeys but the 4 pen system definitely interests me.

[happymonster]

Ah! So it's not just me then..

[surt]

While I don't personally see four unrelated pen colours as tremendously useful, I don't see them as a problem. If I don't want to use them, I won't.

If they were paired then they could be useful for specifying a dither colour pair or a ramp for each mouse button.

Could also be nice to have line, fill and transparent always at hand.

I'd like to see them be more than just colours: a full tool-context where you can specify separate tool, brush, dither pattern, etc. for each button-modifier combo.

[ilkke]

Hi, just discovered this thread to my delight!

Of all the programs that can be used for pixelling on PC (I started on Amiga), I found out that every single one is lacking perhaps an important feature or two, so your project is more than welcome

I have yet to read through all the suggestions by other people, but as a general rule, I believe you should add keyboard shortcuts (configurable if possible) to as many functions as possible, and also feel free to include anything that you feel belongs in the program. What's the use of making a new program if it's not different than the others? Also, when some people find a feature useful, and others object to it, perhaps it's best practice to make it optional, or configurable, or just easy to ignore.

Using four-color controversy as an example:
People are used to pressing 'x' to swap bf and fg color in PhotoShop. If you implement the 4 color thingie, then you'd either need more keys as shortcuts (wither 2 for next & prev, or 4 for each color having it's own), or more keypresses (of a single key) to to get back to the first color. Having 4 keys is perhaps quickest but maybe not economic. None of this would break the standard workflow if you simply make RMB paint with bg color and LMB paint with whatever color is selected. I personally do not imagine the feature to be useful as I use '[' and ']' to move through the palette quickly (which works well if you use few colors), but it wouldn't hurt me unless I had to go out of my way to achieve what I'm already used to.

My workflow relies on several functions that I find a must in a paint program, but I'd prefer to wait until the program starts to flesh out instead of bombarding you with feature ideas.

Good luck with it and I hope to see a test version soon!

P.S.
Oh, yes, make the icons for GUI editable!

[happymonster]

Thanks for the support!

I've been a little busy with friend's birthdays lately, but have also been doing some design work and ideas.

Cheers!

[happymonster]

I've also been working on other cool graphical techniques which will find their way into Pixe. I love experimenting with graphics technology, even if I can't explain how they work in proper mathmatical terminology.

[happymonster]

Frustratingly I've been feeling pretty tired this week. Maybe it's not helping that we've had a lot of snow these past few days.
As a consequence I've not really been upto doing much the last few days.

Hopefully I will feel more awake soon!!

[happymonster]

Don't worry, this is not dead!

I've been to a party this weekend and have valentine's day to celebrate with my girlfriend next weekend (so presents to buy!). I've also been working on a test program for a cool idea which works fabulously well and will be put into Pixe.

[happymonster]

Ok, here is the new design for Pixe when clipped to be running in a 1024 x 768 mode (obviously this will be a little less normally due to the taskbar/window title):




As you can see, the main tools are now at the top, to the right of the palette. Why is this?
Well, this design is based on a theory of minimising mouse movements. Apart from the canvas the most important parts of the GUI are the palette and the main tools (IMHO), with brush preset sizes close behind. So, I reasoned that a good design would minimise the amount of mouse movement necessary between those elements. Accordingly I created 6 variant designs using Excel (as a kind of coloured graph paper designs) and analysed each one in terms of distance, feel, visual look and how much you had to overlap elements to reach gui parts.

Let me explain that last part again.. In the old design you had to move over the other tool icons to select draw, line, etc.. Not only that, but the commonest tools where both the furthest away and the elements where you had to 'reach past' other tools to select them the most. Psychologically I think this does have a negative effect compared to designs where you don't have to do that and it seems easier to select tools / buttons.

I tried making the tools vertically orientated to the right of the tool options section. Despite the narrowness this seemed to work ok, except that you had to move some distance to get from the top colour to the bottom tool. If I put the tools to the right of the colours then you have to overreach for every colour which seems wrong.

So, in the end although I would have liked the tools and tool options to be closer, this seems (currently) the best answer. The palette, tools and brushes are all oriented around the top-left corner so reducing the mouse movement and overreach. The most important tools are now at the bottom of the 8 x 2 tool panel (closest to the image), while the most important brushes are closest to the image too.

Also in terms of style, you can see I have refined the 3D look somewhat and reduced the strenght of the coloured title 'bars', while adding more text titles to add both space and clarity. The icons are now very slightly softer/rounded and I've added (what will be an optional) tool highlighing effect to indicate which tool option panel is open.
Also, you now have an optional x1, x2 or x3 image view in the palette when it's over the image, which helps with drawing.

The top right of the panel under layers will feature both layers, layer tools and multiple effect/paint/filter slots (at least 10) which you can use to store paint modes, etc..
 
The palette and options are not done, so this is something I will go back to, but I think I will have a less cluttered version than previously and put some of the options in a seperate colour options panel.

[surt]

Personally I'm more in favour of the GUI using more horizontal screen space and less vertical screen space, as I prefer my view port nearer square, and what with widescreens and all. Being able to turn off the panel titlebars should alleviate this some (and maybe option to drop the infobar down to a panel?). On the plus side the current layout allows for larger layer previews.

Tools are something I particularly like having vertical, a one-deep bar at the screen edge is my preference (that's how I have things setup in GGale). You could always use the opposite edge to the main panels.

Having the image preview share space with the palette/colour selector is a neat idea. Maybe the option to toggle it between view centred and cursor centred, so it can double as a GGale/Neopaint-style loupe.

[happymonster]

The new gui makes it easier to move the various sections of the gui around (by editing text files). So yes, you could have what you suggest.

No feedback from anyone else?

[blumunkee]

Interesting. You've basically oriented your workflow to the top left of the screen. Personally I think bottom right is where most of the action is, but that may be because most paint programs laid out in the same traditional manner.

Having used Grafx2 over the past 2 weeks, I've come to appreciate the value of using non-persistent GUI elements to good effect. By that I mean there parts of the GUI that only pop up when needed. A good example are the brushes. In Grafx2 they are accessed by clicking on a small rectangular icon. The resulting popup shows a window with a large selection of brush shapes and sizes. I'd easily trade the inelegance of clicking through two events—selecting the brush icon and then selecting the brush size—over Pixe's approach, simply because it allows a much broader range of brush selection.

I think your program could benefit by allowing for more easily expandable non-persistent functionality. The brush sizes are an example, and I think the tool options would save a bunch of screen real estate if they where made to expand when needed. That would leave room for things that should be persistent, like the preview, palette, and layers.

[happymonster]

Maybe I only have experience of the older versions, but I thought Promotion, PSP and Photoshop all had a default top-left workflow? Anyway, you will be able to change things a bit.

I have to disagree with using only one icon button to select a brush. It's something that I do quite commonly (selecting different preset brushes) and so I don't want to have to click on an icon to do such a common task. I will probably make the largest brush (the one on the far left) a drop down arrow which leads to more brush size / shape options (as before).

The tool options will need all that space when I implement all the ideas I have for them, so it seems cleaner for me to have panels (like preview) not be hidden when options are open but you move over the canvas.

So Palette / Preview will be semi-persistant and layers will be persistant.


I think we are discussing things in a rather circular manner though, no one approach will please everyone.

[happymonster]

I'm having some difficult lately..

Doing Pixe is just a hobby for me, but it does give me a very nice feeling to know that others use it. Despite difficulties it has really improved immensely due to feedback from people here.

Unfortunately, I've been getting bogged down in making the GUI flexible enough to suit everyone and trying to come up with a default look that both myself and the majority like. As such I've not actually made much progress on the actual functionality while I've been floundering around trying to come up with a specific focus.

I always have the difficulty of where to draw the line between my own desires and that of other users. I think if I just do what other people want I will lose motivation. I mentioned this before with the GUI, but sadly I don't think people really heard what I said. I don't want to give up on Pixe, so I think the best direction is to make Pixe more what I want for a while (and that will probably be a bit less traditional, a bit more experimental, as that is the kind of things I like to play with).

I've just been getting frustrated with trying to make it good enough without any other real help besides opposing ideas and suggestions. Curse thee Adobe and your design teams!

So I'm going to have to pull back from implementing everyone else idea's for now and focus on my own design here.. As a consequence probably not many of you will like the way it will develop, but as I have said before, on my own I can't do the perfect Paint Program for everyone, it's just too ambitious.

But, this way Pixe will still develop..

[Mathias]

Hey man, dont' let it get to you too much. I'd highly recommend pulling back a little if you think this endeavor is too great in scope. Take a hiatus if need be. I know from personal experience that once I've worked for too long any one project, and the time spent is disproportionate to what the end-result is meant to be, I begin to hate the project and additional time spent on it is done begrudgingly because I hate to not finish something. I'm sure most are like that with pretty much anything, including you with this.

I didn't take you seriously at first. When you initially posted about creating your own specialized pixeling program, I thought 'yeah sure, this'll last for a few weeks . . .' But wow, look at you go! I have full confidence you'll have a finished release relatively soon. I think you've come to one of the best possible sites for feedback, so wise choice there  -BUT-  most of these guys are dedicated artists and don't understand your development process so I think you're wise again to have the discernment to know that their point of view most likely lacks the programming understanding you have and so the cascade of feature requests and disagreements is impossible to perfectly rectify.

You cannot please everyone all the time. So don't try. Unless you enjoy defeat. I think this is a life lesson applicable to everything. Why cram every perceivable feature into the first release? Keep your idea log running and plan expansions, new versions, however you to handle it, with additional features, but code your engine flexibly so as to allow for convenient integration later in the future. Who knows where this will go. It may eclipse Promotion and all the others.

My underlying point is a recommendation to you - Determine a goalmarker where you can cut off your alpha-phase and polish to something releasable, then implement richer features later.

(and to weigh in on the multiple colors thing, if it can be done smoothly, do it, why not? I like the concept)

[Jim16]

I like the design and feel to this. Now a must download!
I will see how this go's! This is probs a step up from Mspaint to the noobs on the internet so the more you do the more the new guys get to play with Like matias said, you do your own thing but make sure that its flexible in use. Actually as is is perfect for me and has all the available tools a basic pixel artist needs.

[happymonster]

Thanks Mathias and Jim!

Some good advice there! I do have a tendency to try to please everyone all the time in terms of designing games/programs, and clearly that's sometimes impossible.

I also got some other good advice from other people: Instead of focussing on photoshop, GIMP, and things like the GIMP redesign posts, think about what ProMotion and Graphics Gale do wrong as well of course think about what I want to see in Pixe.

[Mathias]

happymonster, where you at? pinging for progress . . .  Is there anything we here at pixelation can do for you?

[happymonster]

Hiya!

No, this is not dead. But I've had 3 things happen lately:

1. Spending more time at the weekends with my girlfriend.
2. Working on my own ideas rather than other peoples.
3. I recently brought a great netbook (Samsung NC10), which I want to use Pixe on. The lower resolution of the netbook (1024 x 600) means I've had to redo the interface to be more compact (while not too complicated) so that it works fine on both my main PC and the netbook.

I am still working on Pixe (albeit slowly).

[Ai]

Time for bumping! Any news for the last 5 months?

[happymonster]

I'm still working on Pixe (still slowly as well!)

 It now has partially implemented layers, but is not ready for public usage yet.

[Mathias]

Thanks for the update.

[happymonster]

Having to change the layer code as although it worked and was very powerful it was difficult to program for and conceptially to use. Now I'm replacing with a more traditional layer system (although a little bit more powerful I have to say).

The design and layout has also changed considerably since I last posted a picture. Part of this is due to buying a netbook which with a 1024 x 600 resolution meant that I had to change the GUI layout if I wanted to use Pixe on it. Also, I detect a general simplification in my design, moving away from having too much visible at once and just promoting the most commonly used aspects to the main screen, with eveything else tucked away in options.

So, here's the current design / screenshot, compact to fit in small screenmodes:

• Slimmer status text bar at the top (incorporating small pen colour indications in this screenshot).
• Palette underneath (still full size, with square swatches).
• Most common brush presents underneath. The leftmost one is for grabbed brushes, right clicking will let you select from multiple entries. Probably do the same with the presets to allow you to pick bigger sizes, etc..
• Drawing / most commonly used tools underneath the palette on the right (arrayed in the familiar vertical layout).
• Less commonly used options on the left
  
• Tool options panel (which changes for each selected tool) in the middle.
• Layers below, selectable with left mouse button, right mouse button for options (unless I change this idea..)

And an older screenshot showing the palette options for altering a single colour:

[happymonster]

Thanks. Are you refering to colour depth, i.e. 4 colour images, etc.. or colour palette range (512, 4096 colour palette)?

[ptoing]

He is referring to the latter. as in 9-bit (RGB 333) like Atari ST or the Genesis have.
In Promotion you can set anything from 2222 to 8888 RGBA, which is very helpful.

[32]

It may have been mentioned already but it would be nice if the colour sliders updated with your current selection, it makes colour picking a helluva lot faster if I can see what colour I'm getting before I move the sliders. I doubt I could reliably use RGB sliders without it.

I'm liking the look of this so far and I'll definitely give it a go when you release it.

[happymonster]

Ah I see.. Well maybe in the future, I'm not going to add things like that unless the basics are all done.

32: They do, that's just an old shot.

[surt]

Looking very nice, though I'm not sure about the tools being split in half by the options like that.

Any chance of another build to play with? 

[happymonster]

Not quite yet. Parts are still not-working due to removing the old layer code. I'm restoring functionality with the new code, but it's not ready for a demo yet.

[happymonster]

What do people think about paint mode / effects using something like this:

On the icon
----------------

Left click: Select for painting
Right click: Apply to the whole image (i.e. as a fullscreen filter)
Middle click / other key: Apply to the whole of the current user selected brush

I'm trying to see the best way to do this without duplicating too many icons / panels?

[happymonster]

I've been adding some more paint modes (hence my earlier question). So far I've got working:

Paint, Replace (replace pen colour 0 in image, with pen colour 1), Swap (swaps pen colours in image), Outline, Halftone and Noise (Like an airbrush but moves pixels around a little rather than adding new colour).

These all work for all drawing primitives by the way.

[Helm]

Also don't forget to put a thing like, double clicking in replace mode replaces all pixels of color A with color B. Optionally also removes the redundant index and remaps palette.

[happymonster]

Helm: Replace mode already replaces pixels of color A with colour B, you would have to right click to apply the paint mode to the whole image (in my current plans).
The colour index part is a good idea, but probably would be better as a seperate palette 'tidy / clean up' icon. This isn't something I am focussing on at the moment though.

I'm getting the undo/redo system working again at the moment.

[happymonster]

Ok, undo/redo seems to be working..

I've also got the first version of the PXE file format (layer supporting) implemented with load & save. Still need to add in full layer support though and link that in with the saving.

I think my priorities have been undo/redo, load/save, and then get grabbed brushes working again with the new internal layer/image format. After that I can start to fix the bugs that will have crept in and see how usable it is.

[BlackArmada]

when is a new executable verson going to be available?

[happymonster]

I still need to fix brushes, flood fill and some bugs first. But definately before christmas! 

[CrazyMLC]

I've only read the last page of this thread but I'm very hyped, I love the options between eclipse and circle, 'draw from centre', etc.

I'm going to try and give some feedback but again I've only read the last page.

One of the things that turned me off of using one of the programs I tried, GraphicsGale, is that everything took up so much space.
I have a pretty big monitor and I don't like having to move my head to do everything, I like having everything right in front of me.
When I tried GraphicsGale everything was disorganized, the windows were everywhere, etc, and to be able to have all the windows in the one window, I had to maximize it.
I loved all the features when compared to MSPaint, but I stopped using it because of the simple options that MSPaint has, all you need to do what you're doing is on the interface and everything else is on the menu bar. I'd love to have a simple interface like that but more organized and with all the extra features that makes art easier to make.

Keep it simple stupid.

I'd also like to be able to have multiple files open at once, a feature I didn't see from the screenshots.
Also as for layers, I'd like to be able to have an 'animation mode' where the previous and next layer act like onion skins.
And to only have two colors selected at once, but to be able to set sets of two colors to be able to switch to with the scroll wheel. For example: If I'm making a little cute dragon maybe I want to be able to have two colors of peach for the belly and two colors of red for the rest of the body.

[happymonster]

Thanks!

I also prefer a simpler interface. The latest promotion seems ever so complicated if you are not used to it already..

[happymonster]

I thought I'd better explain about the layers I use in Pixe. As in other paint programs you will be able to have multiple layers and move them around, in order positions, etc..

However, unlike in other paint programs, each layer in Pixe is multi-leveled. Not quite sure what the correct term for this would be, mabe eraseable layers, or scratch layers..? The idea is that say you were painting in oil paints and you wanted to remove a patch of a colour.. you could (if you were really good!) remove the colour layer with a palette knife revealing the old paint underneath. So, with Pixe you have an option to select the right mouse button as erase and this will erase any pixels under the drawn area that are the same colour as your current left mouse button pen. This doesn't mean drawing with a background colour, it means the old pixels are revealed underneath, without having to create a seperate layer.

In practical terms, this allows you to draw shapes over detailed backgrounds, say a white cloud shape over a shaded blue background and remove white pixels without having to redraw the blue shades. Yes, you can do this with layers in promotion / photoshop, or be the Fix Background option in promotion. But they require you to: either create a new layer for each seperate item, or to repeatedly fix background pixels when you start each new action. And if you didn't and you realised you need to erase pixels, then you are stuck.. With the layer system in Pixe you will be able to automatically and transparantly erase any pixels of any colour, anywhere on the  layer no matter when you drew it. Not only that but each layer has 4 levels, so you can erase upto 3 previous layers of 'paint' and each erase action is undo/redoable and the 4 levels for each layer are saved in the PXE file format.

I really think this will be very useful, but you don't have to use it if you want to. It's currently working fully in my development version so you will be able to play with it soon when I release a testing version.

[Stratto]

I really think this will be very useful, but you don't have to use it if you want to.

That actually sounds very useful.
btw will this have a color counter?

[happymonster]

Do you mean a total colour used information option? Yes, I'd like to have that..

[happymonster]

Added right clicking on an effect icon applies it to the whole image.
Added both BMP and PXE image file format loading and saving. You can currently press L or S to load and save from/to a set BMP filename, but no file selector yet.
Also added quite a few little bug fixes.

[happymonster]

I'm going to try and release a demo / beta-test tomorrow (hopefully)..

[CrazyMLC]

HOORAAAAAAAY!
YEEEEEAAH!
HUZZZZAH!

Can't wait to test this out.

[happymonster]

Pixe v0.4
-------------

Ok, this is now available for testing / use.  

http://www.retroidea.com/Pixe/Pixe_v0_4.zip

I'm going to add some detailed comments about the various tools (as a kind of read me manual) so you have more of an idea about what's usable:

Pixe will automatically save the image on exit as a project.pxe format. This is a format which supports layers (although not implemented) as well as the 4 level data for each layer. All tool options, positons are also automatically saved on exit (apart from user selected brushes). On start up Pixe will load the project.pxe file if found to continue working.

Pressing L will load a 8-bit BMP file from untitled.bmp (with minimal error-checking, so the wrong image or size will crash). Pressing S will save your current image as a normal BMP to untitled.bmp. Please note that this doesn't change subsequent saves on exit to use this file format or name, project.pxe will still be saved and loaded on the next startup. No file selector yet sadly (hence the L and S), but there will be one in the future.

Canvas: Left mouse button = draw with pen 1, Right mouse button = draw with pen 2, Middle mouse button held down & movement = scroll image, Arrow keys = scroll image, Mouse wheel = zoom in/out. Left control held and subsequent click = colour select to pen 1 or pen 2 depending on the mouse button pressed.
(The direction of scrolling can be reversed by selecting the scroll icon in the system (computer monitor icon) tool options, if you prefer the google maps style method of scrolling).

Palette: Left mouse button = select colour for pen 1, Right Mouse button = select colour for pen 2. Hold for one second with left mouse button = drag colour to another palette entry to Copy. Hold for one second with right mouse button = drag colour to another palette entry to Move (may change to swap in the future..)

Brushes: One user-definable brush (with preview) and 7 preset default brush sizes. More will be supported in the future.

Draw tools: All drawing tools work except for filled freehand.

Line tools: Only normal line works at the moment.

Box tools: All work.

Ellipse tools: All work.

Fill tool: Only one fill tool at the moment (more will be added), but this works.

Brush tools: Flip X, Flip Y and Rotate 90 DON'T work, but all others do. Normal brush mode, select area with left mouse button to copy into user-brush. Right mouse button when selecting area also erases the background (as per DPaint / PPaint / ProMotion). Tile brush mode allows you to copy a brush from the image using the grid size settings (even if not on), you can draw using the selected tile for creating mock-ups. Right click will go back to selecting a new tile. Click on a main draw tool (i.e. draw, line, etc..) to cancel the mode. You can toggle on/off brush transparancy (which treats the colour in pen 2 (right mouse button) as transparent. This is in fact dynamic, every time you select a new pen 2 colour in the palette the brush transparancy will be updated (if on) automatically.

Effect options: Three types of right mouse button drawing (will be selectable via keys in the future as well). Normal paint, eyedropper (GraphicsGale), and eraser. Eraser will erase pixels of the same colour as pen 1 (left mouse button) on the image, revealing OLD pixel data underneath. Works anywhere on the image at any time, and upto 3 layers can be erased. Below are multiple drawing modes, all of which work apart from shrink outline and brightness. Effect modes can be used with both preset brushes and user-selected brushes, as well as in all drawing operations. Please note that some effects might not always be visible (i.e. colour replace) if not over applicable colours. Icons and order in the panel are quickly done, and unfinalised. Right clicking on an effect icon applies the effect to the WHOLE image, rather than selecting the effect to draw with.

Undo / Redo: 64 level undo (left mouse button) and redo (right mouse button) working.

Palette options: RGB & HSV sliders all working, click on the slider bar to move to that point, or drag as normal. If you have the cursor slightly above the bar then the mouse cursor will change to a left arrow if left of the position indicator, or to a right arrow if to the right. Clicking in this state will decrease or increase the value for fine control. More global palette options, cut / copy / swap / insert / delete / ramp will be added in the future.

Grid options: Left clicking on the tool icon on the main panel turns snap to grid on/off. Right clicking switches between no-grid and checked grid. Fit to grid will fit two part drawing operations like boxs, ellipses, brush cutting within the grid size. Grids are shown as a grey colour by treating colour 0 in the image as transparant. This is not saved in final images and is purely visual. Size and offset can also be changed as well as the type of grid : none, line or check.

System options: Will have system related tools, settings. Currently only reverse scrolling on/off.


I'm most proud of the erasable layers, effect modes, more dynamic approach to brush transparancy, and smooth zooming in/out so far.
Erasable layers need testng some more please, but also let me know what you think, etc.. etc..

[happymonster]

Someone on another forum pointed out a speed issue when drawing in the centre of an image, which I tracked down and now hopefully have fixed in the updated exe (v0.41, same link). This should be faster all round actually, and should also fix a bug where if you had a grid effect on screen and went from the grid menu to the palette menu the grid would turn off.

[surt]

Had a quick play. It's looking and feeling very slick. The tools-split-by-options doesn't bug me like I expected.  

Couple of bugs:

• Drawing with Freehand the "Joined Up" option appears to join the last point to the second point, rather than the first
• Sizing an Ellipse with "Draw From Centre" option doesn't snap to grid when sizing

Still want panning in screen-space rather than image-space.  

[happymonster]

Thanks for the bug reports.

Still want panning in screen-space rather than image-space.

Sorry, I don't know what you mean, can you explain some more please?

[happymonster]

Has anyone else besides Surt tried it?

[Stratto]

I tried it out, but i encountered a problem with the grid.
I can't remember what i did exactly, but i think i changed the bg color and the grid disappeared, and i couldnt get it back.

[Akira]

I tried it. It's excellent so far. The biggest issue i had with it was when i clicked on to the screen from my IM window a line would be randomly drawn on the canvas. Not just a single click but a line. This doesn't happen if i switch the window in any other way, just when i change focus by clicking on to the canvas from a window on top.

[happymonster]

Stratto: That was a bug in the first version I uploaded. Could you please try again and see if this is now fixed?

Akira: Thanks! I didn't think of that, but I can change that so you have to click on the window once to get the focus back.

[happymonster]

* Fixed a bug with cutting/copying out a brush.
* Added Flip X, Flip Y & Rotate 90 functions in the Brush Options panel.
* Fixed speed issue with brush / fill / filled shape crosshair drawing.
* Fixed a few gui issues.
* Changing a colour with palette sliders is a little bit faster. (I still need to make this non-blocking when updating the screen).
* Added first data driven keyboard shortcuts: X - Flip X, Y - Flip Y, Z - Rotate 90 (all for when you have a user-brush), Control + Z - Undo, Control + Y - Redo.
* Fixed ellipses/circles drawn with expanding mode not snapping to the grid.

? Can't seem to reproduce joined-up freehand connecting to point 2 instead of start point.

(Zip file updated)

[happymonster]

I've been working on more stuff today, but getting tired now so will give this a rest until next week. I hope people like the new stuff I've not seen in other paint programs.

It's come an amazingly long way since the first version, so I'm excited about the possibilities for the future.

[EyeCraft]

I had a go of it. It has some very nice elements to it. Two things that I really missed though:

- The ability to load your own palette files
- The ability to shrink the canvas to a particular size?

A number of things lack tooltips, so I didn't really know what they did.

Also it seems like I can only select a new brush size from the buttons under the palette if I click on the paintbrush icon first?

More control over palettes in general would be really good. The ability to move colours around on the palette, the ability to mix two colours, to sort colours based on value, popularity, saturation and hue. Also shortcut keys for navigating the palette, (maybe numpad arrows?).

Also the dark background around the canvas should be something changable, or at least more neutral so as not to throw off colour perception.

Over all, though, it's pretty sexy.

[surt]

Thanks for the bug reports.

Still want panning in screen-space rather than image-space.

Sorry, I don't know what you mean, can you explain some more please?

eg. Zoomed in 32X. Move mouse one pixel's worth. The image on screen would move one screen pixel. Currently it moves 32 screen pixels.

? Can't seem to reproduce joined-up freehand connecting to point 2 instead of start point.

Always happens for me. You've got to push the mouse quickly for it to be evident though. EVIDENCE!

One thing that would be nice to have is the ability to start a tool from off-canvas.

[happymonster]

EyeCraft: A lot of those things you mention are things I plan to add.

Surt: Thanks for the image, I'll look into it. As for the one pixel worth, it would take forever to navigate around an image an high magnification!

[surt]

As for the one pixel worth, it would take forever to navigate around an image an high magnification!

In which case you zoom out. The reason for zoom is control. With the current method you have to be very careful not to pan right past what you want.
That is why screen-space panning is the norm. See Gimp, GGale, etc.

[happymonster]

Hmm.. makes sense. I'll have to have a play sometime.

BTW: Does anyone want to help with any icons? 20 x 20 monochrome style. They would have to be free of all restrictions for use in Pixe though. Let me know if you want to help..

[CrazyMLC]

I tried it, not sure how to save/load files.

[happymonster]

L & S (to load/save "untitled.bmp") It's in the readme post I made with the link.

[Jakten]

I'm liking this so far though I have a couple qualms. Is there a way to change the middle mouse drag to move the image according to you movements? It's weird to me to pull down and watch the image go up.
I don't really understand the zoom options, i figured clicking the zoom button would give me a magnifying glass but instead it did nothing. I found out that all I have to do is use the middle mouse button but I haven't found out how to use the zoom options that come from the mag-glass. It looks as thought it sets up your layout to have full size versions and zoomed in versions for working which I think is awesome. I just don't know how to make it work lol. As with the 3 options above grid are confusing to me. I'm sure you probably just haven't programmed those though.

I really like the different drawing tools you added though like colour replace and this tool that would be great for making oblique angled plans. I dont understand how the brightness tool works though.

Great stuff thought I really like how everything is laid out.

[happymonster]

Jakten:

Go to the system options menu (the icons that looks like a computer monitor) and you can select the option in there to reverse the middle mouse drag mode.

The zoom options (besides using the scroll wheel) aren't implemented yet..

but I haven't found out how to use the zoom options that come from the mag-glass. It looks as thought it sets up your layout to have full size versions and zoomed in versions for working which I think is awesome. I just don't know how to make it work lol.

The icons in there aren't working yet.

There 3 icons above the grid icon on the left hand tool menu will be (from top to bottom): Image options, Stencil options, Layer options.

The brightness tool doesn't work yet either, still need to program that.. and in my development version I am replacing that with brush pattern drawing.

[happymonster]

I've been working on some bug fixes and new features, but not uploaded the exe yet as it's easier to work on a few things and make sure they all work properly rather than uploading and then having to fix..

I'll think I'll space things out a little before the next downloadable update as I doubt people are using this for anything more than testing yet.

[happymonster]

Hmm.. I've been wondering whether it might be worth getting rid of the layer panel (below the tool options) and putting that in the layer tool options. I could then extend the tool panels vertically by one tool and provide more space for icons and options..

It's tricky as I want this to work on netbooks and they are quite limited in vertical space.

[surt]

If that means you would have to keep switching back and forth between tool options and layer options, then please no.

Why not run the layers along one edge of the canvas view?

[happymonster]

Don't worry, as you said I'll just run the layers down a thin interface strip to the right of the canvas. This will also let me add layer option tools as well.

[happymonster]

Doing quite a bit on different things at the moment (I'll post the change log when the next public beta is uploaded), so things are progressing well.

What essential (and basic) features does Pixe need to be usable in your view? I'm not talking about features not in another paint program, or advanced features in ProMotion, Photoshop, etc.. But more basic features that are required to start using the program.

[happymonster]

Effect modes are easy to add. I've changed the halftone effect to dither 50% (and also added dither 25% and dither 75%) these apply the current colour / brush filtered through a dither pattern, so allowing transparant drawing (unlike the old halftone). Also added something I think will be very useful, single colour stencil. This will let you draw as normal, but won't overwrite colours that match the current pen 2 (right mouse button). This is useful for drawing in shapes when the surrounding area is a single colour, without worrying about going over the edge.

I have the ideas.xls file which contains a lot of Surt's ideas for effect and such, but some are quite complicated so I'm looking to implement simple and useful effects at the moment.

No doubt I'd do more work on some totally different area of the program next..

(These changes aren't uploaded yet).

[happymonster]

http://www.retroidea.com/Pixe/Pixe_v0_4.zip

v0.42
-----

* Stopped icons being highlighted when mouse is over them, but whilst already dragging a slider.
* Stopped mouse cursor changing to arrows when above slider if dragging.
* Right mouse button on brush tool icon no longer select tile option, but lets the user change brush settings without altering the current drawing tool.
* Dragging a palette entry with the right mouse button now swaps colours instead of replacing one.
* Moving over pen swatches above palette allows you to select a colour for that pen with the eyedropper (left mouse button) or swap both pens (right mouse button)
* Palette and Grid sliders no longer block the GUI whilst waiting for the visual update to be done. Therefore more precision is allowed with the small drawback of a slight delay before the change is visible on the screen.
* Fixed a strange bug with undo / redoing graphics drawn with user brushes.
* After cutting out a brush, the default draw mode is now freehand, rather than dotted freehand.
* Added copy, swap, ramp, insert and delete palette entry tools.
* Added one level undo/redo for palette changes (whilst in the palette options panel only)
* Added Double X, Double Y, Double, Halve X, Halve Y and Halve (and some with keyboard shortcuts)
* Removed the layer strip below the tool options (this will go be moved to an thin vertical interface panel to the right of the canvas)
* Extended the panels for tool options, and started redesign for all panels.
* Added 25% dither, 50% dither (replaces halftone) and 75% dither. These are all now also transparant rather than dithering between both pen colours.
* Added Single colour stencil, paint as normal, except it won't overwrite colours that match pen 2.
* Added Shade effect, which if the current palette is within the range of pen 1 & pen 2, is shaded one palette entry lower if left mouse button is pressed, and one palette entry higher if right mouse button is pressed. Final colours are clipped to range boundary defined by pen 1 and pen 2.

[happymonster]

Hmmm.. Seems a lack of response? Too many updates from myself, or are people just waiting for more features.. or just not that bothered?

Maybe it's unrealistic of myself to expect a response every time I post or update. Obviously I need more fans!

[EyeCraft]

Fear not!

I dunno, I'm definitely interested in the project (especially after trying it). I guess I just assumed you'd take longer to implement so much 

Looks like a very nice update, will download and check it out. 

[happymonster]

Ah, ok! Thanks!

[surt]

Some of us are interested but also lazy.

The effects are great but they would be much more useful with some way to combine them.
e.g. Use Two-colour Replace Paint and Two-colour Dither to safely dither-blend colour transitions.

Ideally they'd combine in a graph of course, but I doubt you want that level of interface complexity.

Probably the simplest option would be to independantly toggle each on and off as in grafX2.

Effect Suggestions:

• Two-colour Replace Paint (replace both colours with the result)
• Range Replace Paint (mask to colour indicies between the two pen colours)
• Two-colour Dither (probably better as an option)

[happymonster]

I'm not quite sure what you mean by two-colour replace? Do you mean replacing two distinct entries in the palette with the current pen colour? And Dither is non-transparant and uses both pen colours?

I don't quite get Range Replace Paint either.. anything lower than pen 1 is clipped to pen 1, and anything higher than pen 2 is clipped to pen 2?

[surt]

I'm not quite sure what you mean by two-colour replace? Do you mean replacing two distinct entries in the palette with the current pen colour?

Replace both colours with the result. Current pen colour if using single colour paint, yes, or dither of both colours if using two-colour dither.

Dither is non-transparant and uses both pen colours?

Exactly.

I don't quite get Range Replace Paint either.. anything lower than pen 1 is clipped to pen 1, and anything higher than pen 2 is clipped to pen 2?

Replace anything within the range with the result. A range mask, basically. Not so useful without the four pen contexts I guess.

[happymonster]

Well, I can see the use in various two colour dithers. I think the others are a bit more specialised..

I'd prefer to get more commonly used effects in there at first, and then see how the interface is working before adding more rarely used ones.

[Jakten]

I really like the dithering tools! Great addition. I had a strange bug happen I think. I was right clicking through the right side of the menu (the one with the brush options and draw box etc.) and when I went to draw it drew a couple centimetres down and left from where my cursor was. Left clicking a few times fixed this but it was kind of odd. I'm not sure what shrink mode is doing, is it some kind of a mask?

[Photocopier]

when I click a menu option it draws underneath. 
but it's a really nice program 

[happymonster]

Ah, sounds like you've identified the problem Jakten reported. I'll look into that!!

[happymonster]

I've been busy doing sprites lately (you might have seen them) as well as doing other stuff, so not had time to do much on this lately.

[BwdYeti]

This is pretty nice. I look forward to the full version.

Some bugs I found:

Dragging a color in the palette over any icons in the menu and clicking on them breaks that icon.
If you move the pointer to the palette while drawing it switches to grabbing a color in the palette, and then kinda freaks out.
With the Ctrl eyedropper, moving the mouse after clicking and before releasing makes it not select any color.
If you can, holding Ctrl-Z/Y should go through steps repeatedly instead of requiring another press for each step.
I don't know the exact circumstances but Ctrl sometimes takes focus away or makes it lag or something. Something like Ctrl-Z right after drawing something.

Keep it up

[happymonster]

Thanks for the bug reports. I'll try to look into them when I get the chance.

[EyeCraft]

What essential (and basic) features does Pixe need to be usable in your view? I'm not talking about features not in another paint program, or advanced features in ProMotion, Photoshop, etc.. But more basic features that are required to start using the program.

Sorry, been meaning to remark on this. I've given a couple of attempts at bringing Pixe into my typical workflow to see where I get hung up on it. Here's my list (from most needed to least):

- Specific load/save of images, with selectable path, name and file type
- Application not full screen
- A faster eye drop? For instance ability to make right-click eye drop
- Canvas resizing
- Save/Load palettes
- Zoom-able preview, resizable preview viewport, ability to have preview always visible (basically make preview port its own mini window)
- A readout somewhere that tells you what magnification you're currently at

[NaCl]

I tried it, but had tons of serious problems. here are a few:

Instead of being able to draw a line how I wanted, it would draw "zig zags". Like, when I tried to freehand a 45 degree line, it would draw stairs. Only when I moved the mouse very fast would it give some sort of angle, though still not a free hand drawing, it was a bunch of segments of lines attached together.

I tried to get rid of everything I had drawn but could find no way

Tried to select a piece of the canvas but then my mouse because the area I selected and I couldnt get rid if it.

After I selected another tool, it still tried to make selections, I couldnt draw any longer.

Random white lines kept being drawn on the drawing area at times.

Drew a box, then couldnt do anything but draw boxes, even if i selected another tool.

Anyway there was some more stuff, and I don't know if it's my computer or I was just not using it right but I can't see my self using this at all with so many problems. I really couldnt figure out what was going on at any point.

[happymonster]

Updated, but not had much chance to test, so may have introduced some bugs..

v0.43
-----

* Added change image size option, 6 size presets and X & Y sliders to resize image. Need options to make as new, resize/crop existing image instead of erasing.
* Fixed bug where you could drop a colour from the palette over an icon.
* Stopped being able to draw onto palette and dragging a colour automatically as a consequence.
* Now able to start to draw off of the canvas.
* Bug fixed where you could click on an icon and draw to the canvas underneath.
* Fixed bug with palette swatch not always being drawn in correct colour when mouse is over entry in the palette.
* Fixed bug with holding down control and mouse button for the eyedropper when moving over image. Colour is now correctly updated dependent on final position.
* Added smoother per pixel scrolling when holding down the middle mouse button and moving the mouse.

[happymonster]

I'm on holiday from tomorrow until the new year, so this will be the last version before Christmas. Thanks to those who've enjoyed it despite the rough edges and missing bits.

[surt]

Yay, proper panning!
Working nicely.

[happymonster]

Thanks! Will try to do more work on this soon..

[qubodup]

I think the concept drawings (or were these screenshots?) are very nice. I am searching for a tile pixel editor and somehow found this thread.

happymonster: you should update the first post of this thread - at least give it a big, fat link to http://www.retroidea.com/Pixe/ 

I'm on 64bit Linux and wasn't able to make 0.4 run in Wine, I hope that it is portable enough for my platform and that you'll some day release the source.

PS: If you still use Excel for brainstorming, I recommend you upload it to Google Docs and share the read-only link here

[happymonster]

No, this is not dead!   Real life got in the way a bit, but I've been hard at work lately for the upcoming v0.5 release. Still a bit to do on that first! I've added some new features, bug fixes and GUI / interface changes since the last version here.

Here's a (large) screenshot showing the latest version (you will notice some changes from the last screenshot):
http://www.retroidea.com/Pixe/Pixe_34.png

The interface is a bit wider to fit in the layers strip and this also means more space for tool options. Generally the GUI is lighter in brightness, with more style consistent icons and anti-aliasing as well as more rounding on interface elements. In this screenshot you can see the optional 3 pane zoom windows (each zoom can be altered individually) ala Dpaint..

[happymonster]

With hindsight, it might have been better to start a new thread.. This one is now very large and the title isn't really representative of the project anymore.

I'll do that when I next post an update..

[surt]

Nice.
Is the image pane below the tools just a preview or a full image editor?
Is the layer count fixed at 8 or does the layer strip scroll?

[happymonster]

All the three windows are a full image editor.
As for the layer count, I've not got that far yet!