Go Back   Steve's Digicams Forums > Digital SLR and Interchangeable Lens Cameras > Sony Alpha dSLR / Konica Minolta dSLR, Sony SLT

Reply
 
Thread Tools Search this Thread
Old Mar 5, 2006, 12:32 PM   #11
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

kassandro wrote:
Quote:
Yes, dcraw.c is really a great piece of software. I always wonder, from where David Coffin got all the information about the different raw file formats.
Lots of time spent on it, because he wanted better output than Canon could provide for his own camera when he first started this project.

David Coffin released the first version of dcraw.c on February 23, 1997 (years before Adobe's first release of camera raw in 2002).

From my conversations with David, it can be pretty tough deciphering the files. He has to take photos with different settings, trying to figure out what changed in the raw files with the settings used so he can decode them. That's why I don't mind helping out by sending him some images when I have access to images from new models, so that he can see what changed in the files using known settings.

When manufacturers encrypt some of the data, this makes it even tougher. But, David's a pretty sharp guy, and he's managed to break the encryption used by some of the manufacturers in their raw files, too (for example, the encryption used by Nikon for the RGB multipliers related to white balance in the .nef files generated by the D50, D2Hs and D2X models).

Ditto for Sony's encryption used in the raw files generated by some of their models (and there are more examples of where manufacturers have taken steps to try and hide the data in them, outside of not documenting their formats, where David has cracked their encryption).

We owe a lot of thanks to David and developers like him for trying to decipher these proprietary formats for us.

Quote:
Dcraw.c is hopelessly slow
Nah... the code is pretty tight for what it's doing. You can compile it using processor specific parameters if you need faster conversion, too.

You can also convert multiple files at once via command line. For example:

dcraw -w pict0001.mrw pict0002.mrw pict0003.mrw pict0004.mrw

I've also seen some third party front ends for it around that let select files via a GUI.

Sure, it's not as flexible as many others. But, there are a number of third party products that do have more flexibility that use some of David's code for the raw converstion piece. He wants to keep it as simple as possible, so that it's easier to use his code in other applicatons, as well as making sure it's not platform or operating system specific.

That approach has some drawbacks if you want to use it as an only solution.

Quote:
It should be an input plugin for an image processing program supporting 16 bit color channels.
Again, one of David's goal is to make sure it's not platform or application specific, so that others can more easily build on it.

A developer can use his code to create a plugin that can be used for 16-bit editing. I'd be surprised if some of the products based on his code don't do this already. I haven't gone through the list lately.

David does have a basic plug-in for The Gimp. But, The Gimp doesn't support 16-bit editing yet. ;-) UFRaw is another plug-in that is a popular choice for users of The Gimp that's based on David's code. I think that most of the limitations you see are in the editors and raw converters using David's code, not David's code itself.


JimC is offline   Reply With Quote
Old Mar 5, 2006, 2:08 PM   #12
Senior Member
 
Join Date: Oct 2004
Posts: 448
Default

The slowness of dcraw.c is caused by many factors. Some of them have their origin in the broad choice of sensors and with the exception of the Foveon sensor David wants to handle all these sensors with one routine if possible. This keeps the code compact but slows it down as well. Most importantly a fast demosaicing routine should be written with SSE/SSE2 assembler and not in C. Modern video processing is unthinkable without SSE/SSE2.
I agree that 16 bit is not a problem for dcraw.c. The compression to 8 bit simply occures at the very end. On the other hand, for optimal image processing 16 bit color channels are a neccessity. All advanced raw processing software works with 16 bit channels until the creation of the final output, which in most cases, i.e. jpeg, has 8 bit color channels.


kassandro is offline   Reply With Quote
Old Mar 5, 2006, 2:14 PM   #13
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

kassandro wrote:
Quote:
The slowness of dcraw.c is caused by many factors. Some of them have their origin in the broad choice of sensors and with the exception of the Foveon sensor he wants to handle all these sensors with one routine if possible. This keeps the code compact but slows down as well. Most importantly a fast demosaicing routine should be written with SSE/SSE2 assembler and not in C. Modern video processing is unthinkable without SSE/SSE2.
Again, he doesn't want it to be specific to any platform.

David Coffin Wrote: (via e-mail to me sent on September 29, 2004, when we were discussing the merits of DNG). He said he didn't mind me quoting it:

Quote:
I think Adobe's DNG idea is well-intentioned, but suffers from two serious flaws:

First, why would camera makers want to change their raw formats? Compatibility leads to commoditization,and that leads to competition based on price alone. Great for consumers, terrible for producers.

Second, this format cannot anticipate innovations that haven't happened yet. When new sensors appear, the standard must be updated, along with the software that implements it.

There is only one way to guarantee that a digital archive will be readable in fifty years. For any non-text files, it must include decoding software as human-readable source code. If the decoder is written in a language other than C, it would be prudent to include an interpreter for that language, written in C.

Dcraw already fills this role. When the first DNG camera is available, dcraw.c will support it as one more raw format among many.
BTW, dcraw.cnow supports DNG. Here is more recent quote from David Coffin (March 9, 2005):

Quote:

After four months of work, dcraw 7.00 is available for download at
http://cybercom.net/~dcoffin/dcraw/ . It's a major rewrite:

* Not only is Adobe DNG now supported, the entire codepath has been redesigned for it. Adobe's XYZ->CAM matrices allow color science to replace black magic, whether decoding DNG or the original raw files.

* The Foveon-related code has been completely rewritten to give realistic colors under all light sources.

The license has changed. The new Foveon code is under the GPL license, so authors of closed-source applications may need to pay me to use it. The rest is under my old free-for-all license. See dcraw.c for details.

My future plans are:

* Adding support for SMaL-based thin cameras (
http://www.smalcamera.com/ ) Currently these cameras are completely useless without Windows.

* Improving camera white balance support, first for Canon, then Nikon, and maybe others.

Dave Coffin 3/9/2005



Here's my favorite quote (from David's web page):

Quote:
So here is my mission: Write an ANSI C program that decodes any raw image from any digital camera on any computer running any operating system.


JimC is offline   Reply With Quote
Old Mar 5, 2006, 2:23 PM   #14
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

P.S.

We're getting way off topic here (since the OP only wanted to know if a D lens was better for flash exposure). ;-)

So, if he objects, we should start a new thread (even though the data in raw files may show some evidence of the information a camera has available from ADI and non-ADI compatible lenses).

JimC is offline   Reply With Quote
Old Mar 5, 2006, 2:38 PM   #15
Senior Member
 
Join Date: Oct 2004
Posts: 448
Default

I agree that we are way of topic. The raw format only came into play through Dalibor's observation that the Minolta raw format contains distance information even for non-(D) lenses. There will certainly be opportunity to continue the dcraw.c discussion at some later time.
kassandro is offline   Reply With Quote
Old Mar 5, 2006, 2:47 PM   #16
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

It's my fault (and I'm a moderator so I should know better). :-)



JimC is offline   Reply With Quote
Old Mar 5, 2006, 4:28 PM   #17
Member
 
Join Date: Jan 2006
Posts: 49
Default

kassandro wrote:
Quote:
Taking into account the crop factor, your 50 mm lense is already a tele lense. Thus you hardly will use that lense with a flash. I think the ideal lense for the internal flash and also for low light is the Sigma 1.8/24 mm EX DG lense. It covers exactly the angle of the internal flash. Thus, if you take an even wider lense, you get dark corners.
My knowledge of flash systems is very limited, that may be whyI'm not following these points.

Why wouldn't the 50 mm be used with a flash? I don't understand the significance ofthe 50 mmalready being a tele lense.

Page 31 of the KM5D manual states that the built-in flash can be used withfocal lengths of 18 mm or longer. Shorter than 18 mm results in the corners not being illuminated.However, yourecommend 24 mm, why is that?

Thanks,

Scott

P.S. Jim, I'm fasinated by the other discussion in this thread.
Magnum is offline   Reply With Quote
Old Mar 6, 2006, 3:10 AM   #18
Senior Member
 
Join Date: Oct 2004
Posts: 448
Default

@Magnum:
With a crop factor of 1.5 a 50mm lense this lense has an effective focal length of 75mm and for me the tele range starts at around 70mm. Of course you can use the flash with any lense, but nevertheless the flash is rarely used in combination with a tele lense, because you have to move further away (which may not always be possible) to frame the subject. Now, if you move further away the flash becomes less powerful. There is one exception from this rule. If you make macro shots, then the flash does not work properly if you are too close or the flash may generate unwanted shadows of your lense on the picture. Thus in this case it is wise to move away from the subject as far as possible.
I am very surprised that the KM 5D works already at 18 mm - without dark corners of course. On p.31 of the german manual of my KM 7D it is clearly stated that the flash works only with focal length larger than 24 mm. I hardly can believe that the KM 5D has a better flash than the KM 7D. I rather believe that the german manual is again incorrect. That wouldn't be the first time. I have to check this. An 18 mm focal length means a 35 mm equvalent of 27 mm and many flashes can cope with the angle of such a lense. Actually, the flash of my Coolpix 8400 works already fine at a 35 mm equivalent of 24 mm and the CP 8400 has even an aspect ratio of 4:3 instead of 3:2 of the KM 7D.
kassandro is offline   Reply With Quote
Old Mar 6, 2006, 1:06 PM   #19
Member
 
Join Date: Jan 2006
Posts: 49
Default

kassandro,

Thanks for explaination.

FYI, KM's website has the manuals available in PDF, so if you don't yet have an English copy, that might be an easy way to obtain it. While you are there, thereis also auseful guide, at least for the 5D. I love PDF manuals for keyword searching, zoom, etc.

Scott
Magnum is offline   Reply With Quote
Old Mar 6, 2006, 2:05 PM   #20
Senior Member
 
tmoreau's Avatar
 
Join Date: Dec 2005
Posts: 477
Default

kassandro wrote:
Quote:
@Magnum:
Of course you can use the flash with any lense, but nevertheless the flash is rarely used in combination with a tele lense, because you have to move further away (which may not always be possible) to frame the subject.
In a fit of nit-pickery, I must take exception to this! Your obviously refering to your particular style of photography/ common subjects. I can think of many cases to use a 150mm lens at 10-15 feet with flash. There are also applications for (external) flash at ranges measured in dozens of feet.

The 5d is improved so that you can zoom in raw files, I'd not be surprised to find the flash imroved too
tmoreau is offline   Reply With Quote
 
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



All times are GMT -5. The time now is 1:37 AM.