Bounty proposal: Paint

I’ve now finished the Wrap option for Move Whole Sprite.

Here are the remaining bounty tasks (there are also a few issues people have raised with the existing features, not listed here):

Sprite Formats

• Allow creation of new format sprites:
• Alpha mask sprites
• Alpha channel sprites
• Editable vertical/horizontal DPI {45|90|180}
• Enhanced “full info” display in sprite file viewer
• Minimise wasted space
• Display more information (potentially under control of the user) to ensure it lives up to the title of “full info”

General Editing

• Undo/Redo function (F8/F9)
• Edit alpha mask/channel
• Add “Font” and “Size” options to Text tool
• Enhanced Brush tool ideas:
  
  • Add opacity slider
  • Alpha channel sprite support + sprite brushes effectively provide airbrush support
  • Make it more user friendly (the typing in sprite/shape names interface isn’t ideal, especially for the builtin brushes)
  • RISC OS version compatibility issues (Forum post)
  • Tint brush sprite by currently selected colour when “shape” option unticked, i.e. use a ColourTrans Transfer Function



• Enhanced spray can tool ideas:
  
  • Opacity

Bug fixes

• Crash on brush selection (Forum thread)

Hopefully that lot won’t take me too many centuries! A few of them I’ve already done a little bit of work towards, mainly Undo/Redo.

My offer still stands that if any other developer is feeling enthusiastic, impatient, or insane enough to take on some of these tasks, I’d gladly split the bounty proceeds subject to ROOL’s approval.

Personal gripe – does the new sprite creation window still have the height above and before the width? That one keeps catching me out as it’s common to specify width and then height (look at any screen resolution definition, one doesn’t talk about 1080×1920 and if one did we’d assume the screen was portrait). The way Paint’s window is set up leads to the dimensions being misinterpreted.

Could this be tweaked? [good news – a minute or two in a template editor ought to do it!]

Thoughts on the others:

Undo/Redo function (F8/F9)

One level or multiple levels of undo/redo?
If one level, will it be “last thing done” or a checkpoint (like PhotoDesk’s pressing Space)?

Add “Font” and “Size” options to Text tool

If fonts, would they be anti-aliased into the image?

Add opacity slider

Sounds useful.

An idea that you probably won’t want to do (I reckon it’s a bit complicated) is a clone tool. This is different to copy in that you give it a source location and from then on it behaves like a cross between brush and spray can, only it reads pixels from the source (the destination is fixed when you first use the tool after setting the source, and the two move in sync). This is useful for rapidly touching up flaws and blemishes in the image.

Better explanation here – https://learn.corel.com/tutorials/using-the-clone-brush/
It isn’t the software I use, but they’re pretty much the same idea.

Personal gripe – does the new sprite creation window still have the height above and before the width?

Yeah.

Could this be tweaked? [good news – a minute or two in a template editor ought to do it!]

Maybe. Were you volunteering? It would also need the icon numbers swapping around, otherwise the tab order will be wrong.

One level or multiple levels of undo/redo?

It’ll be multiple levels. It’ll be unavailable while some operations are underway, for example while a polygon is being defined, which is what Draw does.

If fonts, would they be anti-aliased into the image?

Depends how easy that is to do. Draw seems to be able to do it if you select “None” as the text tool’s background colour. I’ll have a look at the code.

An idea that you probably won’t want to do (I reckon it’s a bit complicated) is a clone tool.

It’s not so much that I don’t want to. It’s more that there are other programming projects I’d like to get involved with and barring someone finding an elixir of eternal youth, I know I’ve got to choose a finite number to do in whatever time I’ve got left. :)

I’ve been trying to get my head around what’s expected for this requirement:

• Alpha channel sprite support + sprite brushes effectively provide airbrush support

It came from this discussion:

I’ve just realised that the alpha channel support with the brush tool effectively provides airbrush capability. Might be worth having some predefined generated brushes, like how the brush tool currently has some predefined shapes.

Yes, some kind of airbrush functionality could be nice, and shouldn’t tread on the toes of commercial image editors too much. It’s also something that could be made to work on older OS versions (alpha-masked brush sprites probably wouldn’t work on older OS’s due to the kernel not understanding them, but a simple brush opacity value would work as translucent sprite rendering can be handled by SpriteExtend+BlendTable+InverseTable softloads)

The brush tool will have an opacity slider that should work with alpha mask sprites. Regarding predefined brushes, I think we could include some softer brush sprites, possibly with their own alpha masks.

The thing is, I still wouldn’t call that an airbrush. Airbrush implies it keeps laying down more colour the longer the mouse button is held down, according to a spray rate setting. If I add an airbrush checkbox and a spray rate setting to the brush tool, then I’m making the existing spray can tool redundant.

I could add the brush sprite selection controls to the spray can tool instead, but I think that will over-complicate it and confuse users (although maybe just 3 or 4 predefined spray pattern images that work like the toolbox buttons could work). Otherwise, the word “airbrush” probably doesn’t belong on this bounty requirement. Don’t forget the spray can tool is already getting an opacity slider as well.

Yeah, I think that adding an airbrush tool to Paint is beyond the scope of this (already pretty extensive!) bounty. Just adding alpha mask/channel support to the Paint tool would be great. I think all the original comment noted was that this would in principle give the foundation for creating a full airbrush tool, but it’d be a lot of work to implement properly, and as you say there’d be a question about whether it’s really an extension to the Spraycan tool, or it’s own thing, etc.

then I’m making the existing spray can tool redundant.

Not really, it’s like the difference between a paintbrush and a felt tip.

At the moment, the brush and spray can are pretty harsh (pixel set or pixel unset), however one sets a group of pixels in a predefined pattern (the brush sprite) while the other sets ‘random’ pixels in a given radius. I feel that even at 95% transparent, you would be able to see effects of using a brush, whereas the spray can may be a little slower to use but its random nature would better disguise its use.

So I would say that they are different tools…

Jeffrey,

Yes, some kind of airbrush functionality could be nice, and shouldn’t tread on the toes of commercial image editors too much. It’s also something that could be made to work on older OS versions (alpha-masked brush sprites probably wouldn’t work on older OS’s due to the kernel not understanding them, but a simple brush opacity value would work as translucent sprite rendering can be handled by SpriteExtend+BlendTable+InverseTable softloads)

When you say alpha-masked brush sprites probably wouldn’t work on older OS’s, is there a particular RISC OS version I should check for (say, 3.50)? Or is there a better way to determine support?

Presumably on machines where an alpha-masked brush won’t work, I’d want to disable the alpha mask / alpha channel features of Paint altogether, correct?

When you say alpha-masked brush sprites probably wouldn’t work on older OS’s, is there a particular RISC OS version I should check for (say, 3.50)? Or is there a better way to determine support?

I think the best way to determine support is via OS_ReadModeVariable. On RISC OS 3.5+, any sprite type which the kernel doesn’t recognise gets treated as 32bpp. So if you pass it a mode word for a non-32bpp sprite which has a property you’re interested in (e.g. RISC OS Select alpha mask, or RISC OS 5 alpha channel), and you get back a log2bpp of 5 (or C=1, which is what will happen on RISC OS 3.1), you know that the kernel doesn’t support the sprite type and you should avoid using it.

Presumably on machines where an alpha-masked brush won’t work, I’d want to disable the alpha mask / alpha channel features of Paint altogether, correct?

Yes.

Ah great, thanks.

The brush tool enhancements are coming along nicely by the way, but will need to wait until after RISC OS 5.28 for release I think.

I’ve been playing with brush opacity. The bad news is because of the way the brush tool works, by repeatedly plotting the brush sprite under the mouse pointer as it’s dragged around, the opacity rapidly builds up as the images overlap. I could code something to mitigate this a little by slowing or stopping the plotting if the mouse pointer has moved less than a threshold distance in a certain time, but we’ll still have to live with darker intersection patterns where edges of two brush plots overlap. Yep the circle brush basically becomes a Venn Diagram tool, or perhaps a Slinky spring drawing tool! It looks a little better in true colour modes but you can still see the effect especially when zooming in.

The memory hungry solution could be to implement a simple layering feature, where the brush strokes are plotted to a second sprite (at full opacity) while the mouse button is held down, which is then blended at the required opacity with the underlying sprite. Unfortunately I’m sure you can understand my reluctance at wanting to code that as part of this bounty. It’s also not immediately obvious to me at what point the new brush strokes would get written onto the underlying sprite. I suppose it would be each time the mouse button is released. If it was done too often it would start to create the interference patterns again where the last brush stroke overlapped the current one.

Hmm. I’ve been ruminating about this overnight and whilst outside and wound up writing about half the code for a basic Layers feature in my head! Not wanting to waste those thoughts I’ve quickly rattled the code off into a file.

I might see how easy it is to hook this up to the brush tool logic so the brush plots to a second translucent layer (which gets made automatically if there’s enough memory, the first time the brush tool’s selected) whenever the opacity slider is less than maximum. Then when the sprite window redraws, any visible layers will get plotted on top of the base sprite. Whenever the brush tool stops or the mouse button is lifted, that’s when the active layer will be merged down (just plotted onto the underlying sprite / mask). I don’t think the merge should delete the layer in this case, just clear it, because it will be reused next time the brush is used. If there’s not enough memory to make the layer, the opacity slider for the brush would be disabled.

I’ve already got functions to make and delete a temporary sprite, so maybe this is doable without taking up too much extra time. I have no intention of making a user interface for manipulating and selecting layers anytime soon, but a lot of the functionality would be there, so it wouldn’t take someone too long in the future, especially if it was menu-driven.

I’ve given this some more thought and I’m not sure there’s a clean way to solve this problem with Layers in Paint at present. I’m still implementing brush opacity by plotting the current brush stroke to a second sprite, as described above, but I’ve decided it’s probably best to hold back on creating data structures to support multiple layers just for that. They’re out of scope for the bounty, but I got a little over-enthusiastic thinking I could get them for free by the way I did the opacity. Just about every operation in Paint makes use of sprwindow_swap_output_to_sprite(), which could be modified to direct output to an active layer, but there are too many edge cases that would need extra code (for example the transformations, Adjust Size, Move Whole Sprite, Undo / Redo, Edit DPI, Insert Columns / Rows etc.), never mind the fact all this stuff would pollute the codebase until we get a UI for the layers. So, yeah, I’m going to park the little bit of code I wrote for that. It’s certainly something I might revisit in future though.

I’m pleased to report that the brush opacity feature seems to be working now, using the fix described above. At the moment the opacity value is hard-coded as I haven’t built an Opacity control on the tools window yet, but the new interface to select brushes is mostly done. If I can find some time to iron out the worst bugs, I might put together a test build so you can have a play with the new features.

YES :)

That sounds like excellent work, Andy :)

Whilst I’m writing, would it be possible for you to chat to Andy Vawer (or Adrian Lees) who I believe have both (independantly) produced JPEG/PNG handling expansions for !Paint (particularly Andy). There’s a danger of things being caught up between folks not wanting to damage each others’ bounties, and features not getting integrated in. If anyone feels like they’re missing out bounty-wise, let me know and I’m sure we can make it right.

Basically the JPEG/PNG handing is the key use I have for Adjust !Paint – being able to send screenshots in standardised/compressed formats is essential for email. No-one needs to be sending 3840×2160, 16M sprites via email!

Hopefully you guys can work it out, and manage to integrate things in in time for 5.28?

Sorry for the following question…
Is there no way to get the Adjust Code from ROL/3QD?
I use the a9home Paint without really changes on my RISC OS 5.xx machines.
Is really better to use in my eyes. The jpeg stuff is not working because the module behind will not work with RISC OS 5.xx but the other parts.

Basically the JPEG/PNG handing is the key use I have for Adjust !Paint – being able to send screenshots in standardised/compressed formats is essential for email.

Have you never tried !Snapper 8)

Whilst I’m writing, would it be possible for you to chat to Andy Vawer (or Adrian Lees) who I believe have both (independantly) produced JPEG/PNG handling expansions for !Paint (particularly Andy). There’s a danger of things being caught up between folks not wanting to damage each others’ bounties, and features not getting integrated in.

ROOL asked me to hold off on any big changes until after 5.28 is out so I wasn’t planning on submitting any further code (unless any new showstopper bugs appear) until then.

I certainly wasn’t worried about integrating with the PNG bounty, so long as it’s only import / export (or clipboard transfer) of PNGs/JPEGs, once it’s converted to sprites internally it shouldn’t overlap with any of my changes. I’m quite confident merging my code with anything that does change, though (which would happen after 5.28).

If anyone feels like they’re missing out bounty-wise, let me know and I’m sure we can make it right.

I’m not missing out thanks. To be brutally honest, my main concern is just getting it to the finish line now, so I can move on to other things.

Chris Johnson – it’s not so much me, but users who send me screenshots!

Andy – that’s cool. My intent was simply to make sure you were aware of what others had done, so that it could all dovetail together.

Raik – might be possible, but with Andy V’s JPEG/PNG work, and Andy S’s artistic/brush improvements, we’re probably in broadly the same league now without.

I agree that the whole ImageFileRender architecture would be extremely welcome in OS5, but one step at a time, I guess!

Raik – might be possible, but with Andy V’s JPEG/PNG work, and Andy S’s artistic/brush improvements, we’re probably in broadly the same league now without.

Maybe but not sure. In vacation I have try to use the Paint from Direct Image.
I’m missing any handling things e.g. Font support and other. If I back at work next week I can post any screenshots what I mean.
Nothing against the improvements. Really good work and many thanks for this.

I’m missing any handling things e.g. Font support

Font support for the text tool is one of my remaining bounty tasks. We’ll get there. :)

Sounds really good but it is like it is… double work.

Raik – so true, but also, that kind of thought leads to improvements not happening, which is why I’m so pleased that Andy S and Andy V have risen to the challenge of improving things.

Behind the scenes, we’d obviously like to merge in stuff from both branches, but in the absence of anything concrete, what we’re seeing here is the best way forwards. Frustrating, yes, but the end result is positive progress :)

Is what I mean. I see the positiv progress and I’m happy about this. But a rest of frustration is alive. To many things are really unsolved…