Digital Camera RAW files - dcraw
Martin Hodgson
save its files in RAW format.
In 2003 Chris Terran published his RISC OS port of Dave Coffin's "dcraw"
utility (v. 4.88 from www.cybercom.net/~dcoffin/dcraw/), which reads and
manipulates RAW files from many cameras. I have this port. It does not
include support for the 450D. The current version 8.87 does support the
450D.
dcraw is written in ANSI C. As a hobby programmer who never went beyond
BASIC, I am trying to compile it on my Iyonix with RISC OS 5.13.
I have !gcc with all options from the riscos.info site. According to Mr.
Coffin dcraw should simply compile - just like that. Compiled versions are
available for Windows and Mac, so it does work.
When I run !gcc on dcraw I get a screenful of errors (undeclared
variables, and variable's sizes not set). Some of the variables (the
CLASSES in D.C.'s terminology) I can just add to the header declarations
myself. Others I do not even know what kind of variable they are.
There was some discussion, similar to all this, a year or so back. It
seemed to fizzle out on the newsgroups.
Did anyone discover how to compile dcraw on RISC OS ? Chris Terran did it
in 2003. Chris even added the ability to output 24 bit Sprite files.
Is anyone prepared to compile dcraw now ? Or help a poor novice do it ?
Please !
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> dcraw is written in ANSI C. As a hobby programmer who never went
> beyond BASIC, I am trying to compile it on my Iyonix with RISC OS
> 5.13. I have !gcc with all options from the riscos.info site.
> According to Mr. Coffin dcraw should simply compile - just like that.
> Compiled versions are available for Windows and Mac, so it does work.
I've managed to build it in the past. It's a pretty scary ANSI C
program, and it can take a while to build. It will stress the C
compiler to almost breaking point.
More fundamentally, unless you have a very fast machine, I would not
try to run dcraw under RISC OS. It will take a /long/ time to process
each image due to heavy use of floating point and large amounts of
memory.
However, here is a zip file containing dcraw 8.88 compiled for both
ARMv4 (all machines except the Iyonix) and ARMv5 (the Iyonix);
http://www.rjek.com/dcraw_riscos_888.zip
It is completely untested. Built using the toolchain we use to build
NetSurf from UNIX.
B.
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> In a dim and distant universe <4fe9748794...@freeuk.com>,
> Martin Hodgson <marth...@freeuk.com> enlightened us thusly:
> > In 2003 Chris Terran published his RISC OS port of Dave Coffin's
> > "dcraw" utility (v. 4.88 from www.cybercom.net/~dcoffin/dcraw/),
> > which reads and manipulates RAW files from many cameras. I have
> > this port. It does not include support for the 450D. The current
> > version 8.87 does support the 450D.
>
> Do you know if Chris's version is still available to download
> anywhere? Did he include the source code? If so, it might be easier
> to re-compile using his original RISC OS Make files - as I've found
> the linking and make files are the most complicated part of porting
> third-party stuff.
Assuming you have the libraries, compiling dcraw is a case of;
gcc -o dcraw dcraw.c -ljpeg -llcms
The version I built and posted a link to earlier doesn't have JPEG
output enabled (what's the point?) and my only change was to get it to
use a dynamic area for memory so it can run on ROL's RISC OS. (A 10MP
image requires around 100MB of RAM to process.)
B.
Martin Hodgson
> http://www.rjek.com/dcraw_riscos_888.zip
> B.
Rob, what an incredible response ! Thank you very much indeed.
I tried running the Iyonix version (on my Iyonix, with 512 MB of RAM, of
which 100MB was allocated to the Next slot).
Simply letting it loose on an 18.5MB Canon RAW file, without any options
set resulted in it crashing out with a Segmentation fault. Setting the -T
option (for TIFF output) gave the same error, as you might expect.
I have saved the error report.
However, setting the -e option (to extract the embedded JPEG file) worked
like magic, doing the job in a very few seconds.
So there is something there to play with. I will go away for a while to
play with the various options to see what else I can get out of this.
In particular I think I will try to procure some smaller, less detailed
RAW files from somewhere. It might be useful to see what happens then.
Hitting it with 18MB for the first try might be a bit unfair.
Martin Hodgson
Steve Fryatt
<4fe98b38d0...@freeuk.com>:
> Rob, what an incredible response ! Thank you very much indeed.
>
> I tried running the Iyonix version (on my Iyonix, with 512 MB of RAM, of
> which 100MB was allocated to the Next slot).
>
> Simply letting it loose on an 18.5MB Canon RAW file, without any options
> set resulted in it crashing out with a Segmentation fault. Setting the
> -T option (for TIFF output) gave the same error, as you might expect. I
> have saved the error report.
How are you calling it? If you're running it from a task window, you need
to make sure that the task window has 100MB in its slot: that means that
Next must be set to 100MB (or whatever) /before/ you open the task window.
--
Steve Fryatt - Leeds, England
Martin Hodgson
The answers are yes, yes, and yes.
Actually I have tried Next slots of (just over) 100MB, 200MB and 300MB,
all giving the same error report.
With Next at 409MB the program complained about lack of memory !
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> > How are you calling it? If you're running it from a task window,
> > you need to make sure that the task window has 100MB in its slot:
> > that means that Next must be set to 100MB (or whatever) /before/
> > you open the task window.
>
>
> The answers are yes, yes, and yes.
>
> Actually I have tried Next slots of (just over) 100MB, 200MB and
> 300MB, all giving the same error report.
>
> With Next at 409MB the program complained about lack of memory !
Firstly, it's compiled to use dynamic areas. So having all available
memory in the next slot will mean there's none available for the DA.
Secondly, have you tried using both the ARMv3 and ARMv5 versions of
dcraw?
Thirdly, I've had somebody test it with this image (taken from an EOS
400D) - this this also crash for you?
http://www.rjek.com/test-image.cr2
B.
Martin Hodgson
Rob Kendrick <nn...@rjek.com> wrote:
> On Sun, 05 Oct 2008 17:02:23 +0100
> Martin Hodgson <marth...@freeuk.com> wrote:
> Secondly, have you tried using both the ARMv3 and ARMv5 versions of
> dcraw?
Yes
> Thirdly, I've had somebody test it with this image (taken from an EOS
> 400D) - this this also crash for you?
> http://www.rjek.com/test-image.cr2
> B.
I take from your email that this build of dcraw /does/ work with the
test-image.cr2 file from an EOS 400D on somebody else's machine.
When I try it here with either the ARM3 or the ARM5 versions, and my 512MB
of RAM shared equally between the Next and Free slots, I get the same
Segmentation error, and pretty much the same error reports.
I can extract the embedded JPEG (using the -e switch), and the EXIF data
(with -i -v), but that is all.
I can't even test Chris Terran's old port on the file - it reports that
"dcraw does not yet support EOS 400D".
All this is on an Iyonix, RISC OS 5.13, 512MB RAM, clean fresh start and
nothing running except the usual RISC OS things such as Internet, plus
HID, Gamma, Druck's DA Limit in Boot.Choices.Boot PreDesk and Tasks.
Time to start removing a few things to see what happens. DALimit might be
the first to go.
I will report progress, or lack of it, when I have something useful to say.
Many thanks for all your help this far.
Martin Hodgson
Evan Clark
Martin Hodgson <marth...@freeuk.com> wrote:
> All this is on an Iyonix, RISC OS 5.13, 512MB RAM, clean fresh start and
> nothing running except the usual RISC OS things such as Internet, plus
> HID, Gamma, Druck's DA Limit in Boot.Choices.Boot PreDesk and Tasks.
> Time to start removing a few things to see what happens. DALimit might
> be the first to go.
Works for me on Rob's test image, also using RISC OS 5.13, 512MB RAM,
HID, Gamma, and DAlimit.
Next is set to 9600K
DAlimit is set to:
SYS "OS_DynamicArea",8,128*1024*1024,256*1024*1024,128*1024*1024
Evan.
Martin Hodgson
> http://www.rjek.com/test-image.cr2
I have now stripped !Boot.Choices.Boot down to bare essentials :
nothing in Choices except the two directories PreDesk and Tasks.
In PreDesk I had :
!!!!SoftSCSI
!+Resource
!Country
DismntFix
FilerSA
NewLook
Configure Dir containing !Run, Monitor
SaveAs Dir containing !Run, SaveAs
In Tasks were :
!FilerHRun
FlrSetup
PinSetup
ScrnSetup
Running dcraw for ARM3 or ARM5 gave the same Segmentation fault as before,
with Next slot at 150MB.
So I re-instated Boot as it was and ran dcraw_armv5 on test-image.cr2
again.
The resulting error report follows (I almost know this off by heart now) :
*dcraw_armv5 test-image.cr2
Fatal signal received: Segmentation fault
Stack backtrace:
Running thread 0x7b058
( 9787efc) pc: 3a718 lr: 3f4ec sp: 9787f00 __write_backtrace()
( 9787fa0) pc: 3f04c lr: 79ff4 sp: 9787fa4
__unixlib_raise_signal()
( 9787fb0) pc: 79f04 lr: 6100736c sp: 9745bf8 __h_cback()
Register dump at 09787fb4:
a1: c710d814 a2: 661064a8 a3: 6100736c a4: 0
v1: 4b v2: 7a490 v3: 7bf34 v4: 7bf00
v5: 1a0008 v6: 7bf04 sl: 9745008 fp: 9745c6c
ip: 2 sp: 9745bf8 lr: 6100736c pc: 15024
cpsr: 20000010
00015010 : .0 ã : e3a03000 : MOV R3,#0
00015014 : .0‰å : e5893000 : STR R3,[R9,#0]
00015018 : . ‘å : e5912004 : LDR R2,[R1,#4]
0001501c : .àÂã : e3c2e001 : BIC R14,R2,#1
00015020 : .. à : e081000e : ADD R0,R1,R14
00015024 : .0 å : e5903004 : LDR R3,[R0,#4]
00015028 : ...ã : e3120001 : TST R2,#1
0001502c : .@Ãã : e3c34003 : BIC R4,R3,#3
00015030 : .Pۈ : e0805004 : ADD R5,R0,R4
( 9745c6c) pc: 15344 lr: 16174 sp: 9745c70 malloc_unlocked()
( 9745c84) pc: 16148 lr: 4a754 sp: 9745c88 malloc()
( 9786f68) pc: 4a5ec lr: b024 sp: 9786f6c ?()
( 9786fe0) pc: 5f330 lr: 2c858 sp: 9786fe4 ?()
( 9786ff0) pc: 2c834 lr: ab14 sp: 9786ff4 _main()
*
Apologies for this long missive, but I hope something there rings a bell
or two.
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> In article <20081005174...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
> > On Sun, 05 Oct 2008 17:02:23 +0100
> > Martin Hodgson <marth...@freeuk.com> wrote:
>
>
> > Thirdly, I've had somebody test it with this image (taken from an
> > EOS 400D) - this this also crash for you?
>
> > http://www.rjek.com/test-image.cr2
>
> I have now stripped !Boot.Choices.Boot down to bare essentials :
> nothing in Choices except the two directories PreDesk and Tasks.
Sorry, I have no idea :( This is not helped by the only machine I have
to hand being RPCemu - on which it runs, although I gave up letting it
run after two hours of attempting to process!
I'll see if I can set up my A9 Home over the coming week to
investigate further.
B.
Rob Kendrick
Evan Clark <ev...@ejclark.fsnet.co.uk> wrote:
> Works for me on Rob's test image, also using RISC OS 5.13, 512MB RAM,
> HID, Gamma, and DAlimit.
Out of interest, how long did it take? I'm pretty sure it's not going
to be especially useful if you're like me and you go and and take 300
shots.
B.
Martin Hodgson
> Evan.
That's the same DALimit entry that I have. Anyway I cut and pasted your
line above into the file and commented out the one I use. Then re-booted
and set Next to 9600MB.
Result - as always : "Segmentation error" when dcraw 3 or 5 are run.
So there is something odd about my particular machine. I bought it in
October 2003, with the hardware mods that CTL had introduced. It has all
the original bits, such as the 32MB video board and the RAM. Only the DVD
drive is not original. So far I have had absolutely none of the odd
problems that various other people have had in the past.
Martin Hodgson
Evan Clark
Rob Kendrick <nn...@rjek.com> wrote:
> Out of interest, how long did it take?
About 7 minutes!
> I'm pretty sure it's not going to be especially useful if you're like
> me and you go and and take 300 shots.
Probably not ;-)
BTW, I had to perform a reset between my last post and repeating to check
the timing. I then twice got the same error as Martin with an almost
identical stack backtrace. After a further reset it ran without error.
Evan.
Evan Clark
Evan Clark <ev...@ejclark.fsnet.co.uk> wrote:
> BTW, I had to perform a reset between my last post and repeating to
> check the timing. I then twice got the same error as Martin with an
> almost identical stack backtrace. After a further reset it ran without
> error.
I have made further observations.
The resets are a red herring.
The problem seems to relate to translation of UNIX style/RISC OS style
pathnames, and occurs when the CSD is not set to the root directory.
The solution seems to be to use full pathnames for dcraw_armv5 and the
target file or put dcraw_armv5 in the library and use the full pathname
for the target file.
Evan.
Rob Kendrick
Evan Clark <ev...@ejclark.fsnet.co.uk> wrote:
> In article <20081005215...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> wrote:
>
> > Out of interest, how long did it take?
>
> About 7 minutes!
Interesting. That's actually longer than I was expecting. On hardware
similar to an A9 Home (400MHz S3C2440, Mobile SDRAM, PIO IDE), it only
takes 3.5 minutes.
B.
Martin Hodgson
> Evan.
That works here also. And processing Rob's test image also takes about 7
minutes.
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> > The solution seems to be to use full pathnames for dcraw_armv5 and
> > the target file or put dcraw_armv5 in the library and use the full
> > pathname for the target file.
>
> That works here also. And processing Rob's test image also takes
> about 7 minutes.
Excellent! If I have time this week, would you be open to doing some
more tests for me? Might as well attempt to fix this issue and submit
a workaround upstream.
Additionally, I'd love to find out why it takes an Iyonix over twice as
long as hardware similar to the A9 Home's running Linux, so I'd like to
add some timing information to find where the delay is.
B.
Martin Hodgson
> B.
Be delighted to do so.
Incidentally, I note Chris Terran's port from 2003 requires one to use
RISC OS file naming conventions, not Unix ones, when calling dcraw.
Martin Hodgson
A.Lefevre
Martin Hodgson <marth...@freeuk.com> wrote:
[snip]
>Is anyone prepared to compile dcraw now ? Or help a poor novice do it ?
>
>Please !
>
>Martin Hodgson
>
This stirred something in the grey cells. I had a rummage and found that I
had downloaded dcraw-7/17-1/zip about three years ago. It was probably when
I bought a digital camera, but I've never looked at it. It was published by
John-Mark Bell, is dated May 2005. Quote:-
"This is a quick (and untested) compilation of dcraw for RISC OS"
The same source, dcoffin, is quoted.
Is this any use?
Alec Lefevre
--
Martin Hodgson
A.Lefevre <le...@freeuk.com> wrote:
> In message <4fe9748794...@freeuk.com>
> Martin Hodgson <marth...@freeuk.com> wrote:
> [snip]
[Snip]
> This stirred something in the grey cells. I had a rummage and found that I
> had downloaded dcraw-7/17-1/zip about three years ago. It was probably when
> I bought a digital camera, but I've never looked at it. It was published by
> John-Mark Bell, is dated May 2005. Quote:-
>
> "This is a quick (and untested) compilation of dcraw for RISC OS"
> The same source, dcoffin, is quoted.
> Is this any use?
> Alec Lefevre
It is certainly a much later version than Chris Terran's, but it will not
cover my camera, which was a new model this year.
Do you have an URL ? It might be of interest anyway.
Martin Hodgson
A.Lefevre
Martin Hodgson <marth...@freeuk.com> wrote:
Sorry, no URL. The file was sent from his email address at soton.ac.uk
I believe he is a contributor to NetSurf. Perhaps somebody else can help?
Alec Lefevre
--
Rob Kendrick
A.Lefevre <le...@freeuk.com> wrote:
> Sorry, no URL. The file was sent from his email address at
> soton.ac.uk I believe he is a contributor to NetSurf. Perhaps
> somebody else can help?
I suspect John-Mark, like I, just compiled the latest sources because
somebody asked here, and nothing else.
B.
John Tytgat
> It is certainly a much later version than Chris Terran's, but it will not
> cover my camera, which was a new model this year.
>
> Do you have an URL ? It might be of interest anyway.
Try: http://joty.drobe.co.uk/dcraw_softfloat_gccsdk4.zip
It's an equally quick and untested compilation of the latest source I
found (v8.88), compiled with GCCSDK 4 using softfloat settings (i.e.
avoiding FPU ARM instructions), no CPU/Arch tuning.
It really out to be put in riscos.info's Autobuilder instead of
supplying like this but my free time is scare at the moment.
John.
Martin Hodgson
John Tytgat <th...@is.invalid> wrote:
> Martin Hodgson wrote:
> Try: http://joty.drobe.co.uk/dcraw_softfloat_gccsdk4.zip
> It's an equally quick and untested compilation of the latest source I
> found (v8.88), compiled with GCCSDK 4 using softfloat settings (i.e.
> avoiding FPU ARM instructions), no CPU/Arch tuning.
> It really out to be put in riscos.info's Autobuilder instead of
> supplying like this but my free time is scare at the moment.
> John.
These two compilations of dcraw process Rob Kendrick's test-image in 2
minutes 45 seconds. Both versions (_O2 and _O3) seem to behave in an
identical manner. What is the significance of the two?
This is a vast improvement on the 7 minutes we had before.
Both compilations require Unix style file paths. That's OK, but has
implications - see below.
I am using Dave Watson's Frontender v. 2.0.5 (June 2003) to set up a
front end to dcraw, giving easy access to all the options. I can also set
it up to use Filer drag / drop operations - except that it does of course
enter RISC OS file paths, which dcraw rejects. Only Chris Terran's port in
2003 takes RISC OS conventions.
As things stand it is most realistic to put the file(s) into the root
directory and enter the file name manually.
Finally, using dcraw_O3 to process an 18MB image from my Canon 450D gives
a 36MB TIFF file. It was with trepidation I loaded this into Photodesk,
expecting to bring it to its knees !
Which it did, until I thought to increase the image cache (Iconbar menu ->
Preferences) from a measly 8MB to a sensible 50MB. Now Photodesk is as
lively as ever.
Does life get any better than this ?
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> These two compilations of dcraw process Rob Kendrick's test-image in 2
> minutes 45 seconds. Both versions (_O2 and _O3) seem to behave in an
> identical manner. What is the significance of the two?
The -O3 is optimised more, at the cost of the size of the program.
Sometimes this makes the program faster, sometimes not. (It's not
something the compiler can know in advance.)
> This is a vast improvement on the 7 minutes we had before.
Such are the joys of not using the floating point emulator!
> Does life get any better than this ?
Unfortunately, yes - my desktop takes 3 seconds to process my test
image. This is much more reasonable when you've been out and want to
view your 100s of shots! Not to mention that it's fast enough for
real-time thumbnailing etc.
B.
Martin Hodgson
> B.
Presumably you refere to your Wintel M/C.
Yes, your comments are absolutely true, but..
I dread connecting any camera to the Wintel - every damn graphics utility
I ever install tries to grab all the images off the camera, unless I have
remembered to used msconfig to disable them at startup.
For my wife's compact camera I always load the (JPEG) files /I/ want onto
the Iyonix, into logical directories. The failures are deleted in the
camera one way or the other . Then I use EXIFinfo to automatically
generate a Web page of thumbnails with summary shooting info. and with
links to the originals. Thump makes it easy to add comments etc.
That can then be transferred to, and viewed on, /any/ computer, including
a Wintel.
Try that in Photoshop Elements (Wintel) and I get a Flash based file,
unusable on RISC OS, and un-editable anywhere.
That is what I hope to do with the RAW+JPEG files my new Canon SLR
generates.
Converting all the RAW files at once on RISC OS will require some form of
script writing so the computer can chunter through a hundred or so files
(coming from the discipline of film, I tend not to shoot hundreds at a
time).
On the other hand, dcraw extracts the embedded JPEG files in a flash.
These JPEGs are more than adequate for run-of-the-mill prints and take up
relatively little disc space. The select few RAW files I deem worthy of
serious work can be left till another time. That might be the way to go -
I am still considering the options.
The one fly in the ointment is that my Iyonix currently refuses to
recognise the camera as a mass storage device, and it will not read the
card in my card reader - but that's a matter for another day.
ATM I am forced to switch on my games console (aka "High Powered Expensive
Wintel Beast") to at least grab the files off the camera . >:(
Martin Hodgson
Rob Kendrick
Martin Hodgson <marth...@freeuk.com> wrote:
> > > Does life get any better than this ?
>
> > Unfortunately, yes - my desktop takes 3 seconds to process my test
> > image. This is much more reasonable when you've been out and want
> > to view your 100s of shots! Not to mention that it's fast enough
> > for real-time thumbnailing etc.
> Presumably you refere to your Wintel M/C.
No. Any modern computer, even old PowerPC Macs will vastly outperform
RISC OS kit at this. (My desktop's an AMD-based Linux box. So neither
of the syllables of 'wintel' apply!)
> I dread connecting any camera to the Wintel - every damn graphics
> utility I ever install tries to grab all the images off the camera,
> unless I have remembered to used msconfig to disable them at startup.
Ah, I never connect the camera to the computer - I always pop the card
out and plug it into a dedicated media reader. I find this is a lot
faster.
B.
glavallin
Martin Hodgson <marth...@freeuk.com> wrote:
> In article <gcklmm$sa$1...@aioe.org>,
> John Tytgat <th...@is.invalid> wrote:
>> Martin Hodgson wrote:
>> Try: http://joty.drobe.co.uk/dcraw_softfloat_gccsdk4.zip
>> It's an equally quick and untested compilation of the latest source I
>> found (v8.88), compiled with GCCSDK 4 using softfloat settings (i.e.
>> avoiding FPU ARM instructions), no CPU/Arch tuning.
>> It really out to be put in riscos.info's Autobuilder instead of
>> supplying like this but my free time is scare at the moment.
>> John.
> These two compilations of dcraw process Rob Kendrick's test-image in 2
> minutes 45 seconds. Both versions (_O2 and _O3) seem to behave in an
> identical manner. What is the significance of the two?
> This is a vast improvement on the 7 minutes we had before.
> Both compilations require Unix style file paths. That's OK, but has
> implications - see below.
> I am using Dave Watson's Frontender v. 2.0.5 (June 2003) to set up a
Where can I find Dave Watson's frontender? Not found anything on
Google.
> front end to dcraw, giving easy access to all the options. I can also set
> it up to use Filer drag / drop operations - except that it does of course
> enter RISC OS file paths, which dcraw rejects. Only Chris Terran's port in
> 2003 takes RISC OS conventions.
> As things stand it is most realistic to put the file(s) into the root
> directory and enter the file name manually.
> Finally, using dcraw_O3 to process an 18MB image from my Canon 450D gives
> a 36MB TIFF file. It was with trepidation I loaded this into Photodesk,
> expecting to bring it to its knees !
> Which it did, until I thought to increase the image cache (Iconbar menu ->
> Preferences) from a measly 8MB to a sensible 50MB. Now Photodesk is as
> lively as ever.
> Does life get any better than this ?
> Martin Hodgson
--
Geoff
Wey Hey were like monkeys...I can use tools too!
Steve Fryatt
<d13c48ed4f...@gjlavallin.plus.com>:
> In message <4fed16cae5...@freeuk.com>
> Martin Hodgson <marth...@freeuk.com> wrote:
>
> > I am using Dave Watson's Frontender v. 2.0.5 (June 2003) to set up a
>
> Where can I find Dave Watson's frontender? Not found anything on
> Google.
http://homepage.ntlworld.com/the.watsons/frontender/
druck
> In message <4fed16cae5...@freeuk.com>
> Martin Hodgson <marth...@freeuk.com> wrote:
[snip two entire previous messages irrelevant to your request]
>> I am using Dave Watson's Frontender v. 2.0.5 (June 2003) to set up a
> Where can I find Dave Watson's frontender? Not found anything on
> Google.
[snip further text uselessly left at the end]
Please learn to snip. Your one line request required precisely one
line of quoting to make sense. That is ALL that should be quoted.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Glenn Richards
> Thirdly, I've had somebody test it with this image (taken from an EOS
> 400D) - this this also crash for you?
> http://www.rjek.com/test-image.cr2
Not sure if it's any relevance but the RAW viewer power toy extension
for XP wouldn't read that image either (it reads .CR2 files from my
EOS-20D no problem). Photoshop CS2 loaded it fine though.
One question... who's the cute girl on the left in the grey top and dark
trousers holding the bottle of water? ;-)
--
Squirrel Solutions Ltd Tel: (01453) 845735
http://www.squirrelsolutions.co.uk/ Fax: (01453) 843773
Registered in England: 05877408
Glenn Richards
> That works here also. And processing Rob's test image also takes about 7
> minutes.
That's a bit.. sub-optimal?
(Takes about 2 seconds to open in Photoshop here, AMD X2 5000+, 3GB RAM...)
Glenn Richards
> I dread connecting any camera to the Wintel - every damn graphics
> utility I ever install tries to grab all the images off the camera,
> unless I have remembered to used msconfig to disable them at startup.
Straying slightly off-topic here but...
The only thing I ever use EOS Viewer for now is setting the owner name
on the camera and syncing the camera's time and date with the PC.
Originally I used it for thumbnailing and exporting TIFFs to Photoshop 7
but the RAW Viewer power toy now handles thumbnailing transparently and
Photoshop CS and above have the Camera RAW plug-in so it's no longer
needed. I just pull the CF card out of the camera and chuck it in the
card reader (USB2, the camera's USB1 so it's faster to use the reader).
For the "I've just taken 300 shots in RAW" scenario Adobe Bridge is your
friend! Select all, process automatically, save as JPEG.
Incidentally a 16-bit/channel PNG saved from my EOS-20D is around
40MB... will Photodesk cope with this?
Rob Kendrick
Glenn Richards <gl...@squirrelsolutions.co.uk> wrote:
> Martin Hodgson wrote:
>
> > That works here also. And processing Rob's test image also takes
> > about 7 minutes.
>
> That's a bit.. sub-optimal?
>
> (Takes about 2 seconds to open in Photoshop here, AMD X2 5000+, 3GB
> RAM...)
That's because your CPU is designed for complex modern data processing
requirements, and the CPU in the Iyonix (or any other RISC OS box) is
not.
B.
John Tytgat
But are we comparing apples with apples ? The input file is the same but
the code being executed is probably totally different, no ?
John.
Rob Kendrick
Adobe's RAW processor is based on dcraw - if anything, it's slightly
slower.
B.
Martin Hodgson
Glenn Richards <gl...@squirrelsolutions.co.uk> wrote:
> Incidentally a 16-bit/channel PNG saved from my EOS-20D is around
> 40MB... will Photodesk cope with this?
Don't know about a PNG.
Photodesk copes nicely with a TIFF from my 14 bit/channel EOS-450D
weighing in at 36MB. Converted from RAW by dcraw. On Iyonix.
Slightly to my surprise admittedly, but it most certainly does work.
Don't forget to increase PD's image cache to around 50MB.
And BTW, dcraw on Iyonix processes the original 18MB RAW in slightly
under 3 minutes, which does feel /much/ better than 7 or 8 previously
Martin Hodgson
druck
> In article <vcSdnfrnq88vKG7V...@eclipse.net.uk>,
> Glenn Richards <gl...@squirrelsolutions.co.uk> wrote:
>> Incidentally a 16-bit/channel PNG saved from my EOS-20D is around
>> 40MB... will Photodesk cope with this?
> Don't know about a PNG.
> Photodesk copes nicely with a TIFF from my 14 bit/channel EOS-450D
> weighing in at 36MB. Converted from RAW by dcraw. On Iyonix.
> Slightly to my surprise admittedly, but it most certainly does work.
> Don't forget to increase PD's image cache to around 50MB.
It should be at least twice the uncompressed size of the largest image
you are going to handle. So there is room for the image and the undo
buffer without reverting to very slow virtual memory during
operations.
Martin Hodgson
Rob Kendrick <nn...@rjek.com> wrote:
> On Mon, 13 Oct 2008 21:39:11 +0100
> Glenn Richards <gl...@squirrelsolutions.co.uk> wrote:
> > Martin Hodgson wrote:
> >
> > > That works here also. And processing Rob's test image also takes
> > > about 7 minutes.
Down to 2 min. 45 sec. with the later compile of dcraw.
> >
> > That's a bit.. sub-optimal?
> >
> > (Takes about 2 seconds to open in Photoshop here, AMD X2 5000+, 3GB
> > RAM...)
Takes me 4+ min. (for Windows to fire up fully), plus 9 seconds to
actually process and write the image (AMD 64 single core 2.8GHz, 2GB RAM,
Win XP).
Then a few seconds more to send the result over to the Iyonix (after
Windows has finally found the other computer on the network - many more
long seconds).
That's why dcraw on the Iyonix is such a blessing. If I were into bulk
processing of hundreds of RAW images I would arrange the workflow
differently.
I might even make more use of Photo Shop - it lacks Photo Desk's speed and
flexibility of use (e.g. any tool for any effect), but does have some
useful predefined tools. In recent years it even seems to have, to some
extent, followed Photo Desk's lead. And I do like the concept of
adjustment layers.
Incidentally, nowadays there is access to the Photodesk code. Has anyone
thought of seeing how it handles Plug-ins? Like Artworks, and Photo Shop
for that matter, Plug-ins do provide scope for extending the possibilties
of the basic application.
Chris Hornby (Photodesk Ltd.) used to declare that he did not want to
bother publishing the details, but that he was surprised no one had sussed
it out anyway.
Existing Photo Desk plug-ins are usually quarter to half the size (MB) of
a Photo Shop plug-in for the same job.
Martin Hodgson.
george
Rob Kendrick <nn...@rjek.com> wrote:
Would I be right in thinking the main shortcoming in the Iyonix is
lack of a dedicated floating point processor and the code to utilise
it (which is presumably a RISC OS issue)?
George
--
druck
> Would I be right in thinking the main shortcoming in the Iyonix is
> lack of a dedicated floating point processor and the code to utilise
> it (which is presumably a RISC OS issue)?
No, its a shortcomming of all ARM chips, none of which have a floating
point capability which RISC OS is capable of using. Those with a
vector floating point unit are incompatible with all RISC OS FP code.
druck
> Incidentally, nowadays there is access to the Photodesk code. Has anyone
> thought of seeing how it handles Plug-ins? Like Artworks, and Photo Shop
> for that matter, Plug-ins do provide scope for extending the possibilties
> of the basic application.
Yes, Nik Wiess has taken over development and is documenting the
interface.
Martin Hodgson
druck <ne...@druck.freeuk.com> wrote:
> On 15 Oct 2008 Martin Hodgson <marth...@freeuk.com> wrote:
> > Incidentally, nowadays there is access to the Photodesk code. Has anyone
> > thought of seeing how it handles Plug-ins? Like Artworks, and Photo Shop
> > for that matter, Plug-ins do provide scope for extending the possibilties
> > of the basic application.
> Yes, Nik Wiess has taken over development and is documenting the
> interface.
> ---druck
That's good to know.
Martin Hodgson