Which future image file format for digital camera...
JPEG, the current standard
Currently, all camera support JPEG format to store photograph. This format is very popular, robust. Image can be encoded/decoded very quickly and algorithm are very optimized to be embedded into device. Under Linux libjpeg is available and very stable, but is not maintained since a very long time.
But JPEG has several limitations. Where JPEG is perfect to publish photograph over internet, especially when you need small file sizes, JPEG is not adapted for image editing. It's a lossy image format duing of the compression method used. Also, the color depth is limited 8 bits per pixel, where camera sensor use at least 12 bits. This is a very restrictive issue especially to fix photograph when exposure is closed: you will lost image informations and you don't use the full bandwidth of your camera sensor.
RAW Formats
This is why camera constructors have introduced RAW formats. Instead to have a ready to use image as JPEG, RAW is an unprocessed file including all sensor informations and using the sensor color depth (currently 12 or 14 bits). RAW files are containers which embed the un-demosaiced image, a color profile, all meta-data, and a JPEG preview image. You need to process RAW files on your computer to be able to use it (digiKam use dcraw in background), and it can take a while.
The advantage of RAW is that you use the full bandwidth of your camera sensor. Its perfect to correct image in your photograph workflow, you don't lost image quality. But the disadvantage is that you need to reproduce a part of your camera adjustments to be able to start image corrections. It's a lots of work. Another problem is than RAW files are proprietary formats, undocumented (excepted few one as X3F from Sigma), and not writable. It's really well explained in OpenRaw web site. By chance, we have crazy hackers in this world who have processed an incredible reverse engineering. It's now possible to extract and decode these file formats (thanks to Dave Coffin for dcraw, Andreas Huggel for Exiv2, and Phil Harvey for Exiftool).
Question: which image format camera makers will use in the future ?
Digital Negative
DNG is a RAW file format created by Adobe. It's an extension of standard TIFF/EP format and is fully documented about file structure. The goal of DNG is to replace all proprietary RAW file formats and increase interoperability everywhere. Other advantage is the JPEG lossless compression used to store image data (with 16 bits color depth support of course). DNG file sizes are generally lesser than RAW files (ratio 1/2): it's an advantage for archiving purpose. Unforget than all Adobe products support DNG as well, few camera as Pentax are able to write DNG image, and Adobe is under progress to standardize DNG as ISO standard: we cannot ignore it...
But DNG is not perfect. Sure Adobe provide a SDK to use it, but i do not support Linux. Also, SDK code is not Opensource compatible. Why Adobe do not have published this SDK using BSD license as it's done with XMP SDK ??? It's look really strange... Also, DNG SDK is covered by a lots of patents. You can use the Adobe code but no more. So, there will be no chances for the moment to see DNG SDK under Linux.
But i'm curious. As you know, i'm not a beginner developer. I have studded DNG SDK, ported code to Linux, fixed several memory leak and created a small program over libkdcraw to convert RAW to DNG. I have been horrified by the nonexistent API documentation from DNG SDK. There is nothing to read. You need to look into Adobe code to try to understand what you need to do exactly. It's a shame from a pro-compagny like Adobe. Note that the XMP SDK is completely different and very well documented.
So what the result ? My small DNG converted provide a right structured DNG file but all colors of converted image are broken... I have tried to find over Internet any informations to learn how to use DNG SDK: nothing. All is closed. Thanks Adobe!
So, we will only able to read DNG file thrue dcraw for the moment, not to write a valid DNG file for archiving. If anybody has more informations, let's me hear.
HD Photo
HD Photo is potentially the perfect JPEG replacant. It's another TIFF/EP based image format created by Microsoft. It use wavelets lossless compression and 16 bits color depth. Image file sizes are similar than DNG and algorithms are optimized to be included to camera device. Microsoft is under way to standardize this format as a new JPEG-XR norm with Joint Photographic Experts Group (which host already JPEG format)
Microsoft provide a HD Photo SDK, but i doesn't support Linux (as excepted). I have played with the code to be able able to use it under Linux. After some fix, the code compile and run fine. it provide a library and an command line tool to convert image to HD Photo.
But HD-Photo is not perfect too. The license is very restrictive (more than DNG SDK) and code is covered by a lots of patents. This is the hell...
An Open Source Alternative?
So i'm pessimist about the future of photography. Which file format will be used in 10 years by camera to host images? I'm sure than Adobe or Microsoft will trying to force DNG or HD-Photo everywhere. Adobe has already a great advance against Microsoft.
At least, my wish is to see Adobe using the right way: publish DNG SDK using an open source license (as XMP SDK) and provide a real API documention to be able to create valid DNG file.
And open source then? The community is not able to provide something to replace JPEG file format? Why not to extent PNG format to use a new compression algorithm which will support 16 bits color depth and lossless compression?
Like you know already, i love PNG and i use it to archive my photographs. For the moment it's perfect and open source of course.
And JPEG-2000?
JPEG-2000 is out here since the battle is already lost for it. Sure, JPEG-2000 support 16 bits color depth, lossless compression (using wavelets), and we have already some open source library to play with it. But the algorithm is not adapted to be embedded into camera device. It require too many resources (memory and CPU) to compress or uncompress an image. Also JPEG-2000 is also a patented stuff...
To Conclude
This is my wishes for a perfect photograph file format:
- Open source
- Not patented
- 16 bits color depth or more
- Color profile support
- XMP, Exif, IPTC support
- Lossless compression
- Wavelets like compression
- Fast preview extraction
- Full documented SDK
- Standardized
The ticket is open. Let's me hear your vision of the future. Perhaps somebody know already an alternative (why not (:=))). Perhaps i'm wrong somewhere here... I hope...
hard to competet
Given that the only thing that really matters is digital camera support, and none of the digital cameras use an open source stack that I know of, isn't it kind of impossible for Open Source to come up with a less-patent-laden standard (I'm sure a patent-free standard is pretty much impossible).
If they go through a ISO process hopefully they'll open up the specs enough to allow open source implementations...
I'm sure it would have some
I'm sure it would have some flaws but OpenEXR seems to compare quite well. (apart from not being designed for cameras)
But OpenExr do not support
yes OpenExr can be a good candidate. But it do not support metadata. Why ?
Gilles Caulier
A RAW-like file format needs
A RAW-like file format needs to be able to deal with different complex and bizarre pixel formats. Most camera sensors only record one channel per pixel. This is why TIFF is used as the base for these formats - it has an insanely flexible way of representing different pixel formats. PNG and OpenEXR both represent bog-standard combined RGB pixels.
Also, PNG does support compressed 16bit. I use it every day.
Why not to extend PNG
Why not to extend PNG specification to store RAW image data in a dedicated chunk. PNG is a perfect image container...
Gilles Caulier
Re: PNG as a container
But Tiff already is a container format. Granted we could patch another format into PNG but in practice you can already put anything into a Tiff file (all RAW files are basically Tiffs already).
Also while the Jpeg 2000 format does have some patents associated to it, the format itself is supposed to be unencumbered. Or at least so does the JPEG (as in the group) say. That is the patents (if you believe in software patents) do not call for licensing when implementing and using the format. So in theory, there should be no reason not to use JPEG 2000. Which does have its good sides.
That is of course if one believes the JPEG. Whether they can ultimately be trusted may be another matter... If the thing made it through ISO (although whether ISO can be trusted after the recent debacle is yet another problem) or was to be validated elsewhere, like by the W3 and made it into a couple major browsers, things would be simpler...
Quoi qu'il en soit, félicitations pour le travail en cours. Ça avance à grand pas et vu du côté utilisateur c'est un vrai plaisir. Les quelques aspects un peu bricolo de l'interface disparaissent à grande vitesse et pour ma part, si j'en suis encore à Bibble pour la conversion de RAW, tout le reste du traitement est fait avec Digikam depuis déjà un moment. Dès qu'il saura associer un RAW et les versions développées, ce sera parfait (pour l'instant pour faire le ménage à la main c'est un peu long).
Venez à la prochaine LinuxBierWanderung et je vous paie une bière (ou avant pour les parisiens ;) )
The DNG SDK is under an open
The DNG SDK is under an open source license, albeit not compatible with the GPL.
...is under an open source
...is under an open source license... really?
Look the license:
2. RESTRICTIONS AND OWNERSHIP ... You will not copy, use, display, modify or distribute the Software or Documentation in any manner not permitted by this Agreement. No title to the intellectual property in the Software or Documentation is transferred to you under the terms of this Agreement. You do not acquire any rights to the Software or the Documentation except as expressly set forth in this Agreement. All rights not granted are reserved by Adobe.
If Adobe want to publish DNG sdk really in open source, they can use BSD licence like it's used by XMP SDK...
Out of context, this means
Out of context, this means nothing. The section 1. clearly state:
"Software License. Subject to the restrictions below and other terms of this Agreement, Adobe hereby grants you a non-exclusive, worldwide, royalty free license to use, reproduce, prepare derivative works from, publicly display, publicly perform, distribute and sublicense the Software for any purpose. "
Yes they could have used the BSD license, and I have already asked them several time. Nonetheless the license of the source code qualifies as "open source".
You are wrong about JPEG2000
You are wrong about JPEG 2000.
Patents:
The patented technology used in the base standard (Part 1 - which is the pure JPEG2000) is available license and royalty fee free, which is guaranteed by the ITU-Ts patent policy. The patent holders participated in the procedure of standardizing the system and as such had to agree that they provide these techniques freely for the purpose of implementing a JPEG 2000 system.
Embedding:
The algorithm can well be adapted to embedded systems (dedicated processors, whatever) and there are already systems available (e.g. http://bapis.de/en_areas.htm quote "In this case up to 500ipm DIN A4/200dpi can be JPEG2000 compressed"). See also "Hardware acceleration of JPEG2000..." on http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=783143.
By the way, JPEG2000 is already used on every german identification cards (saving the photo on the chip of the card).
The actual problem is the availability of open source libraries. Jasper seems to be a bad implementation, indeed taking too much resources. The problem lies in the EBCOT (Embedded Block Coding with optimized Truncation) part, not the wavelet part. The algorithm should e.g. be perfect for fast preview extraction, contrary to JPEG. Perhaps with the rise of OpenJPEG (http://www.openjpeg.org/) it gets better.
great
Patents: this is nice to hear. So, this will prevent future license/patent problems with this format...
Embedding: well, like dedicated hardware are available for device like camera, why camera maker do not use it already. What the problem ? Or it's just a question of time ?
Open Source lib: yes, to have implemented and tested JPEG2000 support in digiKam using Jasper library, i can said than encoding/decoding image is really slow, especially with 16 bits color depth images. I have not yet tested openjpeg library.
> why camera maker do not use
> why camera maker do not use it already. What the problem ? Or it's just a question of time ?
Well, I guess it's like always: the price. While jpeg coders get produced thousands a day a jpeg2000 chip is really rare. My example just shows that it is technically possible to create a system on a chip for it, not that it's done regularily for customer electronics. That's why they are still way too expensive to be used in cameras. As long as they can still fool their customers with megapixels there won't be no change. Perhaps if prices stabilize and people learn that other characteristics are more important. But guessing from the bad quality the resampling in compact cameras has ("digital zoom") or how bad the color balancing sometimes is, I doubt it at the moment. Also why don't cameras offer other filetypes? They don't seem to care.
I think another problem with Jasper is the lacking Documentation (on markers or coding options for example).
Raw format
I think some kind of raw format is indispensable for a "future photography" format. Being able to set the white-point after the actual shot and highlight recovery are two very important features.
I think it's just not about higher bit-depth. Obviously file formats for digital cameras have other needs than image file formats that were developed before digital cameras were widely used.
Marc
Why not JPEG?
"But JPEG has several limitations" - Actually it is the software that has the limitations not JPEG.
ITU-T T.81 (1992) specifies that the Baseline proces (8bit DCT) is "required for all DCT-based decoders".
But the JPEG specification also defines 8bit and 12bit DCT and 2bit to 16bit lossless.
Doesn't DNG use JPEG lossless compression already?
The mystery is, why 12bit JPEG only seems to be used for medical imaging.
In EXIF 2.2 (2002) the sYCC colourspace was introduced. This has a gamut about 60% larger than sRGB. All of the major camera manufacturers encode to this colourspace with large numbers of pixels outside of the sRGB colourspace. So there are 100s of millions of cameras producing JPEGs with the sYCC colourspace.
But almost all software crops the colourspace to sRGB without even maintaining the correct hue. The only photo processing program that explicitly supports sYCC, that I can find, is Silkypix.
The moral is that inventing specifications does not necessarily lead to impementation in software, unless it helps the hardware manufacturers to sell more cameras. I imagine that Zoran could add 12bit JPEG to the COACH9 chipset software without any difficulty, if a camera maker wanted them to.
My challenge to Digikam is to provide a means of loading the billions of EXIF 2.2 camera JPEGs intact, without corrupting the colourspace.
This is not a trivial task because sYCC uses sRGB values that are negative or greater than one. This is consistent with tristimulus theory and colour matching functions but conflicts with the ICC specification. So it may be easier to handle camera JPEGs as a kind of RAW.
I expect that the JPEG patents must be about to expire, even if they haven't already.
yes, DNG use 16 bits JPEG compression
Yes it is. Looking in DNG SDK implementation, comments on dng_lossless_jpeg.cpp file said:
// Lossless JPEG code adapted from: /* Copyright (C) 1991, 1992, Thomas G. Lane. * Part of the Independent JPEG Group's software. * See the file Copyright for more details. * * Copyright (c) 1993 Brian C. Smith, The Regents of the University * of California * All rights reserved. * * Copyright (c) 1994 Kongji Huang and Brian C. Smith. * Cornell University * All rights reserved. * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose, without fee, and without written agreement is * hereby granted, provided that the above copyright notice and the following * two paragraphs appear in all copies of this software. * * IN NO EVENT SHALL CORNELL UNIVERSITY BE LIABLE TO ANY PARTY FOR * DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT * OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF CORNELL * UNIVERSITY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * CORNELL UNIVERSITY SPECIFICALLY DISCLAIMS ANY WARRANTIES, * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS * ON AN "AS IS" BASIS, AND CORNELL UNIVERSITY HAS NO OBLIGATION TO * PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. */
>why 12bit JPEG only seems to be used for medical imaging.no idea... but in all case use a wavelet based algorithm instead JPEG give a better compression ratio and less artifact.
Well, I guess it's like
Well, I guess it's like always: the price. While jpeg coders get produced thousands a day a jpeg2000 chip is really rare.