Cory Papenfuss wrote:
Yes. I believe that's right. The article referenced of course
presents the failure to utilise internal interpolation, and that you
have to convert "by hand", as an argument against RAW. I'm thinking
that the ideal format would be a file containing the Bayer data as
well as additional information representing *one possible*
transformation - so that the file might be stored or displayed as RGB
without no user interaction, while you also retained the opportunity
to use completely different interpolation parameters. But maybe they
do this already?
None that I know of do this. I think the difference is that TIFF
format allows for other *colorspaces* (Lab, CMYK, etc)... the Bayer
pattern is a slightly different animal. It's not really a colorspace
so much as spectral spatial filtering on an RGB image.
Yes, but isn't the Bayer pattern data somewhat analogues to YCbCr, i.e.
television-style encoding via luminance and crominance? This is part of
the TIFF spec, although not considered "baseline TIFF".
One could certainly define a baseline interpolation routine, but
that's beyond what TIFF does.
I, personally, think that the Bayer is a good compromise. It
provides luminance information at every pixel location. The chroma
is downsampled (2:1 for G, and 4:1 for B and R). Since that's not
too far from visual perception, it seems like an acceptable way to go.
It seems to me that what exactly constitutes "luminance" is still an
assumption, though. I'm wondering what the results might be like if
they also included some elements with no filter at all. Didn't Fuji
or someone try that, by the way?
I think some have used CMY, and some CMYK. I don't know for sure.
Luminance is fairly well defined, for an individual pixel, I'd say.
If you look at the datasheet for the sensor, it's got the respective
pixel color spectral response. The output is the integral of that
(i.e. filter) and the incident light. Mapping that to the human eye
response (XYZ space) is where it gets ugly.
I think they sorta did that. The TIFF has a number of funky
tags in it. Some are obviously proprietary.
This actually touches on some other recent discussions on the list,
since what you're saying here makes me think that the Pentax
engineers do indeed know what they are doing; taking an existing
format and adapting it just enough to suit your special needs (when
there is nothing available already that does) is good engineering,
IMO. Divining yet another way that's incompatible with everything
else to represent a picture would not be...
Differently put, it seems like Pentax have done this exactly the way
I would have ;-)
Pretty much... 'cept for the issues I've raised with technical
support. The biggest is the choice to have a full-blown (but yet low
quality) JPEG in the RAW. I'm sure they did it so it takes less CPU
to zoom in on camera and in their gimpy bundled software.
Possibly. If that's the case it would probably have made more sense to
have a prescaled version, though. Rather like a "multi-view" a.k.a.
"pyramid encoded" TIFF or a photo-CD image.
Do they follow the TIFF spec when storing the JPEG data, by the way?
The TIFF format for the -DS even tags the data as compression type
"PackBits," even though it's not quite what it actually is. Packbits
is a RLE compression... they abused the standard and called Packbits
two 12-bit numbers in three bytes. A play on language, perhaps... :)
Yeah, I guess can argue that they do pack the bits ;-) What do they call
the pixel data type, by the way?
-Cory
*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************
