Bounty proposal: Paint

I would vote for […]

+1

Changes in width/height only affect right/top edges.

So just like at present using the Hand tool to reset the origin, and using either Adjust size or Delete rows/columns (or Insert).

Consistency.

It would be nice to click on the image and be offered the chance to delete all rows/columns to the left/right/above/below rather than have to guess about how many there are…

It would be nice to click on the image and be offered the chance to delete all rows/columns to the left/right/above/below rather than have to guess about how many there are…

A fair point but for that (or for a full crop of the image) I tend to use the Copy tool with Export selected. You can then just rubber band the region you want and drag it back onto the sprite file window.

If so, it looks like that can only reduce the size of the sprite and not increase it. Is that right? I do like the cross shape with the four text boxes though.

Sorry Andy S, I didn’t see this until now.

Negative numbers increased the size of the sprite. Adjust clicking the arrows decremented the value.

Anyway, it looks like you already have nice solutions for this dialogue. :)

I bring tidings of some tangible progress at last. You may have noticed that Paint 2.26 now has the Colour Handling features.

!Help is available to explain the user interface additions, but it’s worth mentioning that you can now swap the foreground and background colour by dragging one of the colour icons on the new colour indicator swatch over the other one. Clicking on the icon for the background colour now opens its own colour picker in >256 colour sprites and the background colour has a dotted (actually dashed) outline on the colours window.

If you cast your mind back through the mists of time to the discussion of the artist-friendly palette layout in this thread, we discussed a process for remapping sprite palettes and pixel colours to preserve the new artist-friendly layout when you Edit Palette. As suggested, a confirmatory dialogue box lets you choose if you want to do this. I noticed one thing that we didn’t cover in that discussion: if you do remap the palette to artist-friendly and later delete the palette, almost every colour will be wrong (even if you didn’t edit any colours at all). As that would be confusingly horrible, I coded up a routine that reverses the remapping if 75% of the colours still match the artist-friendly ordering.

This then got me thinking that a more ideal solution could be never remapping palettes for the artist-friendly layout and instead always running a detection routine before building the colours window, so if most of the colours match the default palette, the colours window is shown in artist-friendly order, else not. However, at this point I’ve implemented your original suggestions, so please let me know your thoughts on these two designs.

I need to play with this properly still, but it’s great to see the changes. I’ve come across a few glitches so far, but I’ll post separately on those once I’ve given it a more thorough test.

On the artist-friendly issue, though: why not just restrict the artist-friendly display option to 256-colour sprites with no, or an old-style fixed, palette? That makes it clear that ‘artist-friendly’ is just a visual rearrangement of the colours in the Colours window, and doesn’t affect the actual sprite data.

If you have an editable palette (ie you’re actually changing the sprite data) then having an ‘artist-friendly’ layout seems both redundant and confusing. I think in the case of 256-colour sprites with full editable palettes you’d be better not having the option of multiple layouts in the Colours window at all – after all, you can arrange the palette just how you want using the colour editing function, then save it out and re-use as desired.

That would make the situation simpler, both code-wise and for the user, I think.

Hi,

I’m using Paint 2.20 (14 Oct 15) in the ROM 5.23 (21 Mar 17). Not new, so maybe this has already been seen. I just ran into it today.

16m colour mode, 1280×1024. Pi 2. Nothing unusual.

Menu → Snapshot.

Take any sort of snapshot. Doesn’t matter what or how.

It will pop up a save box with a sprite called “screen” as the default.

Drag it to Paint’s icon bar icon.
It will fail → Sprite doesn’t exist

if you do remap the palette to artist-friendly and later delete the palette

Yeah. That’s what happens if you delete the palette. ;-)

Maybe a simpler approach might be to pop up a confirmation – are you sure you wish to delete the palette?
Then on the user’s head be it.

On the artist-friendly issue, though: why not just restrict the artist-friendly display option to 256-colour sprites with no, or an old-style fixed, palette? That makes it clear that ‘artist-friendly’ is just a visual rearrangement of the colours in the Colours window, and doesn’t affect the actual sprite data.

Because I agreed quite strongly with what Jeffrey said about it:

A rearranged 256 colour palette sounds like a good idea to me, although it might be a bit odd when the palette jumps between the two formats (if the new view is automatically used when the default palette is detected, imagine what happens if someone edits a standard palette and then closes and re-opens the view)

A novice isn’t going to understand why the colours would jump around just because they edited one colour, and if we instead disabled the layout if a palette was even present, we make the feature less available, especially when having a palette is Paint’s default behaviour when in a 256 colour screen mode.

That’s why I still think the ideal would be Paint just looking at the sprite’s palette, no matter how it is arranged, and deciding whether that can be shown in an artist-friendly order. The perfect form of that would be some kind of algorithm that looks at the HSV values and maybe some other properties of the colours and sorts them into that layout algorithmically – but I think that would be pretty tough (you’re mapping 3 or more dimensions onto a 2D area, with possible duplicates). The simpler algorithmic option is just counting how many colours match the default palette and using the artist-friendly sequence if a majority do.

Having said that, something very close to your suggestion could be achieved quite easily by just changing the default behaviour of Edit Palette to be using the RISC OS default palette (i.e. don’t remap to artist-friendly) and having the confirmation dialogue box disabled by default.

16m colour mode, 1280×1024. Pi 2. Nothing unusual.

Menu → Snapshot.

Take any sort of snapshot. Doesn’t matter what or how.

It will pop up a save box with a sprite called “screen” as the default.

Drag it to Paint’s icon bar icon.
It will fail → Sprite doesn’t exist

Hmm, that’s odd. Just tested 2.24 in RPCEmu and it worked. I haven’t got a Pi 2. Does it work if you instead drag it to a sprite file window?

Does it work if you instead drag it to a sprite file window?

Same error, and flags the sprite file as changed.

Okay, forget it. I just rebooted and it all works as expected.

I think this is the part where nemo pops up and says something disparaging about the RMA. ;-)

Same error, and flags the sprite file as changed.

What happens if you run two instances of Paint; make a sprite in the first; MENU→Save; drag the icon onto the second instance of Paint on the icon bar?

if we instead disabled the layout if a palette was even present, we make the feature less available

But why do you need an ‘artist-friendly’ layout at all in cases where the palette is editable to whatever you like? The original suggestion seemed to me to overcome a problem that only affects fixed/no palettes – you can’t change the actual colours, and they’re in a funny order within the window. So it’s useful to offer an option to give an alternative layout for the Colours window, making it easier to find the colours you want without actually editing the colour values in the sprite.

In the case of editable-palette sprites, it feels odd to have access to one specific mapping, designed to re-order the standard palette to a more friendly layout, when you can’t guarantee that the ‘base’ palette will be standard, and hence that the final order will be anything useful.

Okay, forget it.

Your wish is my command Rick!

What were we talking about, anyway?

What was your name again…? ;-)

But why do you need an ‘artist-friendly’ layout at all in cases where the palette is editable to whatever you like? The original suggestion seemed to me to overcome a problem that only affects fixed palettes – you can’t change the actual colours, and they’re in a funny order within the window.

I take your point. It would be useful knowing of the users that actually edit palettes, what the typical use case is. If most users are only tweaking a small number of the colours, rather than, for example, all 256, then preserving a consistent layout makes more sense. It doesn’t help that there’s no way to manually change the palette order (out of scope for the bounty though!) short of redefining every colour. At least in the days of much of the RISC OS users being school pupils, I rather expect Edit Palette was used briefly for experimentation more often than to purposefully make a fully custom palette. I don’t think if a novice is just clicking around that it should do something confusing without explanation.

It would be useful knowing of the users that actually edit palettes, what the typical use case is

I’m sure it varies a lot. But if you’re, say, designing icons it can be very useful to fiddle with a sprite’s palette. You might have created a design in ArtWorks, exported it as an optimised 256-colour sprite, and then want to adjust some of the existing colours, or add some for further editing, etc. If you’re brave enough to try to work on the new-format toolsprites, you’ll definitely need to edit palette values direct.

By the way, in case this is coming over as negative, I really like the new artist-friendly layout! I think it’s a great addition for working on old-format 256-colour sprites. I just can’t see the rationale for using it when you’ve got a proper editable palette, and I think it’s more confusing for a new user to have messages about rearranging colour values when they try to edit a single colour, as well as more work for you to insert algorithms to decide when and if to shuffle colour values around.

Two observations:

Firstly, I presume palettes can be saved and loaded? Maybe Paint should simply show the palette as-is, and leave it to some sort of add-on to handle palette manipulations? I will agree that the standard order is bizarre in its groupings of four, so maybe it might be useful to have a basic optional translation by colour type (like all the greys together, all the blues, etc) but anything complex probably ought to be done to the palette by a different application?

The second observation is that PhotoDesk has an awkward palette arrangement too. It looks visually as if it is arranged “dark to light”. The thing that PhotoDesk does offer, that it may be something to consider for Paint, is the ability to pop open a window of “named colours”. I’ve dropped a screenshot showing this at http://heyrick.ddns.net/files/pdcols.png

I presume palettes can be saved and loaded?

Yes, they can.

Maybe Paint should simply show the palette as-is, and leave it to some sort of add-on to handle palette manipulations?

But that won’t help in the central case here – old-style 256-colour sprites – because you can’t edit their actual colour values, either inside or outside Paint. Andy’s useful addition is for Paint to optionally display the colours in the Colours window in a more helpful order, which has no effect on the sprite data itself. I think that’s a nice feature – I’m only questioning its usefulness/practicability in the case of new-style, editable-palette sprites.

By the way, in case this is coming over as negative, I really like the new artist-friendly layout! I think it’s a great addition for working on old-format 256-colour sprites. I just can’t see the rationale for using it when you’ve got a proper editable palette, and I think it’s more confusing for a new user to have messages about rearranging colour values when they try to edit a single colour, as well as more work for you to insert algorithms to decide when and if to shuffle colour values around.

I agree that the message is likely to be confusing for a new user, which is why I added an option to turn it off. It would need very few code changes to just have it off by default, with no remapping of palettes when off and we could go further and have the whole artist-friendly layout option defaulting to off as well unless the sprite has no palette.

To remove more of the functionality than that, we’ll have to wait for Michael Drake and Jeffrey to weigh in again, as the remapping stuff was basically their design.

I will agree that the standard order is bizarre in its groupings of four, so maybe it might be useful to have a basic optional translation by colour type (like all the greys together, all the blues, etc) but anything complex probably ought to be done to the palette by a different application?

Rick that was basically my preferred option. Note that the feature is already optional (open Paint→Advanced), and the algorithmic sorting of the colours was my ideal solution to this (other than a more extensive choice of predefined palettes but that’s unfortunately out of scope).

Okay, just downloaded the beta Harddisc4. Paint is in !Boot.350Hook.Apps (or something like that).

First up, the create new sprite window is much better. A personal annoyance of mine is how the width is after the height, but it’s been like that since forever. The mess of colour/palette options is greatly improved by the drop-down choices. For 256 colours, what’s the difference between 64 fixed and 16 fixed? I tried both, the result in the palette looks the same…

Which brings me to:

to optionally display the colours in the Colours window in a more helpful order

I really like the artist friendly layout. Yeah. That. That’s a nice arrangement.

One tiny question – why is Edit palette in the Paint submenu and not in the Edit submenu?

I’m only questioning its usefulness/practicability in the case of new-style, editable-palette sprites.

Well, here’s an idea. It is optional right? So default it to “on” if it’s a fixed palette, and “off” if it is a custom palette. That seems sensible, doesn’t it? And if the user disagrees, they can change it. Does Paint support Paint$Options like Edit does? Add something to allow them to override this (maybe a bitmap to select on/off in given contexts) and all bases are covered.

I like that colour arrangement and creation window enough that I’ve just dropped a copy of this into Apps so hopefully it’ll override the ROM version.

Thanks for the positive feedback guys.

One tiny question – why is Edit palette in the Paint submenu and not in the Edit submenu?

Ask Acorn. According to Help, the Edit menu is “to perform various operations on the whole sprite” whereas the Paint menu is “to control the colours and tools used during painting”.

Does Paint support Paint$Options like Edit does?

Yeah it does and my new settings are saved there too. Just make sure your copy of Paint isn’t buried very deep in your directory structure, as that feature seems to choke on very long path names.

For 256 colours, what’s the difference between 64 fixed and 16 fixed? I tried both, the result in the palette looks the same…

Yeah the 256 colours that it generates are the same. The difference is just the number of palette entries saved with the sprite. I can’t remember the exact voodoo used to expand the colours but it behaves the same way that Paint always has with those palettes. It’s a VIDC backward-compatibility thing.

If you cast your mind back through the mists of time to the discussion of the artist-friendly palette layout in this thread, we discussed a process for remapping sprite palettes and pixel colours to preserve the new artist-friendly layout when you Edit Palette. As suggested, a confirmatory dialogue box lets you choose if you want to do this.

I may be missing the point (since I don’t mind the 4×4 weird layout of 256), but could the artist-friendly thing be dealt with by just re-ordering the colours window to not be in ascending colour number order? That would allow you to pick the colour in an artist-friendly way, but the underlying sprite would still be in weird order which is helpful to avoid needing a custom palette or ColourTrans table (so making sprites smaller/faster to plot). I don’t see any reason to shuffle pixels or similar as long as the colours are the default RISC OS palette.

You could even have other views. Menu click on the colours window and choose from: artist-friendly, weird VIDC, luminance, or any other arbitrary sort order in the colours window.