What about ArtPaint?

Pete 2017-03-31 22:36:53 UTC #1

Back in the good old BeOS days, ArtPaint was one of my favourite programs, seeing a lot of use, but it sort of languished in Haiku. The version I had was from 2008 (not realizing work was being done on it) and had so many lacks and bugs it was essentially useless.

I recently pulled the latest from HaikuDepot and found that it was actually becoming usable, though with still a few problems. I've bashed on a few of these, and I think it's now pretty close to its BeOS glory days. And it's likely that some GASoC work will be done.

So now might be a good time to see how it looks to others, and where it could still be improved.

I've put my latest update at http://GoodeveCA.net/ArtPaint (in both hpkg and zip). The source archhive at https://github.com/HaikuArchives/ArtPaint should match that when I get a PR accepted. Comment either here or at https://github.com/HaikuArchives/ArtPaint/issues

BTW, I noticed in another thread that Brunobastardi complained that no Haiku graphics program handled "large" images. How large is large? I have no problem with say 12 MP images from my camera, and I was able to nearly double that -- though I hit a "memory" limit above that.

Giova84 2017-04-01 14:08:42 UTC #2

Hi Pete, you did a good work!

However there are still some things that doesn't work, in ArtPaint:
If i add a Text field, it doesn't apply the color which I choose from the color palette; If i change the size of text (from the Text window), this doesn't have any effect on the text (it will remain always of the same size). Furthermore I don't see a way to move the Text on the image. EDIT: ok, was enough to drag and drop the text using the pointer of the mouse, i was expected to see another kind of pointer, like i see on others image editors.

I'd like to make a transparent layer, so I choose the transparency tool: it said: "click on the image to apply the transparency" (now I am on Windows and I don't recall exactly the exact phrase: ok, now I am on Haiku and it said "Press the mouse button to adjust layer transparency"): the only thing that happen, is that ArtPaint take the whole CPU (as I can see from ProcessController in the Deskbar) and no trasparency is applied.

I opened a PNG file with a transparent background, but in ArtPaint this background is replaced with a white color.

There would be some chance to see these things fixed?
Kind regards.

Pete 2017-04-01 22:22:49 UTC #3

Thanks!

Hah! Yes, I see that. The text panel doesn't seem to have any effect! Will have to add that to the issues.

This is confusing... There are two methods here. If you just want to make the whole layer transparent to some level, use the "Change Transparency..." item in the "Layers" menu.

The Transparency Tool (from the Tools window) had me totally baffled too -- until I actually read the manual... It doesn't actually make the area you paint transparent : it changes it to the level of transparency set in the Colour Palette. So if you've been working with a solid colour you won't see any transparency appear. Set the slider in the Palette window first. I think the "Speed" control in the tool panel isn't working very well. It seems to set the selected level almost immediately, whatever the speed. I suspect it was adjusted for the slower machines of 20 years ago. Another thing to look into.

Ya got me! It's not actually 'white'. If you check with the Colour Selector, you'll see that the alpha is zero. This is the way it is in BeOS, too, but it is definitely not ideal. It'd be much nicer to have the chequered background that most other apps show. ...And I spent days and days, and days, trying to make it do just that! I don't know what I'm missing, but everything I tried just brought me back to white (or else mucked up other things). Maybe it'll get figured out eventually.

Pete 2017-05-03 03:28:19 UTC #4

If anyone is using ArtPaint, I thought I'd let you know there's yet another update on my site:

http://goodeveca.net/ArtPaint/

v 2.1.2 fixes the TextTool glitch that Giovanni noticed, plus another annoyance or two. The suite of add-ons is now complete, and a few have been updated with better control panels. The manual has been updated a bit too.

humdinger 2017-05-03 06:26:21 UTC #5

I appreciate your work on ArtPaint! Ever more usable.

I'm a bit concerned, however, of forking ArtPaint and "releasing" new versions alongside the ones of the official repo. I'm sure you'll create pull-requests in time as you did in the past, and offering a sort of WIP "beta" version is OK too. But naming it "v2.1.2" like the next official release may cause trouble or at least confusion.

HaikuArchive is (at least wrt ArtPaint...) quite quick in merging PRs and if you think a new release is due, just open an issue saying so. Maybe others work on stuff that they'd want included, too.

Perelandra0x309 2017-05-03 12:42:33 UTC #6

Yes, please merge with the repo, I get ArtPaint that way. Also any possibility of getting x86 and x86_64 versions? I got a laptop and am trying to get an x86 hybrid instance setup but was disappointed to find no ArtPaint for it.

Pete 2017-05-03 19:10:12 UTC #7

Of course I hope/assume that the updated ArtPaint will be released into the depot as soon as possible. However, I don't see 2.1.1 there yet... I got the impression from Scott that putting a tag on that commit -- which Waddlesplash did for me -- would trigger a HaikuPorts build. (PRs are just slightly behind at the moment because of my GitHub stumbles that Humdinger knows about, but I should get things up-to-date in a day or so.)

However, for me, there are severe problems in having the depot as the only source. You can only install packages into a system that is at least as new as the package, because HaikuPorter puts all sorts of unnecessary dependencies in. I can't, for example, install the previous ArtPaint 2.1.0 from the depot into my perfectly satisfactory slightly older Haiku! When I build a package by hand, I can avoid that sort of silliness, and some other thngs that HP seems to do like insert unwanted mimetypes. The actual working contents of the package of the depot's eventual 2.1.2 should be identical to mine.

Pete 2017-05-03 19:13:57 UTC #8

Haven't tried but I guess it ought to be possible. I don't have x86_64, so somebody else would have to do that, but if I get a chance I'll see what happens under gcc5.

PulkoMandy 2017-05-04 07:13:17 UTC #9

Haikuports build are not automated at all at the moment. So to make a new release of something, you would need to update the recipe at haikuports, then poke one of the haiku devs to build the package and upload it to the repository. This is of course not a good solution, because the haiku devs have more useful things to do. Fortunately there is some progress on setting up a build bot to automate at least that part (you will still need to update the recipe).

As for the packages requiring you to update your install, this will change once beta1 is released. Currently the packages are built against a random nightly, and you need one at least as new to install them. Once beta1 is out, it will be the stable reference on which packages are built, so it will be much easier to install the packages without needing to update everything.

phoudoin 2017-05-04 15:08:18 UTC #10

Regarding the white background, I guess it's due to the white fill made in BackgroundView::Draw().
Instead, having set via BackgroundView::SetViewBitmap() a checkered bitmap and do nothing in Draw() should do what you're looking for.

In Sanity, I've made a quick and dirty CheckerBitmap.cpp that create a... well, a checkered bitmap.
Feel free to use it:

github.com

phoudoin/sanity/blob/master/CheckerBitmap.cpp

#include "CheckerBitmap.h"

#define ASSEMBLE_COLOR(a, r, g, b) ( (a << 24) | (r << 16) | (g << 8) | b )

CheckerBitmap::CheckerBitmap(uint32 size)
	: BBitmap(BRect(0,0, (size * 2) - 1, (size * 2) - 1), B_RGBA32)
{
	uint32 * bits = (uint32 *) Bits();
	uint32 height = 2 * size, width = 2 * size;
	
	uint32 light = ASSEMBLE_COLOR(255, 255, 255, 255);
	uint32 dark = ASSEMBLE_COLOR(255, 230, 230, 230);
	
	for (uint32 y = 0; y < height; y++)
		{
		for (uint32 x = 0; x < width; x++)
			{
			if (	((y < size) && (x < size)) || ((y >= size) && (x >= size))	)
				*bits = light;
			else

This file has been truncated. show original

Pete 2017-05-05 01:06:28 UTC #11

Mmmm? I don't see any white fill in BackgroundView::Draw(). And actually the background is where you do get a pattern -- of 'thin stripes'

ImageView is where the image atually gets composed (with 'BlitImage') and I struggled with that for days! Nothing worked. Must be missing something simple, but I couldn't see it...

Pete 2017-05-05 01:18:30 UTC #12

I've been hearing that for a while... Until it happens, though, I think I'll continue to create packages by hand.

Perelandra0x309 2017-05-05 12:08:16 UTC #13

Yes it is slightly annoying, but it encourages the use of the latest nightly image. If you have special needs for keeping older hrevs (like me for testing SoftwareUpdater) then that does present an issue but creating a clone of haikuports and building manually isn't too difficult, there is fairly good documentation.

Pete 2017-05-06 01:44:05 UTC #14

Not sure that's a particularly important thing to encourage. "If 't ain't broke..." and all that... For me with a DSL connection, updating is a bit of a chore, so when I have a version that works for me I have a positive wish not to update. [And I'm a nut whose day-to-day workhorse is still the "Ming Special" Be provided me with! Does my email and most of my common browsing -- BBC, Wikipedia, Google...]

Pete 2017-05-14 20:56:42 UTC #15

Umm...again I guess you have to explain what you mean by "needed" colours. That surely entirely depends on personal preference and the goal of the art.

The "Reducer" add-on actually existed in BeOS ArtPaint, but was removed by one of the porters, apparently because he thought it crashed. (Doesn't seem to now.) And maybe nobody knew about it because it was never in the docs! I personally had no real interest in it until I started thinking of turning arbitrary images into HVIF icons, via ArtPaint, autotrace, WonderBrush, and Icon-O-Matic... [And came to the conclusion it would only be a good scheme in very special cases. I successfully turned an old Amiga art of a tiger (below) into an HVIF. It is 19K!]

So just to illustrate colour reduction, here's a JPG of the ILBM original:
and a 16-colour reduction:
That's with the original ILBM dithering suppressed, and no dithering in ArtPaint.

Pete 2017-05-15 06:34:33 UTC #16

As a postscript, it's probably worth noting that ImageMagick works perfectly in Haiku, and is available on HaikuDepot. Out of interest, I just tried its colour-reduction scheme, and its 16-colour output is far superior to ArtPaint's. It's something of a monster to figure out (and command-line only, of course) but it does a heck of a lot of fancy stuff.

lelldorin 2017-05-15 06:47:21 UTC #17

Have never heard of this add-on. Is it included in art paint? Would be for my art paint tips and tricks page on the besly.

http://besly.de/menu/search/archiv/gfx/artpaint_tips-tricks_eng.html

Would like to describe more such things but know me with art paint and what it all can not be so.

That looks in any case already times very well.

I have meant that when I invite a picture in corel's photopaint, I can reduce the colors to the colors that are contained in the picture. In a gray scale image it can be there already times 2-6 colors. For my tutorials on the besly I use this often to reduce the images, which accelerates the load of the page, even if many mean that one does not need today.

Pete 2017-05-15 22:47:11 UTC #18

It's included in v2.1.2, though it was missing in Haiku versions before that. 2.1.2 has unfortunately not made it to the depot yet. It is available on my site http://goodeveca.net/ArtPaint, and on BeShare.

I'm glad you have a "tips" page for ArtPaint on besly. I was thinking something like that would be very useful.

Hmm, I wonder exactly what that involves. A 32-bit/pixel image isn't going to be affected by the actual number of colours present, but I noticed that when I used ImageMagick for colour reduction it generated an appropriate colourmap, rather than just repopulating the 32-bit version (as ArtPaint does). Just checked -- yes the IM file is about half the size! So for your needs ImageMagick would probably be the choice.

lelldorin 2017-05-16 04:38:57 UTC #19

Ok i will take the package and test the colorreducer for my tips page on besly.
Then i can put this ArtPaint version on our repository server.

Any other nice tips for ArtPaint?

Pete 2017-05-16 05:52:28 UTC #20

I'm sure there are -- once I get my wits together... I had some thoughts while working on the updates, but they've sort of faded right now.

One thing that misleads people a bit right now is that they think the initial 'white' background is actually (opaque) white, when it is actually fully transparent. If there's uncertainty, the Color Selector tool will show the actual alpha at any point. As I said a while back I'd like to fix this, but I've hit a blank wall so far.

You inspired me to go look up BeTips again [which seems to be pretty dormant; I need to ask Scot] and saw one ArtPaint tip that was a total surprise. I've always zoomed the image using the menu, which is a bit tedious. I never knew that the "Mag:" field in the Status Bar pops up a slider if you click on it that allows immediate zooming to any size! Definitely worth publicizing. (Hah! Just actually read the manual page, and it is documented.. Pays to RTFM -- carefully!)