Sign in to follow this  
Lode

LodePaint

Recommended Posts

Lode    1003
Hello, LodePaint is a painting program supposed to be as easy to use as Paint, but with a lot more features, focused on pixel-editing and color math rather than printing and publishing. It has been getting more and more features lately, and I can already happily use it myself to create textures and pixel art drawings, as well as cropping screenshots and such. Please try it out! It can be downloaded here: https://sourceforge.net/projects/lodepaint/ Features: -brushes such as pixel-pen, soft brush, eraser, color replacing brush, ... -geometric tools such as circles, polygons, rectangles and floodfill -full alpha channel support, more alpha channel features than any painting program I know -easy navigation: zoom and pan while in the middle of using any tool, full usage of all mouse buttons, use the arrow keys to move exactly one pixel, ... -many filters, including color manipulation, generation of patterns, fourier transform, convolution matrices, transformations, pixel-art rescaling, curves, ... -rectangular selections that can be dragged around and copied (when holding CTRL) -masks that allow filters to operate fully, partially or not at all on areas of any shape of the image -support for HDR images, with a color mode of 128-bit (one 32-bit float per color channel per pixel) -file formats: PNG, JPEG, BMP, TGA, RGBE (HDR) and an unofficial 128-bit dummy format because no other file format exists for the 128-bit RGBA images -plugin support for extra file formats and filters -unlimited undo and redo steps -support for many color models, both in the color chooser dialog and various filters -customizable colors of the GUI, as well as ability to customize all icons and the very GUI itself -pasting a screenshot or data from other painting programs -the GUI uses OpenGL, in fact this program runs in a computer game engine (requires 3D hardware acceleration) -multiplatform (Windows and Linux) and open source Screenshot:

Share this post


Link to post
Share on other sites
szecs    2990
The interesting thing is that you do the same as me:
We have a windowed application, with a custom windowed GUI inside it.
This post is more like a question:
Is it elegant to do like this, or is it more elegant to use the win32 windowing in case of a windowed program, or it doesn't matter?

I feel it's a bit strange, but maybe it's a common thing.

BTW the GUI is good, haven't tested all the edit box features yet (this is my whim)
and still haven't implemented the offset thing :P

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by szecs
The interesting thing is that you do the same as me:
We have a windowed application, with a custom windowed GUI inside it.
This post is more like a question:
Is it elegant to do like this, or is it more elegant to use the win32 windowing in case of a windowed program, or it doesn't matter?

I feel it's a bit strange, but maybe it's a common thing.

BTW the GUI is good, haven't tested all the edit box features yet (this is my whim)
and still haven't implemented the offset thing :P


Whether or not it's elegant, I don't know. I know that it's certainly not common at all, I've never seen any computer program with a built-in GUI, except computer games and old DOS programs which had their own GUI rendered with ASCII characters.

A disadvantage is that some computers don't support it (when not having hardware acceleration), but an advantage is the flexibility and multiplatformness.

Share this post


Link to post
Share on other sites
First off, this is an incredible program, and it's clear you've put tons of work into it. It's very nice, and pretty polished.

I've been looking for a new pixel editor for a couple months now, since I upgraded to Windows 7, and they made MSPaint a artistic brush program (paint/watercolor simulator thingy), which makes it not so good with pixel editting.

Your program just became my new tile/sprite editor, if it can hold it's own for more than casual playing around.

(I understand it's still work in progress, so pardon me if I point out bugs or wanted features that you're already aware of)

Bugs:

1) Drawing a line of pixels, using the Pencil tool, off the edge of the image, shuts down or crashes the program. (A very smooth/silent crash)

2) When selecting the text in the RGBA sliders of the color, you can 'select' beyond what you are supposed to, when selecting from right to left.

3) The [x]'s don't work on your GUI windows.

4) Your triangle fill algorithm is slightly off; observe:



5) Your message boxes sometimes have too wide a string of text:



GUI nit-picks:

1) If the window does not have focus, and you click on the window, ignore that first click (Regain focus, but don't use that click to draw).

2) Allow arrow keys to move the image around the view. (Especially since if you drag the image somewhere where you can't see it, you can't drag it back).

3) When you have text input boxes, the first click in the box ought to select all the text (glad to see you accept double clicks!).

4) Allow the text to be slightly larger, if possible. Some of your users will be running at a higher resolution (which many artists will be).

5) If the window loses focus, make sure to collapse the menus.

6) When you create a new window, center it in the view.

7) Allow for drawing multiple lines of text (accept Enter presses as newlines).

8) In the 'Rescale' window, instead of having a 'Use Percent' button, make changing the 'Width' automaticly change the 'Width (%)' field with it, and vice-versa.

9) When you click of a drop down menu (like the one in the 'Rescale' window), close the menu.

10) Clicking off the image, should unselect the current section of image you have selected.

11) Instead of a 'Reload' button, sense if the image file changed, and pop up a "The image on file was changed, do you want to reload from the changed file? (Your work since last save will be lost)"

12) 'Image->Selection->Select All' is typically in 'Edit->Select All'. Same with 'Select none'. As for 'Image->Selection->Delete Selection', it does the exact same thing as 'Image->Clear', and so isn't neccesary. 'Image->Clear' should also be in the 'Edit' menu.


Feature requests:

1) User customization of:
- A) The colors the 'color pallette' in the upper-right corner.
- B) The default colors in that corner, when the program starts up. (I don't mind if I have to do it in a text file)

2) User customization of the default folder to 'Open' or 'Save' at.

3) A way to edit just specific channels of the color (especially the alpha) without messing up the other channels (Little checkmarks next to the 'R' 'G' 'B' 'A' under in the Color selection window would be good). Also, a way to only have one channel of the image visible at a time.

4) A way to view the image you're working on tiled side by side (good for tile editing for games).

5) When setting shortcuts, why is the brush size shortcuts called 'Dyn change up' and 'Dyn change down'? Might I recommend, 'Brush size increase' and 'Brush size decrease'? Also, I feel it increases it's size in too high increments, obviously that is relative to how you use the program - large images or small images, but since holding CTRL and scrolling the mouse wheel already increases it in increments of 5, could the Dyn shortcuts only increase/decrease it by 1 (or perhaps allow the user to set it, when setting the shortcut)?




I like the looks of the GUI! I really really like that you support transparency; it irritates me that MSPaint doesn't support it.

You have in the 'File' menu: 'Save', 'Save as...', and 'Save Copy As...'. I'm not sure what the Linux has for standard menus, but it'll probably confuse Windows users. I assume (but haven't tried it) 'Save Copy As' functions how Windows users will expect 'Save As' to function. Maybe make 'Save as' work as normal, and save a new copy (and overwrite the older if named the same), and have 'Save as...' be renamed to 'Rename and save' or 'Rename image file' or something.

Kudos for implementing your own Open/Save windows!

Question: Why's the program say, 'Standby' every now and then? Shouldn't it go to standby when the window loses focus?



This is an awesome application, excellent job! It's very very impressive (and much better than I would've done). I think the custom GUI gives it a nice personal touch.

Thanks for sharing it, and thanks even more for making it freely available and open source.

Share this post


Link to post
Share on other sites
Lode    1003
Thanks for your very thorough list of bugs and suggestions. Some of them are already on the TODO list, others will be added. This post certainly gives me a boost to fix certain ones instead of always implementing new filters :)

I'm actively working on this program, so bug fixes such as the ones you mentioned, or others, and new features, can be added at any time.

The arrow keys already have the purpose of moving the mouse cursor. But if the image is outside of view, press the "zoom 1" button in the toolbar to bring it in the center again.

The small distinction between clear and delete selection is that clear also works if there's no selection. And with masks there's also a difference. The "del" key is assigned as shortcut to delete selection, but I don't think the "del" key fits as shortcut that clears the entire image if there's no selection at all.

Having the ability to choose predefined color palettes (in the color chooser) and create your own ones is also planned.

I'm also going to make the folders of the file menu much handier by remembering last location and such. User customization of this default path also sounds like a nice idea. I might even add customizable favorite locations in the file dialog.

The "dyn change" shortcuts are called "change" because it can also change other things than brush size. It can for example be configured to change the hue of the color and such instead in the options dialog. Maybe separate shortcuts for some of those could be a good idea indeed...

The full list of todo's is here: http://lodepaint.svn.sourceforge.net/viewvc/lodepaint/trunk/src/todo.h?view=markup

About "save as" and "save copy as":

-"save" and "save as" do exactly that what all Windows programs (as well as modern linux programs) do.
-"save copy as" does exactly the same as "save as", except that after doing "save copy as", the path of the image is still set to the previous location. In other words, when doing "save" after "save copy as", the image is saved to the old location instead of the new location. So... Save copy as, is used to make a quick backup of the image to a separate file, while still working on the original file. I thought that this feature worked exactly like this in some windows programs, including photoshop.

I haven't done anything to detect whether the window has focus or not. If SDL can do that, maybe I can use that, but for now I've not studied that. I must say that there's a trend in Flash games these days where Flash games pause if your browser window loses focus, and I HATE that. Must be a brand new feature in Flash because I never saw it before and now it's a trend.

The "Standby" is there because LodePaint uses a game engine, so it redraws every frame. So the video card is being used all the time. So if you'd leave your computer and let LodePaint run, it'd constantly consume more electricity. Hence the pause feature, while in "pause" mode, it draws only every half second or so. So this is actually a "green" feature! :D

Share this post


Link to post
Share on other sites
haegarr    7372
Quote:
Original post by Lode
Whether or not it's elegant, I don't know. I know that it's certainly not common at all, I've never seen any computer program with a built-in GUI, except computer games and old DOS programs which had their own GUI rendered with ASCII characters.
It can often be found for 3D modelling applications. Look at blender, Maxon Cinema 4D, Poser, etc.

Share this post


Link to post
Share on other sites
Dragon88    246
So is this intended to be a paint application that eventually gets embedded in other applications (builtin image editing for games, etc)? I guess I'm not sure why you chose to have builtin GUI. The goal of the application in general seems like it might be similar to Paint.NET.

Just curious, not denigrating your work in any way.

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by Dragon88
So is this intended to be a paint application that eventually gets embedded in other applications (builtin image editing for games, etc)? I guess I'm not sure why you chose to have builtin GUI. The goal of the application in general seems like it might be similar to Paint.NET.

Just curious, not denigrating your work in any way.


In theory it would be kind of possible to embed this program in a screen in a wall in some 3D room of a game I guess (with some work), but no, that's not the intention, it's intended as a standalone application.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lode
About "save as" and "save copy as":

-"save" and "save as" do exactly that what all Windows programs (as well as modern linux programs) do.
-"save copy as" does exactly the same as "save as", except that after doing "save copy as", the path of the image is still set to the previous location. [*snip*] I thought that this feature worked exactly like this in some windows programs, including photoshop.

That makes sense; I always find myself doing 'Save As: myfile_WIP_1.png', and then having to 'Save as:' or 'Recent files...' to get back to my original. I don't use Photoshop, but now that you mentioned it, PaintShopPro has that also, I just was confused about what it was so I never used it.
Quote:
I haven't done anything to detect whether the window has focus or not. If SDL can do that, maybe I can use that, but for now I've not studied that.

It's pretty easy, if you feel it's important (as a user, I probably wouldn't notice unless I was running 50 things at once), just capture 'SDL_ACTIVEEVENT', and if 'state' contains (bitwise) 'SDL_APPINPUTFOCUS' the window lost or gained focus. If the 'state' field contains 'SDL_APPACTIVE', it was minimized/maximized, and you can go to lower intensity of drawing.

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by Servant of the Lord
That makes sense; I always find myself doing 'Save As: myfile_WIP_1.png', and then having to 'Save as:' or 'Recent files...' to get back to my original. I don't use Photoshop, but now that you mentioned it, PaintShopPro has that also, I just was confused about what it was so I never used it.
.


On closer inspection it turns out Photoshop doesn't have it, so my memory probably also comes from Paint Shop Pro instead (I don't actually own these programs, just have memories of them or can search screenshots of their file menu on the web). I just know I've seen that functionality before, somewhere. And indeed, avoiding having to use the save as twice for such cases is exactly the intention of this :)

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by Servant of the Lord
Bugs:

1) Drawing a line of pixels, using the Pencil tool, off the edge of the image, shuts down or crashes the program. (A very smooth/silent crash)


I can't reproduce this one. Is it every time you move the mouse outside the image while drawing? Or only in a special circumstance?

Share this post


Link to post
Share on other sites
Quote:
Original post by Lode
I can't reproduce this one. Is it every time you move the mouse outside the image while drawing? Or only in a special circumstance?

No special circumstance - happens every time I do it, even if I just start up the application.
Works with the Pencil, Brush and Eraser tools. Clicking and holding down the mouse button, to draw with that tool, and continuing to hold it down as you drag it off the image causes it to crash. It doesn't occur if going up or left, only if going down or to the right*. Oddly, it doesn't crash if you only go one or two pixels outside the image, you have to go about ~5 pixels outside the image for it to crash.

*I would guess, from similar bugs in my programs, you are accessing the pixels of the SDL_Surface directly, and writing to a place that's out of bounds of the surface data.

Share this post


Link to post
Share on other sites
Lode    1003
Ok, I'm investigating it... It doesn't happen for me, and there are various checks in both the buffer you're drawing on (it's an OpenGL texture instead of an SDL_Surface!) and the undo buffer against accessing values outside of the range, so there must be going on something more subtle somewhere. Hard to tackle bug, this one!

If the size of the painting is a power of two, then the size of the image is exactly the size of the buffer. If the size of the painting isn't a power of two, then the buffer is larger in memory (mapped to a power of two buffer, for OpenGL). So possibly it might crash more for you on an image of 256*256 pixels, than an image of 257*257 pixels for example... But for me it doesn't, but I'll find it!

EDIT: Fixed it. The fix will be in the next release. The cause was a call to "glTexSubImage2D" with out of range parameters. Apparently some video cards like this better than others :)

[Edited by - Lode on March 15, 2010 7:27:31 PM]

Share this post


Link to post
Share on other sites
Lode    1003
The crash bug should be fixed! Could you check if it doesn't crash anymore? (when painting with brush and moving outside the painting while drawing).

Some of the reported bugs were fixed (like the X buttons now work, some input fields behave a bit better, ...).

And there's support for opening multiple images now (but not yet copying data between them, that's for the future).

The newest version is here: https://sourceforge.net/projects/lodepaint/

Share this post


Link to post
Share on other sites
lightbringer    1070
Quote:
Original post by szecs
Is it elegant to do like this, or is it more elegant to use the win32 windowing in case of a windowed program, or it doesn't matter?


It's not elegant at all. Native applications should use the native windowing (that users are already familiar with) for best look & feel. Don't make users learn the quirks of a new windowing toolkit if you don't have to.

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by lightbringer
Quote:
Original post by szecs
Is it elegant to do like this, or is it more elegant to use the win32 windowing in case of a windowed program, or it doesn't matter?


It's not elegant at all. Native applications should use the native windowing (that users are already familiar with) for best look & feel. Don't make users learn the quirks of a new windowing toolkit if you don't have to.


For LodePaint it was this custom GUI, or GTK+. I chose the custom GUI.

But szecs is making a game, for a game it most certainly is elegant imho.

Share this post


Link to post
Share on other sites
lightbringer    1070
Quote:
Original post by Lode
For LodePaint it was this custom GUI, or GTK+. I chose the custom GUI.

IMHO that was a big mistake. At least, I have no interest in using your program based on this fact alone :)

Quote:
Original post by Lode
But szecs is making a game, for a game it most certainly is elegant imho.

For a game it's a different story of course. From szecs's post it was not apparent to me that he meant a game.

Share this post


Link to post
Share on other sites
szecs    2990
Don't use me as an example. My GUI is still broken...(the minesweeper)

But one thing is truth: an editor type application should have the most features the native GUI has, in your case keyboard navigation and short cuts (but I know it's a work-in-progress project).
I don't know if I will implement it, because most of the time my users will be clicking on the field. But your users need to be able to switch between tools an features very frequently.

And I suggest to include the shift+ellipse/rectangle feature: with shift pushed you can draw circle/square.

And an other thing: if user uses a tool, then presses a tool hotkey while drawing, an other tool will be switched on, but if the user switches back to the first one, the firstly used feature continues (even if (s)he drew with the other tool). So the features/tools should be canceled and switched of completely, when selecting an other tool.

And a thing that bothers me about Photoshop, and I like in Paint, that the opposite button click cancels the drawing.

Is it possible to make the polygon tool place points only when left button is clicked, but not when it is held down? Or is it intended to work like that?

I hope that's clear what I'm saying, I'm not sure.

[Edited by - szecs on March 22, 2010 10:18:48 AM]

Share this post


Link to post
Share on other sites
szecs    2990
Sorry for the separate posts.

Edit box:
The caret blinking should be reset (show the caret and reset timer) on events (click, keyboard events)
And if a portion of the text is selected, pressing "Home/End" should turn off selection.
Because now the caret will be placed at the beginning/end of the whole text, but writing will be placed in selection.

Share this post


Link to post
Share on other sites
Lode    1003
Quote:
Original post by lightbringer
Quote:
Original post by Lode
For LodePaint it was this custom GUI, or GTK+. I chose the custom GUI.

IMHO that was a big mistake. At least, I have no interest in using your program based on this fact alone :)


Do you have some examples of big things missing in this custom GUI that make this a problem?

Simply "because it's custom" doesnt really help much. GTK, Qt and Java are also custom in some ways for example. So is the "GUI" of web-based applications such as the Gamedev.net forum... And many movie / mp3 players for PC.

What kind of things could users be expecting from a GUI that doesn't behave properly here?

I know there are some things that can be improved, such as the edit boxes, using tab to navigate to other fields, mnemonics for menus, etc..., and these things are possible and will be done, but knowing the most annoying / important ones is interesting to know where to put the priorities.

Share this post


Link to post
Share on other sites
lightbringer    1070
Quote:
Original post by Lode
Do you have some examples of big things missing in this custom GUI that make this a problem?


Sorry, I know I'm not being very helpful, but I don't have time to download and evaluate it in detail (although I might if it had a native look and feel ;-) ). One thing that is apparent from the screenshot is that it looks nothing like the native interface in any recent Windows release. If anything it kind of reminds me of GUIs circa 1994-96. This is already a big problem IMHO because it means that users will not be immediately familiar with it.

Quote:
Original post by Lode
Simply "because it's custom" doesnt really help much. GTK, Qt and Java are also custom in some ways for example. So is the "GUI" of web-based applications such as the Gamedev.net forum... And many movie / mp3 players for PC.


Custom - there is a tremendous difference between "Qt custom" and "Lode custom" in that there are at least many other programs out there that are "Qt custom" :-)

GTK, Qt - I'm not familiar enough with them so can't comment on specifics.

Java - SWT provides native look and feel. Swing has a pluggable L&F so you can set the L&F to native, although IIRC it's only an emulation. Generally I would use SWT for best native look and feel on every platform, but I'd rather not open that can of worms and invite the Swing vs SWT people into this thread :D

Web applications - are not really desktop applications although they are moving that way thanks to JS/AJAX. Also, the web works on a different model (stateless, post/get, state emulation via sessions) so it's much harder to make it adapt a native L&F (but you can provide a "standard" L&F if you use one of the javascript libraries like Dojo, for instance). Even then, there are some web-specific usability guidelines that most good websites follow, such as form labels and fieldsets (and more generally: progressive enhancement).

iTunes/movie players/Blender/Steam - many are good examples of why not to use a custom GUI. iTunes works, barely. Others - not so much. Blender still gives me chills and I've been using it on and off for years now. If there was an equally powerful open-source 3D modeling app, I'd jump at it in half a minute.

Quote:
Original post by Lode
What kind of things could users be expecting from a GUI that doesn't behave properly here?

It must look and behave (L&F) like a native app as much as possible. This includes everything from how the menu is laid out to what happens when the user right-clicks somewhere. On Vista/7 it must integrate seamlessly with Aero. For cross-platform all this is of course rather difficult, but that's why we have cross-platform frameworks like SWT. I don't know which problems are specific to your program (my guess: many) but from the above comments it seems that keyboard shortcuts are one of the main problems.

Various companies (Microsoft, Apple) publish design guidelines for their user interface toolkits. If you are not familiar with those yet I suggest you look them up, as they should help you understand and iron out some of the issues (I'm assuming it's a bit late in your project now to go with a non-custom GUI).

[Edited by - lightbringer on March 22, 2010 2:31:18 PM]

Share this post


Link to post
Share on other sites
Lode    1003
Well on a Windows Vista / Windows 7 PC, there's an actual Windows Vista / Windows 7 frame around it, if that can improve the first impression :)

I just don't own these OSes to make such screenshots. And the WinXP look as well as my KDE 3.5 desktop look aren't sexy enough. Do you think showing the regular window decoration around it in screenshots could improve this first impression?

Quote:
Original post by szecs
Sorry for the separate posts.

Edit box:
The caret blinking should be reset (show the caret and reset timer) on events (click, keyboard events)
And if a portion of the text is selected, pressing "Home/End" should turn off selection.
Because now the caret will be placed at the beginning/end of the whole text, but writing will be placed in selection.


Ok in a next release these features will be in the edit boxes + also the ability to select text while holding shift + the arrow keys and home/end. It was only 5 minutes of work to implement :)

[Edited by - Lode on March 23, 2010 3:33:45 AM]

Share this post


Link to post
Share on other sites
Lode    1003
It now supports copying images and selections to the clipboard, having multiple images open at once, pasting images as selection into an other open image, and blending the selection with the image with the Image->Selection->Blend Selection operation (NOTE: the linux release is a bit younger and currently has much more blend modes while the windows release has only 1).

IMHO this makes the whole program a lot more powerful because thanks to all these things together it's now possible to combine images from multiple sources in various ways. Not as good as layers yet, but a first step in that direction :)

Share this post


Link to post
Share on other sites
Sign in to follow this