Paul Shields wrote:
> ...I think the more pertinent question is - how many third party RAW editors
> use the Canon SDK? Last time I looked it could be counted on two fingers. The
> problem with the Canon SDK is that it still keeps certain information hidden
> away.
>
It appears that we may be misunderstanding each other. Let my elucidate
my position. Other than applying a patch to dcraw, which hardly counts,
I've never done anything at all like writing image processing software.
I have, however, written a fair amount of database and data manipulation
software in other areas, in a number of systems and languages. For the
vast majority of that work, I have had no idea whatsoever how the data
is stored as a string of bytes. On rare occasion, I've decoded some
stored data. While occasionally amusing, that was mostly frustrating and
generally unproductive. In a situation where memory was tight, I did
once code a bunch of on/off data at the bit level within bytes, eight
pieces of separate data per byte. That might have been fun for someone
else to go in and decode. :-)
I had one system I wrote that got data from another system. That other
system was originally written to use MS Access as backend during
development. Once stabilized, the data was removed from Access on a
network PC to Informix on a minicomputer in another state. As it turned
out, a couple of file names had to be changed to meet the rules of the
new enviroment. So I had to change a handful of lines of code, dead
simple and quick. Later, the data was moved again, to some monster
corporate database system in yet another location. I had to change a
setting in the link interface, that was all. My system went on without
missing a beat as the data changed physical location, hardware type, OS
and database backend system twice.
Perhaps you can see why I don't see knowledge of the underlying
structure in the source file as important.
In other cases, I've had to link to a different file driver when the
storage form/system has changed. About as easy, change a handful of
lines of code to identify the different driver name.
There are myriads of syntaxes, but the underlying things to be done are
always the same. If I want a piece of data, I might write something like:
key1 = a
key2 = b
key3 = c
get(thisfile,key1,key2,key3)
I still have no idea how the data is stored underneath, but the record
buffer now holds the values I want.
So I may be hallucinating, but I imagine a proper SDK providing, among
others, a function like getpixelvalues(r,c). Upon providing row and
column number of a pixel, such a function would provide a return value
of the brightness of the specified pixel. A nicety might be a second
return value indicating R, G or B.
With a later, more highly functional imaging system, the function might
add return values to let me know if the pixel had experienced overflow
and perhaps what the read value for it after clearing and before
exposure was. That would make quality processing of highlight and shadow
values easier and better.
Such a change would mean a revised data storage format, with more
fields. However, a proper development kit would include a driver that
would know the format from the header, and return the correct values for
new or old format - and probably a flag to indicate which form the data
is stored. This sort of arrangement provides stability for developers
and flexibility for hardware/firmware folks to change internal format as
may be needed.
If the SDKs for RAW files aren't providing that sort of functionality,
you are right, they may not be what is needed.
I still think a proper software environment as described above is a
better situation than a generic format. As I proposed above, it's not
unlikely that sensor systems will add information as they become more
sophisticated. The examples I mentioned above would be of immense value
to image processing.
If I know which pixels with the maximum value are actually that value
and which ones have overflowed, I should be able to write better
highlight recovery routines. But how does a predetermined format like
DNG allow for such changes and additions? One of the great failings of
some early PC database programs is that they couldn't tell you whether
the value in a field was actually an entered zero, or whether it had
never been set. Proper programming for many purposes then required not
only another field to hold that information, but additional code to deal
with it. Or one could lower the maximum value by one or more, which also
can work, but requires lots of extra code. Ick.
That's my perspective, and I think essentially all our detail
differences flow out of different perspectives. So I won't go on and
beat the details to death again.
Moose
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|