Adobe - today the world, tomorrow the universe...

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

http://www.dpreview.com/news/0503/ [...] ectory.asp

--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

Alan Browne writes:

> http://www.dpreview.com/news/0503/ [...] ectory.asp

A solution looking for a problem.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <Jmz2e.76534$He3.1698998@wagner.videotron.net>,
Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote:
>
>http://www.dpreview.com/news/0503/05033002adobe_directory.asp

What if you're not an ASMP member?
All of a sudden, you're a second class citizen.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

"Alan Browne" <alan.browne@FreeLunchVideotron.ca> wrote in message
news:Jmz2e.76534$He3.1698998@wagner.videotron.net...
>
> http://www.dpreview.com/news/0503/ [...] ectory.asp
>

Oops, Bad link on the website for the ASMP!

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

On Wed, 30 Mar 2005 19:18:09 GMT, "Dave R knows who"
<kilbyfan@spamnotAOL.com> wrote:

>
>"Alan Browne" <alan.browne@FreeLunchVideotron.ca> wrote in message
>news:Jmz2e.76534$He3.1698998@wagner.videotron.net...
>>
>> http://www.dpreview.com/news/0503/ [...] ectory.asp
>
>BTW, How is their standard for the Digital Negative going? I read about
>this in a mag last year.
>

I know I'm backing up my RAW files as DNGs. I presently have a bunch
of Kodak files from the 90's I can no longer open because they have a
bad habit of totally dropping support for their products when there is
no more profit to be made from them.
RAW files that are totally proprietary to camera manufacturers make me
nervous. Everything looks pretty good right now, but 15 years from
now when we are running Windows ZX or Mac OS19 and the Nikon D1, Fuji
S2, and Canon 10D haven't been produced for that long I'd rather take
the 15 minutes now to double archive my images in an open source type
format than regret it at that point.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

"ian lincoln" <jessops@sux.com> wrote in news:9OE2e.1340$r47.1126
@fe3.news.blueyonder.co.uk:

> I would suggest a straight conversion to tiff. for your raw files.
> Information intact except the file sizes will be twice as large.

Except that TIF does not contain the entire info from the RAW.
Different RAW converters gives different results.

Another option is to make a copy of the dcraw code and then
use that code to decrypt your old RAW files.


/Roland

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis <johnf@panix.com> wrote:

> What if you're not an ASMP member?
> All of a sudden, you're a second class citizen.

A "General" member, too, which means you have to have made "most" of your
income from publishing sales for 3 years running. So much for breaking
into the biz...

Makes me glad I left photography behind as a profession when I did. The
business side of things is just a disaster any more.

On the other hand, at least the "directory" won't be full of people willing
to sell their work for next to nothing, which is a plus.

--
Jeremy | jeremy@exit109.com

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

Roland Karlsson wrote:

> "Gene Palmiter" <palmiter_gene@verizon.net> wrote in
> news:IhH2e.37406$oa6.5285@trnddc07:
>
>
>>I have completely moved to DNG. I convert straight off my camera. To
>>my way of thinking there is no downside. My Oly E-10 is getting
>>old...support could vanish any day. It still works but how long will
>>the software support the native format. I like the concept of DNG and
>>I see no downside to it.
>
>
> No downside, except it being ... ehem ... nothing?
>
> It is just a cointainer. RAW format is still RAW format
> - but now contained in DNG.

When converting to DNG one has the option of containerizing the RAW or
not. Once converted to DNG, if the RAW is not containered, then the
camera RAW cannot be (directly) resurected by Adobe s/w. I suppose that
they have no intention of doing so either. So perhaps a 3rd party will
write a utility to take DNG back to the OEM raw format for DNG's that
don't contain the OEM RAW.

--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

On 31 Mar 2005 16:38:04 GMT, Roland Karlsson
<roland_dot_karlsson@bonetmail.com> wrote:

>Personally I think that published specs for the format on
>all RAW formats and a free software that can read them all
>is a much better idea. Dcraw comes to my mind.

...and simply archive a copy of DCRAW or similar (inc. source code
where available) with the native RAW files.

Arguments that 'we won't be able to run that software in the future'
have so far been shown to be bogus. I can still run 8 bit ZX-81,
Commodore VIC-20, Sinclair Spectrum & BBC Micro software with suitable
(and free) emulators. These are 25 year old home micros, with
extremely limited popularity compared to MS-DOS based systems.

--
Owamanga!
http://www.pbase.com/owamanga

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <Xns962ABD8E2C2BFklotjohan@130.133.1.4>,
Roland Karlsson <roland_dot_karlsson@bonetmail.com> wrote:
>
>Personally I think that published specs for the format on
>all RAW formats and a free software that can read them all
>is a much better idea. Dcraw comes to my mind.

Then you miss the point. Dcraw not only knows how to read
many RAW files (which is a good thing) - it also imposes the
authors choice of RAW-to-RGB conversion algorithms (which isn't).

Furthermore, dcraw doesn't really understand much about the RAW
formats in question - just enough to know where the values from
the sensor are stored, and some (hard-coded, camera-dependent)
knowledge about the sensor layout.

Look at the DNG spec some time, and see how much additional
data is included besides the RAW sensor data values. Note,
too, that this data is all in a format for which the specs
have indeed been published - this isn't going to happen for
the proprietary file formats used by the manufacturers.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

Roland Karlsson writes:

> Except that TIF does not contain the entire info from the RAW.

What's missing?

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <jgho41tk1a8c9p8k1n6tjcud9b1j927bp7@4ax.com>,
Mxsmanic <mxsmanic@hotmail.com> wrote:
>Roland Karlsson writes:
>
>> Except that TIF does not contain the entire info from the RAW.
>
>What's missing?

The RAW data.

Every RAW-to-RGB converter applies its own algorithms to the
raw sensor values, a process which is generally not reversable.

If you decide, at a later date, that a different RAW converter
produces better results, you're not going to be able to go back
and use that new converter on your old images if all you saved
was a TIFF file generated by the converter you were using then.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In rec.photo.digital Roland Karlsson <roland_dot_karlsson@bonetmail.com> wrote:
>Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote in news:TzV2e.3805
>$rl.129237@weber.videotron.net:

>> When converting to DNG one has the option of containerizing the RAW or
>> not. Once converted to DNG, if the RAW is not containered, then the
>> camera RAW cannot be (directly) resurected by Adobe s/w. I suppose that
>> they have no intention of doing so either. So perhaps a 3rd party will
>> write a utility to take DNG back to the OEM raw format for DNG's that
>> don't contain the OEM RAW.
>>

>The idea behind DNG is that RAW formats are similar. They are
>almost all Bayer matrices. But - there are problems. The Fuiji
>being the most complicated problem - with both 45 degree
>tilted images and the double images with different sensitivity.

>Personally I think that published specs for the format on
>all RAW formats and a free software that can read them all
>is a much better idea. Dcraw comes to my mind.

Published specs! Oh my....

Utopia at last.

----- Paul J. Gans

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

looks like the problem adobe is trying to solve is the prevalence of bootleg
versions of ps.
i expect they'll ask for your ps registration b4 they list you in their
directory, no?

"Roland Karlsson" <roland_dot_karlsson@bonetmail.com> wrote in message
news:Xns9629D342E72CBklotjohan@130.133.1.4...
> Mxsmanic <mxsmanic@hotmail.com> wrote in
> news:masl4195mjps6makco096g519u2engimq5@4ax.com:
>
> > Alan Browne writes:
> >
> >> http://www.dpreview.com/news/0503/ [...] ectory.asp
> >
> > A solution looking for a problem.
> >
>
>
>
> Sure looks that way. I wonder if any digital photographer really
> has been waiting for an Adobe creative community directory?
>
>
> /Roland

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <d2hqg1$gr7$1@inews.gazeta.pl>,
Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>What DNG could have been was merely a container for the RAW, a model
>descriptor and a description of how to decode that particular variant of
> it (in a HOL form).

HOL?

I see DNG as pretty close to the first two parts of what you describe;
a container for the RAW, and tags to describe the sensor attributes.

I'm not sure that a DNG should contain a description of how to decode
the data, if by that you mean convert it to RGB; I see that as beyond
the scope of a RAW file format. If I'm misinterpreting your point,
and you're only suggesting it should describe the colour filters, etc.,
which were used to generate the raw sensor readings at a sensor site,
then a DNG already contains that, as well.

Just how does a DNG differ from what you would perceive as the ideal?

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis wrote:

> In article <d2hqg1$gr7$1@inews.gazeta.pl>,
> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>>What DNG could have been was merely a container for the RAW, a model
>>descriptor and a description of how to decode that particular variant of
>> it (in a HOL form).
>
>
> HOL?

High Order Language (C, Ada, many others)

It can even be a very generic language (very Pascal like) easilly
convertible to whatever HOL is preffered by you. Just embed that
descriptor language with every file. A couple KB at most.

> I see DNG as pretty close to the first two parts of what you describe;
> a container for the RAW, and tags to describe the sensor attributes.
>
> I'm not sure that a DNG should contain a description of how to decode
> the data, if by that you mean convert it to RGB; I see that as beyond
> the scope of a RAW file format. If I'm misinterpreting your point,
> and you're only suggesting it should describe the colour filters, etc.,
> which were used to generate the raw sensor readings at a sensor site,
> then a DNG already contains that, as well.
>
> Just how does a DNG differ from what you would perceive as the ideal?

IMO the DNG should be close to what it is, but should also contain the
recipe to decode it in a human and near-to-machine readable form. This
last bit so that code can easilly be written for it on pretty much any
compiler with little fuss.

Why? Well configuration control is tough. It's not always easy to find
the right decoder for a particular format of data. If each file also
contained the recipe, then any cook could deliver the dinner. As file
sizes go up, the amount of code required to decode them gets smaller and
smaller in comparative size.

This is why film is so nice. It's not analog, it's image. You don't
need anyhting to decode it other than a source of light behind it.

Another way to backup digital? Have it printed to a slide! <runs>

Cheers,
Alan.

--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis wrote:

>>IMO the DNG should be close to what it is, but should also contain the
>>recipe to decode it in a human and near-to-machine readable form. This
>>last bit so that code can easilly be written for it on pretty much any
>>compiler with little fuss.
>
>
> The problem there is that there isn't a unique way of getting from the
> RAW sensor values to a RGB image format. Even with a single sensor
> pattern, the common RGBG Bayer array, there are multiple different
> algorithms available today (and, no doubt, new and better ones yet
> to be published). The choice of algorithm determines how you need
> to access the raw sensor values.

But that's precisely why I say put the description in the file. If, for
instance the DNG converter can read the RAW then it can encode the means
to read the containerized RAW in the DNG. That's all.


>
> Add to that the problems of the shifted or rotated Bayer array,
> or a sensor with site layout not based on a rectangular grid,
> and the idea of embedding metacode seems less and less practical.
>
> I think that the DNG approach, which can be viewed as a DDL (Data
> Description Language) is more flexible in the long term.

Is it so? I'm not sure it has description built in, just the tags
saying "I come from Mars V 2.7.3.2.a with a dash of lime juice."

>
> Sure, you're going to run into situations where a DNG-to-RGB
> converter will come across a DNG format it doesn't understand.
> But if it doesn't understand the data format, it's unlikely
> that the algorithm(s) it uses to generate the RGB values will
> map cleanly onto the new pattern.

er, that's why the HOL. Can't miss, it was matched at conversion time.
If you can adapt and compile the code you can get the data out.

Cheers,
Alan


--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis writes:

> The RAW data.
>
> Every RAW-to-RGB converter applies its own algorithms to the
> raw sensor values, a process which is generally not reversable.
>
> If you decide, at a later date, that a different RAW converter
> produces better results, you're not going to be able to go back
> and use that new converter on your old images if all you saved
> was a TIFF file generated by the converter you were using then.

If color digital cameras produced true RGB output to begin with, no
"conversion" would be necessary.

--
Transpose hotmail and mxsmanic in my e-mail address to reach me directly.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <d2i6b4$hia$1@inews.gazeta.pl>,
Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>As you can see from the above, the notion I'm describing is to have the
>description of how to decode the particular file in the file. If you
>have a thousand files from the same camera/sensor, they'll all have the
>same decoing instructions. OTOH, if you have a thousand files from a
>thousand different cameras/sensors, they'll each have unique
>instructions according to the camera/sensor used to capture that image.

You obviously still don't get it.

What it the end result of this "decoding" ?

It can't be a rectangular 2-D array of RGB pixels, because that's going
to embed a particular "decoding" algorithm to get from the existing
layout of sensor sites to those RGB values.

Look at all the different sensor layouts that already exist.
RGBG rectangular-grid Bayer arrays; Foveon sensors (which do
measure all three components at each sensor site); the Fuji
sensors (grid rotated by 45 degrees) and super-sensors (with
an extra measurement at some of the sites), and some of the
other staggered-array sensors.

How can you "decode" these into a common format?
It's just about plausible to contemplate this for sensors
where the sensor sites are already laid out in such an array
(although the advantage of doing this are questionable; the
"decoding" step is pretty much just a copy, with the only
part that is in any way complex is deciding which components
of the RGB value are populated from the raw sensor data).
You don't fill in missing components; that's the job of the
RAW conversion algorithm, which the user has to be free to
select.

But how about those other layouts? How do you "decode" those
without embedding a particular RAW-to-RGB conversion algorithm?


To summarize: With sensors that are laid out in a 2D grid,
the "decoding" is so straightforward that it doesn't need
code embedded in the RAW file. For other sensor layouts,
you don't have a way to "decode" the data into a 2D grid
without performing some processing on the data, which is
contrary to the spirit of a RAW file format.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis wrote:

> In article <d2i6b4$hia$1@inews.gazeta.pl>,
> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>>As you can see from the above, the notion I'm describing is to have the
>>description of how to decode the particular file in the file. If you
>>have a thousand files from the same camera/sensor, they'll all have the
>>same decoing instructions. OTOH, if you have a thousand files from a
>>thousand different cameras/sensors, they'll each have unique
>>instructions according to the camera/sensor used to capture that image.
>
>
> You obviously still don't get it.

Mirror handy?

>
> What it the end result of this "decoding" ?
>
> It can't be a rectangular 2-D array of RGB pixels, because that's going
> to embed a particular "decoding" algorithm to get from the existing
> layout of sensor sites to those RGB values.

You're standing much too close to the trees. All I'm saying is that

1) the file (DxNxGx) could contain the algorithm (in a descriptive human
readable form) to take the content of the RAW part of the file and
convert it into an X,Y matrix consisting of RGB points of arbitrary depth.

2) For a Canon 20D, one description;
For a Maxxum 7D, another;
For a Sigma 10D, a very different one;
For a S3, a pretty different one again.

I never said it would be simple, but defineitley it is feasible.

>
> How can you "decode" these into a common format?
> It's just about plausible to contemplate this for sensors
> where the sensor sites are already laid out in such an array
> (although the advantage of doing this are questionable; the
> "decoding" step is pretty much just a copy, with the only
> part that is in any way complex is deciding which components
> of the RGB value are populated from the raw sensor data).
> You don't fill in missing components; that's the job of the
> RAW conversion algorithm, which the user has to be free to
> select.
>
> But how about those other layouts? How do you "decode" those
> without embedding a particular RAW-to-RGB conversion algorithm?

THAT'S WHAT I'VE BEEN SAYING: Embed the layout-specific algorithm in
the image file, but in a human readable HOL format that can be put into
a program and recompiled to read the RAW and output an RGB matrix
convenient to the new computer, os, environment, etc.

It's not about being automatic, it's about self documenting image files.

Here's one. See if you can read the last line.

------------FILE BEGINS---------------
------------DESCRIPTION BEGINS--------
This file is in ROT-13. In ROT-13, Alpha characters are offset by 13
positions. To decode, read after the DESCRIPTION ENDS LINE BELOW.
BEGIN
Repeat
C<= GETCHAR (InFile);

IF C IN ['A'..'Z'] THEN
BEGIN
IF C < "N" THEN C<=C+ORD("M" )
ELSE C<=C-ORD("N" )
END
ELSE
IF C IN ['a'..'z'] THEN
BEGIN
IF C < "n" THEN C<=C+ORD("m" )
ELSE C<=C-ORD("n" )
END;
Write (OutFile(C));
Until EOF;
END;
------------DESCRIPTION ENDS------------
Qb lbh trg vg?
------------FILE ENDS ------------------

Didya?

Cheers,
Alan
--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

John Francis wrote:

> In article <d2ig0o$rfb$1@inews.gazeta.pl>,
> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>>THAT'S WHAT I'VE BEEN SAYING: Embed the layout-specific algorithm in
>>the image file, but in a human readable HOL format that can be put into
>>a program and recompiled to read the RAW and output an RGB matrix
>
>
> We all fully understand that's what you've been saying.
> And, despite being told over and over again, you totally fail
> to grasp the fact that conversion from RAW to an RGB matrix
> is not a uniquely-defined process; there are many possibilities.
>
> That is what a RAW converter does; if you're going to embed a
> single RAW-to-RGB conversion algorithm you might just as well
> save the result as an RGB TIFF file, and forgo any RAW format.
>
> One reason that there is enthusiasm for RAW formats in general
> is because it allows you to go back and reconvert those old RAW
> files when a better algorithm comes along, or simply to choose
> a different RAW converter for different situations.
>
> Your approach removes that possibility; you are limiting users
> to what can be achieved by image processing after conversion
> to an RGB matrix using the algorithm embedded in the file.

Not at all. The description (algorithm) allows the future reader to
understand exactly how the sensor that took that image is layed out.
From there he can do whatever he likes with it. And that is the point.
If you find a RAW file in the future and you don't know what the
physical layout is you can't do much with the RAW data except by trial
and error.



--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <Gnc3e.31135$rl.738189@weber.videotron.net>,
Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote:
>John Francis wrote:
>
>> In article <d2ig0o$rfb$1@inews.gazeta.pl>,
>> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>>
>>>THAT'S WHAT I'VE BEEN SAYING: Embed the layout-specific algorithm in
>>>the image file, but in a human readable HOL format that can be put into
>>>a program and recompiled to read the RAW and output an RGB matrix
>>
>> Your approach removes that possibility; you are limiting users
>> to what can be achieved by image processing after conversion
>> to an RGB matrix using the algorithm embedded in the file.
>
>Not at all. The description (algorithm) allows the future reader to
>understand exactly how the sensor that took that image is layed out.

That's in direct contradiction to what you state above. If you
wrap the embedded HOL and compile it, it's going to produce an
RGB matrix. That's not a suitable pre-processing step for input
to an image reconstruction algorithm, so you can't use that code.

If I need to know the true sensor layout (and to get at the actual
sample values at the sensor site) I don't see how reverse-engineering
a piece of HOL, no matter how self-documenting it is, is much better
than inspecting the value in the Sensor Layout tag, and reading the
documentation for that tag.

Furthermore, even if you could solve that problem, you're still
going to come up against the difficulty that image reconstruction
isn't a problem with a unique solution. For example: take a much
simpler problem, that of up-sizing an image. There you already
know that you're starting with a fully-populated 2D RGB matrix.
Despite that, there are still people sell plug-ins for Photoshop,
or entire packages such as Genuine Fractals, because there is no
one-size-fits-all solution to the problem.

Or let's take an even simpler case. We know the sensor is a
regular RGBG Bayer array; we want the G component at one of the
sites where it isn't directly measured. What is that value?
You can't answer that question until you know what choice has
been made for the image reconstruction algorithm.

In fact that, in a nutshell, pinpoints the issue. You say:

>>>THAT'S WHAT I'VE BEEN SAYING: Embed the layout-specific algorithm

And you can't do that. The best you can do is embed *a* layout-
specific algorithm - there is no unique solution to the problem.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <d2i0un$hf9$1@reader1.panix.com>,
John Francis <johnf@panix.com> wrote:
>I suppose if you treated the RAW file as a list of totally independent
>sensor readings, each of which bundled the sensor value (or values),
>XY coordinates, some descriptor of the sampling area shape, and some
>way of describing what filter (or, even worse, filters) affected the
>sample value, you could come close to writing a general-purpose image
>reconstruction algorithm. That algorithm would be orders of magnitude
>more complicated than the reconstruction algorithms in use today, and
>would run slower (I'd estimate at best 1000 times as long as typical
>Bayer reconstruction algorithms, and I think I'm being very generous).

What is wrong with that?

You can have special case algorithms that deal with the easy cases and
leave the general one for situations you didn't expect.

Suppose that you can have a special case algorithm for normal RGBG
rectangular sensor and suddenly Fuji comes along with a rotated sensor
and with non-uniform site distribution. In that case you can convert the
Fuji images at a slow speed until you manage to get a special case
algorithm for those sensors.


--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <d2pn22$nh4$1@reader1.panix.com>,
John Francis <johnf@panix.com> wrote:
>In article <mhne15pdlrat4k0hch76ur8g14@inews_id.stereo.hq.phicoh.net>,
>Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>>
>>What is wrong with that?
>>
>>You can have special case algorithms that deal with the easy cases and
>>leave the general one for situations you didn't expect.
>
>That wasn't possible under the original scenario - there would only have
>been the general-purpose access mechanism. If you allow for alternate
>access mechanisms for those special-case algorithms you need some way
>of describing the layout so that people can code those alternates.

A general purpose format is useful only if it doesn't get in the way.

It sort of depends on what you want to do. A camera manufacturer has to
be convinced that using a standard format simplifies things (or meets a
strong demand from the market). Otherwise there is no point in switching.

On the other hand, it may be a good idea to convert RAW images to a standard
format and archive both he original image and the converted image. That
ensures that you can access your images in future even if the original
RAW converter no longer works.

In the first case, the standard format has to be very extensible. In the
second case, it just has to work for existing formats and can be
extended when required.

>In practice, of course, nobody would bother using an image reconstruction
>algorithm that ran multiple orders of magnitude slower than special-case
>code,

Why? I don't have raw converters for every possible camera. Even if
a general purpose converter would take an hour, it would be a better deal
then looking for some software if you just want to convert one image.

>so you wouldn't even have the general-case framework available in
>many of the conversion utilities. Nor, for that matter, would anybody
>bother to create the general-purpose code for inclusion in a RAW file
>format if they didn't need it for the converter they were supplying.

The general purpose converter would be a proof of concept that the format
actually works (in the general case). Releasing it as open source
ensures that everybody has access to that code.

>Mandating it as part of a proposed standard for a common RAW file
>format would just ensure that manufacturers were less likely to adopt
>the proposed format.

If you give away a reference implementation for free, there is much better
chance that things get adopted.

>That doesn't mean it would be a bad approach for somebody trying to
>build an extensible converter - it's going to be a lot faster to code
>up access methods like that than it would be to recast your favourite
>reconstruction algorithm to work at full speed with a new sensor.
>But most peole would regard that as merely a stopgap solution.

For archives, having something that is guaranteed to work is a good idea.


--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <r0g4e.37879$5A5.636436@weber.videotron.net>,
Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote:
>John Francis wrote:
>
>> In article <mhne15pdlrat4k0hch76ur8g14@inews_id.stereo.hq.phicoh.net>,
>> Philip Homburg <philip@pch.home.cs.vu.nl> wrote:
>>
>>>What is wrong with that?
>>>
>>>You can have special case algorithms that deal with the easy cases and
>>>leave the general one for situations you didn't expect.
>>
>>
>> That wasn't possible under the original scenario - there would only have
>> been the general-purpose access mechanism. If you allow for alternate
>> access mechanisms for those special-case algorithms you need some way
>> of describing the layout so that people can code those alternates.
>
> From your first reply, you have misconstued what it was that I
>proposed. What I proposed was that for a RAW image from a particular
>sensor type the image embeded HOL algorithm would contain the code
>specific to that type sensor. You misunderstood from the begining the
>reason for it as well as the functioning of it.

Are you now claiming that you didn't even propose that the output from
that HOL code should be a 2D array of RGB pixels? Or do you still
believe that there is a unique way of doing this for any given sensor?

You proposed it should contain HOL code, rather than any other form
of description. Every time I pointed out a problem with *using* that
HOL code (quite apart from any practical issues to do with the need
for some sort of infrastructure to turn meta-code into the language
of choice for the implementer) you back-pedalled, and claimed that
wasn't what you had actually said (when you weren't too busy simply
making derogatory remarks, or posting silly little pseudo-code jokes).

At this point it's getting hard to see just what your objection is
to the current mechanism that DNG provides.

Perhaps, at this point, you should try getting a little closer to
the trees yourself (if it's possible to get closer to the trees
than actual code), and produce a metacode fragment to handle the
very simple case I mentioned earlier - the RGB pixel value (or at
least the green component thereof) from a Bayer-pattern RGBG
sensor, at a sensor site where this isn't actually measured.

Then, perhaps, you'll get an understanding of the practical problems.

Archived from groups: rec.photo.equipment.35mm,rec.photo.digital,rec.photo.digital.slr-systems (More info?)

In article <M7i4e.46803$5A5.697804@weber.videotron.net>,
Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote:
>
> The problems that I was addressing was the problem of knowing
>what decoding or translation is appropriate to a file of _uncertain_
>origin. If you include knowledge of the origin in the file, then the
>file can be decoded.

Which makes it hard to understand why you brought this up in a
discussion of DNG, as a shortcoming: DNG mandates a scheme for
identifying the sensor geometry. Thst makes it rather hard to
come up with a DNG file of _uncertain_ origin.

>You've been bobbin' and weavin to avoid acknowledging your own
>misunderstanding from the beginning. Doesn't impress anyone.

I suggest you take your own advice, and look in a mirror.
You levelled your criticism at an inappropriate target - far
better to criticise the camera-specific RAW files, which have
no such information - you proposed a poorly-thought-out method
for addressing the problem, which did no such thing, and would
also be extremely unlikely to be adopted in the very case where
it might conceivably offer an advantage, and you've consistently
attempted to insist that you're right, but just misunderstood,
while shifting your position so often it's hard to keep track.
(And throwing in ad-hominems, to boot - who cares what I was
doing in 1983? Is it in the least bit relevent to the facts?)

I sure don't know who you think *you* are impressing.