Bounty proposal: Paint

They’re not supported yet.

Please don’t rush to do what ROL did. There’s a lot that could have been done with mapping functions, and wasn’t. And what I’m having to do to achieve the result on the right would make your teeth curl.

And for Andy:

That’s the result of loading a sprite file with an extension area.

putting the “stab” into “having a stab at CMYK”

Doesn’t look that different. The one on the left is a bit darker is all. I was expecting the boat to look like Mr. Blobby or something.

On a related (thinking of darkness), gamma/device/colour calibration…

A “bit” darker? There’s sea in the RH picture. There’s solid black ink in the left. It’s the same image.

On a related (thinking of darkness), gamma/device/colour calibration…

That already exists though. 1MB GIF WARNING

And the calibrator:

A “bit” darker?

Haven’t you gotten accustomed to British understatement yet?
Solid black is indeed a “bit” darker than sea.

That already exists though.

Sort of.

The RiscPC had screen gamma control (I remember having an app that let me tweak the gamma). Thing is, once you have fiddled with the monitor gamma and the picture on the screen looks “correct”… Will it print like it looks?
Until all of that is working in sync, whatever is on screen is just a representation.

In nerdier terms, how did it arrive at such darkness? Is it merging in too much K or something?

A cheap and cheerful way to bash CYMK into RGB is:

/** CMYK to RGB conversion */
/* Adobe PhotoShop algorithm */
cyan = Math.min(255, cyan + black); //black is from K
magenta = Math.min(255, magenta + black);
yellow = Math.min(255, yellow + black);
rgb[0] = 255 - cyan;
rgb[1] = 255 - magenta;
rgb[2] = 255 - yellow;


/* GNU Ghostscript algorithm -- this is better*/
int colors = 255 - black;
rgb[0] = colors * (255 - cyan)/255;
rgb[1] = colors * (255 - magenta)/255;
rgb[2] = colors * (255 - yellow)/255;

(found online, probably StackOverflow like everybody else…)

However, proper conversion requires colour profiles, so back to my earlier question.

Adobe PhotoShop algorithm

No it isn’t.

Ghostscript algorithm — this is better

Yup. Though you don’t do it quite like that with integer maths.

proper conversion requires colour profiles

Well… it certainly requires a non-linear transformation. Profiles allow you to adapt to data from multiple sources. In a closed system you don’t need them.

If only someone had ICC support.

once you have fiddled with the monitor gamma and the picture on the screen looks “correct”… Will it print like it looks?

It certainly won’t “print how it looks” if nothing is calibrated. The workflow I promoted had a linearly-calibrated screen (because otherwise everything in RISC OS gets the colours wrong) and calibrated PostScript (and hence PDF) output:

That was good enough for tens of millions of colour items. But on RISC OS out-of-the-box, it’s purely garbage-in, garbage-out.

Thanks everyone for all the testing. It might be a little while until I can find a spare moment to debug these errors but when I do your detailed posts will help.

nemo:

And for Andy:

Thanks. Can you tell me what address !Paint was running at when that error occurred? Was that using the RISC OS 5.27 beta softload or was it RO4 again (with a debug build of Paint perhaps)?

That’s the result of loading a sprite file with an extension area.

What on Earth is an extension area for a sprite file? Is that an extra block of memory after the sprite header? A search of the entire site for “extension area” only brings up a brief mention under the Sound Channel Control Block. You did mention the “offset to next sprite in area” could be used to skip over blocks of memory – is it anything to do with that?

What on Earth is an extension area for a sprite file?

Is it a ROL only thing?

http://www.riscos.com/support/developers/prm/sprites.html

Scroll down to Technical Details

What on Earth is an extension area for a sprite file?

Is it a ROL only thing?

No – those are the RISC OS 3 PRMs.

The extension area is as old as the Sprite format. There was never any official guidance for its use but a format emerged: It comprises a number of labelled blocks, possibly terminated by a non-compliant block:

+0  4   Identifier
+4  4   Length 'L' (including this header, whole words)
+8  L-8 Data
+L  ...

The extension area stretches from the end of the area header to the start of the first sprite and must be a whole number of words. If that length is less than 8, it is non-compliant data (all four bytes of it). Otherwise check the length at +4, if it’s not a multiple of four, is less than 8 or would reach past the first sprite, it is a non-compliant block and stretches to the first sprite. Otherwise it is a compliant extension block identified by its first word. Repeat as space allows.

Identifier words have been taken from the Draw Object allocations (i.e. if you have Draw Objects you have Sprite Extensions); FourCCs (which are massively outside the Draw Object range [which is 16bit]); Draw Tags (which is slightly more problematic); some other number somebody made up (:-/).

Editors should maintain (not strip) the extension area. It has been used to attach metadata to sprites; long sprite names; profiles; clipping paths; other things I’ve forgotten.

The extension area is as old as the Sprite format. There was never any official guidance for its use but a format emerged: It comprises a number of labelled blocks, possibly terminated by a non-compliant block

Would you be willing to share a test image? Did it work with pre-bounty versions of Paint?

I have tried my luck with Paint 2.28 on OS6.20. On starting a drag in the Sprite file window the error is simply “Sprite doesn’t exist”, with no mention of SpriteExtend.

An inspection of starting a drag on OS5.27 shows that a curved pointer appears, which is ptr_drop. This does not exist in OS6.20. iconsprites it into the pool on OS6.20 and the drag starts without any error.

An inspection of starting a drag on OS5.27 shows that a curved pointer appears, which is ptr_drop. This does not exist in OS6.20. iconsprites it into the pool on OS6.20 and the drag starts without any error.

Nice detective work David, thank you! I wonder if that’s the same issue nemo had on RO4:

Well it didn’t do that on 4.37. No.

Instead it exploded with “SpriteExtend: No such sprite”. Trying to drag anything in the file window triggers that.

It’s certainly a plausible explanation.

The question is, is it !Paint’s business to be supplying this missing icon? I would have suggested not, because it could overwrite a user’s choice of icon, unless it explicitly checks for its existence first, which would be a bit messy. On the other hand, if Paint doesn’t fix it, how many users of RO4 or Six are going to know what to do? I suppose that’s one downside of RISC OS applications not having installers as such. There’s the ROM and the !Boot, but presumably some people will want to run new Paint from disc without changing those.

Edit: Just noticed the usage of the “ptr_drop” sprite is hard-coded into the CnpDrag code for Paint:

static void cnp_drag_set_ptr_drop(void)

{ sprite_id id;
  id.tag    = sprite_id_name;
  id.s.name = "ptr_drop";
  wimpt_noerr (pointer_set_shape (wimp_spritearea, &id, 1, 15));
}

It seems to me, if we don’t want to supply the icon with Paint’s sprites, that that function could just be updated to ignore any missing sprite there rather than dying. This code was quite recent. Ah, looks like it’s part of the Clipboard Support bounty.

It’s certainly a plausible explanation.

With OS4.39 RPCEmu adding the missing ptr_drop sprite works here.

Isn’t ptr_drop supposed to be a hand or something? (I’m in a nice tea shop in town, far away from my computer)

If so, surely it is part of the standard icon set?

Best to cope sanely with the sprite not existing, but perhaps not include it yourself. It shouldn’t be the app’s job to supply system sprites, and doing so may annoy the user – I have something here that still resets the sprite icon to the way it looked back in RISC OS 3…

If there’s concern over “in or out” of the OS sprites, and you don’t want to supplied separate Sprites for 3.x/4.x etc, then probably the best solution is to call it ptr_pdrop (or some such) [p is for paint] and include it in !Sprites for everyone. That way you’re not overwriting anything in the sprite area, just adding to it.

Alternatively, supply it (ptr_drop) and don’t worry. The Theme system on RO5+ means that any user-modified icons should be part of the desktop theme, which should be protected via the setting in Theme config screen. OK, so there are times when it is better to not protect the icons, but in that case, the pointer would overwrite the theme, just like anything else – hardly the end of the world, esp as it is a pointer, not an general icon.

Or, just alter the code to only use it if available, I guess. Further idea – could it go in the app sprite area rather than the wimp sprite pool? (I’m guessing that pointers probably have to be in the wimp pool, but it doesn’t hurt to ask)

could it go in the app sprite area rather

If you do a plain old SpriteOp, yes.

Did [extension areas] work with pre-bounty versions of Paint?

Yes. No. Yes. No.

By which I mean (on RO4), if Paint is not running, double-clicking on a Sprite file with an extension area works fine. But if Paint is already running, it explodes. But then when you double-click again, it works.

Meanwhile everything else copes fine of course. Because they read the description of a sprite area and understood it.

test image?

Try this

Is someone still working on the Clipboard Support bounty?

I couldn’t find any forum thread other than these two posts, although “Further clipboard support” is still showing underway.

I could certainly put in a fix for this “ptr_drop” issue, but I don’t want to frustrate anyone if they’re still working on c.CnpDrag or other clipboard code.

An inspection of starting a drag on OS5.27 shows that a curved pointer appears, which is ptr_drop. This does not exist in OS6.20. iconsprites it into the pool on OS6.20 and the drag starts without any error.

However, the missing sprite(s) are provided in the wider boot sequence in !Boot.Resources.Wimp but for whatever reason we’re rummaging around in the RISC OS 3.50 hook directory and aghast with surprise when it doesn’t work, having not run the rest of the boot sequence for the OS it’s intended for.

Time wise, the parallel would be copying mspaint.exe from Windows 10 and seeing what happens if you ran it on Win95 or maybe Win98.

Note that for RISC OS 5.00 and later the assumption is you can just grab the latest ROM, the missing Wimp sprite fixups are only activated in PreDesktop for 4.99 and earlier (obvious caveat for any lurking RISC OS 6 users that 6 > 5 > 4.99!).

caveat for all the RISC OS 6 users round here that 6 > 5 > 4.99!).

Just think how much better that would work if “RO6” was labelled as 4.3×.¹
Don’t you just wish you had a TARDIS and a large club to knock sense into people.
Any moment now Nemo will mutter about module versions…

¹ Of course there is the possibility that RO6 would throw a hissy fit about some element of a foreign !Boot/System. Always good fun merging things with unknown interactions.

having not run the rest of the boot sequence for the OS it’s intended for.

Just to confirm: Paint 2.28 does work on RISC OS 3.71 when the ROOL !Boot is used. The additional sprites are loaded as expected.
(Tested on RPCEmu 0.9.1pp3 for Mac)

Sprow suggested

for whatever reason we’re rummaging around in the RISC OS 3.50 hook directory and aghast with surprise when it doesn’t work

No, the ‘surprise’ is when something as benign and trivial as a missing communal sprite causes a major official application to panic, quit, and lose all your work.

For the avoidance of doubt: If you’re writing code that behaves like that in 2019, you’re an idiot. Paint has been idiotic for a very long time though, so present company excepted.

Steve said

knock sense into people

“RO6” is the most infuriatingly childish case of “one potato two potato” I’ve ever heard of. And 6.20 (which I think is as far as it got), with its massively inefficient stack frame implementation imposed on every SWI, is particularly unloved at Nemo Towers.

I have to agree with Nemo – just because something comes with the OS doesn’t excuse the author from trying to create something “safe” across a range of hardware. It’s also not uncommon for people to want to run selected applications from one version on another. Just look at the (quite numerous) list of people who’d like to run the Adjust+ versions of Draw and Paint on modern hardware.

If the goal is to exceed the capabilities of Adjust’s !Paint (which must, after all this time, surely be the target) I can imagine quite a few folks (myself included) wanting to benefit from the new features without completely re-loading a new !Boot onto my VRPC setups. That’s not an unreasonable expectation at all – !Paint is an application, not a core OS module.