Dear all,

I would like to know the x and y dimensions of a sprite or a JPEG on disk.
For a JPEG, I found the following OS call:

SYS "JPEG_FileInfo",0,path$ TO ,,x%,y%

"path$' is the path of the JPEG in question, obviously.
However, x% and y% are always 0. What am I doing wrong? And does a similar
call exist for sprites? OS_SpriteOp only examines sprites in a sprite pool,
not on disk - as far as I understand...

Kind regards,
Paul

--
https://riscos.sprie.nl

In article <59ef9cf586Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:
> SYS "JPEG_FileInfo",0,path$ TO ,,x%,y%

Should R0 on entry not have bit0 set,
i.e. SYS "JPEG_FileInfo",1,path$ TO ,,x%,y%

--
Chris Johnson

In article <59ef9fa796chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:

> Should R0 on entry not have bit0 set,
> i.e. SYS "JPEG_FileInfo",1,path$ TO ,,x%,y%

Oh dear, indeed! Problem partly solved.
And for a sprite?

Kind regards,
Paul

--
https://riscos.sprie.nl

On 28/05/2022 11:48, Paul Sprangers wrote:
> In article <59ef9fa796chrisjohnson@spamcop.net>,
> News <chrisjohnson@spamcop.net> wrote:
>
>> Should R0 on entry not have bit0 set,
>> i.e. SYS "JPEG_FileInfo",1,path$ TO ,,x%,y%
>
> Oh dear, indeed! Problem partly solved.
> And for a sprite?

Sprite files contain multiple sprites, so you would need to specify
which sprite you wanted dimensions of.

In order to read the dimensions (both JPEG and Sprite, or any image
format) you will need to read at least part of the file into memory
anyway. So why not just read the sprite file in, and then use SpriteOp
to read the dimensions of desired sprite(s)?

Gerald.

--
gerald at hollypops dot co dot uk
Repton Resource Page
www.reptonresourcepage.co.uk

In article <ReWdnVLwIJhwvw__nZ2dnUU7-f2dnZ2d@brightview.co.uk>,
Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> Sprite files contain multiple sprites, so you would need to specify
> which sprite you wanted dimensions of.

I think I better describe what I'm after, because I run into more problems
than reading sprite dimensions alone.

I would like to be able to drag either a single sprite or a JPEG to my
window, after which the BASIC program saves a sprite thumbnail of it,
preferably to an existing sprite file. The thumbnail should be 40x40 pixels
at maximum. I haven't been able to find a detailed description (or any
description at all) of how to do this.

At this moment I use the ChangeFSI library for the conversion, as described
in a document called "CmdBasUse", found within the ChangeFSI application
directory. After having typed "LIBRARY "<ChangeFSI$Dir>.ChangeFSI" at the
top of my program, I have access to the following function:

error% =
FNChangeFSI(A$,spritearea%,workspace%,worklimit%,oksave%,okinfo%,RETURN
ram%,fast%)

A$ contains the paths and conversions details, as described in the same
document. Until now I only succeeded to convert small JPEGs, that are
converted to the desired sprite thumbnails indeed, but that are stored to
disc, rather than to an existing sprite file. Larger JPEGs fail to convert
at all, producing an error that I can't understand: "Unknown or missing
variable in "ChangeFSI" in "ChangeFSI" [sic] at line 1672" - a line that
has nothing to do with the routine in question. As I have very little to no
understanding of the parameters of the function, I assume that I don't use
them properly, although it does work for small JPEGs (smaller than 15KB,
approximately).

I let ChangeFSI create the spritearea%, as well as the workspace% and the
worklimit%, by entering -1,-1,0 respectively, as described in the document.
However, I've no idea what to do with the "RETURN ram%" parameter. I've
entered a random variable (r%), which seems to be accepted by the function.
But blindly experimenting with random spriteareas and workspaces has only
resulted in fatal errors so far. As usual, I've actually no idea what I'm
doing.

Would someone be willing to explain how to use this function properly, or
how to achieve my goal otherwise?

Kind regards,
Paul

--
https://riscos.sprie.nl

On 30/05/2022 12:58, Paul Sprangers wrote:

> At this moment I use the ChangeFSI library for the conversion, as described
> in a document called "CmdBasUse", found within the ChangeFSI application
> directory. After having typed "LIBRARY "<ChangeFSI$Dir>.ChangeFSI" at the
> top of my program, I have access to the following function:

I have no clue on the ChangeFSI functions, but what version are you
using? Also, what version of RISC OS?

The images you are dragging from, into your window, where are they
coming from? I.e., a file? another application?

Cheers,

Gerald.

--
gerald at hollypops dot co dot uk
Repton Resource Page
www.reptonresourcepage.co.uk

In article <56KdnRloBeIyTAn_nZ2dnUU7-S3NnZ2d@brightview.co.uk>,
Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> I have no clue on the ChangeFSI functions, but what version are you
> using? Also, what version of RISC OS?

ChangeFSI 1.63
RISCOS 5.29

> The images you are dragging from, into your window, where are they
> coming from? I.e., a file? another application?

The images come from disk, typically photographs. So, not from a file, nor
from another application.

Kind regards,
Paul

--
https://riscos.sprie.nl

On 30/05/2022 15:51, Paul Sprangers wrote:
> In article <56KdnRloBeIyTAn_nZ2dnUU7-S3NnZ2d@brightview.co.uk>,
> Gerald Holdsworth <nospam@hollypops.co.uk> wrote:
>
>> I have no clue on the ChangeFSI functions, but what version are you
>> using? Also, what version of RISC OS?
>
> ChangeFSI 1.63
> RISCOS 5.29
>
>> The images you are dragging from, into your window, where are they
>> coming from? I.e., a file? another application?
>
> The images come from disk, typically photographs. So, not from a file, nor
> from another application.
>

RISC OS 5.29 may be able to handle, and convert, JPEGs natively. !Paint
can certainly import a JPEG and output a Sprite, and it can also export
a JPEG. I'd have a hunt around the RO5 PRMs to see if there is anything,
or post on the ROOL forums.

Cheers,

Gerald.

--
gerald at hollypops dot co dot uk
Repton Resource Page
www.reptonresourcepage.co.uk

In article <ZeadnfdmIvFTZAn_nZ2dnUU7-WfNnZ2d@brightview.co.uk>,
Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> RISC OS 5.29 may be able to handle, and convert, JPEGs natively. !Paint
> can certainly import a JPEG and output a Sprite, and it can also export
> a JPEG.

Yes, I know. And both !ArtWorks and !DPlingScan can perfectly resize any
bitmap as well. But the point is that I want to do it myself - or better: I
don't want to force possible users of my program to be dependent of those
(commercial) programs. And I want to figure out how those programs do it...

> I'd have a hunt around the RO5 PRMs to see if there is anything,
> or post on the ROOL forums.

I did find some related posts on the ROOL forum, but not helpful enough for
me to tackle the problem. Probably I will have to admit that the WIMP is
too complex for me.

Kind regards,
Paul

--
https://riscos.sprie.nl

On 31/05/2022 08:27, Paul Sprangers wrote:
> In article <ZeadnfdmIvFTZAn_nZ2dnUU7-WfNnZ2d@brightview.co.uk>,
> Gerald Holdsworth <nospam@hollypops.co.uk> wrote:
>
>> RISC OS 5.29 may be able to handle, and convert, JPEGs natively. !Paint
>> can certainly import a JPEG and output a Sprite, and it can also export
>> a JPEG.
>
> Yes, I know. And both !ArtWorks and !DPlingScan can perfectly resize any
> bitmap as well. But the point is that I want to do it myself - or better: I
> don't want to force possible users of my program to be dependent of those
> (commercial) programs. And I want to figure out how those programs do it...
>
What I meant was that I'm sure that if !Paint can do this, then the RISC
OS SWI calls can probably do it. I.e., I'm wondering if !Paint is just a
wrapper around the OS_Sprite calls.

OS_Sprite 10 may be able to import a JPEG and convert to a Sprite for
you. I've had a play, but it was only brief. I need to look into it much
deeper.

Cheers,

Gerald.

--
gerald at hollypops dot co dot uk
Repton Resource Page
www.reptonresourcepage.co.uk

In article <59f119bd97Paul@sprie.nl>,
Paul Sprangers <Paul@sprie.nl> wrote:
> In article <ZeadnfdmIvFTZAn_nZ2dnUU7-WfNnZ2d@brightview.co.uk>,
> Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> > RISC OS 5.29 may be able to handle, and convert, JPEGs natively.
> > !Paint can certainly import a JPEG and output a Sprite, and it
> > can also export a JPEG.

> Yes, I know. And both !ArtWorks and !DPlingScan can perfectly
> resize any bitmap as well. But the point is that I want to do it
> myself - or better: I don't want to force possible users of my
> program to be dependent of those (commercial) programs. And I want
> to figure out how those programs do it...

> > I'd have a hunt around the RO5 PRMs to see if there is anything,
> > or post on the ROOL forums.

> I did find some related posts on the ROOL forum, but not helpful
> enough for me to tackle the problem. Probably I will have to admit
> that the WIMP is too complex for me.

I do not think it is the Wimp that is your problem.

Earlier you said...
> The images come from disk, typically photographs. So, not from a
> file, nor from another application.

.... but any image that is dragged from disc *is* a file!

I suspect your problem with sprites is that a sprite file can (and
usually does) contain several sprites. The information about each one
is scattered throughout the file - there is no handy list at the
beginning. So after a drag of a sprite file, you first have to find a
list of the sprites within, then the details of each one ... then
decide which one is required. Which probably entails loading the whole
file into memory.

This is unlike a jpeg file, which simply contains one jpeg.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

In article <_-CdncrtZoeZZQj_nZ2dnUU7-UPNnZ2d@brightview.co.uk>,
Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> What I meant was that I'm sure that if !Paint can do this, then the RISC
> OS SWI calls can probably do it. I.e., I'm wondering if !Paint is just a
> wrapper around the OS_Sprite calls.

Ah, I see what you mean. But since I still have to scale the resulting
sprite, I could as well use the ChangeFSI function right away.

The routine does allow me to convert 2 or 3 small JPEGS, or 1 slightly
bigger JPEG, to the desired thumbnail before it runs out of memory. But
I've no idea how to manage extra workspace, nor do I have an idea how to
save the resulting sprite into an existing sprite file. Despite the quite
extensive documentation, I fail to understand the working of the function.

Kind regards,
Paul

--
https://riscos.sprie.nl

In article <59f133acfdNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

> I do not think it is the Wimp that is your problem.

Well, it's certainly not my *only* problem...

> I suspect your problem with sprites is that a sprite file can (and
> usually does) contain several sprites. [ ... ]

Actually I want to restrict myself to sprite files that contain just one
sprite. Since my program is meant to process photo's, JPEGs will be the
vast majority of the dragged files anyway.

The current problem (the one that blocks me from running into new ones) is
that I fail to handle the ChangeFSI function properly. The routine that I
have now does allow me to process some small JPEGs the way I want, before
it runs out of memory. I don't know how to increase its workspace, despite
the nice documentation, nor do I know how to save the resulting sprite into
an existing sprite file.

Kind regards,
Paul

--
https://riscos.sprie.nl

Paul

I am a bit confused as to how you are doing this. Are you in or out
of the desktop? You say in your early post that you drag a file to
your window. To me this suggests you are in the desktop. However, it
looks from the documentation I looked at that the function
FNChangeFSI is used from the command line. I am not sure whether it
can be used from a wimp program.

--
Chris Johnson

In article <59f145bf22chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:
> used from the command line

.... or a single tasking binary (it mentions F12).

--
Chris Johnson

In article <59f145bf22chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:

> However, it looks from the documentation I looked at that the function
> FNChangeFSI is used from the command line. I am not sure whether it can
> be used from a wimp program.

Yes, it can. Near the bottom of the document in question is a description
of how to use it in a BASIC (Wimp) program (FNChangeFSI is even exclusively
intended for BASIC programs). And it does work indeed, as I described in
previous posts, but not always and probably not the way it should.

Kind regards,
Paul

--
https://riscos.sprie.nl

On 31/05/2022 14:30, Paul Sprangers wrote:
> In article <_-CdncrtZoeZZQj_nZ2dnUU7-UPNnZ2d@brightview.co.uk>,
> Gerald Holdsworth <nospam@hollypops.co.uk> wrote:
>
>> What I meant was that I'm sure that if !Paint can do this, then the RISC
>> OS SWI calls can probably do it. I.e., I'm wondering if !Paint is just a
>> wrapper around the OS_Sprite calls.
>
> Ah, I see what you mean. But since I still have to scale the resulting
> sprite, I could as well use the ChangeFSI function right away.
>

OS_SpriteOp 52 paints a scaled sprite onto the screen. I can't see any
calls to rescale a sprite as a new sprite in the area.

Incidentally, if you wanted to see how many sprites are in a file
without loading the entire file, just look at the first four bytes -
this is the total number of sprites in the file. This is different to a
sprite area where the area size is the first four bytes, then the number
of sprites.

Unless you fancied writing your own scaling routine...

Gerald.

--
gerald at hollypops dot co dot uk
Repton Resource Page
www.reptonresourcepage.co.uk

On 31 May, Gerald Holdsworth wrote in message
<Aa-dnfbF4Md84gv_nZ2dnUU7-KHNnZ2d@brightview.co.uk>:

> Incidentally, if you wanted to see how many sprites are in a file without
> loading the entire file, just look at the first four bytes - this is the
> total number of sprites in the file. This is different to a sprite area
> where the area size is the first four bytes, then the number of sprites.

A much easier, and clearer, way to express that is:

A sprite area is a block of memory where the first word contains the size of
the block, followed by the contents of a sprite file starting from the
second word.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Gerald Holdsworth <nospam@hollypops.co.uk> wrote:

> On 31/05/2022 14:30, Paul Sprangers wrote:
> > In article <_-CdncrtZoeZZQj_nZ2dnUU7-UPNnZ2d@brightview.co.uk>,
> > Gerald Holdsworth <nospam@hollypops.co.uk> wrote:
> >
> > > What I meant was that I'm sure that if !Paint can do this, then the
> > > RISC OS SWI calls can probably do it. I.e., I'm wondering if !Paint is
> > > just a wrapper around the OS_Sprite calls.
> >
> > Ah, I see what you mean. But since I still have to scale the resulting
> > sprite, I could as well use the ChangeFSI function right away.
> >
>
> OS_SpriteOp 52 paints a scaled sprite onto the screen. I can't see any
> calls to rescale a sprite as a new sprite in the area.

The way this is usually done is to create a new sprite in the area (or some
other area), redirect output to it via OS_SpriteOp 60 and then use
OS_SpriteOp 52 (or 56 using a matrix) to plot the original sprite scaled
into your new sprite.

Be careful when using SpriteOp 60. Never forget to switch output back to the
screen, and if your code crashes while output is switched, you will usually
have to reboot.

In terms of quality you are much better off using ChangeFSI, since SpriteOp
52 scales down in a very naive way, which causes massive aliasing effects,
while ChangeFSI interpolates between pixel values and uses error diffusion.

--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------

In article <mpro.rd434c00756yg00vg.spamtrap@mw-software.com>,
Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In terms of quality you are much better off using ChangeFSI, since
> SpriteOp 52 scales down in a very naive way, which causes massive
> aliasing effects, while ChangeFSI interpolates between pixel values and
> uses error diffusion.

I can confirm that. ChangeFSI does a very good job from within a BASIC
program, but not by using its library function as described in the
documentation. At least, I certainly failed to get it working. Using the
command line instruction however, and start that as a Wimp_Task, did the
trick. No need to mess with local memory blocks or sprite areas or
whatever. It rescales every JPEG, no matter how large, to the desired
dimension, quickly and transparently.

Now that this problem has been solved, I'm running into a new one. But
that's for another thread.. Thank you for all your thoughts and
suggestions.

Kind regards,
Paul

--
https://riscos.sprie.nl

On Saturday, June 11, 2022 at 7:56:59 AM UTC+1, Paul Sprangers wrote:
> In article <mpro.rd434c0075...@mw-software.com>,
> Martin Wuerthner <spam...@mw-software.com> wrote:
>
> > In terms of quality you are much better off using ChangeFSI
[...]
> I can confirm that. ChangeFSI does a very good job from within a BASIC
> program, but not by using its library function as described in the
> documentation. At least, I certainly failed to get it working. Using the
> command line instruction however, and start that as a Wimp_Task, did the
> trick. No need to mess with local memory blocks or sprite areas or
> whatever. It rescales every JPEG, no matter how large, to the desired
> dimension, quickly and transparently.

One tip and one bear trap with calling FNChangeFSI when JPEGs are involved:

First, in the 'CmdBasUse' document in the section immediately below where it describes how to use FNChangeFSI, there are descriptions of some system variables you can (optionally) set. In particular if you make ChangeFSI$Cache larger than the source image it'll be loaded into RAM and processed much quicker.

The bear trap with a few image types (certain JPEGs, BTPC images, & PhotoCDs at a quick look in ChangeFSI 1.66) is the source image may be passed to a helper application to do the processing. That helper program will displace your calling program in BASIC which is also in the application slot so never returns. This can be avoided by using the *ChangeFSI alias to launch it in a separate Wimp task and collect the result,
Sprow.