Downloads
Stable release: 0.14 (new)
What Is LibRaw
LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others). Details >>
LibRaw is based on the source codes of the dcraw utility, where part of drawbacks have already been eliminated and part will be fixed in future. The users of the library are provided with API to be built into their software programs.
LibRaw 0.14.5
Submitted by lexa on 24 December, 2011 - 20:57- Fixed bug (uninitialized variable) in SMAL format decoding.
- Imported new dcraw 9.12 (1.446): support for Leica V-LUX 3, updated color data for Canon S100, Fujifilm X10, Nikon 1 J1/V1, Panasonic GX1, Samsung NX200, Sony NEX-7
LibRaw 0.14.0 (Release)
Submitted by lexa on 21 September, 2011 - 20:45After three months of testing the LibRaw 0.14 is considered stable. This version is recommeded to use instead of LibRaw 0.13.
The most significant change of this version is multiple rendering (via LibRaw::dcraw_process() calls) of same RAW data without re-opening RAW file through the sequence of open()/unpack() calls. You should be able to change any processing parameters (except shot_select parameter) between dcraw_process() calls.
So, it is possible to implement near-realtime preview of entire image in half-resolution mode and realtime preview of selected area (e.g. around mouse pointer position) in full-resolution mode.
Changelog:
Displaying L channel in Photoshop
Submitted by lexa on 3 April, 2011 - 19:16Once in a while one may want to adjust L channel viewing it separately. The rub is that to do this without using extra layers one needs either to use grey Lstar profile as grey working space in Photoshop Color Settings (Cmd/Ctrl-K), or to switch on Show Channels in Color in Photoshop Interface Preferences (Cmd/Ctrl-K). Otherwise the brightness and contrast of the L channel display are wrong.
Festina Lente
Submitted by lexa on 5 December, 2010 - 23:01For quite some time we were suggesting that floating point implementation of demosaicking algorithms allows for higher quality results. Incidentally, some programmers who vigorously argued for years insisting integer processing is quite sufficient are now starting to code their demosaicking in floating point too. Here is a comparison of the results of original AHD demosaicking algorithm implemented using floating point and integer arithmetics.
Bayer moire
Submitted by lexa on 1 December, 2010 - 18:25With the existing diversity of RAW converters and their algorithms, there is the problem of choice: which converters are better (and for which purposes). An evident methodology is often encountered in internet forums: take one or several images, process them using different converters/algorithms/settings and compare them visually. The result often looks like this: image P should better be processed using algorithm Q, and image A is better handled by algorithm Z with option f+.
Moreover, it is simply wrong to analyze things in terms “worse or better”. The correct formulation is “closer to/farther from the initial image”.
The problem is that here we deal with a complex system, which includes
- The photographed object and light.
- The light path in the camera with lens aberrations and light scattering within the camera.
- The sensor with all construction features: anti-alias filter, color bayer filters, microlenses, etc.
- In-camera processing, both analog and digital.
- And, yes, also the RAW converter in question.
LibRaw Repository on GitHub
Submitted by lexa on 18 October, 2010 - 09:15The copy of LibRaw internal SVN repository has been created on GitHub. All changes made to the master branch through Git will be incorporated into the main Subversion repo.
So, if you wish to participate in LibRaw development you may get full sources from GitHub, add your changes, commit, and send us a request to merge your changes into the main source tree; all this using just standard GitHub tools. Also you can report a bug or make a feature request using GitHub interface.
URLs:
- github.com/LibRaw/LibRaw - LibRaw homepage on GitHub.
- git://github.com/LibRaw/LibRaw.git - git repository URL.
Chasing a Gray Cat In a Gray Room: the level of middle gray and the headroom in the highlights for Canon 5D Mark II
Submitted by lexa on 7 March, 2009 - 23:07The current methods used to determine the sensitivity of digital cameras are not based on the RAW data coming from the sensor; rather they are based on the results of processing the RAW in a converter (be it an external converter or in-camera).
This approach, with all its simplicity, is in fact based on the properties of the RAW converter and on the transformations it applies to RAW data. In particular, the converter can introduce hidden exposure compensation, change the tone curve, and so on. The sensitivity of the camera resulting from such a procedure is a pretty arbitrary value. The matter is discussed in good detail in Wikipedia, in the article explaining ISO 12232 standard.
This approach allows the camera manufacturers to enjoy all sorts of tricks while stating the sensitivity, say cameras from different manufacturers but having the same rated sensitivity behave wildly different when it comes to photographic latitude. This means that switching between different camera bodies one often needs to re-adapt, changing the way he applies exposure compensation.
A simple experiment that takes no additional equipment other than already existing camera and lens allows to accurately determine how the camera exposes, that is:
- which level of signal (in terms of RAW data) is obtained while setting the exposure by the exposure meter;
- what headroom in highlights is left, i.e. how many exposure stops are between the middle gray and sensor saturation.
Two Paths Leading Nowhere
Submitted by lexa on 31 January, 2009 - 19:18During the last 10 to 15 years, digital photography forced the film out of nearly all the domains. End users purchased hundreds of millions of digital cameras; and that is not including the cameras sold integrated with cellular phones. Such a huge industry can't exist without standards and such standards appear to exist. They cover the storage media (various flash cards), and image format which happens to be JPEG. Currently JPEG is the most widely used image format and its image quality and size satisfy the overwhelming majority of users.
However it is not always what professionals want. By professionals we do not mean just professional photographers. The list includes designers, pre-press staff, archivists, photo banks and many others. It often happens that JPEG format is also deemed less than appropriate by advanced amateurs. That is why nearly all digital cameras that are positioned by manufacturers as professional or semi-professionals models (as well as all current dSLR cameras) suggest an alternative format, the so-called RAW. For a casual onlooker it may appear that RAW is also some kind of a standard format that delivers better quality – quality for pros.
This small article is to show that the matter is much more complicated. At the current stage the situation with RAW format is not just bad but really dreadful and continues to spiral downwards rapidly. This affects mostly professionals while less demanding amateurs simply enjoy the progress of digital.
Dan Margulis on RAW module
Submitted by ib on 9 January, 2009 - 05:01The question that needs an answer is, for what purpose is the module designed. I can think of four different approaches to acquisition.
- I want the module to do nothing more than open the file without damage. I understand that it will probably be flat and colorless if I do this. I intend to fix the problems in Photoshop.
- Although I will refine the image in Photoshop, I would like to be able to make quick, obvious moves in the acquisition module to make life easier later.
- I am not interested in the very best quality. I will do whatever is possible in the raw module but I will not work in Photoshop afterward. So I would like to be able to get attractive color from the module.
- I want to make the image as perfect as possible in the module. I will intervene later in Photoshop only as necessary.
You need to decide which group(s) you appeal to.
Random And Groundless Thoughts On Color Control In a Raw Convertor
Submitted by lexa on 1 October, 2008 - 22:30
CAM book
After finally finishing reading Fairchild’s Color Appearance Models I started to get deep into thought and some empirical things became clear.
Color Contrast
In the photographical community it is pretty much a common place that if you show the viewer two pictures, one with normal colors and one with an increased saturation, the viewer will in most of the cases pick the one with the higher saturation (if it is, for example a landscape scene) as the more natural one (of course if saturation is increased in the reasonable limits).
I could not quickly find the wording of this effect in books by Margulis, although I was almost certain that it was there in one way or another: in his book Photoshop Lab Color) this rule (increasing the a-b axis contrast) is used starting with the very first example.
RAW decoding/processing library
Photographers using digital cameras know that shooting using the RAW format, where "raw" data from the camera matrix are saved to file, provides the highest flexibility for further processing. At the same time, photographers and pre-press specialists still can't enjoy the full potential of the RAW format, since most popular converters significantly and irreparably impair the quality of the initial material.
Developers willing to get rid of this sad discrepancy run into a vast diversity of formats and either have to waste time and effort on studying them, or confine themselves to a limited set of formats, or use ready solutions for extracting RAW data for furher manipulations and rendering into an image.
Most software products for RAW file processing extract the input data using code that is based on the source of the dcraw utility by Dave Coffin. For all its evident advantages, however, dcraw is a command-line utility rather than a software library. As a result, one should either make his or her library from it (and many developers, including Adobe, have followed this way) or use the dcraw command line (which is far from convenient, too).
In addition, dcraw tampers the data at the extraction stage and does not extract some of important parameters from the RAW file, thus impairing the quality of the result.
On the basis of the above reasoning, the authors have decided to create the LibRaw library, which is presented on this site.
- Right now LibRaw can be built into your software.
- Right now part of dcraw problems have been resolved.
- In the nearest future, further processing will be improved after some modifications in the library.
LibRaw is intended to be used in any software that involves RAW file processing for a variety of purposes: RAW converters, data analyzers, panorama stitchers, noise suppressors, etc.
LibRaw is free and distributed in source code under the terms of GNU GPL v2 (or later). Licensing under other terms is also possible for free; please contact the authors.
If your application needs basic RAW-format support (e.g file viewers, GUI on top of LibRaw/dcraw without own RAW processing code and so on), you may use slightly simplified LibRaw-Lite (distributed under LGPL terms).
About This Site
Besides developers using LibRaw (and possibly our future software), we'll be glad to see the other readers and contributors to this Web site:- authors willing to publish their papers on image processing, color management, specific features of digital photographing, and other similar issues
- photography enthusiasts willing to understand how all these things work
- computer programmers (programmers interested in photography, photographers interested in programming...) willing to announce their products.