Rotating Images with Variations on Beagleboard Fail

[Richard Ashbery]

Attempts at rotating images with Variations on Beagleboard fail with
Fatal signal received: Segmentation fault.

Anyone know of a workaround?

Works perfectly on Iyonix 5.18

Variations (0.41d) Beagleboard -xM (RISC OS 5.19 16-Dec-12)

Richard

[John Rickman Iyonix]

Richard Ashbery wrote

PrivateEye can rotate in 90 degree steps, or PhotoDesk?


--
John Rickman - http://mug.riscos.org/

[patric aristide]

On 2012-12-26, John Rickman Iyonix <ric...@argonet.co.uk> wrote:
> Richard Ashbery wrote

> PrivateEye can rotate in 90 degree steps, or PhotoDesk?
>
>

Private eye does indeed support rotations. I found Variations complaining
quite often but not actually crashing. Unfortunately it's a bit
limited. Not sure if I feel like spending 100 quid on 1990's software
though.

Patric

[patric aristide]

On 2012-12-26, John Rickman Iyonix <ric...@argonet.co.uk> wrote:
> Richard Ashbery wrote
>

> PrivateEye can rotate in 90 degree steps, or PhotoDesk?
>
>

P.S.: Just checked, I do get the error message but then
Variations goes on to complete the task. From your post
it sounds as if you're getting a fatal abort.

I'm running !V 0.41d.31 on my BB-xM

patric

[Peter Dowson]

In article <slrn3vfskdm...@odin.sdf-eu.org>,

Variations (0.41d 5 feb 2008) Beagleboard -xM (RISC OS 5.19 10 nov 12)
Works fine no errors.

[Peter Dowson]

In article <53045b079...@internode.on.net>,
Peter Dowson <p_do...@internode.on.net> wrote:

[Snip]

> Variations (0.41d 5 feb 2008) Beagleboard -xM (RISC OS 5.19 10 nov 12)
> Works fine no errors.

Forgot to say exceptions off errors with exceptions on sorry.

[Richard Ashbery]

In article <e7ea4a045...@rickman.argonet.co.uk>, John Rickman

Iyonix <ric...@argonet.co.uk> wrote:
> Richard Ashbery wrote

> > Attempts at rotating images with Variations on Beagleboard fail
> > with Fatal signal received: Segmentation fault.

> > Anyone know of a workaround?

> > Works perfectly on Iyonix 5.18

> > Variations (0.41d) Beagleboard -xM (RISC OS 5.19 16-Dec-12)

> PrivateEye can rotate in 90 degree steps, or PhotoDesk?

Yes - PrivateEye can but Variations has the advantage of doing a mass
rotation/save operation once images have been selected. Correct me if
I'm wrong but none of the other RISC OS image editing software can do
this. Process is slow in PrivateEye because of the many keyboard
operations required to rotate/save images. PhotoDesk calls the outdated
JPEGTRANS utility for rotating images which is incompatible with
SpriteExtend used by PrivateEye and Variations. This is annoying in as
much as if you rotate an image in PrivateEye/Variations and then import
it into Photodesk, V3.12 (22-04-12) it appears with Stripey lines.

Sadly RISC OS users have very few options.

Richard

[Richard Ashbery]

In article <53045b587...@internode.on.net>, Peter Dowson

Grhhhh of course - it works fine with Exceptions off - thanks Peter.
I'd forgotten to try this - rarely needed for most BB software I run.

Sadly, I think Rob has given up further development of Variations so it
is unlikely we will have a version that is fully ARMv7 compatible (ie.
works with AE ON).

Thanks for the reminder..

Richard

[druck]

On 27/12/2012 15:59, Richard Ashbery wrote:
> Yes - PrivateEye can but Variations has the advantage of doing a mass
> rotation/save operation once images have been selected. Correct me if
> I'm wrong but none of the other RISC OS image editing software can do
> this.

!JPEGtools can also rotate/flip multiple files.

> Process is slow in PrivateEye because of the many keyboard
> operations required to rotate/save images. PhotoDesk calls the outdated
> JPEGTRANS utility for rotating images which is incompatible with
> SpriteExtend used by PrivateEye and Variations.

Unfortunately it also uses JPEGtrans, although a later version, which
still produced sprites incompatible with SpriteExtend - the fault
actually being with the RISC OS software for not handling valid JPEG
block formats.

> This is annoying in as
> much as if you rotate an image in PrivateEye/Variations and then import
> it into Photodesk, V3.12 (22-04-12) it appears with Stripey lines.

There is an easy way around that, just load the JPEG in to !Paint, and
save it as a sprite straight in to Photodesk or whatever else you want
to edit it with.

> Sadly RISC OS users have very few options.

Plenty of options, not all straightforward, or quick.

---druck

[patric aristide]

Sounds like the best option would be not to try using
RISC OS for this task then :(

patric

[druck]

Anything above 5 Mpix is painfully slow to work with even on an Iyonix.

---druck

[David Pitt]

As identified elsewhere 'jpegtran' is the problem on the ARMini.

Used from the command line the 'jpegtran' supplied with !Variation does
crash on a rotate if Alignment Exceptions are on. This 'jpegtran' is date
stamped 10 Aug 2004 and is 193716 bytes.

There is a later recompilation of jpegtran which does rotate from the
command line with Alignment Exceptions on, this is dated 22 Dec 2012 and is
260148.

http://www.chris-johnson.org.uk/software/3party.html

There are however snags,

1. The output jpeg is filetyped as text here!

2. Simply placing that newer 'jpegtran' in !Variation just results in a "No
writable memory at this address" on attempting a rotate. !Variation is
supplied in compressed BASIC so making any fix harder. The 'jpegtran'
command issued by !Variation does contain the -maxmemory switch.


--
David Pitt

[Chris Johnson]

In article <mpro.mfqfxb00...@pittdj.co.uk>,

David Pitt <ne...@pittdj.co.uk> wrote:
> 2. Simply placing that newer 'jpegtran' in !Variation just results
> in a "No writable memory at this address" on attempting a rotate.

I think this will be due to the assigned wimpslot being too slow.

--
Chris Johnson

[Jess]

In message <5304b555...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> Sadly RISC OS users have very few options.

Sadly the excellent option we have is no longer being developed.

--
Jess Iyonix

[Chris Johnson]

In article <53051fa97cchr...@spamcop.net>,

^^^^
low

--
Chris Johnson

[David Pitt]

No such luck, I did try that.

OTOH being a bit more observant, the rotation is actually being done despite
the error!


--
David Pitt

[Chris Johnson]

In article <mpro.mfqrt000...@pittdj.co.uk>,

David Pitt <ne...@pittdj.co.uk> wrote:
> Chris Johnson, on 28 Dec, wrote:

> > In article <mpro.mfqfxb00...@pittdj.co.uk>,
> > David Pitt <ne...@pittdj.co.uk> wrote:
> > > 2. Simply placing that newer 'jpegtran' in !Variation just
> > > results in a "No writable memory at this address" on attempting
> > > a rotate.
> >
> > I think this will be due to the assigned wimpslot being too slow.

> No such luck, I did try that.

> OTOH being a bit more observant, the rotation is actually being
> done despite the error!

Once our visitors have left later on so I can get at the BB in the
spare bedroom, I will have a quick look.

--
Chris Johnson

[Richard Ashbery]

In article <mpro.mfqrt000...@pittdj.co.uk>, David Pitt

<ne...@pittdj.co.uk> wrote:
> Chris Johnson, on 28 Dec, wrote:

> > In article <mpro.mfqfxb00...@pittdj.co.uk>, David Pitt
> > <ne...@pittdj.co.uk> wrote:
> > > 2. Simply placing that newer 'jpegtran' in !Variation just
> > > results in a "No writable memory at this address" on attempting
> > > a rotate.
> >
> > I think this will be due to the assigned wimpslot being too slow.

> No such luck, I did try that.

> OTOH being a bit more observant, the rotation is actually being
> done despite the error!

I don't think so - the error will stop rotation being performed. All
that happens is that the little blue rotation icon disappears.

I have also tried doing this with a newer version of jpegtran but get
the "no writable memory at this address" error. Despite increasing the
WimpSlot by a significant amount (last line but one in the !Run file)
the error still occurs.

Any other ideas would be appreciated.

Richard

[Richard Ashbery]

In article <kbi6m1$3fa$1...@dont-email.me>, druck <ne...@druck.org.uk>
wrote:

> On 27/12/2012 15:59, Richard Ashbery wrote:
> > Yes - PrivateEye can but Variations has the advantage of doing a
> > mass rotation/save operation once images have been selected.
> > Correct me if I'm wrong but none of the other RISC OS image
> > editing software can do this.

> !JPEGtools can also rotate/flip multiple files.

Doesn't this require command line instructions? I'll investigate
further.

> > Process is slow in PrivateEye because of the many keyboard
> > operations required to rotate/save images. PhotoDesk calls the
> > outdated JPEGTRANS utility for rotating images which is
> > incompatible with SpriteExtend used by PrivateEye and Variations.

> Unfortunately it also uses JPEGtrans, although a later version,

Oh - you are quite right.

> which still produced sprites incompatible with SpriteExtend - the
> fault actually being with the RISC OS software for not handling
> valid JPEG block formats.

Pity :-(

> > This is annoying in as much as if you rotate an image in
> > PrivateEye/Variations and then import it into Photodesk, V3.12
> > (22-04-12) it appears with Stripey lines.

> There is an easy way around that, just load the JPEG in to !Paint,
> and save it as a sprite straight in to Photodesk or whatever else
> you want to edit it with.

Yes I can see that would work - but changing formats and maybe back
again to jpeg causes more image quality issues and takes longer.

> > Sadly RISC OS users have very few options.

> Plenty of options, not all straightforward, or quick.

As mentioned before !Variations is beautifully simple in that multiple
jpegs can be selected, rotated and saved all in a single operation and
at a reasonably speed. If we can get around the current problem "no
writable memory at this address" error (with the latest copy of
jpegtran) then it becomes a useful desktop application on ARMv7 systems
where the photographer may only need to perform simple rotation and
image editing.

Richard

[Richard Ashbery]

In article <53052dd11achr...@spamcop.net>, Chris Johnson

Await with interest :-)

Richard

[David Pitt]

Richard Ashbery, on 28 Dec, wrote:

> In article <mpro.mfqrt000...@pittdj.co.uk>, David Pitt
> <ne...@pittdj.co.uk> wrote:
> > Chris Johnson, on 28 Dec, wrote:
>
> > > In article <mpro.mfqfxb00...@pittdj.co.uk>, David Pitt
> > > <ne...@pittdj.co.uk> wrote:
> > > > 2. Simply placing that newer 'jpegtran' in !Variation just results
> > > > in a "No writable memory at this address" on attempting a rotate.
> > >
> > > I think this will be due to the assigned wimpslot being too slow.
>
> > No such luck, I did try that.
>
> > OTOH being a bit more observant, the rotation is actually being done
> > despite the error!
>
> I don't think so - the error will stop rotation being performed. All that
> happens is that the little blue rotation icon disappears.

Jpegs are definitely rotating here.

Click menu on a jpeg in the 3x3 grid or on a single jpeg window and the
rotate happens without error.

The "No writable memory at this address" error only occurs using the rotate
buttons attached to the single window, clicking 'Describe" and "Cancel'
displays the rotated jpeg.


--
David Pitt
MessengerPro on iMac

[Richard Ashbery]

In article <mpro.mfr05g00...@pittdj.co.uk>, David Pitt

<ne...@pittdj.co.uk> wrote:
> Richard Ashbery, on 28 Dec, wrote:

> > In article <mpro.mfqrt000...@pittdj.co.uk>, David Pitt
> > <ne...@pittdj.co.uk> wrote:
> > > Chris Johnson, on 28 Dec, wrote:
> >
> > > > In article <mpro.mfqfxb00...@pittdj.co.uk>, David
> > > > Pitt <ne...@pittdj.co.uk> wrote:
> > > > > 2. Simply placing that newer 'jpegtran' in !Variation just
> > > > > results in a "No writable memory at this address" on
> > > > > attempting a rotate.
> > > >
> > > > I think this will be due to the assigned wimpslot being too
> > > > slow.
> >
> > > No such luck, I did try that.
> >
> > > OTOH being a bit more observant, the rotation is actually being
> > > done despite the error!
> >
> > I don't think so - the error will stop rotation being performed.
> > All that happens is that the little blue rotation icon disappears.

> Jpegs are definitely rotating here.

> Click menu on a jpeg in the 3x3 grid or on a single jpeg window and
> the rotate happens without error.

Yes it does. OK so how would you do auto-rotation/auto-save on a group
of jpegs, avoiding the error?

> The "No writable memory at this address" error only occurs using
> the rotate buttons attached to the single window, clicking
> 'Describe" and "Cancel' displays the rotated jpeg.

I think there is some misunderstanding. My point is that it is not
actually rotated in the thumbnail viewer (I think this is what you are
calling the single window). Sadly !Variations is unable to show the
actual orientation of the jpeg.

Richard

[David Pitt]

TBH I have never really used !Variation so it is not immediately obvious to
me that it not doing something as it should. The fact of the "No writable
memory at this address" error would indicate something is not happening as
it should.

--
David Pitt

[John Rickman Iyonix]

Richard Ashbery wrote

> PhotoDesk calls the outdated
> JPEGTRANS utility for rotating images which is incompatible with
> SpriteExtend used by PrivateEye and Variations. This is annoying in as
> much as if you rotate an image in PrivateEye/Variations and then import
> it into Photodesk, V3.12 (22-04-12) it appears with Stripey lines

Thanks for that bit of information Richard I'd often wondered why some
of my images were stripey in PhotoDesk.

[druck]

On 28/12/2012 15:26, Richard Ashbery wrote:> In article

<kbi6m1$3fa$1...@dont-email.me>, druck <ne...@druck.org.uk>
> wrote:
>> On 27/12/2012 15:59, Richard Ashbery wrote:
>>> Yes - PrivateEye can but Variations has the advantage of doing a
>>> mass rotation/save operation once images have been selected.
>>> Correct me if I'm wrong but none of the other RISC OS image
>>> editing software can do this.
>
>> !JPEGtools can also rotate/flip multiple files.
>
> Doesn't this require command line instructions? I'll investigate
> further.

No, its the desktop front end to JPEGtrans.

>>> Process is slow in PrivateEye because of the many keyboard
>>> operations required to rotate/save images. PhotoDesk calls the
>>> outdated JPEGTRANS utility for rotating images which is
>>> incompatible with SpriteExtend used by PrivateEye and Variations.
>
>> Unfortunately it also uses JPEGtrans, although a later version,
>
> Oh - you are quite right.
>
>> which still produced sprites incompatible with SpriteExtend - the
>> fault actually being with the RISC OS software for not handling
>> valid JPEG block formats.
>
> Pity :-(
>
>>> This is annoying in as much as if you rotate an image in
>>> PrivateEye/Variations and then import it into Photodesk, V3.12
>>> (22-04-12) it appears with Stripey lines.
>
>> There is an easy way around that, just load the JPEG in to !Paint,
>> and save it as a sprite straight in to Photodesk or whatever else
>> you want to edit it with.
>
> Yes I can see that would work - but changing formats and maybe back
> again to jpeg causes more image quality issues and takes longer.

There is exactly the same loss of quality from loading a JPEG, editing
and saving a JPEG. There is no additional loss from loading a JPEG,
saving as a lossless sprite, editing that and re-saving as a JPEG.

---druck

[Chris Johnson]

In article <53053703...@invalid.addr.uk>,
Richard Ashbery <bas...@invalid.addr.uk> wrote:
> Await with interest :-)

Have now had a look. With AEs on, my version of Variation (o.41d.34)
doesn't even get as far as 'loading' the selection - perhaps this is
djpeg being used to decompress to a sprite for the thumbnail. I
haven't checked that - the version I am using is certainly BB
friendly. With AEs off, it does load the selection but any attempt to
rotate fails as stated elsewhere in the thread. I have tried
'hacking' the runimage to use a larger -maxmemory but this doesn't
work. I have tried two versions of jpegtran (both ARMV7 friendly) and
they will rotate correctly in wimpslots far smaller than the
-maxmemory argument being passed by the program.

Since the !RunImage is about 500 KB of highly compressed Basic, it's
a nightmare to try to track what is going on. Not sure whether anyone
has tried to get the uncompressed source out of Rob.

It would appear that a number of people have asked in the not too
distant past about rotating jpegs (losslessly) in a batch process. It
shouldn't be too difficult to produce a front end that could rotate
camera images in a batch process in the background. I'll have a think
- I might be able to strip a significant part of the code out of one
of my other apps to knock a trial version together.

--
Chris Johnson

[Ron]

In message <530552aef1chr...@spamcop.net>
Chris Johnson <chrisjoh...@spamcop.net> wrote:
<snip>

> It would appear that a number of people have asked in the not too
> distant past about rotating jpegs (losslessly) in a batch process. It
> shouldn't be too difficult to produce a front end that could rotate
> camera images in a batch process in the background. I'll have a think
> - I might be able to strip a significant part of the code out of one
> of my other apps to knock a trial version together.
>

This Obey file might help someone in the meantime. Assuming the binary
jpegtran can be found by the system (eg !Boot.Library)
Name the Obey file "jpegrotate270", set the CSD in the directory of
jpegs and double-click the file "jpegrotate270"

Echo jpegtran rotate 270 option. Other rotate options are 90 or 180<10>
Set Alias$rotate SetEval leaf "%%0" RIGHT(LEN "%%0"-2)|mEcho |<leaf>|mjpegtran -rotate 270 |<leaf> @.rotated270.|<leaf>
CDir @.rotated270
Repeat rotate @ -type c85
Set Alias$jpegtype SetType %%0 c85
Repeat jpegtype @.rotated270
Unset Alias$rotate
Unset Alias$jpegtype

Better still, Run the Obey file in a Taskwindow so that it multitasks.

Cheers Ron M.

[Richard Ashbery]

In article <530552aef1chr...@spamcop.net>, Chris Johnson

<chrisjoh...@spamcop.net> wrote:
> In article <53053703...@invalid.addr.uk>, Richard Ashbery
> <bas...@invalid.addr.uk> wrote:
> > Await with interest :-)

> Have now had a look. With AEs on, my version of Variation
> (o.41d.34) doesn't even get as far as 'loading' the selection -
> perhaps this is djpeg being used to decompress to a sprite for the
> thumbnail. I haven't checked that - the version I am using is
> certainly BB friendly.

Using jpegtran and djpeg (Absolutes dated Dev 2012) from...

http://www.riscos.info/packages/GraphicsDetails.html#libjpeg-progs.

(thanks to Druck) you should be able to drag a directory of jpegs (taken
on a DCAM in portrait mode) over !Variations icon. Thumbnails should be
displayed. If you select one (indicated by a blue rotate direction
arrow) and press required Rotate icon then "No writable memory at this
address" error occurs. Obviously the error inhibits rotation (only the
direction arrow disappears). Note - AE's ON.

(I'm sure you know this but I've written down the above operation to
avoid any confusion)

With AEs off, it does load the selection but
> any attempt to rotate fails as stated elsewhere in the thread. I
> have tried 'hacking' the runimage to use a larger -maxmemory but
> this doesn't work. I have tried two versions of jpegtran (both
> ARMV7 friendly) and they will rotate correctly in wimpslots far
> smaller than the -maxmemory argument being passed by the program.

> Since the !RunImage is about 500 KB of highly compressed Basic,
> it's a nightmare to try to track what is going on. Not sure whether
> anyone has tried to get the uncompressed source out of Rob.

I will try and contact him and see if he could offer any help.

> It would appear that a number of people have asked in the not too
> distant past about rotating jpegs (losslessly) in a batch process.
> It shouldn't be too difficult to produce a front end that could
> rotate camera images in a batch process in the background. I'll
> have a think - I might be able to strip a significant part of the
> code out of one of my other apps to knock a trial version together.

That would be excellent Chris and thank you for the effort put into
solving this problem.

Richard

--
Regards

Richard Ashbery
(U3A Medium Walks Group Leader)

[Richard Ashbery]

In article <6913580...@ron1954.woosh.co.nz>, Ron

<be...@woosh.co.nz> wrote:
> In message <530552aef1chr...@spamcop.net> Chris Johnson
> <chrisjoh...@spamcop.net> wrote: <snip>

> >

> This Obey file might help someone in the meantime. Assuming the
> binary jpegtran can be found by the system (eg !Boot.Library) Name
> the Obey file "jpegrotate270", set the CSD in the directory of
> jpegs and double-click the file "jpegrotate270"

> Echo jpegtran rotate 270 option. Other rotate options are 90 or
> 180<10> Set Alias$rotate SetEval leaf "%%0" RIGHT(LEN
> "%%0"-2)|mEcho |<leaf>|mjpegtran -rotate 270 |<leaf>
> @.rotated270.|<leaf> CDir @.rotated270 Repeat rotate @ -type c85
> Set Alias$jpegtype SetType %%0 c85 Repeat jpegtype @.rotated270
> Unset Alias$rotate Unset Alias$jpegtype

> Better still, Run the Obey file in a Taskwindow so that it
> multitasks.

Looks promising but running Obeyfile reports - first image is found
with a message.... only one input file then a batch of "Switches"
information and finally.... Repeat: SWI &4258B not known.

> Cheers Ron M.

[Tim Hill]

In article <kbks8f$aei$1...@dont-email.me>, druck <ne...@druck.org.uk> wrote:

[Snip]

> There is exactly the same loss of quality from loading a JPEG, editing
> and saving a JPEG. There is no additional loss from loading a JPEG,
> saving as a lossless sprite, editing that and re-saving as a JPEG.

Many people don't seem to understand that when a picture is
lossy-compressed to a jpeg, the image is essentially reduced to be a
complex mathematical formula, rather than the relatively simple x/y
bitmap array of pixel information. It reduces a picture to an approximate
algorithm. Editing that jpeg "formula" to make pixel-level changes to an
image is impossible without staggering complexity and immense power.
consequently, as Druck describes, jpeg is always returned to be an 'array
bitmap' so you can edit it. When re-saved it is re-interpreted from an
array to be a jpeg 'formula' again. Each time you reload and save as jpeg
you lose information to the approximations.

Consequently, you should always work from a master 'array bitmap' and
only publish in jpeg. Compression of 'array bitmaps' such as Sprites can
still be achieved using non-lossy methods, such as storing them in a zip
file.

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

Robin: "Self-control is sure tough sometimes, Batman!" Batman: "All virtues are, old chum. Indeed, that's why they're virtues."

[Ron]

In message <5305a84a...@invalid.addr.uk>
Richard Ashbery <bas...@invalid.addr.uk> wrote:

<snip>

> > Better still, Run the Obey file in a Taskwindow so that it
> > multitasks.
>
> Looks promising but running Obeyfile reports - first image is found
> with a message.... only one input file then a batch of "Switches"
> information and finally.... Repeat: SWI &4258B not known.
>

Maybe it is only working on RISC OS 5 then.
I just checked what I posted by selecting it in the newsreader,
dragging the selection to a file courtesy StrongEd, setting the
file to type Obey, and it worked fine.

Is jpegtran working for you in the basic form on one file?

*jpegtran -rotate 270 @.foo/jpg @.foo270/jpg

should do a similar thing as long (as you Set the CSD to the
folder containing foo/jpg first.)
I dont know what exact the requirements are for a wimpslot,
but it doesn't sound like your error.

Thanks for the report,

Ron M. (Iyonix)

[Sprow]

On Dec 29, 9:18 pm, Ron <b...@woosh.co.nz> wrote:
> > > Better still, Run the Obey file in a Taskwindow so that it
> > > multitasks.
>
> > Looks promising but running Obeyfile reports - first image is found
> > with a message.... only one input file then a batch of "Switches"
> > information and finally.... Repeat: SWI &4258B not known.
>
> Maybe it is only working on RISC OS 5 then.

SWI 4258B is in DDEUtils, that suggests there should be an RMEnsure/
RMLoad of DDEUtils and that the author happens to have DDEUtils loaded
on their machine.

Tim Hill wrote:
> > There is exactly the same loss of quality from loading a JPEG, editing
> > and saving a JPEG. There is no additional loss from loading a JPEG,
> > saving as a lossless sprite, editing that and re-saving as a JPEG.
>
> Many people don't seem to understand that when a picture is
> lossy-compressed to a jpeg, the image is essentially reduced to be a
> complex mathematical formula, rather than the relatively simple x/y
> bitmap array of pixel information. It reduces a picture to an approximate
> algorithm.

However, in the context of jpegtran, it can operate losslessly on
JPEGs for certain operations.
In your description of JPEG you didn't mention that the master bitmap
is split into a grid of squares (usually 8x8 pixels) so operations
that don't change the contents of the squares can be done losslessly.

For example - a mirror in the Y axis, or a rotate, can both be done
without requantising.

Most competant JPEG tools will also let you set the 'Q' factor. The
higher that number (maximum 100) the less quantised your image will
become, but the larger the resulting JPEG of course. It's not a free
lunch,
Sprow.

[Chris Johnson]

In article <530552aef1chr...@spamcop.net>,

Chris Johnson <chrisjoh...@spamcop.net> wrote:
> It shouldn't be too difficult to produce a front end that could
> rotate camera images in a batch process in the background.

I now have an app that will batch rotate a dragged selection of jpegs
in the background. It is still a bit rough and ready (hopefully I
shall have time today to improve it), but if anyone would like to
give it a try let me know privately - my posting address is valid.

--
Chris Johnson

[Richard Ashbery]

In article <6c33da0...@ron1954.woosh.co.nz>, Ron

I'm sure this should work - using your example above with a jpeg
called Img/jpg in the root directory the command......

*jpegtran -rotate 270 @.Img/jpg @.Img270/jpg

run in a TaskWindow the OS reports.... "only one input file" followed
by the usual Switches. No SWI error this time.

Is this a syntax issue? What does "only one input file" mean?

Richard

[Chris Gransden]

In article <5306af31...@invalid.addr.uk>,

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> I'm sure this should work - using your example above with a jpeg
> called Img/jpg in the root directory the command......

> *jpegtran -rotate 270 @.Img/jpg @.Img270/jpg

> run in a TaskWindow the OS reports.... "only one input file" followed
> by the usual Switches. No SWI error this time.

> Is this a syntax issue? What does "only one input file" mean?

The command should be,

*jpegtran -rotate 270 -outfile @.Img270/jpg @.Img/jpg

The version of libjpeg-progs on riscos.info was recently updated to version
8. This also has support for lossless scaling.

Chris.

[Richard Ashbery]

In article <5306b587...@care4free.net>, Chris Gransden

<chr...@care4free.net> wrote:
> In article <5306af31...@invalid.addr.uk>, Richard Ashbery
> <bas...@invalid.addr.uk> wrote:

> > I'm sure this should work - using your example above with a jpeg
> > called Img/jpg in the root directory the command......

> > *jpegtran -rotate 270 @.Img/jpg @.Img270/jpg

> > run in a TaskWindow the OS reports.... "only one input file"
> > followed by the usual Switches. No SWI error this time.

> > Is this a syntax issue? What does "only one input file" mean?

> The command should be,

> *jpegtran -rotate 270 -outfile @.Img270/jpg @.Img/jpg

Excellent Chris - that works a treat - I think we can say that the
latest release of jpegtran (18-Dec-12) is compatible with RISC OS 5.19
(rel date 16-Dec-12).

Merely curious but why is the rotated jpeg saved as a text file? It is a
simple matter to add another line *SetType Img270/jpg jpeg to change it
however.

> The version of libjpeg-progs on riscos.info was recently updated to
> version 8. This also has support for lossless scaling.

Useful.

Richard

[Peter Young]

On 31 Dec 2012 Richard Ashbery <bas...@invalid.addr.uk> wrote:

[snip]

> Excellent Chris - that works a treat - I think we can say that the
> latest release of jpegtran (18-Dec-12) is compatible with RISC OS 5.19
> (rel date 16-Dec-12).

Did anyone mention where this version can be got from, or have I been
asleep?

With best wishes,

Peter.

--
Peter Young (zfc Ta) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pny...@ormail.co.uk

[Ron]

In message <5306bdaa...@invalid.addr.uk>

Richard Ashbery <bas...@invalid.addr.uk> wrote:

> > The command should be,
>
> > *jpegtran -rotate 270 -outfile @.Img270/jpg @.Img/jpg
>
> Excellent Chris - that works a treat - I think we can say that the
> latest release of jpegtran (18-Dec-12) is compatible with RISC OS 5.19
> (rel date 16-Dec-12).
>
> Merely curious but why is the rotated jpeg saved as a text file? It is a
> simple matter to add another line *SetType Img270/jpg jpeg to change it
> however.
>
> > The version of libjpeg-progs on riscos.info was recently updated to
> > version 8. This also has support for lossless scaling.
>
> Useful.
>
> Richard

I see,
and the riscos.info version has different characteristics to the
jpegtran at other locations.
With this version you can get jpegtran to set the filetype by using
-output foo.jpg rather than -output foo/jpg

So instead of

| This script works with jpegtran from libjpeg-progs-8d-1 available from www.riscos.info

Echo jpegtran rotate 270 option. Other rotate options are 90 or 180<10>

Set Alias$rotate SetEval leaf "%%0" RIGHT(LEN "%%0"-2)|mEcho |<leaf>|mjpegtran -rotate 270 -outfile rotated270/|<leaf>.jpg %%0

CDir @.rotated270
Repeat rotate @ -type c85
Set Alias$jpegtype SetType %%0 c85
|Repeat jpegtype @.rotated270
Unset Alias$rotate
Unset Alias$jpegtype

you could do

| This script works with jpegtran from libjpeg-progs-8d-1 available from www.riscos.info
| jpegtran will set the filetype if output is foo.jpg instead of foo/jpg

Echo jpegtran rotate 270 option. Other rotate options are 90 or 180<10>

Set Alias$rotate SetEval leaf ("%%0" RIGHT(LEN "%%0"-2)) LEFT(LEN "%%0"-6) |mEcho |<leaf>|mjpegtran -rotate 270 -outfile rotated270/|<leaf>.jpg %%0

CDir @.rotated270
Repeat rotate @ -type c85

Unset Alias$rotate

but it should really check for the input jpeg being named @.foo/jpg
before chopping off the last 4 characters.
eg If "%%0" RIGHT 4 = "/jpg" Then (do this) Else (do that)

Regarding this filetyping, I have noticed the need for unix naming with
another binary also, so it appears the function is getting lost in the
GCC unixlib riscos to unix translation.
The mimemap performs this function for networking, maybe it could be
extended for system files? -but it would also mean you would have to
change the extension rather than just the RISC OS filetype.

Ron M.

[Ron]

In message <7a75ea0...@ron1954.woosh.co.nz>

Ron <be...@woosh.co.nz> wrote:

> you could do
>
> | This script works with jpegtran from libjpeg-progs-8d-1 available from www.riscos.info
> | jpegtran will set the filetype if output is foo.jpg instead of foo/jpg
> Echo jpegtran rotate 270 option. Other rotate options are 90 or 180<10>
> Set Alias$rotate SetEval leaf ("%%0" RIGHT(LEN "%%0"-2)) LEFT(LEN "%%0"-6) |mEcho |<leaf>|mjpegtran -rotate 270 -outfile rotated270/|<leaf>.jpg %%0
> CDir @.rotated270
> Repeat rotate @ -type c85
> Unset Alias$rotate
>
> but it should really check for the input jpeg being named @.foo/jpg
> before chopping off the last 4 characters.
> eg If "%%0" RIGHT 4 = "/jpg" Then (do this) Else (do that)

I have now made such a script, it has the ingrediants that could be tweaked
for use with GCC binary (in general) batch processing so might be handy.
It works in RISC OS 3.7 and 5.18, should be OK for 5.19 too?


| This batch script rotates jpegs in the CSD using jpegtran from the libjpeg-progs-8d-1 package available from www.riscos.info
| The outfile name is changed from foo/jpg to foo.jpg to allow filetyping

Echo jpegtran rotate 270 option. Other rotate options are 90 or 180<10>

Set Alias$rot270 SetEval leaf "%%0" RIGHT(LEN "%%0"-2)|mEcho |<leaf>|mIf leaf RIGHT4="/jpg" Then SetEval leaf leaf LEFT(LEN"|<leaf>"-4)|mjpegtran -rotate 270 -outfile rotated270/|<leaf>.jpg %%0
CDir @.rotated270
Repeat rot270 @ -type c85
Unset Alias$rot270


Though this can work, I think it is less restrictive to a use an obey file
(replacing the alias) and calling that with the Repeat command. There is
then plenty of space for extra lines of commands, and you can pass plenty
of parameters then also.

An application/window is always going to do organise things and be easier
to use at a later date, There is a mind boggling number of options that
could be included in an app.
For Jpeg's, you might want to use jhead to strip exif info so that the
postscript driver can print them, and I would include a jpeg density
option, so that they load into draw at a predetermined scale.

Ron M.

[David Pitt]

David Pitt, on 28 Dec, wrote:

> Richard Ashbery, on 26 Dec, wrote:
>
> > Attempts at rotating images with Variations on Beagleboard fail with
> > Fatal signal received: Segmentation fault.
> >
> > Anyone know of a workaround?
> >
> > Works perfectly on Iyonix 5.18
> >
> > Variations (0.41d) Beagleboard -xM (RISC OS 5.19 16-Dec-12)
>
>
> As identified elsewhere 'jpegtran' is the problem on the ARMini.
>
> Used from the command line the 'jpegtran' supplied with !Variation does
> crash on a rotate if Alignment Exceptions are on. This 'jpegtran' is date
> stamped 10 Aug 2004 and is 193716 bytes.
>
> There is a later recompilation of jpegtran which does rotate from the
> command line with Alignment Exceptions on, this is dated 22 Dec 2012 and
> is 260148.
>
> http://www.chris-johnson.org.uk/software/3party.html
>
> There are however snags,
>
> 1. The output jpeg is filetyped as text here!

>
> 2. Simply placing that newer 'jpegtran' in !Variation just results in a

> "No writable memory at this address" on attempting a rotate. !Variation is
> supplied in compressed BASIC so making any fix harder. The 'jpegtran'
> command issued by !Variation does contain the -maxmemory switch.

Take 2.

The latest 'jpegtran' at :-
http://www.riscos.info/packages/GraphicsDetails.html#LibJpeg-Progs
wraps the commands in aliases which includes their required WimpSlot sizes.

To force !Variation to use this 'jpegtran', and not its own internal
version, it is only necessary to remove the <Variations$Dir> prefix from the
two lines in !RunImage that make the call to 'jpegtran'. (Zap works best on
heavily compressed BASIC.)

I looks to me that this works, there is no "No writable memory at this
address" error and the jpeg rotates. I do not use !Variation and am not at
all familiar with it so this result could be a bit superficial.

Calls to 'djpeg' also need changing.

Is this any good?
--
David Pitt

[druck]

On 29 Dec 2012 Tim Hill <t...@invalid.org.uk> wrote:
> Many people don't seem to understand that when a picture is
> lossy-compressed to a jpeg, the image is essentially reduced to be a
> complex mathematical formula, rather than the relatively simple x/y
> bitmap array of pixel information. It reduces a picture to an approximate
> algorithm. Editing that jpeg "formula" to make pixel-level changes to an
> image is impossible without staggering complexity and immense power.

That's not really the problem, even if you had the processing power
you would still lose more information every time a pixel is changed.
Indeed recalculating the coefficients every time a pixel changed would
be far far worse than one JPEG to bitmap operation, edit the
uncompressed bitmap and one convertion back to JPEG.

> consequently, as Druck describes, jpeg is always returned to be an 'array
> bitmap' so you can edit it. When re-saved it is re-interpreted from an
> array to be a jpeg 'formula' again. Each time you reload and save as jpeg
> you lose information to the approximations.

One conversion each way will lose very little further information
compared to what it already discarded by the JPEG process*, so is
acceptable for editing photos from a camera. What you want to avoid is
repeated conversion to and from JPEG when performing multiple editing
operations.

> Consequently, you should always work from a master 'array bitmap' and
> only publish in jpeg. Compression of 'array bitmaps' such as Sprites can
> still be achieved using non-lossy methods, such as storing them in a zip
> file.

It is far better to use a dedicated lossless compressed image format
such PNG, which can give much better results than zipping, and is also
immediately editable on a wide range of platforms.

* Regardless of the quality setting used, the JPEG conversion
immediately throws away half the colour information in the image. So
1000 pixel wide images can have 1000 changes of brightenss, but only
500 changes of colour on each line. The quality setting will determine
how much more information is discard from both sharpness of edges and
subtlety of graduations in both brightness and colour components.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page - http://www.armclub.org.uk/32bit/

[Richard Ashbery]

In article <mpro.mfzl8d00...@pittdj.co.uk>, David Pitt

<ne...@pittdj.co.uk> wrote:
> David Pitt, on 28 Dec, wrote:

> To force !Variation to use this 'jpegtran', and not its own
> internal version, it is only necessary to remove the
> <Variations$Dir> prefix from the two lines in !RunImage that make
> the call to 'jpegtran'. (Zap works best on heavily compressed
> BASIC.)

There are 78 references to <Variations$Dir>. Being a StrongED user, I'm
unfamiliar with Zap so wouldn't have a clue where to start.

I would have expected that just by substituting the new versions of
djpeg and jpegtran for the old would suffice - probably not as simple
as that though!!

> I looks to me that this works, there is no "No writable memory at
> this address" error and the jpeg rotates. I do not use !Variation
> and am not at all familiar with it so this result could be a bit
> superficial.

> Calls to 'djpeg' also need changing.

> Is this any good?

?????

Richard

[Tim Hill]

In article
<119f43a0-6e3b-4ae8...@eo2g2000vbb.googlegroups.com>,
Sprow <ne...@sprow.co.uk> wrote:

[Snip]

> Tim Hill wrote:

No, I didn't write this. Missing attribution.

> > > There is exactly the same loss of quality from loading a JPEG,
> > > editing and saving a JPEG. There is no additional loss from loading
> > > a JPEG, saving as a lossless sprite, editing that and re-saving as
> > > a JPEG.

I wrote this:

> > Many people don't seem to understand that when a picture is
> > lossy-compressed to a jpeg, the image is essentially reduced to be a
> > complex mathematical formula, rather than the relatively simple x/y
> > bitmap array of pixel information. It reduces a picture to an
> > approximate algorithm.

Missing SNIP.

> However, in the context of jpegtran, it can operate losslessly on JPEGs
> for certain operations. In your description of JPEG you didn't mention
> that the master bitmap is split into a grid of squares (usually 8x8
> pixels) so operations that don't change the contents of the squares can
> be done losslessly.

You conveniently snipped my next sentence which included "pixel-level
changes" to suit that comment, did you?

> For example - a mirror in the Y axis, or a rotate, can both be done
> without requantising.

Yes. You're right. With the J-tools you can download from my website
which also has a link to the updated jpegtrans for the BB.

http://timil.com/riscos

[Snip]

Good grief.

T

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

Batman: "Remember the Boy Scouts' motto." Robin: "'Be prepared'." Batman: "It would do well to keep that in mind at all times."

[Richard Ashbery]

In article <5309b8...@invalid.org.uk>, Tim Hill

> Yes. You're right. With the J-tools you can download from my
> website which also has a link to the updated jpegtrans for the BB.

> http://timil.com/riscos

Tim - you are aware of the more recent Jpegtools at....

http://www.riscos.info/packages/GraphicsDetails.html#libjpeg-progs

Richard

[Tim Hill]

In article <5309d7e2...@invalid.addr.uk>, Richard Ashbery

Yes. Thanks for the reminder. I need to investigate further why my
attempts to use Jcut with the new jpegtran didn't work.

(The !Jcut.!RunImage is such that it uses the jpegtran in the Jcut
application directory so to attempt this, the 12 Jan 2003 version -
rename it - has to be replaced by the 18.12.2012 version. Trying to load
a jpeg results in the same output as from "*jpegtran -h". Which is odd.)

[Chris Johnson]

In article <5309e1...@invalid.org.uk>,

Tim Hill <t...@invalid.org.uk> wrote:
> Trying to load a jpeg results in the same output as from "*jpegtran
> -h". Which is odd.)

You may find that the JCut runimage needs modification. As far as I
remember the original just uses (in the jpegtran cmd line it
constructs) the in and out files space separated. Depending on what
#defines have been used during the compilation of the jpegtran
binary, jpegtran may require the filenames as
-outfile outfilename infilename

--
Chris Johnson

[Tim Hill]

In article <5309e6df30chr...@spamcop.net>,

The command string does seem to be in the correct order. with switches
preceding the filenames and spaces between, as you say. Has the command
line syntax been changed? The -help output seems similar.

It won't even load a file...

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

Batman to Robin: "Stop fiddling with that atomic pile and come down here!"

[Tim Hill]

In article <530ce0...@invalid.org.uk>,

Tim Hill <t...@invalid.org.uk> wrote:
> In article <5309e6df30chr...@spamcop.net>,
> Chris Johnson <chrisjoh...@spamcop.net> wrote:
> > In article <5309e1...@invalid.org.uk>,
> > Tim Hill <t...@invalid.org.uk> wrote:
> > > Trying to load a jpeg results in the same output as from "*jpegtran
> > > -h". Which is odd.)

> > You may find that the JCut runimage needs modification. As far as I
> > remember the original just uses (in the jpegtran cmd line it
> > constructs) the in and out files space separated. Depending on what
> > #defines have been used during the compilation of the jpegtran
> > binary, jpegtran may require the filenames as
> > -outfile outfilename infilename

> The command string does seem to be in the correct order. with switches
> preceding the filenames and spaces between, as you say. Has the command
> line syntax been changed? The -help output seems similar.

> It won't even load a file...

I think I can now see what the problem is.

Old jpegtran
usage: jpegtran [switches] inputfile outputfile

New jpegtran
usage: jpegtran [switches] [inputfile]

And outputfile now ONLY seems to form part of an 'advanced' switch,
meaning that any app relying on the old version's syntax has been broken
by the new one. Simply re-ordering the parameters doesn't work.

Surely, when a utility such as this is updated, there should be no change
to the command line syntax (apart from new stuff)?!! Perhaps the new
version isn't really jpegtran after all, as it no longer behaves in the
same way. ;-)

[Chris Johnson]

In article <530ce4...@invalid.org.uk>,

Tim Hill <t...@invalid.org.uk> wrote:
> Surely, when a utility such as this is updated, there should be no change
> to the command line syntax (apart from new stuff)?!! Perhaps the new
> version isn't really jpegtran after all, as it no longer behaves in the
> same way. ;-)

All versions of jpeg, however compiled, work with the command line
format

jpegtran -outfile outfilepath infilepath

which is the 'multiplatform' way of doing things.

The usage in the form

jpegtran infilepath outfilepath

is special and requires compilation with a particular set of compiler
switches.

--
Chris Johnson

[Ron]

In message <530d0bc097chr...@spamcop.net>

As a work-around for older frontends needing to run the standard format
jpegtran binary try this.

Rename the new jpegtran binary to jpegtrn or whatever.
Create an Obey file named jpegtran

If "%4" <>"" Then jpegtrn %0 %1 %2 -outfile %4 %3
If "%4" <>"" Then Obey
If "%3" <>"" Then jpegtrn %0 %1 -outfile %3 %2
If "%3" <>"" Then Obey
If "%2" <>"" Then jpegtrn %0 -outfile %2 %1
If "%2" <>"" Then Obey
If "%1" <>"" Then jpegtrn --help
If "%1" <>"" Then Obey
If "%0" <>"" Then jpegtrn --help
If "%0" <>"" Then Obey
jpegtrn --help


You may need a higher number than 4 depending on how many arguments
the particular frontend can use, but you can see the pattern.

Ron M.

[Tim Hill]

In article <9738120...@ron1954.woosh.co.nz>,
Ron <be...@woosh.co.nz> wrote:

[Snip]

>
> As a work-around for older frontends needing to run the standard format
> jpegtran binary try this.

> Rename the new jpegtran binary to jpegtrn or whatever.
> Create an Obey file named jpegtran

> If "%4" <>"" Then jpegtrn %0 %1 %2 -outfile %4 %3
> If "%4" <>"" Then Obey
> If "%3" <>"" Then jpegtrn %0 %1 -outfile %3 %2
> If "%3" <>"" Then Obey
> If "%2" <>"" Then jpegtrn %0 -outfile %2 %1
> If "%2" <>"" Then Obey
> If "%1" <>"" Then jpegtrn --help
> If "%1" <>"" Then Obey
> If "%0" <>"" Then jpegtrn --help
> If "%0" <>"" Then Obey
> jpegtrn --help


> You may need a higher number than 4 depending on how many arguments
> the particular frontend can use, but you can see the pattern.

Indeed. I have added <jcut$dir>. in front of jpegtrn and tried this with
up to nine parameters (just in case) but still no joy. I am not familiar
with the use of 'Then Obey' as shown, is this the usual way to exit the
statements?

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

Robin: "That's an impossible shot, Batman." Batman: "That's a negative attitude, Robin."

[Ron]

In message <530d1a...@invalid.org.uk>
Tim Hill <t...@invalid.org.uk> wrote:
<snip>

> > You may need a higher number than 4 depending on how many arguments
> > the particular frontend can use, but you can see the pattern.
>
> Indeed. I have added <jcut$dir>. in front of jpegtrn and tried this with
> up to nine parameters (just in case) but still no joy. I am not familiar
> with the use of 'Then Obey' as shown, is this the usual way to exit the
> statements?
>

Yes, Obey on its own exits the file

I tried JCut and there is a further culprit.
The -c needs to be -copy which appears to be always in %0

By uncommenting line 1 you can view the arguments as they are getting
used.

|Echo %*0
If "%9" <>"" Then <Jcut$Dir>.jpegtrn -copy %1 %2 %3 %4 %5 %6 %7 -outfile %9 %8
If "%9" <>"" Then Obey
If "%8" <>"" Then <Jcut$Dir>.jpegtrn -copy %1 %2 %3 %4 %5 %6 -outfile %8 %7
If "%8" <>"" Then Obey
If "%7" <>"" Then <Jcut$Dir>.jpegtrn -copy %1 %2 %3 %4 %5 -outfile %7 %6
If "%7" <>"" Then Obey
<Jcut$Dir>.jpegtrn --help

It looks like there is always a high number so after some observations
you can alter the number of arguments.

JCut !RunImage is uncompressed BASIC, and it would be better to alter
the syntax in there.
However using the above for a while could help reveal any more needed
changes.

Tim, an old MimeMap problem popped up again the other day.
Downloading a zip file, I had to change the following line to ddc
to get it Filetyping. It's normally a91

Is the a91 needed when you send a zipfile to Windows?

application/zip Zip ddc .zip .arc .spk .lha .arj .lzh

The */zip Method wasn't doing it either.
I have cut out */zip for a while to see how things go.
Ron M.

[Chris Johnson]

The various JXYZ utilities are all written in Basic. It is fairly
simple to change the lines that construct the jpegtran command lines
so that it uses the -outfile switch.

--
Chris Johnson

[Ron]

In message <530d1d6aa1chr...@spamcop.net>

I guess the next question is wether someone can fix the ones that
people download.

These changes seem to let JCut work OK.

Search and Replace for !JCut.!Runimage

-c to -copy
"+s$+" "+d to -outfile "+d$+" "+s

There are several instances of -c to change.
Ron M.

[Chris Johnson]

In article <1fad5f0...@ron1954.woosh.co.nz>,

Ron <be...@woosh.co.nz> wrote:
> I guess the next question is wether someone can fix the ones that
> people download.

I did fix up some versions when the BB (ARMini) first came out. I
could have a look at the various JXXX utilities on my ARMini, put in
the latest v8 jpegtran binary and then check they work OK. Then put
them up on my site.

Incidently, the jpegtran 'front end' I recently produced uses the v8
module and seems to be working fine on the BB. The small number of
users who volunteered to test it haven't had any disasters strike
that I am aware of.

This front end allows you to drag a selection of files, or a dir of
files, and will batch process the files using any of rotate
left/right/180deg, flip vert/hor, transpose, transverse. I did add
the lossless scale facility, but I haven't found any viewer/processor
on RISC OS that can actually display the scaled down image (eg.
Thump, SwiftJPEG display a totally black image of the correct size,
DPlngScan complains about an invalid marker and refuses to do
anything else). The readme to v8 does say in the scaling section that
few applications can deal with the new format. I guess other OSs will
by now read them, but not RISC OS.

--
Chris Johnson

[Chris Johnson]

In article <530d1d6aa1chr...@spamcop.net>,

I now have a version of !JCut that works with the latest version of
jpegtran, and hopefully should work also with any newer versions that
are relesed. The main problems were (a) needing the -outfile switch
and (b) the use of abbreviations for the switches, some of which
became ambiguous because version 8 has introduced a number of new
switches. If anyone wants a copy let me know and I will email the new
runimage.

I guess I should also get a copy off to Tim, but he doesn't appear to
be around here during the week, so it isn't desperate.

--
Chris Johnson

[Ron]

In message <5306ad8a60chr...@spamcop.net>

Was there a limit of 10 arguments that RISC OS could pass once?
That might be why pains were taken to remove -outfile.

It would cut down the length of the string if -c and -o was used,
especially when there isn't many options to cater for.
Obviously that would require a patch in the autobuilder and the
!Jcut !Runfile and others would still have to be changed.

I have had trouble on and off with the length of the <Wimp$ScrapDir>
in another unixlib port and there is even a possibility of having it
work on my Iyonix and then fail on the Risc PC with 'line too long'.

Personally I think a regularly visited directory like ScrapDir,
should be in the Root directory.
It's not like there are comparable busy things that would cause
a clutter of system files to spoil the look.
Well, !Newsbase is one thing I've moved to the Root directory.

Even if the computer can handle long paths, it is tiring looking
at them, and when you have to dig down deep for things also.

Ron M.

[Chris Johnson]

In article <225bcf0...@ron1954.woosh.co.nz>,

Ron <be...@woosh.co.nz> wrote:
> Was there a limit of 10 arguments that RISC OS could pass once?
> That might be why pains were taken to remove -outfile.

> It would cut down the length of the string if -c and -o was used,
> especially when there isn't many options to cater for.
> Obviously that would require a patch in the autobuilder and the
> !Jcut !Runfile and others would still have to be changed.

In several of my apps that spawn taskwindows, one thing I have done
to cut down length of command lines is to set temporary system
variables for the file paths and use them in the command - this
markedly reduces the command lengths.

I think the module DDEUtils also allows longer command lines to be
used in many cases.

I have also just fixed up !JCut to use the latest jpegtran. One of
the problems there (apart from -outfile) was that it used a number of
one char abbreviations for some of the command line switches, and the
new jpegtran has introduced some additional commands, so the
abbreviations were now ambiguous and were translated by jpegtran
incorrectly.

--
Chris Johnson

[Tim Hill]

In article <530f88b2c1chr...@spamcop.net>, Chris Johnson

Well observed! Usenet is usually a weekend thing here.

Please send a copy to tim at timil dot com and I'll change the version on
my download page. And thanks for that. You have saved me having to make
those very changes. :-) Thank you.

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

Robin: "Let's go!" Batman: "Not you, Robin. They have strict licensing laws in this country. A boy of your age is not allowed in a drinking tavern."

[Tim Hill]

In article <225bcf0...@ron1954.woosh.co.nz>,
Ron <be...@woosh.co.nz> wrote:

> Personally I think a regularly visited directory like ScrapDir,
> should be in the Root directory.

Then move yours into the Root directory if you want to. Just remember to
add it to 'look at' in Configure>Boot and hope it doesn't break any
wrongly-made programming assumptions.

The late, lamented, Paul Vigay use always to use the RAM disc for his
!Scrap, for reasons of speed and security. RISC OS lets you put anything
where you want to put it. (This really pisses people used to other
platforms and packaging, which like everything to be in fixed and the
same places. A good reason, on its own, for some of us to do things
differently!!!)

[Ron]

In message <531068...@invalid.org.uk>

Tim Hill <t...@invalid.org.uk> wrote:

> In article <225bcf0...@ron1954.woosh.co.nz>,
> Ron <be...@woosh.co.nz> wrote:
> > Personally I think a regularly visited directory like ScrapDir,
> > should be in the Root directory.
>
> Then move yours into the Root directory if you want to. Just remember to
> add it to 'look at' in Configure>Boot and hope it doesn't break any
> wrongly-made programming assumptions.
>
> The late, lamented, Paul Vigay use always to use the RAM disc for his
> !Scrap, for reasons of speed and security. RISC OS lets you put anything
> where you want to put it. (This really pisses people used to other
> platforms and packaging, which like everything to be in fixed and the
> same places. A good reason, on its own, for some of us to do things
> differently!!!)
>

I found there was no need to move the whole application, just change the
parameter in !Scrap.Boot and !Scrap.Run.

Run <Obey$Dir>.!RunImage <Boot$Dir>.^ -Boot
and
Do Run <Obey$Dir>.!RunImage <Boot$Dir>.^
respectively puts the scrap dir in the root.

I think it is more portable for (my) application to use its own
temp directory related to the drive that the app is started from.
If working in ram or Fat32fs, It is only a matter of copying my app to
the drive and running it from there and it will use a temp on that fs.
I still have to compare the temp FS to the Destination FS to work out
if Rename can be used instead of Copy.
A bit finicky, but comparing the characters up to $ of the app dir
to the same number of chars on the destination path allows this.
It's a pity *Copy with D(elete) cant work this out.

Ron M.

[Russell Hafter News]

In article <531068...@invalid.org.uk>,

Tim Hill <t...@invalid.org.uk> wrote:

> The late, lamented, Paul Vigay use always to use the RAM
> disc for his !Scrap, for reasons of speed and security.

How does this happen?

Presumably, at the very least, you have to create the RAM
disc each time the machine boots up, then copy !Scrap across
from a master copy, then Filer_Boot or Filer_Run the version
in the RAM disc, so the machine uses that Scrap rather than
the master Scrap.

While I can see that this could be automated, is it all
really worth it?

--
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>

[Tim Hill]

In article <53107ab7...@walkingingermany.invalid>, Russell Hafter

News <see...@walkingingermany.invalid> wrote:
> In article <531068...@invalid.org.uk>, Tim Hill
> <t...@invalid.org.uk> wrote:

> > The late, lamented, Paul Vigay use always to use the RAM disc for his
> > !Scrap, for reasons of speed and security.

> How does this happen?

> Presumably, at the very least, you have to create the RAM disc each
> time the machine boots up, then copy !Scrap across from a master copy,
> then Filer_Boot or Filer_Run the version in the RAM disc, so the
> machine uses that Scrap rather than the master Scrap.

Yes, one way is included in Paul's MiscSetup Configure tool.
http://www.vigay.com/software/miscsetup.html
You simply tick an option.

> While I can see that this could be automated, is it all really worth it?

I think that the endless discussion at the time (!) resulted in 'yes and
no'. It may have been a fraction quicker but was the added security of
any real benefit? Oh, and it placed less burden on your hard drive.

[Chris Johnson]

In article <531088...@invalid.org.uk>,

Tim Hill <t...@invalid.org.uk> wrote:
> I think that the endless discussion at the time (!) resulted in
> 'yes and no'. It may have been a fraction quicker but was the added
> security of any real benefit? Oh, and it placed less burden on your
> hard drive.

The speed aspect has come to the fore again with the advent of the BB
and RaspberryPi. Although the hardware is generally pretty nippy, a
bottleneck is writing over usb to your boot drive, which may be a
rather slow filecore formatted memory stick or card. Running !Scrap
on a RAM drive may speed things up considerably. On the downside,
some apps (which actually store and retain data in scrap) are rather
hungry when it comes to scrap files. For example, I have had !Thump
scrap files of 300MB or more, and !NetSurf on this Iyonix has a scrap
directory of ca. 100MB at the moment. It is always worth keeping an
eye on the size of scrap and pruning manually at times. I used to
think that applications were supposed to delete all their scrap files
when quit, and well behaved ones would clean scrap on startup, in
case the machine was not shut down correctly on a previous occasion.

--
Chris Johnson

[Folderol]

On Sun, 20 Jan 2013 11:30:08 +0000 (GMT)
Chris Johnson <chrisjoh...@spamcop.net> wrote:

> I used to
> think that applications were supposed to delete all their scrap files
> when quit, and well behaved ones would clean scrap on startup, in
> case the machine was not shut down correctly on a previous occasion.

You thought correctly! However not all programmers seem to bother :(

--
W J G

[Tim Hill]

In article <5310f8b734chr...@spamcop.net>, Chris Johnson
<chrisjoh...@spamcop.net> wrote:

[Snip]

>I used to think
> that applications were supposed to delete all their scrap files when
> quit, and well behaved ones would clean scrap on startup,

So did Paul, which is why RAM disc was okay for it.

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Share in a better energy supplier: http://tjrh.eu/coopnrg
* Share in cheaper ethical telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/

[Steve Fryatt]

On 20 Jan, Tim Hill wrote in message
<5310fd...@invalid.org.uk>:

> In article <5310f8b734chr...@spamcop.net>, Chris Johnson
> <chrisjoh...@spamcop.net> wrote:
>
> [Snip]
>
> > I used to think that applications were supposed to delete all their
> > scrap files when quit, and well behaved ones would clean scrap on
> > startup,
>
> So did Paul, which is why RAM disc was okay for it.

I'm not sure that it's actually documented anywhere authoritative. IIRC a
lot of thought went into where NetSurf could store data like the unicode
mappings, and it was decided that Scrap was the least-worst option (from a
list which I'm pretty sure included getting a new resource allocated by
ROOL).

--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 20 April 2013
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/

[Richard Ashbery]

In article <5310f8b734chr...@spamcop.net>, Chris Johnson

<chrisjoh...@spamcop.net> wrote:
> In article <531088...@invalid.org.uk>, Tim Hill
> <t...@invalid.org.uk> wrote:

> Running !Scrap on a RAM drive may speed things up considerably. On
> the downside, some apps (which actually store and retain data in
> scrap) are rather hungry when it comes to scrap files. For example,
> I have had !Thump scrap files of 300MB or more, and !NetSurf on
> this Iyonix has a scrap directory of ca. 100MB at the moment. It is
> always worth keeping an eye on the size of scrap and pruning
> manually at times.

Any use... ScrapClean from http://www.highpath.net/highpath/computers.
Accomplished with a few lines of BASIC so maybe ARMv7 compatible.

Richard

[Bryn Evans]

In a mad moment - Richard Ashbery mumbled :

Don't forget that !Memphis can be configured to act as !Scrap as well.



--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com

[SG nws]

Bryn Evans wrote:
> !Memphis can be configured to act as !Scrap as well.

Yes, but it's as well to bear in mind that some progs
will not work (I think Newsbase is one) in that case.
The problem is described in the accompanying !Help.

--
Stewart Goldwater
http://janusg.co.nr

[Bryn Evans]

In a mad moment - SG nws mumbled :

> Bryn Evans wrote:
>> !Memphis can be configured to act as !Scrap as well.

> Yes, but it's as well to bear in mind that some progs
> will not work (I think Newsbase is one) in that case.
> The problem is described in the accompanying !Help.

I stand corrected.

[Jim Lesurf]

In article <mpro.mgxcwc03...@stevefryatt.org.uk>, Steve Fryatt

<ne...@stevefryatt.org.uk> wrote:
> On 20 Jan, Tim Hill wrote in message <5310fd...@invalid.org.uk>:

> > In article <5310f8b734chr...@spamcop.net>, Chris Johnson
> > <chrisjoh...@spamcop.net> wrote:
> >
> > [Snip]
> >
> > > I used to think that applications were supposed to delete all their
> > > scrap files when quit, and well behaved ones would clean scrap on
> > > startup,
> >
> > So did Paul, which is why RAM disc was okay for it.

FWIW I've routinely copied !Scrap to ramdisc at bootup and then used it
there for many years. Ensures all the genuinely temporary items are cleared
away at a shutdown. Main reason I did it was to reduce noises from the HD,
but also to lighten HD use and perhaps be a tad faster.

> I'm not sure that it's actually documented anywhere authoritative. IIRC
> a lot of thought went into where NetSurf could store data like the
> unicode mappings, and it was decided that Scrap was the least-worst
> option (from a list which I'm pretty sure included getting a new
> resource allocated by ROOL).

Netsurf is 'unusual'. I found I had to ensure I'd got a basic set of items
it is obsessively determined to find *left* in !Scrap. so I copy back
!Scrap from ram to the main version on HD after an initial use of NetSurf.
Then let this be what is copied onto ram again for use in following
sessions. Seems fine as !NetSurf plonks other stuff into !Boot.Choices
anyway.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

[Vince M Hudd]

Tim Hill <t...@invalid.org.uk> wrote:

> The late, lamented, Paul Vigay use always to use the RAM disc for his
> !Scrap,

Not just Paul. I had one of my RiscPCs set up to move Scrap to the RAM disc
at boot. I've never bothered on any machine since, though.

--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com

[John Rickman Iyonix]

Vince M Hudd wrote

> Tim Hill <t...@invalid.org.uk> wrote:

>> The late, lamented, Paul Vigay use always to use the RAM disc for his
>> !Scrap,

> Not just Paul. I had one of my RiscPCs set up to move Scrap to the RAM disc
> at boot. I've never bothered on any machine since, though.

I tried to do it with my late and largely unlamented A9Home once but
it completely froze the machine and it was a bogger to get it working
again.

--
John Rickman - http://mug.riscos.org/

For ye have the poor always with you; but me ye have not always.

[Chris Evans]

In article <mpro.mgxcwc03...@stevefryatt.org.uk>, Steve Fryatt

<URL:mailto:ne...@stevefryatt.org.uk> wrote:
> On 20 Jan, Tim Hill wrote in message
> <5310fd...@invalid.org.uk>:
>
> > In article <5310f8b734chr...@spamcop.net>, Chris Johnson
> > <chrisjoh...@spamcop.net> wrote:
> >
> > [Snip]
> >
> > > I used to think that applications were supposed to delete all their
> > > scrap files when quit, and well behaved ones would clean scrap on
> > > startup,
> >
> > So did Paul, which is why RAM disc was okay for it.
>
> I'm not sure that it's actually documented anywhere authoritative. IIRC a
> lot of thought went into where NetSurf could store data like the unicode
> mappings, and it was decided that Scrap was the least-worst option (from a
> list which I'm pretty sure included getting a new resource allocated by
> ROOL).

Can a setting be changed to move where NetSurf uses for its large files?

We have a number of our computers here using !Scrap in RAM. It can make
quite a noticable difference in some programs.

Chris Evans

--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!

[David Pitt]

To go back to the original problem perhaps someone may care to look again at
the prospect of using latest Beagle ROM, 23 Jan 2013, with the latest jpeg
tools, these that is :-

http://www.riscos.info/packages/GraphicsDetails.html#LibJpeg-Progs

Replace the executables inside !Variations with the above ARMv7 builds.

The latest Beagle ROM catches the "No writable memory at this address" error
and does something more positive.

Rotations are happening here, but I have not tried batch made and I believe
the command line syntax may be different so there may be gotchas waiting.

Just a thought.

--
David Pitt

[Richard Ashbery]

In article <mpro.mh34qu00...@pittdj.co.uk>, David Pitt

We've already covered that David - batch rotations do not work either
with AE on or off. This is with JPEGTools (jpegtran and djpeg) from
the website you have given above. Checked on ROM 5.19 (16-Dec-12).

Incidentally version 9 has been released by Independent JPEG Group
(IJG) - you've probably seen my other posting appealing for a
programmer to create a RISC OS compatible version. However on
reflection I don't think there is any advantage to RISC OS users
compared with the previous version.

Richard

[David Pitt]

Richard Ashbery, on 23 Jan, wrote:

> In article <mpro.mh34qu00...@pittdj.co.uk>, David Pitt
> <ne...@pittdj.co.uk> wrote:
> > To go back to the original problem perhaps someone may care to look
> > again at the prospect of using latest Beagle ROM, 23 Jan 2013, with the
> > latest jpeg tools, these that is :-
>
> > http://www.riscos.info/packages/GraphicsDetails.html#LibJpeg-Progs
>
> > Replace the executables inside !Variations with the above ARMv7 builds.
>
> > The latest Beagle ROM catches the "No writable memory at this address"
> > error and does something more positive.
>
> > Rotations are happening here, but I have not tried batch made and I
> > believe the command line syntax may be different so there may be gotchas
> > waiting.
>
> We've already covered that David - batch rotations do not work either with
> AE on or off. This is with JPEGTools (jpegtran and djpeg) from the website
> you have given above. Checked on ROM 5.19 (16-Dec-12).

This is what prompted me to have another look with the latest ROM :-

http://www.riscosopen.org/forum/forums/2/topics/1621

--
David Pitt

[Richard Ashbery]

In article <mpro.mh4bov00...@pittdj.co.uk>, David Pitt

Good point.

I've tried this with Absolutely, V1.03 but only on ROM 5.19
(16-Dec-12). I'll get round to updating before long but in the
meantime if you have the latest ROM build would you be so good as to
check if auto-rotate works (with AE on and off). A good test is to
drag a directory containing one or two jpeg images* over Variations
iconbar icon which opens thumbnail display. Select image(s) (showing
rotation arrow) and then click relevant Rotate icon (bottom left of
toolbar). If it works correctly the rotated jpeg will overwrite the
original.

* taken with camera titled on side

Regards

Richard

[David Pitt]

Richard Ashbery, on 24 Jan, wrote:

> In article <mpro.mh4bov00...@pittdj.co.uk>, David Pitt
> <ne...@pittdj.co.uk> wrote:

[snip - Use of latest Beagle ROM]

> > This is what prompted me to have another look with the latest ROM :-
>
> > http://www.riscosopen.org/forum/forums/2/topics/1621
>
> Good point.
>
> I've tried this with Absolutely, V1.03 but only on ROM 5.19 (16-Dec-12).
> I'll get round to updating before long but in the meantime if you have the
> latest ROM build would you be so good as to check if auto-rotate works
> (with AE on and off). A good test is to drag a directory containing one or
> two jpeg images* over Variations iconbar icon which opens thumbnail
> display. Select image(s) (showing rotation arrow) and then click relevant
> Rotate icon (bottom left of toolbar). If it works correctly the rotated
> jpeg will overwrite the original.
>
> * taken with camera titled on side

The bad news is that auto-rotate does require Alignment Exceptions to be
Off. There would appear to be other issues for !Variation on the ARMini, the
latest Beagle ROM does appear to permit the use of ARMv7 jpeg tools but does
not magically fix anything else. Oh well, it was worth a try.


--
David Pitt

[Richard Ashbery]

In article <mpro.mh4zwi00...@pittdj.co.uk>, David Pitt

<ne...@pittdj.co.uk> wrote:
> Richard Ashbery, on 24 Jan, wrote:

> > In article <mpro.mh4bov00...@pittdj.co.uk>, David Pitt
> > <ne...@pittdj.co.uk> wrote:

> [snip - Use of latest Beagle ROM]

> The bad news is that auto-rotate does require Alignment Exceptions
> to be Off.

Have I understood you correctly? With the latest ROM incorporating the
'Absolutely' module auto-rotate works correctly and without error with
AE off.

The reason I'm asking is that I promised to send any useful info back to
Rob Davison although this is rather academic since Rob hasn't got an
ARMv7 system to troubleshoot !Variations.

> There would appear to be other issues for !Variation on
> the ARMini, the latest Beagle ROM does appear to permit the use of
> ARMv7 jpeg tools but does not magically fix anything else. Oh well,
> it was worth a try.

Richard

[David Pitt]

Richard Ashbery, on 25 Jan, wrote:

> In article <mpro.mh4zwi00...@pittdj.co.uk>, David Pitt
> <ne...@pittdj.co.uk> wrote:
> > Richard Ashbery, on 24 Jan, wrote:
>
> > > In article <mpro.mh4bov00...@pittdj.co.uk>, David Pitt
> > > <ne...@pittdj.co.uk> wrote:
>
> > [snip - Use of latest Beagle ROM]
>
>
> > The bad news is that auto-rotate does require Alignment Exceptions to be
> > Off.
>
> Have I understood you correctly? With the latest ROM incorporating the
> 'Absolutely' module auto-rotate works correctly and without error with AE
> off.

Yes.

With Address Exceptions On the error is, "abort on data transfer at
&0009BE50 at code 2489". That line contains CALLLV%. I have not managed to
work out what is at LV% but there is other machine code within !Variation
which may not be ARMv7 compatible. If is a machine code issue then a
recompile may, or may not, be all that is required.

> The reason I'm asking is that I promised to send any useful info back to
> Rob Davison although this is rather academic since Rob hasn't got an ARMv7
> system to troubleshoot !Variations.

--
David Pitt

[Richard Ashbery]

In article <mpro.mh6mg500...@pittdj.co.uk>, David Pitt

<ne...@pittdj.co.uk> wrote:
> Richard Ashbery, on 25 Jan, wrote:

> > In article <mpro.mh4zwi00...@pittdj.co.uk>, David Pitt
> > <ne...@pittdj.co.uk> wrote:
> > > Richard Ashbery, on 24 Jan, wrote:
> >
> > > > In article <mpro.mh4bov00...@pittdj.co.uk>, David
> > > > Pitt <ne...@pittdj.co.uk> wrote:
> >
> > > [snip - Use of latest Beagle ROM]
> >
> >
> > > The bad news is that auto-rotate does require Alignment
> > > Exceptions to be Off.
> >
> > Have I understood you correctly? With the latest ROM
> > incorporating the 'Absolutely' module auto-rotate works correctly
> > and without error with AE off.

> Yes.

> With Address Exceptions On the error is, "abort on data transfer at
> &0009BE50 at code 2489".

In that case I am thoroughly flummoxed - we seem to be getting different
results. I'll upgrade to the latest ROM and do the test again.

> That line contains CALLLV%. I have not managed to work out what is at
> LV% but there is other machine code within !Variation which may not be
> ARMv7 compatible. If is a machine code issue then a recompile may, or
> may not, be all that is required.

Agreed!

Richard

[David Pitt]

Richard Ashbery, on 26 Jan, wrote:

> In article <mpro.mh6mg500...@pittdj.co.uk>, David Pitt
> <ne...@pittdj.co.uk> wrote:

[snip With Address Exceptions On the error is, "abort on data transfer at
&0009BE50 at code 2489".]

> > That line contains CALLLV%. I have not managed to work out what is at
> > LV% but there is other machine code within !Variation which may not be
> > ARMv7 compatible. If is a machine code issue then a recompile may, or
> > may not, be all that is required.
>
> Agreed!

I fear I have to disagree with myself to some extent. The machine code is
not compiled C so any issues would have to fixed the hard way in the source.

--
David Pitt

[Chris Johnson]

In article <mpro.mh8dg600...@pittdj.co.uk>,

David Pitt <ne...@pittdj.co.uk> wrote:
> I fear I have to disagree with myself to some extent. The machine
> code is not compiled C so any issues would have to fixed the hard
> way in the source.

Yes, there is a lot of Basic assembler in the !RunImage file, but
since it is heavily crunched there is no way one could see anything
obvious.

--
Chris Johnson

[C J Craig]

In message <mpro.mh1b4o007...@softrock.co.uk>

Vince M Hudd <vin...@softrock.co.uk> wrote:

> Tim Hill <t...@invalid.org.uk> wrote:

>> The late, lamented, Paul Vigay use always to use the RAM disc for his
>> !Scrap,

> Not just Paul. I had one of my RiscPCs set up to move Scrap to the RAM disc
> at boot. I've never bothered on any machine since, though.

I think it would be useful to do that on RISC OS Raspberry Pi. Or at
least put in on a USB stick..
How would I go about setting that up.
Thanks in anticipation

Chris

--
C J Craig

Ch...@skipton.demon.co.uk
Iyonix ARM XScale computer Risc OS 5.18

[Rob Davison]

Just to let anyone interested know, I've sent a modified !Runimage to
Richard and asked him to try it.

If the tweak fixes the problem I'll address one or two other small
outstanding issues and release a mild update to the program (assuming
I can still find the iconbar ftp password after nearly six years!)


Rob.
--
Maple Glen http://www.mapleglen.co.nz/
on Pbase http://www.pbase.com/mapleglen/
on Flickr http://www.flickr.com/photos/mapleglen/

[Vince M Hudd]

C J Craig <Ch...@skipton.demon.co.uk> wrote:
> In message <mpro.mh1b4o007...@softrock.co.uk>
> Vince M Hudd <vin...@softrock.co.uk> wrote:
> > Tim Hill <t...@invalid.org.uk> wrote:

> > > The late, lamented, Paul Vigay use always to use the RAM disc for his
> > > !Scrap,

> > Not just Paul. I had one of my RiscPCs set up to move Scrap to the RAM
> > disc at boot. I've never bothered on any machine since, though.

> I think it would be useful to do that on RISC OS Raspberry Pi. Or at least
> put in on a USB stick.. How would I go about setting that up. Thanks in
> anticipation

IIRC it was just a matter of putting an Obey file somewhere that will be run
when the computer is booted. That Obey file would copy the !Scrap directory
to the RAM disc, and then set up the system variables as necessary (which
might have been a case of running the !Scrap.!Run or !Scrap.!Boot file,
depending how they go about setting the variables up to start with).

However, it was a long time ago - mid-90s - and I'm explaining it from
memory without being anywhere near a RISC OS computer. The most obvious
thing that would be different now compared to then is that the Obey file can
be placed anywhere, and added to the relevant section of Configure so that
it is run at boot.

I didn't have it set up to copy back to the hard drive when the machine was
shutdown, so anything placed in Scrap during the session would be lost. I
stopped doing it when I began using Fresco, because I then wrote FresCache
to provide more control over what cached files were retained by the browser.

[C J Craig]

In message <mpro.mhc8ag005...@softrock.co.uk>

I was thinking of directing Scrap to a USB stick for RISC OS on a
Raspberry Pi it would then not be lost on power down but then do I
want to keep anything anyway? there must be an Obey file some where
that directs Scrap to a file in !Boot

[Jim Lesurf]

In article <mpro.mhc8ag005...@softrock.co.uk>, Vince M Hudd

<vin...@softrock.co.uk> wrote:


> IIRC it was just a matter of putting an Obey file somewhere that will be
> run when the computer is booted. That Obey file would copy the !Scrap
> directory to the RAM disc, and then set up the system variables as
> necessary (which might have been a case of running the !Scrap.!Run or
> !Scrap.!Boot file, depending how they go about setting the variables up
> to start with).

FWIW I just run an app I call "!RamScrap" during the bootup which just
containes the !Run file with contents

Copy ADFS::HardDisc4.$.!Boot.Resources.!Scrap RAM::RamDisc0.$.!Scrap
RF~C~V
Filer_Run RAM::RamDisc0.$.!Scrap

Seems to work fine. The only cavil is that changes to NetSurf may require
letting NetSurf re-establish is *non scrap* files in !Scrap.

[Vince M Hudd]

C J Craig <Ch...@skipton.demon.co.uk> wrote:

[...]

> I was thinking of directing Scrap to a USB stick for RISC OS on a
> Raspberry Pi it would then not be lost on power down but then do I want to
> keep anything anyway?

Some applications hold information in Scrap that can be useful from one
session to another - your web browser cache, for example. But that aside, I
don't think moving Scrap to another location such as a USB stick (which
sounds like you mean permanently, rather than when the machine boots) is a
particularly good idea. For one thing, it'll cause problems if the USB stick
isn't plugged in, or is simply dislodged slightly.

I suppose one way around that might be to arrange things so that you have a
Scrap still in Boot, and the one on the USB stick overrides it only if it is
seen - that way, if it isn't seen, you still have a working Scrap.

> there must be an Obey file some where that directs Scrap to a file in
> !Boot

The !Boot/!Run files found within the !Scrap application directory (which
itself lives in !Boot.Resources) will set up the necessary system variables
so that your computer knows where it is found.

[Ron]

In message <5315244...@audiomisc.co.uk>

Jim Lesurf <no...@audiomisc.co.uk> wrote:

> In article <mpro.mhc8ag005...@softrock.co.uk>, Vince M Hudd
> <vin...@softrock.co.uk> wrote:
>
>
> > IIRC it was just a matter of putting an Obey file somewhere that will be
> > run when the computer is booted. That Obey file would copy the !Scrap
> > directory to the RAM disc, and then set up the system variables as
> > necessary (which might have been a case of running the !Scrap.!Run or
> > !Scrap.!Boot file, depending how they go about setting the variables up
> > to start with).
>
> FWIW I just run an app I call "!RamScrap" during the bootup which just
> containes the !Run file with contents
>
> Copy ADFS::HardDisc4.$.!Boot.Resources.!Scrap RAM::RamDisc0.$.!Scrap
> RF~C~V
> Filer_Run RAM::RamDisc0.$.!Scrap
>
> Seems to work fine. The only cavil is that changes to NetSurf may require
> letting NetSurf re-establish is *non scrap* files in !Scrap.
>
> Slainte,
>
> Jim
>

That sounds like a good way to do it.
!Scrap is portable in the sense that it sets the Wimp$ScrapDir variable
relative to it's <Obey$Dir>.
It would be a better !Boot configure option to set a destination for
!Scrap, rather than just RAM.
It would have to fallback if the configured !Scrap address doesn't
exist, for example, the usb drive it was last on has been removed or
hasn't been mounted yet. Perhaps it would also need to try to mount
the configured !Scrap drive as well.


One thing, I think you could use the N(ewer) switch with copy so
that you aren't copying the older !Scrap contents un-neccessarily
when using persistent media (not RAM).

Ron M.

[C J Craig]

In message <be055f1...@ron1954.woosh.co.nz>

My thought was to stop the Raspberry Pi's Boot SD getting jammed up
and overflowing with Scrap, Newsdir, Transient, Netsurf and Photodesk.
Scrap files grow like topsy when you are not looking.
I am not sure what would happen if !Scrap was not found.. !Boot
failure?

[Vince M Hudd]

C J Craig <Ch...@skipton.demon.co.uk> wrote:
> > In message <5315244...@audiomisc.co.uk>
> > Jim Lesurf <no...@audiomisc.co.uk> wrote:
> > > In article <mpro.mhc8ag005...@softrock.co.uk>, Vince M
> > > Hudd <vin...@softrock.co.uk> wrote:

[...]

> > > FWIW I just run an app I call "!RamScrap" during the bootup which just
> > > containes the !Run file with contents

[snip contents]

Pretty much what I said, then, but with actual details rather than vague
recollections. :)

> My thought was to stop the Raspberry Pi's Boot SD getting jammed up and
> overflowing with Scrap, Newsdir, Transient, Netsurf and Photodesk. Scrap
> files grow like topsy when you are not looking. I am not sure what would
> happen if !Scrap was not found.. !Boot failure?

I don't think boot would fail - but if Scrap hasn't been seen, it might
cause problems for some applications.

[Harriet Bazley]

On 27 Jan 2013 as I do recall,

Rob Davison wrote:

> Just to let anyone interested know, I've sent a modified !Runimage to
> Richard and asked him to try it.
>
> If the tweak fixes the problem I'll address one or two other small
> outstanding issues and release a mild update to the program (assuming
> I can still find the iconbar ftp password after nearly six years!)
>

Is there any chance of finding the issue affecting 'brush' tools
(editing and mask application)?

Currently I am dependent on the 'magic wand' tool to apply any mask, but
if this overflows into unwanted areas it is very difficult to remove
entirely without the brush tool
(Internal error: undefined instruction at &FC17D47E code 4794)

while it is impossible to use the invaluable clone tool in edit mode -
areas can be selected, but not pasted back into the picture
(Internal error: undefined instruction at &FC17D47E code 4959)

I assume it is the same issue in both cases.

--
Harriet Bazley == Loyaulte me lie ==

Equal bytes for women.