Bounty proposal: Paint

On other image editing software on other operating systems, the DPI is normally for print and as such is specified independently from the width and height in pixels.

I’’m guessing that Paint is mostly used for designing graphics for use in RISC OS apps (icons, buttons, etc), and so the DPI setting will be most useful for matching up to the three supported Desktop DPI settings.

I’m thinking the ideal would look something like this (a Scale image dialogue)

I’m not sure about this (probably because I’ve not understood it correctly). Paint currently offers a ‘Scale X/Y’ and an ‘Adjust size’ function. It sounds like you’re proposing wrapping up the Scale functionality with the new Change DPI feature, but it’s not completely obvious to me why these things belong together. Wouldn’t it be simpler to offer a new ‘Adjust DPI’ menu item/dialogue box on its own, or merge the ‘Adjust size’ and ‘Adjust DPI’ functions into a new ‘Adjust dimensions’ (or something) dialogue box? Scaling a sprite seems to me like a different operation. But correct me if I’ve got the wrong end of the stick :)

but it’s not completely obvious to me why these things belong together.

Me neither. Surely DPI is DPI and size/scaling is size/scaling. If one has a 640×480 image at 180dpi and this gets changed to 90dpi; the image should still be 640×480?

Yup. I’ve just checked the program I use on the PC (PhotoImpact5). “Dimensions…” allows adjustment of the size of the image, while “Resolution…” allows adjustment of the pixels per inch setting. This affects how the image is “interpreted”; thus the usual display DPI is 96, downloaded images are often around 72, the printer is 150/300/600… however changing the DPI does not affect its physical size. The image I’m looking at remains 1353×1612.

RISC OS will have its own specifics (dpi 45, 90, 180) and may need “help” if Paint is going to allow a change from, say, 90:90 (MODE 28) to 90:45 (MODE 15) aspect (implication that pixel size differs).

Here are examples. Yes, I use XP in it’s FisherPrice™ mode.

Setting the scale of the image:

Scaling uses some sort of error diffusion, but there are no choices as to how/what. It usually makes a good result.

Here is setting the dpi:

Another thing not considered (outside of the scope of the bounty!) is changing the data type of the image. While we can choose to have or not have a mask (bitmap mask or alpha mask?), there are other options too. Full RGB to 256 colour (using standard palette, best match palette, greyscale or WebSafe palette), to 16 colour (again with standard, greyscale, or best match palette), and if one wants to be crazy to 1bpp.
Every step UP should be pretty easy. 16 → 256 → 16M shouldn’t create too much grief.
Every step DOWN will be hard and probably require error diffusion and dithering.

However, I mention this to point out that modifying the structure of the image involves three related (but different) things:

• Physical size in pixels
• Resolution in pixels/dots per inch
• Data type (colour depth and palette type (if applicable))

BTW, one Brownie Point if you can identify the girl in the thumbnails.

If one has a 640×480 image at 180dpi and this gets changed to 90dpi; the image should still be 640×480?

Wouldn’t it be simpler to offer a new ‘Adjust DPI’ menu item/dialogue box on its own

It would certainly make my life a lot easier. And it would conform better to the Style Guide’s requirement to “Make each user action perform a well-defined task”. In fact, it was my original understanding of the Editable DPI requirement.

But then I read Martin Bazley and Michael Drake’s comments. Martin’s comment:

Supplement to earlier request to implement DPI/colour changes: Ability to do that without modifying the sprite data. For use when the sprite is in the wrong format for whatever reason. (This wouldn’t cause memory problems, as sprite width is internally represented as words rather than pixels, so changing the BPP would automatically change the width in pixels.) I know, I know, I’m probably the only one who’d ever use it…

Ignoring colour depth for a moment, this comment implied to me he wanted a way to change DPI without calculating a new width or height for the sprite (although he mentions pixel width changing “automatically” which I don’t fully understand at the moment). He then says he’s “probably the only one who’d ever use it”, further implying that the normal expectation is for a feature that does modify the sprite pixel data when DPI is changed.

Then Michael chimed in saying:

That would be behaviour that would seem completely broken to almost all users.

Changing bpp the way people expect is complex, it’s even usually lossy when reducing bpp, and may be better left to other apps.

So I took that to imply he thought changing DPI without modifying pixel data “would seem completely broken to almost all users”. No-one responded any further to those two comments, until now, so I took that as agreement with them.

I think maybe however that I am the one getting the wrong end of the stick here, because re-reading these comments I realise the focus was on changing Bits Per Pixel, which has nothing whatsoever to do with Dots Per Inch. About the only relevance I can see of it is if there’s a requirement to fix the sprite’s dimensions in inches then if you reduce the Dots Per Inch, you reduce the storage requirements (Bits Per Inch, if you like!) by also reducing the number of pixels.

Other than that, as far as I can see BPP is only relevant if changing colour depth, which I’m not supporting, so I’m not sure why the two things were combined into one comment.

So I misread the comments as one person wanting DPI to affect image dimensions and another person disagreeing, so I offered to make it configurable.

Martin and Michael, if you’re there would you like to please clarify what was meant?

Rick, on the flip side of your Windows screenshots, your favourite GNU Image Manipulation Program does give the option to change resolution (in pixels/in by default, with other units available) on its Scale Image dialogue. It would be bad manners to hotlink but they have a screenshot here

To be fair, changing the resolution on that dialogue does not alter the pixel width and height of the image (although you can choose to specify the width and height in inches if you want and then those field do change as you alter the pixels/in as you would expect) but that’s what gave me the idea of putting both things on the same dialogue and it seemed to address what I thought were the concerns raised in those two comments I quoted.

so I took that as agreement with them.

Or it could be that nobody had anything specific to add at the time? ;-)

My understanding, which may be completely wrong, is that a normal DPI setting does not alter the physical sprite data in any way. A sprite of 640×480 that has its 90dpi setting changed to 300dpi will still look like the exact same sprite, and will be 640×480.

What has changed is the interpretation of the pixels. With the girl pictured, at the default 72dpi, sending the image to the printer at default scaling will print half an image as the picture is understood to be 72dpi which is massive. Changing the DPI to the printer standard 600dpi will result in the picture being a small square about a fifth (or so) of the size of the page.
The image hasn’t changed. The interpretation has.

The obvious problem arises in that I don’t think RISC OS makes any such distinction. Pixels will be mapped one for one to the screen if not explicitly scaled; so it seems to me that the only purpose of setting the DPI in sprites is for creating low/normal/high resolution sprites. Indeed, this is backed up by the DPI settings not being able to be arbitrary – the help file suggests 180, 90, 45, 22/23 are the only possible choices.

With that in mind, maybe we shouldn’t be talking about DPI at all (since it’s more used as a ratio adjustment than actual DPI) and call it something else?

BTW, with respect to GIMP, that’s why I said that the two actions were related but were not the same. Ideally one should be able to change without affecting the other. That’s an insane screenshot by the way. A 200×138 image at 143,993dpi? Really? That might print as a handful of ink dots if we’re lucky and the printer doesn’t crash with a divide by zero trying to work it out. ;-)

With that in mind, maybe we shouldn’t be talking about DPI at all (since it’s more used as a ratio adjustment than actual DPI) and call it something else?

Well in RISC OS isn’t it closely related to the screen mode’s eigen factors? I don’t think the casual user is going to respond to well to that jargon though, somehow.

As I understood it, one OS Unit is supposed to (ideally) always represent the same physical distance in inches, implying that for a given screen mode any given pixel width or height will represent one distance in inches. Which is why, under RISC OS, I don’t think it’s completely unreasonable for someone to expect to change DPI and pixel dimensions at the same time, so that the image still occupies the same distance on the screen.

Not completely unreasonable, but also not immediately obvious and not consistent with other operating systems. So I’ll have to wait and see if anyone else has any strong opinions about this or for Martin and Michael to come back, otherwise an atomic DPI operation is fine by me.

Of course, it does mean changing DPI for one coordinate but not the other will distort the aspect ratio of the sprite. We could apply scaling in only that situation to compensate (as I think you suggested Rick) but I’m not sure I like that. If you converted a sprite from Mode 28 to Mode 15 you could either repeat each pixel in the x direction or skip alternate pixels in the y direction but neither option would satisfy every user. That in itself drew me back to thinking some control over the pixel sizes might be desirable.

one OS Unit is supposed to (ideally) always represent the same physical distance in inches,

That’s utterly impractical, given the wide variety of different monitor sizes even in the early days of RISC OS.

My understanding of OS units is that it is an abstraction originally used on the BBC Micro where all graphics screen modes were 1280 units across and 1024 units up.

That is to say:

MOVE 0,0
DRAW 0,1023
DRAW 1279,1023
DRAW 1279,0
DRAW 0,0
DRAW 1279,1023
MOVE 0,1023
DRAW 1279,0

would draw a border around the screen and an ‘X’ inside, regardless of the actual pixel resolution of the current mode. Fire up an emulator (or the real thing) and you’ll see it works just like that in MODE 0, MODE 1, MODE 2, MODE 4, and MODE 5.

This got broken in RISC OS due to some modes being larger than the arbitrary units. Many of the old modes are indeed 1280×1024, however some are smaller (MODES 22, 44-46), and some are larger (MODES 16, 17, 23, 24, and pretty much everything over 29). Ditto for today (FullHD, for instance?).

The PRM is not terribly specific (that I could see) about what an OS unit actually is. The best description is the start of chapter 16 of the BBC BASIC guide – Many graphics modes use a screen coordinate area 1280 units across by 1024 units high, with the origin (0,0) located initially at the bottom left corner.

Besides, actual dots to inches only really makes sense on paper with standardised resolutions. In terms of a monitor, it only works if the screen size is known and fixed; which is unlikely to be the case with most of us.

[Yes, I know EDID is supposed to return screen dimensions. That’s not the point. The point is that 1280×1024 on a 15" screen will have a different concept of size to the same thing on a 19" screen. Or for maximum fun, my little 3.5" LCD panel can accept and display a 1920×1024 image! How big an inch then? :-)]

To the limited extent I understand it, there’s all sorts of vagueness about what DPI exactly equates to in terms of screen resolutions across various OSes. As far as RISC OS sprites go, I think we can forget about printing and concentrate on the screen. As Andy says, the ‘DPI’ of a sprite is really linked to the screen mode – 180 DPI means that one pixel = one OS unit (ie OS units are a nominally 180 DPI grid). The Wiki has it as:

OS units are intended to represent a real-world scale of 180 DPI (i.e. one inch is equivalent to 180 OS units). This also suggests that you should be able to deduce the DPI of a user’s display by looking at the eigen values of the screen mode (e.g. an eigen value of 1 represents 90 DPI). However the limited number of scaling factors available via the eigen system means that at best this is nothing more than a rough estimate.

In terms of Paint, I think the useful operation would be to convert between the three standard DPI settings, leaving the pixel values unchanged. I don’t think that doubling pixels to account for switching from, say, 180 X 180 DPI to 90 × 45 DPI is worth doing – it’s an easy operation to scale the y axis by 2 if the correct aspect ratio is desired.

I could have sworn I read a RISC OS document somewhere recently that was equating OS units to an ideal physical distance. I do appreciate what they’re for programmatically. Maybe the document was talking about the DPIs associated with each screen mode. I can’t seem to find it now.

The best description is the start of chapter 16 of the BBC BASIC guide – Many graphics modes use a screen coordinate area 1280 units across by 1024 units high, with the origin (0,0) located initially at the bottom left corner.

What it didn’t tell me was that when you tell it to draw a filled RECTANGLE with dimensions 1279 by 1023, it actually plots 1280 by 1024 pixels. It’s off topic but it’s worth knowing.

With that in mind, maybe we shouldn’t be talking about DPI at all (since it’s more used as a ratio adjustment than actual DPI) and call it something else?

Coming back to this question, under the skin it’s basically a crude screen mode picker. Choosing something new from the pre-defined DPI values will require a new mode number or mode word to be assigned to the sprite. So, in that regard, it has as much to do with inches as screen modes have to do with them!

Edit: I think Chris was just saying much the same thing in different words, at much the same time! ;)

In terms of Paint, I think the useful operation would be to convert between the three standard DPI settings, leaving the pixel values unchanged. I don’t think that doubling pixels to account for switching from, say, 180 X 180 DPI to 90 × 45 DPI is worth doing – it’s an easy operation to scale the y axis by 2 if the correct aspect ratio is desired.

I agree completely Chris. If someone’s an advanced enough user to want to muck about with DPI, they shouldn’t be afraid of having to make that adjustment. You could even argue it makes it easier for someone to learn about the DPI in RISC OS.

This brings me neatly back to my original understanding of the Editable DPI requirement. It was however, a fun thing to have a natter about!

So, anyway, Rick, don’t keep us in suspense! Who’s that girl? ;)

Who’s that girl? ;)

She’s called Barbara, she’s quite the weirdo (with the obligatory car-crash home/school/everything life), and she has a sideline in wandering around alone in a forest killing giants.

Or for maximum fun, my little 3.5" LCD panel can accept and display a 1920×1024 image! How big an inch then? :-)

Well, since you ask, if 3.5 inches is the visible diagonal size, I make that 2176 pixels along the diagonal, which would be about 621.7 pixels per true inch! :-P

For how many RISC OSian inches that would be, you’d have to give me the eigen factors for that screen mode. I guess it would just be a 180 × 180 “DPI” mode though, wouldn’t it?

Mode 13, 320 × 256 has 409.8 pixels along the diagonal which at 45 DPI would be just equivalent to a 9.1 inch monitor!

she has a sideline in wandering around alone in a forest killing giants.

Sounds lucrative.

Martin and Michael, if you’re there would you like to please clarify what was meant?

I meant that changing the colour depth (especially reducing it) is not straightforward and is best left to other applications. I don’t think it’s something that belongs in Paint.

Also that I thought that changing the colour depth without modifying the bitmap data, but adjusting the width/height would seem broken to almost all users.

I don’t think it’s something that belongs in Paint.

Hmm, I’d have thought that changing colour depth is exactly something that belongs in a sprite editor. But it’s not a big deal as we have ChangeFSI.

Also that I thought that changing the colour depth without modifying the bitmap data

That’s not possible. The colour depth implies bits-per-pixel, which means the actual interpretation of the raw data will depend upon the colour depth chosen. By necessity this would need to be changed.

That’s not possible. The colour depth implies bits-per-pixel, which means the actual interpretation of the raw data will depend upon the colour depth chosen. By necessity this would need to be changed.

Please read the post I was originally replying to. That was my exact point. You’d get garbage if you used it.

Hmm, I’d have thought that changing colour depth is exactly something that belongs in a sprite editor. But it’s not a big deal as we have ChangeFSI.

To me, Paint is for painting. Potentially lossy conversions, e.g. colour depth changes and resizes can be handled by another tool.

I agree that changing the colour depth / pixel format without changing the pixel data isn’t something that should be included in Paint. That’s the kind of functionality that’s best left to a “sprite doctor” tool which can go into a broken sprite file and allow the user to fix problems (delete broken sprites, remove data hidden in padding areas, directly edit sprite headers, etc.)

To me, Paint is for painting. Potentially lossy conversions, e.g. colour depth changes and resizes can be handled by another tool.

Possibly this was answered in an earlier post, but can you clarify what you mean by “best left to other applications”, “handled by another tool”, etc.?

Do you mean that Paint should contain absolutely no support for these actions, or that Paint should contain the UI for performing the action, but the grunt work of performing the action should be left to an external tool (like ChangeFSI)?

The former seems wrong to me (any painting/image editing app worth its salt will at least give the user some ability to scale or convert the format of the images). But the latter seems perfectly sensible (and certainly more sensible than re-inventing the wheel by baking the conversion code directly into Paint). From the user’s perspective, they wouldn’t even know that ChangeFSI was being invoked, unless they didn’t have it installed for some reason.

Stretch goal: Allowing paint to invoke ChangeFSI if an image in a foreign format is dropped onto Paint’s iconbar icon.

Stretch goal: Allowing paint to invoke ChangeFSI if an image in a foreign format is dropped onto Paint’s iconbar icon.

I already had a brief look at this previously (but won’t waste any more time on it now as there are too many in-scope tasks to finish!); got as far as seeing that the core of ChangeFSI seemed to be in BASIC (well, at least, a BASIC file) and thought it would be more useful if it could be invoked from Paint as a module.

FWIW I also think that to the casual user the name “ChangeFSI” doesn’t indicate that it might help them to open their foreign format image. So I think you have a point Jeffrey, that if Paint invoked it automatically, it would remove a potential source of frustration for non-technical users of RISC OS (if indeed there are any these days! Anyone know?). Although ChangeFSI would have to be bundled in such a way that it was seen at boot, or at least by Paint’s boot, for this to really work smoothly.

got as far as seeing that the core of ChangeFSI seemed to be in BASIC (well, at least, a BASIC file)

Correct. There’s a document hidden in the ChangeFSI app which describes how to invoke it from the command line (e.g. from !Paint via system()), or as a LIBRARY

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Apps/ChangeFSI/DataFiles/Documents/CmdBasUse?rev=4.8;content-type=text%2Fplain

I’m not sure what format the “-info” output is in – if it was to be used to examine a file prior to converting it then it would need to be in an easily parseable, stable format so that the tool driving ChangeFSI can interpret the information.

and thought it would be more useful if it could be invoked from Paint as a module.

Converting ChangeFSI to a module will be prohibitively difficult, since it uses the BASIC assembler to generate custom conversion routines for each input & output format.

Do you mean that Paint should contain absolutely no support for these actions, or that Paint should contain the UI for performing the action, but the grunt work of performing the action should be left to an external tool (like ChangeFSI)?

I suppose what I really meant was about what should be prioritised for Paint. Remember that this thread was about choosing stuff to include in the bounty.

I guess it would be fine for Paint to support these features in the grand scheme of things, but I don’t think its urgent, since there are other tools (including one shipped with the OS) that perform that task.

Is there any task where ChangeFSI would be a good choice to perform? I always noticed it slowness and general unpleasantness in use. Its Floyd-Steinberg dithering might have been a nice implementation back in the 80s, but there are different (and even possibly better) things available today. Maybe it is time to provide something more friendly with (or even in) the OS? Maybe a reincarnation of ImageFileRenderer…

e.g. from !Paint via system()

Via system()?!?

That was good back in the singletasking days, but system() does an awful lot of faffing around moving the executable up in memory to make space for the called application to start at &8000…

Since Paint is a regular desktop program…

What I do with Manga:

• Does ChangeFSI exist?
• If so, make a command string with the appropriate scaling
• Pass it to Wimp_StartTask

Wimp_StartTask normally starts a task and returns the handle. However since ChangeFSI is running in a “do this and exit” mode, when StartTask returns, ChangeFSI is done. Furthermore, to the Wimp it’s an entirely different task so all the messing around with memory is neither your problem nor your concern. Just don’t forget to include -nomode in the command line. ;-)

Is there any task where ChangeFSI would be a good choice to perform?

Until something better comes along, any task that needs to convert image formats, scaling, or bit depth.

Seriously – if Manga can’t find ChangeFSI$Dir, it will revert to using the built-in OS image scaling. Marvel at how awful it is… http://i.imgur.com/FdIj2v5.jpg (side by side comparison)

I always noticed it slowness and general unpleasantness in use.

It’s unpleasantness is because it tries to offer a lot of processing options with an extremely minimal UI. As for being tediously slow…you won’t hear any contradiction from me. One of the main things, as far as I was aware, that people used to use Niall Douglas’ Wimp2 for was to force ChangeFSI to multitask while it pondered the fluff in its navel.

but there are different (and even possibly better) things available today.

We can forget Halftone and Bayer. FS is old (late ‘70s). Jarvis/Judice/Ninke is like FS but distributes errors to 12 nearby pixels for fewer visual artefacts. Stucki is a faster, sharper version of that. Burkes is faster yet, but introduces artefacts. Sierra is a faster Jarvis. Filter Lite is similar to FS but is simpler and quicker. Atkinson is like Jarvis/Sierra but only diffuses 3/4 of the quantisation error. Good for details, not so good for bright/dark areas of images. Gradient Based (recent) is like FS but uses elements of randomisation to remove FS’s artefacts.

Maybe it is time to provide something more friendly with (or even in) the OS? Maybe a reincarnation of ImageFileRenderer…

Already discussed this, a while ago. A sort of SpriteExtend that could call out to helper modules to provide support for non-native formats such as JPEG, GIF, PNG, etc.

And there should definitely an option to have the PlotScaled routines do something smarter than duplicate/discard rows and columns to get the image to fit.

Seriously – if Manga can’t find ChangeFSI$Dir, it will revert to using the built-in OS image scaling. Marvel at how awful it is… http://i.imgur.com/FdIj2v5.jpg (side by side comparison)

Which is which? To me the right hand image looks better but I infer from the above that ChangeFSI$Dir is on the left and the built-in OS image scaling on the right:-/

Which is which?

Looks good (right), ChangeFSI.
Looks rubbish (left), OS.

I infer from the above that

That’s just describing the logical behaviour.

The image layout is more “old way, better way”.

nemo:

Don’t forget that 16 entry palettes are also legal for 256 colour sprites.

The documentation for OS_SpriteOp 37 just says:

For 256 colour sprites, bit 31 of R3 controls whether a 64 or 256 entry palette is created.

So the only options there are 64 or 256 entries!

Edit: Just dug out the code Paint runs when a Palette file is dragged into a sprite window, and it reads the sprite header then overwrites the palette data directly in memory. Hmm.

Edit2: If I save a palette from a 16 colour sprite, is that a valid 16 entry palette for use in a 256 colour sprite? If I drag such a palette into a 256 colour sprite window, Paint complains “Palette file doesn’t match sprite palette” which is odd because it looks to me like that message would be generated if the palette file’s too big, not too small.