why is jpeg 2000 not in common use?
peter
is it not in common use, especially when digital camera file sizes are going
up?
hee...@yahoo.com
been and always will be an obstacle against progress, just like
the chains that "robber barons" strung across the Rhein
to collect tolls were an obstacle against trade.
Bill Tuthill
> jpeg 2000 is superior to common jpeg
At smaller file sizes (higher compression) it is superior,
but at larger file sizes (better quality) it seems a toss-up.
Until most browsers support JPEG 2000 (J2k) and have done so
for enough years so that few visitors are unable to read it,
websites cannot use J2k.
> and is supposedly licence fee free.
Most encoders cost money.
> Why is it not in common use, especially when digital camera
> file sizes are going up?
The algorithms are very slow.
Nobody has thought of a good use for it yet. A friend of mine
saves 16-bit images in J2k lossless format because it is
more compact than TIFF, and other formats don't support 16-bit.
Camera manufacturers already have a difficult time writing
RAW files fast enough to keep up. J2k would really slow down
writes, and require larger buffers (and higher cost).
Summary: old JPEG is great, RAW better serves vendor needs,
and TIFF is faster.
hee...@yahoo.com
>Summary: old JPEG is great, RAW better serves vendor needs,
and TIFF is faster.
Old JPEG is just acceptable, RAW is a problem because it is not
an open format, and TIFF files from one program may not
work in another (Photoshop files may be rejected by The GIMP).
Martin Brown
It isn't better by a significantly large factor at high quality settings
to be worth the upheaval. J2k encoders are slow and power hungry. JPEG
is fast and extremely well optimised for use in digicams now.
In essence J2k isn't enough of an improvement to become mainstream. This
may change one day, but don't hold your breath.
Regards,
Martin Brown
Paul Rubin
> Nobody has thought of a good use for it yet. A friend of mine
> saves 16-bit images in J2k lossless format because it is
> more compact than TIFF, and other formats don't support 16-bit.
There's a 16-bit extension for regular jpeg. I don't understand why
it's not more widely supported.
Måns Rullgård
Standard JPEG supports 8 and 12 bits per sample, although only 8-bit
samples are included in the "baseline" subset. I've also been
wondering why there isn't more support for it. It doesn't seem like
it would be very difficult to have as an option in a digital camera.
--
Måns Rullgård
m...@inprovide.com
chri...@alphalibrae.com
browser support (I think).
christina
Måns Rullgård
PNG is good for its intended use, which is simple drawings like web
graphics. It is less suited for photographs since the algorithm it
uses (essentially the same as zip) doesn't compress that type of data
very well. JPEG is designed for photographic images, and does a
rather good job of it. There is a lossless variant of JPEG (also in
the standard, and also not baseline) as well.
--
Måns Rullgård
m...@inprovide.com
John Bean
Indeed. And no means of adding metadata (like EXIF say)
making it even less useful as an image capture format.
--
John Bean
David J Taylor
[]
> PNG is good for its intended use, which is simple drawings like web
> graphics. It is less suited for photographs since the algorithm it
> uses (essentially the same as zip) doesn't compress that type of data
> very well. JPEG is designed for photographic images, and does a
> rather good job of it. There is a lossless variant of JPEG (also in
> the standard, and also not baseline) as well.
PNG offers excellent lossless compression, and does have special
compression capabilities for images that Zip files (for example) do not
have. Whilst its metadata capability is less well established (EXIF data
could be stored in an EXIF segment), this has not become standardised.
Nevertheless, where lossy compression is undesirable, PNG is an
excellent,widely supported standard.
David
Bill Tuthill
>
> ... RAW is a problem because it is not an open format ..
If you want (semi)open RAW, check out Adobe DNG.
-----
Paul Rubin <http://phr...@nospam.invalid> wrote:
>
> There's a 16-bit extension for regular jpeg. I don't understand why
> it's not more widely supported.
I do. JPEG is a space-saving image format, not an archive format.
Going from 8-bit to 16-bit color does not save space!
-----
chri...@alphalibrae.com wrote:
>
> png looks a promising format. 16-bit colour depth, open spec,
> good browser support (I think).
Yes, I use PNG for archiving. However lossless JPEG 2000 saves space
over PNG, so if my software were more up-to-date, I might use J2k.
Many PNG encoders do not support 16-bit colour depth.
-----
Måns Rullgård <m...@inprovide.com> wrote:
> PNG is good for its intended use, which is simple drawings like web
> graphics. It is less suited for photographs since the algorithm it
> uses (essentially the same as zip) doesn't compress that type of data
> very well.
Baloney! PNG is better than TIFF-LZW for compressing photographs.
Unlike standard JPEG, PNG is lossless. I have used PNG for archiving
for the past 5 years.
-----
John Bean <wate...@gmail.com> wrote:
> Indeed. And [PNG has] no means of adding metadata (like EXIF say)
> making it even less useful as an image capture format.
There is a project to support EXIF in PNG, although no software yet:
http://pmt.sourceforge.net/exif/
Måns Rullgård
>>PNG is good for its intended use, which is simple drawings like web
>>graphics. It is less suited for photographs since the algorithm it
>>uses (essentially the same as zip) doesn't compress that type of data
>>very well. JPEG is designed for photographic images, and does a
>>rather good job of it. There is a lossless variant of JPEG (also in
>>the standard, and also not baseline) as well.
>
> Indeed. And no means of adding metadata (like EXIF say)
> making it even less useful as an image capture format.
PNG could be trivially extended to include EXIF data, if it's not
already possible.
--
Måns Rullgård
m...@inprovide.com
John Bean
Of course. But I'm talking about *now*, not "what if...".
As it stands now, PNG doesn't support metadata.
--
John Bean
John Bean
wrote:
>There is a project to support EXIF in PNG, although no software yet:
>http://pmt.sourceforge.net/exif/
Good. It could become a much more useful format in the
future as a result.
--
John Bean
Måns Rullgård
> Paul Rubin <http://phr...@nospam.invalid> wrote:
>>
>> There's a 16-bit extension for regular jpeg. I don't understand why
>> it's not more widely supported.
>
> I do. JPEG is a space-saving image format, not an archive format.
> Going from 8-bit to 16-bit color does not save space!
12-bit JPEG would retain the full dynamic range of the camera without
resulting in huge raw files requiring time consuming postprocessing.
> Måns Rullgård <m...@inprovide.com> wrote:
>> PNG is good for its intended use, which is simple drawings like web
>> graphics. It is less suited for photographs since the algorithm it
>> uses (essentially the same as zip) doesn't compress that type of data
>> very well.
>
> Baloney! PNG is better than TIFF-LZW for compressing photographs.
So? That doesn't make it ideal for photos. Lossless JPEG is still
better.
> Unlike standard JPEG, PNG is lossless.
Lossless JPEG is part of the standard (ITU T.81).
> I have used PNG for archiving for the past 5 years.
Proves nothing.
--
Måns Rullgård
m...@inprovide.com
Måns Rullgård
> PNG offers excellent lossless compression, and does have special
> compression capabilities for images that Zip files (for example) do not
> have.
PNG and zip use the same compression algorithm, so there should be
little difference between those two. Where PNG excels is where JPEG
fails miserably, i.e. non-photographic type images.
--
Måns Rullgård
m...@inprovide.com
David J Taylor
No, PNG also includes knowledge of images, so that it can do better than
the general purpose, non-data-specific Zip. Specifically, PNG can include
a line and/or pixel difference algorithm before the compression step.
David
Bill Tuthill
>
>> There is a project to support EXIF in PNG, although no software yet:
>> http://pmt.sourceforge.net/exif/
>
> Good. It could become a much more useful format in the
> future as a result.
The aforementioned website had not been updated since the year 2000,
and another web citation I found said the project had been abandoned.
I forgot to say that I've used PNG for archiving film scans, which
didn't have EXIF associated with them. For digital image archiving
I would use RAW or DNG.
Barry Pearson
So when DNG becomes the de facto standard raw format, raw will perhaps
cease to be that problem, and will be smaller than TIFF, while offering
better quality than JPEG.
--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/
Walter Dnes (delete the 'z' to get my real address)
> No, PNG also includes knowledge of images, so that it can do better
> than the general purpose, non-data-specific Zip. Specifically,
> PNG can include a line and/or pixel difference algorithm before
> the compression step.
bzip2 is an Open Source, free, multi-platform compression program
that walks all over zip for compressing TIFFs. See http://www.bzip.org
for downloads (or source code if you want to build it yourself). Here's
a test on my machine. The zip files were compressed with infozip at the
-9 (maximum) compression level. The zip files are 25-to-30% larger than
the bz2 files. The main disadvantage of bzip2 is that it compresses
files, period. It doesn't preserve permissions or do archives. In the
unix/linux world, tar is used to archive files with all attributes and
directories, and bzip2 then compresses the tarred archive.
9469952 p1010110.tif
3150395 p1010110.tif.bz2
4040548 p1010110.tif.zip
9469952 p1010111.tif
3271035 p1010111.tif.bz2
4182754 p1010111.tif.zip
9469952 p1010112.tif
3349007 p1010112.tif.bz2
4356461 p1010112.tif.zip
9469952 p1010113.tif
3563915 p1010113.tif.bz2
4437192 p1010113.tif.zip
9469952 p1010114.tif
4063460 p1010114.tif.bz2
5278460 p1010114.tif.zip
9469952 p1010115.tif
3561395 p1010115.tif.bz2
4633882 p1010115.tif.zip
9469952 p1010116.tif
3423767 p1010116.tif.bz2
4299136 p1010116.tif.zip
9469952 p1010117.tif
4111441 p1010117.tif.bz2
5229119 p1010117.tif.zip
9469952 p1010118.tif
3123296 p1010118.tif.bz2
4001000 p1010118.tif.zip
9469952 p1010119.tif
3456093 p1010119.tif.bz2
4415810 p1010119.tif.zip
--
Walter Dnes; my email address is *ALMOST* like wzal...@waltdnes.org
Delete the "z" to get my real address. If that gets blocked, follow
the instructions at the end of the 550 message.
David J Taylor
> On Wed, 21 Dec 2005 07:42:01 GMT, David J Taylor,
> <david-...@blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
> wrote:
>
>> No, PNG also includes knowledge of images, so that it can do better
>> than the general purpose, non-data-specific Zip. Specifically,
>> PNG can include a line and/or pixel difference algorithm before
>> the compression step.
>
> bzip2 is an Open Source, free, multi-platform compression program
> that walks all over zip for compressing TIFFs. See
> http://www.bzip.org
> for downloads (or source code if you want to build it yourself).
> Here's
> a test on my machine. The zip files were compressed with infozip at
> the -9 (maximum) compression level. The zip files are 25-to-30%
> larger than
> the bz2 files. The main disadvantage of bzip2 is that it compresses
> files, period. It doesn't preserve permissions or do archives. In
> the
> unix/linux world, tar is used to archive files with all attributes and
> directories, and bzip2 then compresses the tarred archive.
>
> 9469952 p1010110.tif
> 3150395 p1010110.tif.bz2
> 4040548 p1010110.tif.zip
Thanks for that, Walter.
It would be interesting to know the equivalent sizes for PNG compressed
files (and also setting PNG to the maximum but slowest compression for a
fair comparison).
David
Paul Rubin
> The main disadvantage of bzip2 is that it compresses
> files, period. It doesn't preserve permissions or do archives.
Bzip2 is also much slower and more memory intensive than
zip--sometimes that matters, sometimes not.
Bill Tuthill
>
>> No, PNG also includes knowledge of images, so that it can do better
>> than the general purpose, non-data-specific Zip. Specifically,
>> PNG can include a line and/or pixel difference algorithm before
>> the compression step.
>
> bzip2 is an Open Source, free, multi-platform compression program
> that walks all over zip for compressing TIFFs. See http://www.bzip.org
> for downloads (or source code if you want to build it yourself). Here's
> a test on my machine. The zip files were compressed with infozip at the
> -9 (maximum) compression level. The zip files are 25-to-30% larger than
> the bz2 files.
That is similar to the size advantage I have observed in PNG over ZIP.
Walter Dnes (delete the 'z' to get my real address)
Using the ImageMagick "convert" utility...
convert -quality 100 p1010110.tif p1010110.png
results in a 4034626 byte file. Saving in GIMP as a PNG, at maximum
compression, results in a 3395780 byte file.
David J Taylor
> On Thu, 22 Dec 2005 12:08:49 GMT, David J Taylor,
> <david-...@blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
> wrote:
>> Walter Dnes (delete the 'z' to get my real address) wrote:
>
>>> 9469952 p1010110.tif
>>> 3150395 p1010110.tif.bz2
>>> 4040548 p1010110.tif.zip
>>
>> Thanks for that, Walter.
>>
>> It would be interesting to know the equivalent sizes for PNG
>> compressed files (and also setting PNG to the maximum but slowest
>> compression for a fair comparison).
>
> Using the ImageMagick "convert" utility...
>
> convert -quality 100 p1010110.tif p1010110.png
>
> results in a 4034626 byte file. Saving in GIMP as a PNG, at maximum
> compression, results in a 3395780 byte file.
So a lot better than Zip, and almost as good as BZ2. Looks like
ImageMagick is failing to do the best for you.
David
gle...@gmail.com
Walter Dnes (delete the 'z' to get my real address) wrote:
> On Thu, 22 Dec 2005 12:08:49 GMT, David J Taylor, <david-...@blueyonder.co.not-this-bit.nor-this-part.uk.invalid> wrote:
> > Walter Dnes (delete the 'z' to get my real address) wrote:
>
> > > 9469952 p1010110.tif
> > > 3150395 p1010110.tif.bz2
> > > 4040548 p1010110.tif.zip
> >
> > Thanks for that, Walter.
> >
> > It would be interesting to know the equivalent sizes for PNG compressed
> > files (and also setting PNG to the maximum but slowest compression for a
> > fair comparison).
>
> Using the ImageMagick "convert" utility...
>
> convert -quality 100 p1010110.tif p1010110.png
>
> results in a 4034626 byte file. Saving in GIMP as a PNG, at maximum
> compression, results in a 3395780 byte file.
Try -quality 95 instead of -quality 100.
The final "0" digit of ImageMagick's quality figure tells convert to
use "0" PNG filtering,
while a "5" tells it to use PNG adaptive filtering.
Bill Tuthill
>
> Walter Dnes (delete the 'z' to get my real address) wrote:
>> Using the ImageMagick "convert" utility...
>> convert -quality 100 p1010110.tif p1010110.png
>> results in a 4034626 byte file. Saving in GIMP as a PNG,
>> at maximum compression, results in a 3395780 byte file.
>
> Try -quality 95 instead of -quality 100.
> The final "0" digit of ImageMagick's quality figure tells convert to
Did you figure that out by reading source code?
GIMP has settings 1 - 9 for PNG compression. With lossless formats
like PNG, higher compression values have equal image "quality", so
the ImageMagick -quality option is somewhat of a misnomer.
gle...@gmail.com
hijacked the JPEG -quality option. The 10's digit is the same as the
GIMP settings for zlib compression level, and the 1's digit is the PNG
filter type 0: none; 1; sub; 2: up, 3: average; 4: Paeth,
5: adaptive. Yes, the resulting "image quality" is identical for all
settings when writing
a PNG file.
Bill Tuthill
Higher compression settings just take longer to calculate, right?
(My version of) GIMP defaults to compression level 6, and lacks mechanism
to specify filtering (guess I should upgrade). In your previous post
you recommended compression level 9, adaptive filter 5.
Here are the timings, showing that level 9 takes about 3.5x as long
to achieve a 4.5% smaller file in this instance:
time convert -quality 95 image.jpg image.png
real 0m6.482s
user 0m5.997s
sys 0m0.079s
[191218 bytes]
time convert -quality 65 image.jpg image.png
real 0m1.790s
user 0m1.647s
sys 0m0.079s
[199688 bytes]
Walter Dnes (delete the 'z' to get my real address)
>
> Walter Dnes (delete the 'z' to get my real address) wrote:
>
> > Using the ImageMagick "convert" utility...
> >
> > convert -quality 100 p1010110.tif p1010110.png
> >
> > results in a 4034626 byte file. Saving in GIMP as a PNG, at maximum
> > compression, results in a 3395780 byte file.
>
> Try -quality 95 instead of -quality 100.
>
> The final "0" digit of ImageMagick's quality figure tells convert to
> use "0" PNG filtering, while a "5" tells it to use PNG adaptive
> filtering.
Learn something new every day...
convert -quality 95 p1010110.tif p1010110.png
takes twice as long as -quality 100, but the png file is 3386359 bytes.
John Faughnan
I asked a similar question about JPEG 2000 a while back:
http://groups.google.com/group/rec.photo.digital/browse_frm/thread/d8b83d310e91535d
My question also produced a range of responses, but none felt
satisfactory to me. As I read more about the power drains on large
sensor cameras I gradually settled on the explanation you have
succinctly presented.
So, I just want to say, for what it's worth, that you've summarized the
issues very well. I even read a report of a theoretical JPEG conversion
optimization that reduced power drains by more than one order of
magnitude. JPEG 2000 is computationally intensive, and the cost of
storage has fallen much faster than the power-cost of computation.
The latest versions of Adobe Acrobat can use JPEG 2000 to compress
documents. It's a great format for that as it maintains edges much
better than JPEG at very high compression values, and documents can be
huge and costly to transmit. It may even show up for sharing images on
the web (I hope so!). Alas, in camera JPEG 2000 seems to be doomed.
meta: jfaughnan, jgfaughnan, digital camera, compression, JPEG2000,
standards adoption
Bill Tuthill
> I asked a similar question about JPEG 2000 a while back:
> http://groups.google.com/group/rec.photo.digital/browse_frm/thread/d8b83d310e91535d
Interesting thread. Guido Vollbeding's prediction that JPEG+ will
supercede JPEG 2000 is novel. Whatever happened to that?
> My question also produced a range of responses, but none felt
> satisfactory to me. As I read more about the power drains on large
> sensor cameras I gradually settled on the explanation you have
> succinctly presented.
This was Martin Brown's short post as follows?
"It isn't better by a significantly large factor at high quality settings
to be worth the upheaval. J2k encoders are slow and power hungry.
JPEG is fast and extremely well optimised for use in digicams now.
"In essence J2k isn't enough of an improvement to become mainstream.
This may change one day, but don't hold your breath. "
> So, I just want to say, for what it's worth, that you've summarized the
> issues very well. I even read a report of a theoretical JPEG conversion
> optimization that reduced power drains by more than one order of
> magnitude. JPEG 2000 is computationally intensive, and the cost of
> storage has fallen much faster than the power-cost of computation.
By "one order of magnitude" do you mean 10 times? Last time somebody
made this remark they were calculating in base 2 and meant 2x.
> The latest versions of Adobe Acrobat can use JPEG 2000 to compress
> documents. It's a great format for that as it maintains edges much
> better than JPEG at very high compression values, and documents can be
> huge and costly to transmit. It may even show up for sharing images on
> the web (I hope so!). Alas, in camera JPEG 2000 seems to be doomed.
I'm not so sure. The problem with JPEG is that although it produces
excellent fidelity after in-camera processing, if you try to edit it
later, things get all messed up during re-encoding. What photographers
really need is a format that is computationally as simple as JPEG, and
about as compact as Q 99 4:2:2, but lossless.
John Faughnan
viewed as a thread.
Yes, the news report was a full order of magnitude on the energy costs
of the JPEG compression. It was a very esoteric and theoretical basic
science technique, it used some odd property of the sensor to speed the
encoding. Alas, I don't recall more.
"What photographers really need is a format that is computationally as
simple as JPEG, and about as compact as Q 99 4:2:2, but lossless."
DNG is computationally simple, it's somewhat compact, and it's
lossless. I don't know Q 99 4:2:2, but given the falling costs of
storage maybe DNG is compact enough. What do you think?
meta: jfaughnan, jgfaughnan, DNG, JPEG2000
Bill Tuthill
>
>> "What photographers really need is a format that is computationally as
>> simple as JPEG, and about as compact as Q 99 4:2:2, but lossless."
Q 99 4:2:2 means very high quality JPEG (99 on the IJG scale) with 4:2:2
chroma subsampling. That is the format used by most or all DSLR models
when writing Extra Fine JPEG.
> DNG is computationally simple, it's somewhat compact, and it's
> lossless. I don't know Q 99 4:2:2, but given the falling costs of
> storage maybe DNG is compact enough. What do you think?
Not compact enough. With some DSLR brands, DNG is more compact than RAW,
but not significantly, and not for all brands.
Some cameras, such as the new Sony R1, take 4 times longer to write RAW
than they do to write JPEG. DNG might be even slower because RAW would
have to be converted to 8- or 16-bit TIFF. (DNG uses TIFF internally)
I predict DNG will be less successful than PDF. PDF is very successful!
So I think that DNG might make a good RAW storage format, if you think
RAW conversion and editing may improve in the future. If you think RAW
is just a passing fad, and useless after proper conversion, than I think
PSD adjustment layers are a more efficient archive method.
David Dyer-Bennet
> Not compact enough. With some DSLR brands, DNG is more compact than RAW,
> but not significantly, and not for all brands.
DNG is half the size of RAW on my Fuji S2. I find this quite enough
to make it worth converting, that's a big difference. (S2 RAW files
are right about 12MB).
--
David Dyer-Bennet, <mailto:dd...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
Barry Pearson
[snip]
> Some cameras, such as the new Sony R1, take 4 times longer to write RAW
> than they do to write JPEG. DNG might be even slower because RAW would
> have to be converted to 8- or 16-bit TIFF. (DNG uses TIFF internally)
DNG is a raw file format. "Just" like others, but well-engineered and
published.
> I predict DNG will be less successful than PDF. PDF is very successful!
> So I think that DNG might make a good RAW storage format, if you think
> RAW conversion and editing may improve in the future. If you think RAW
> is just a passing fad, and useless after proper conversion, than I think
> PSD adjustment layers are a more efficient archive method.
Raw isn't a passing fad. It is a powerful tool for high quality digital
photography, for all the well-published reasons. It will get lots
easier to use, with better software, and perhaps services such as
printing services that accept it. (But I expect that they will
especially accept DNGs, because of the camera calibration data in them,
and because of the possibility for photographers to put their own
editing instructions into the DNGs as XMP metadata).
I archive both my DNGs, because they hold the maximum amount of
information so that I can go back and rework images, and any PSD that
has a lot of work on it, so that I can avoid redoing that work. It
isn't either/or, but both.
As you indicate above, the size of DNGs compared to JPEGs is a problem
for cameras. Even if they do maximum DNG lossless compression, it
typically only makes the DNG a little less than half the uncompressed
size. But one thing we know about IT is that speed increases year by
year, and memory costs reduce year by year. Think what memory cards
were like 5 years ago. Now guess what they will be like in 5 years
time, by extrapolation.
Bill Tuthill
>
>> Some cameras, such as the new Sony R1, take 4 times longer to write RAW
>> than they do to write JPEG. DNG might be even slower because RAW would
>> have to be converted to 8- or 16-bit TIFF. (DNG uses TIFF internally)
>
> DNG is a raw file format. "Just" like others, but well-engineered and
> published.
Does DNG preserve the Bayer-pattern raw pixel information? I thought not
but maybe missed something in the spec. I thought DNG is already converted
from raw pixel information to RGB data in TIFF-like format.
If DNG doesn't preserve raw pixel information, then everyone would have to
archive RAW anyway if they think conversion techniques will improve.
Barry Pearson
> Barry Pearson <ne...@childsupportanalysis.co.uk> wrote:
> >
> >> Some cameras, such as the new Sony R1, take 4 times longer to write RAW
> >> than they do to write JPEG. DNG might be even slower because RAW would
> >> have to be converted to 8- or 16-bit TIFF. (DNG uses TIFF internally)
> >
> > DNG is a raw file format. "Just" like others, but well-engineered and
> > published.
>
> Does DNG preserve the Bayer-pattern raw pixel information? I thought not
> but maybe missed something in the spec. I thought DNG is already converted
> from raw pixel information to RGB data in TIFF-like format.
The short answer is "YES"! The longer answer follows.
By default, for all colour filter array (including Bayer) sensors, the
sensor data remains in the DNG file without anything change whatsoever.
In other words, for everything with the possible exception of the
Sigma/Foveon sensor, it is a genuine raw image, needing full raw
conversion. In effect, the DNG file is "just" a different way of
wrapping up the raw image data. (Plus some useful additional data
fields!)
There is some doubt about what happens with the Sigma/Foveon raw image
data. One view is that the DNG Converter "linearises" it. The problem
with that view is that my own experiments suggest that the DNG does not
contain a simple linearisation of the Sigma/Foveon data. In particular,
it compresses very differently, so it is either not linearised, or it
is in a different order. I have been unable to get an answer from
Adobe.
There is a non-default option in the DNG Converter to "linearise" the
sensor data. And DxO can output a DNG in linearised form. But those are
exceptions. So, if you leave the options as defaults, and don't have a
Sigma/Foveon, and are not using DxO to generate your DNGs, you preserve
the original sensor data just as it came off the memory card.
Then, of course, some cameras and digital backs use DNG as their native
raw format. (Why not?) Obviously they use the default position, because
it is the only raw format they provide.
Bill Tuthill
>>
>> Does DNG preserve the Bayer-pattern raw pixel information? [snip]
>
> The short answer is "YES"! The longer answer follows.
Thanks for the answer and explanation. Bad spec reading on my part!
> By default, for all colour filter array (including Bayer) sensors, the
> sensor data remains in the DNG file without anything change whatsoever.
> In other words, for everything with the possible exception of the
> Sigma/Foveon sensor, it is a genuine raw image, needing full raw
> conversion. In effect, the DNG file is "just" a different way of
> wrapping up raw image data. (Plus some useful additional data fields!)
I was going to ask why so many vendors' RAW files are larger than DNG,
but you answered that in another thread, implying that everyone but Canon
uses poor compression algorithms. The Fuji S3 Pro RAW is twice as big,
and Nikon D200 is reportedly almost that bloated.
> There is a non-default option in the DNG Converter to "linearise" the
> sensor data. And DxO can output linearised DNG. But those are exceptions.
If one chose that option however, one loses the ability to reconvert
RAW to DNG in the future if better software becomes available, correct?
Barry Pearson
> > There is a non-default option in the DNG Converter to "linearise" the
> > sensor data. And DxO can output linearised DNG. But those are exceptions.
>
> If one chose that option however, one loses the ability to reconvert
> RAW to DNG in the future if better software becomes available, correct?
Remember that the DNG Converter doesn't alter or move the original raw
files. It generates new files. So if you keep your original files, you
can process them again later. But linearised DNGs cannot be converted
back to non-linearised DNGs.
It must be rare to have a need for linearised DNGs. I suspect most
people using DNG never bother with that non-default option.