How long does it take to convert a raw camera file to "default" JPG?
in [Digital Cameras]
|
Prev: Forget Dpreview's B.S., "diplomatic language" NEX 16mm lensis not good
Next: How long does it take to convert a raw camera file to "default"JPG?
From: Better Info on 12 Jun 2010 15:09 On Sat, 12 Jun 2010 20:18:25 +0200, Jon Smid <Varkensvoer(a)hotmail.com> wrote: > >- Interpolation used. No interpolation (halfsize option of dcraw) will >be obviously the fastest. AHD will be the slowest. VNG Cubic is the slowest, but gives some of the best results in almost all instances. Few editors, however, support this interpolation method. I use Photoline for its 6 different RAW interpolation algorithms. Donation-ware RAWTherapee also has the VNG algorithm available but their own EAHD algorithm is even better when it comes to very fine aliasing artifacts. You might want to check out their interpolation comparison page to see if your RAW editor is performing up to your needs. Adobe Camera RAW, Bibble, Capture One, DxO, LightZone, and SilkyPix all pale in comparison to the better interpolation methods available in other editors. http://www.rawtherapee.com/RAW_Compare/ Photoline's (32bit, not 64bit version) RAW import times on my old workhorse photo-editor 1.8GHz machine: Linear: 2 seconds Cubic: 2.5 seconds AHD: 5 seconds PPG: 3 seconds VNG Linear: 8 seconds VNG Cubic: 9 seconds
From: nospam on 12 Jun 2010 15:57 In article <obQQn.65445$0A4.32329(a)newsfe01.ams2>, Jon Smid <Varkensvoer(a)hotmail.com> wrote: > - Size and compression of input file. > - Interpolation used. No interpolation (halfsize option of dcraw) will > be obviously the fastest. AHD will be the slowest. yep. > - Whether or not threading is used. Standard dcraw does not use > multithreading. Ufraw's dcraw *does* use multithreading on some > interpolation mechanisms. why isn't dcraw threaded? multicore processors are very common, if not the norm. > - Whether or not some 'preloading' is done. I.e. If your image is loaded > already in memory or not on the moment you start timing. (I /suspect/ > that camera raw for instance does preload images). it does cache images, so if you *re* open an image, it's even faster. i cited only the first time opening to avoid any caching. > - Operations done on the image. Just converting to jpeg ? Or applying > curves, sharpening, leveling or whatever ... ? only until it appears on screen or in the case of dcraw, outputs a file. > I guess it will be very difficult giving a decent answer if you don't > define what you exactly mean with 'to convert'. exactly.
From: nospam on 13 Jun 2010 05:27 In article <877hm39u13.fld(a)apaflo.com>, Floyd L. Davidson <floyd(a)apaflo.com> wrote: > The reason it is not multi-threaded is one of the more > significant points about Coffin's intent. It is a > program written absolutely in strict ISO/ANSI Standard C > for *portability*, which means that in 40 years or 400 > years it will be possible to generate a compiler that > will produce a useful binary for whatever hardware > exists. Threads are *not* part of the C Standard, and > never will be (it is an innately platform specific and > non-portable functionality). give me a break. there are platform agnostic libraries for threading.
From: Floyd L. Davidson on 13 Jun 2010 06:14 nospam <nospam(a)nospam.invalid> wrote: >In article <877hm39u13.fld(a)apaflo.com>, Floyd L. Davidson ><floyd(a)apaflo.com> wrote: > >> The reason it is not multi-threaded is one of the more >> significant points about Coffin's intent. It is a >> program written absolutely in strict ISO/ANSI Standard C >> for *portability*, which means that in 40 years or 400 >> years it will be possible to generate a compiler that >> will produce a useful binary for whatever hardware >> exists. Threads are *not* part of the C Standard, and >> never will be (it is an innately platform specific and >> non-portable functionality). > >give me a break. there are platform agnostic libraries for threading. Give you a break: demonstrate how a program can be ISO/ANSI C Standard portable if it requires linking to *any* library for threading. -- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd(a)apaflo.com
From: nospam on 13 Jun 2010 07:07
In article <8739wr9r39.fld(a)apaflo.com>, Floyd L. Davidson <floyd(a)apaflo.com> wrote: > Give you a break: demonstrate how a program can be > ISO/ANSI C Standard portable if it requires linking to > *any* library for threading. why limit oneself to ansi c? nevertheless, there's grand central, and for c++, boost::thread. |