Quick JPEG browser/editor?
Andy Burgess
I was the originator of the orginal News message, and it's taken me this
long to look through the masses of feedback and other threads that had
been started by my posting.
I've downloaded all the suggested software, and have to add the following
further clarification of my initial question:
What I wanted to do was to be able to display pictures quickly on the
screen from a !Thump window; either by drag-dropping into another
application (I'm currently using FYEO), and I had become disenchanted with
Thump because it had forgotten my thumbnails.
Thump - I've set up the Cache option for Thumbnails to never expire
(thanks to help here), but I think it still forgot them (I do **believe**
I regenerated them all). I use ZIPFS 250MB discs for my photographs -
would this be an issue, or have I really not regenerated my thumbnails?
Browsing pictures - I have used !SwiftJPEG before, and am **amazed** at
the speed it loads a 'true' JPEG. However, it doesn't work with my
camera's images (downloaded direct from camera through the very wonderful
Surftec's Digiflash!). Having run ExifInfo, I can now say the following
about my camera's images (and I can also sound like a pro - quoting
exposure f-stop, focal length etc! - should I want to bore people):
Camera : C2, D230
Size : 1600x1200 pixels
Filesize : 383-384 Kbytes
Exposure : 1/250 sec at ISO100
f : 5.60
Focal length: 5.50mm
Bias : 0
Program : Normal
Metering : Pattern
Flash : Fired or Not Fired
Orientation : x0,y0=left,top
Compression : 2
JPEG Quality: HQ (High Quality)
Spec. Mode : Normal
Macro : Off
Digital Zoom: 1
Software : SR37 [Pictureinfo]Resolution=2[Camera Info]
PictureInfo : Type SR973
Camera ID : Olympus Digital Camera
It's an Olympus C2 camera. I'd also like to be able to rotate some
pictures quickly, and save this back in the right format (portrait) to my
ZIP drive. I intend to print some photos off onto photographic paper, and
would like to reduce the time I take to peruse the images.
In summary - what I'd like to do:
* Use SwiftJPEG to display these pictures on the screen - quickly. FYEO is
quite swift, but when you've a lot of pictures to look at ....
* Be able to rotate (and ideally remove the extraneous info from the
photos) - so that I can see my pictures quickly in the right format on the
screen, ideally through SwiftJPEG. ImageMaster takes an enternity to load
and save these large-format pictures. FYEO is good, but it's not as quick
as SwiftJPEG.
* I want to prove to my PC brethren that my Acorn is better for pictures,
but so far I can't! It's embarassing when Thump had to recalculate all the
thumbnails, and made my Acorn look second-rate (I know it isn't)!
The software suggested as browsers, whilst looking very impressive refused
to handle my pictures, and Makoto insisted on changing the file type to
Data! I know I could change this in Makoto, but it was frustrating!
Andy Burgess
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | /
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ ajbu...@argonet.co.uk
druck
> Browsing pictures - I have used !SwiftJPEG before, and am **amazed** at
> the speed it loads a 'true' JPEG. However, it doesn't work with my
> camera's images (downloaded direct from camera through the very wonderful
> Surftec's Digiflash!).
[Snip]
> * Use SwiftJPEG to display these pictures on the screen - quickly. FYEO is
> quite swift, but when you've a lot of pictures to look at ....
The problem is programs such as SwiftJPEG and Thump wont pass Exif JPEG's
from cameras to the fast OS plotting routines, and instead send then through
the slower JPEGtrans program.
The solution is to use David Dacha's excellent !JClean which can be found at
http://www.dacha.freeuk.com/ This strips the exif infor and allows the fast
OS routines.
> * Be able to rotate (and ideally remove the extraneous info from the
> photos) - so that I can see my pictures quickly in the right format on the
> screen, ideally through SwiftJPEG. ImageMaster takes an enternity to load
> and save these large-format pictures. FYEO is good, but it's not as quick
> as SwiftJPEG.
!JClean also has the facility to losslessly rotate the pictures, however the
version of the JPEG routines in the OS before RISC OS Select will not display
rotated camera pictures correctly (the it handles 8x8 and 8x16, but not 16x8
blocks). There is a patch for the module (do a google groups search), or
alternatively use !ChangeFSI or !PhotoDesk to rotate the image and save backs
as JPEG with 85% to 90% to maintain approximately the same quality (but with
a small loss).
---druck
--
The ARM Club * http://www.armclub.org.uk/
Dave Wisnia
>
>I was the originator of the orginal News message, and it's taken me this
>long to look through the masses of feedback and other threads that had
>been started by my posting.
>Browsing pictures - I have used !SwiftJPEG before, and am **amazed** at
>the speed it loads a 'true' JPEG.
snipped
>
>Andy Burgess
>
Textease is the fastest at displaying JPEGs. It is a shame that you
can't drop your JPEGs onto Presenter - Textease says you can, but you
can't on the RISCOS version.
--
Dave Wisnia
Ian Lowry
Dave Wisnia <ds...@freeuk.com> wrote:
[snip]
> Textease is the fastest at displaying JPEGs. It is a shame that you
> can't drop your JPEGs onto Presenter - Textease says you can, but you
> can't on the RISCOS version.
Works here. 5.83
Ian
--
"Bother", said Pooh, as he saw "Filecore in use."
Dave Wisnia
> Dave Wisnia <ds...@freeuk.com> wrote:
>
>[snip]
>
>
>> Textease is the fastest at displaying JPEGs. It is a shame that you
>> can't drop your JPEGs onto Presenter - Textease says you can, but you
>> can't on the RISCOS version.
>
>Works here. 5.83
>
>Ian
--
Dave Wisnia
A.Hodgkinson
<URL:mailto:ajbu...@argonet.co.uk> wrote:
> Browsing pictures - I have used !SwiftJPEG before, and am **amazed** at
> the speed it loads a 'true' JPEG. However, it doesn't work with my
> camera's images [...]
SwiftJPEG uses the fast JPEG routines built into the OS. In RISC OS
3.6 through 4.03, these don't cope with many JPEG types. Select 1 I
believe extends things a bit, and Select 2 extends things further -
you should be able to view the JPEGs using that, e.g. by loading
them into !Paint.
If you wanted to use SwiftJPEG you'd probably still need a newer
version than 1.01. I got part way through doing this then got busy.
1.01 and earlier are very strict about which JPEGs they'll accept as
some earlier OS versions crashed with JPEGs they didn't understand,
so SwiftJPEG tried to never display them accidentally. This check is
relaxed for RISC OS 4 upwards in the new version.
I don't know what plotting capabilities RISC OS 5 has.
--
TTFN, Andrew (on behalf of myself, not my employer).
"Hold tight, lad, and think of Lancashire Hotpot!" - A Grand Day Out
druck
> SwiftJPEG uses the fast JPEG routines built into the OS. In RISC OS
> 3.6 through 4.03, these don't cope with many JPEG types. Select 1 I
> believe extends things a bit, and Select 2 extends things further -
> you should be able to view the JPEGs using that, e.g. by loading
> them into !Paint.
>
> If you wanted to use SwiftJPEG you'd probably still need a newer
> version than 1.01. I got part way through doing this then got busy.
> 1.01 and earlier are very strict about which JPEGs they'll accept as
> some earlier OS versions crashed with JPEGs they didn't understand,
> so SwiftJPEG tried to never display them accidentally. This check is
> relaxed for RISC OS 4 upwards in the new version.
>
> I don't know what plotting capabilities RISC OS 5 has.
As per RISC OS 4.
Brian Carroll
A.Hodgkinson <andrew.h...@pace.co.uk> wrote:
[Snip]
> SwiftJPEG uses the fast JPEG routines built into the OS. In
> RISC OS 3.6 through 4.03, these don't cope with many JPEG
> types. Select 1 I believe extends things a bit, and Select 2
> extends things further - you should be able to view the JPEGs
> using that, e.g. by loading them into !Paint.
I see that the jpeg routines dated Nov 2001 are in now in
!Boot.Library.Graphics rather than ChangeFSI (Select 1, RO 4.29).
Are these used by SwiftJPEG v1.01? It seems to work very well.
> If you wanted to use SwiftJPEG you'd probably still need a
> newer version than 1.01. I got part way through doing this
> then got busy. ...
Is there any liklihood that you might find the time? ....
Please.
Brian.
--
______________________________________________________________
Brian Carroll, Ripon, North Yorkshire, UK br...@argonet.co.uk
______________________________________________________________
Malcolm Ripley
news:4b9e054cc...@argonet.co.uk...
report this week for the interest of those folks who downloaded the HTML
only pre-release version. However, quick FYI related to the above, the full
version will allow you to drag any image (sprite, draw , jpeg , exif) to the
icon
bar and displays it in a window showing any embedded tag details it finds.
It
uses the SpriteExtend JPEG module to do this for jpegs ( OK so it copies the
Exif files, modifies the header and then uses the JPEG module !!). A
catalogue can be built of existing images which preserves all thumbnails it
builds and allows the Exif style tags to be applied to any image. If you
have
ImageFS running then all filetypes recognised by that will also be handled.
If
ChangeFSI is booted then all filetypes recognised by that will also be
handled.
This is all complete.
I'm currently working on the format of the thumbnail viewer (bit of a pain!)
and
the copy of images from one view to another which will also convert
filetypes
at the same time :-). Copied files will inherit their parents catalogue
(tag)details.
It had crossed my mind to add transformations of jpegs as part of a copy
since
it seems trivial to implement, in theory ! It also solves the issue of
copying
a portrait original Exif to a viewable jpeg. I have a few of those :-/
I expect this all to be done for Xmas, work and xmas shopping permitting.
regards,
Malcolm
Rick Hudson
Andy Burgess <ajbu...@argonet.co.uk> wrote:
> Thump - I've set up the Cache option for Thumbnails to never expire (thanks
> to help here), but I think it still forgot them (I do **believe** I
> regenerated them all). I use ZIPFS 250MB discs for my photographs - would
> this be an issue, or have I really not regenerated my thumbnails?
You know, Thump is not a thumbnail archiver - there are apps out that
designed for this. Thump is a directory /browser/ and the caching ability is
just a convenience. It's not supposed to remember thumbnails for ever.
> Browsing pictures - I have used !SwiftJPEG before, and am **amazed** at the
> speed it loads a 'true' JPEG.
Would somebody please explain to me how SwiftJPEG can be faster than any
other JPEG renderer that uses the OS renderer?
--
Rick Hudson
http://homepages.paradise.net.nz/rhudson/ rhu...@paradise.net.nz
http://www.kpo.org.nz/ ri...@kpo.org.nz
David Atkins
druck <ne...@druck.freeuk.com> wrote:
Hi David,
But isn't RISC OS 4 licenced from RISCOS Limited, which in turn is Licenced
from Pace Micro Technology plc - the owner - what's RISC OS 5 and where's
that licenced from?
--
--
David Atkins
Managing Director
MicroDigital Limited, 37 Titus Street, Saltaire, Shipley, West Yorks, BD18 4LU.
Tel: +44 (0)274 618774 Fax: +44 (0)274 619482
Email: mailto:da...@microdigital.co.uk Web: http://www.microdigital.co.uk
MicroDigital Mico and Omega Computers - Powered by ARMŽ and IntelŽ Technology
Operating system - RISC OSŽ Built by RISCOS Limited
RISC OS is a trademark of Pace Micro Technology plc
ARM is a registered trademark of ARM Limited
Intel is a registered trademark of the Intel Corporation
This message and any attachments are intended only for the use of the addressee.
It may contain information which is privileged and confidentail within the
meaning of applicable law. If you are not the intended recipient, please contact
the sender as soon as possible and delete the message. You must not disclose,
forward or copy the mesage or its attachments to any third party.
--------------------------------------------------------------------------------
druck
> In message <2b79c39e...@druck.freeuk.net>
> druck <ne...@druck.freeuk.com> wrote:
>> On 2 Dec 2002 "A.Hodgkinson" <andrew.h...@pace.co.uk> wrote:
>>> I don't know what plotting capabilities RISC OS 5 has.
>>
>> As per RISC OS 4.
>
> Hi David,
>
> But isn't RISC OS 4 licenced from RISCOS Limited, which in turn is Licenced
> from Pace Micro Technology plc - the owner - what's RISC OS 5 and where's
> that licenced from?
I have no idea about licensing, not my department.
The information I am providing is that the OS JPEG rendering in RISC OS 5 is
equivelent to that in RISC OS 4, rather than the enhanced version in Select.
Even more reason to lobby for Select for RO5.
A.Hodgkinson
<URL:mailto:rhu...@paradise.net.nz> wrote:
> Would somebody please explain to me how SwiftJPEG can be faster than any
> other JPEG renderer that uses the OS renderer?
It uses magic.
(Either that, or it's eye-catching, super-funky icon distracts
people whilst images are loading, and since time flies when you're
having fun...)
A.Hodgkinson
<URL:mailto:br...@argonet.co.uk> wrote:
> I see that the jpeg routines dated Nov 2001 are in now in
> !Boot.Library.Graphics rather than ChangeFSI (Select 1, RO 4.29).
> Are these used by SwiftJPEG v1.01? It seems to work very well.
Nope, it'd be clumsy to call them from BASIC and it defeats the
point of using SwiftJPEG. You may as well use ChangeFSI.
> Is there any liklihood that you might find the time? ....
I've got somewhere on this. I still need to do more testing on
an A5000. I've also done a modify-on-load that lets it handle
EXIF images (digital camera output) on pre-RISC OS 4 rendering
modules, along with certain unidentified images (the thumbnails
from ExifInfo, in particular). It also occurred that I might
be able to implement some sort of Rotate function on the front
end if it involves only value changes rather than size changes
in the header, but I don't think that's the case - apart from
anything else, rotated images produced by JPEGTran do *not*
plot properly with the RISC OS 3.7 JPEG routines (you get a
sort of screen door effect).
Reading ahead, I see that Malcolm Ripley's thought of this too!
How annoying - I was feeling really smug about side-stepping the
OS inability to do EXIF images! Oh well. It's typical, isn't it;
you wait ages for an application to come along that'll do it,
then two arrive at once...
David
A.Hodgkinson <andrew.h...@pace.co.uk> wrote:
[Snip]
> in the header, but I don't think that's the case - apart from
> anything else, rotated images produced by JPEGTran do *not*
> plot properly with the RISC OS 3.7 JPEG routines (you get a
> sort of screen door effect).
Change byte &00005C60 of the SpriteExtend 1.04 module from &0C to &10.
--
http://www.dacha.freeuk.com/penny/1d-01.htm
Matron took an anticipatory sip of her Madeira and wished
that she hadn't laced the sexy Basque bodice quite so tightly.
Brian Carroll
[Snip]
> > Is there any liklihood that you might find the time? ....
> I've got somewhere on this. I still need to do more testing on
> an A5000. ...
[Snip]
> Reading ahead, I see that Malcolm Ripley's thought of this
> too! How annoying - I was feeling really smug about
> side-stepping the OS inability to do EXIF images! Oh well.
> It's typical, isn't it; you wait ages for an application to
> come along that'll do it, then two arrive at once...
Thanks for this news, Andrew. As a (fairly newbie) digicam user
I greatly welcome the ability to use EXIFs.
The more buses the better for users like me. But as I gather
more possible applications to deal with a rapidly growing pile of
picture files I just have more excuses to delay instituting a
properly thought out system to manage them :-)