Sign in with
Sign up | Sign in
Your question

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

Last response: in Digital Camera
Share
Anonymous
March 30, 2005 2:13:48 PM

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

http://www.dpreview.com/news/0503/05033002adobe_directo...

--
-- 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.
Anonymous
March 30, 2005 11:07:19 PM

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_directo...

What if you're not an ASMP member?
All of a sudden, you're a second class citizen.
Anonymous
March 30, 2005 11:07:20 PM

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

John Francis wrote:

> In article <Jmz2e.76534$He3.1698998@wagner.videotron.net>,
> Alan Browne <alan.browne@FreeLunchVideotron.ca> wrote:
>
>>http://www.dpreview.com/news/0503/05033002adobe_directo...
>
>
> What if you're not an ASMP member?
> All of a sudden, you're a second class citizen.

Aha! You get it.



--
-- 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.
Related resources
Anonymous
March 30, 2005 11:18:09 PM

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/05033002adobe_directo...

BTW, How is their standard for the Digital Negative going? I read about
this in a mag last year.
Anonymous
March 30, 2005 11:18:10 PM

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/05033002adobe_directo...
>
>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.
Anonymous
March 30, 2005 11:19:40 PM

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/05033002adobe_directo...
>

Oops, Bad link on the website for the ASMP!
Anonymous
March 31, 2005 12:35:17 AM

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

Mxsmanic <mxsmanic@hotmail.com> wrote in
news:masl4195mjps6makco096g519u2engimq5@4ax.com:

> Alan Browne writes:
>
>> http://www.dpreview.com/news/0503/05033002adobe_directo...
>
> 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
Anonymous
March 31, 2005 1:24:21 AM

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

"McLeod" <cerveza@xplornet.com> wrote in message
news:2s0m419bdj43ra02m4mkrmr4kdtsdvsbjf@4ax.com...
> 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/05033002adobe_directo...
>>
>>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.

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


> 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.
Anonymous
March 31, 2005 2:12:41 AM

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
Anonymous
March 31, 2005 2:31:47 AM

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

They used to say that about lasers.

Rob

===============

"Mxsmanic" wrote ...

> A solution looking for a problem.
Anonymous
March 31, 2005 4:14:32 AM

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

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.


"McLeod" <cerveza@xplornet.com> wrote in message
news:2s0m419bdj43ra02m4mkrmr4kdtsdvsbjf@4ax.com...
> 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/05033002adobe_directo...
> >
> >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.
Anonymous
March 31, 2005 4:36:08 AM

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
Anonymous
March 31, 2005 8:04:20 PM

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

"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.


/Roland
Anonymous
March 31, 2005 8:04:21 PM

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.
Anonymous
March 31, 2005 8:38:04 PM

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 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.


/Roland
Anonymous
March 31, 2005 8:38:05 PM

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

Roland Karlsson 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.

It is non proprietary:
http://www.adobe.com/products/dng/pdfs/dng_spec.pdf

"About This Document
The Digital Negative (DNG) Specification describes a non-proprietary
file format for storing camera raw files that can be used by a wide
range of hardware and software vendors. This section contains
information about this document, including how it is organized and
where to go for additional information.

Audience This document is intended for developers of hardware and
software applications that will generate, process, manage, or archive
camera raw files."


--
-- 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.
Anonymous
March 31, 2005 8:50:40 PM

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
Anonymous
March 31, 2005 9:23:25 PM

Archived from groups: 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.

The real win with DNG will come when it's adopted as the native RAW
format of most cameras. There's no need AFAIK for more than one RAW
format in the world, and DNG should be that format, because it's
open and will probably remain that way.

IMHO anyway.

--
Ben Rosengart (212) 741-4400 x215
Sometimes it only makes sense to focus our attention on those
questions that are equal parts trivial and intriguing.
--Josh Micah Marshall
Anonymous
March 31, 2005 9:23:26 PM

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

On Thu, 31 Mar 2005 17:23:25 +0000 (UTC), Ben Rosengart
<br+rpdss@panix.com> wrote:

>The real win with DNG will come when it's adopted as the native RAW
>format of most cameras. There's no need AFAIK for more than one RAW
>format in the world, and DNG should be that format, because it's
>open and will probably remain that way.

The problem with that is that the camera manufacturers will never go
for it. The Sony 6.1 Megapixel sensor is in a lot of cameras, but the
image file looks different out of every camera due to the way the
voltages are converted to digital information by each manufacturer-and
each different camera, for that matter.
Anonymous
March 31, 2005 9:43:17 PM

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.
Anonymous
March 31, 2005 10:09:34 PM

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

johnf@panix.com (John Francis) wrote in news:D 2hcrl$jnq$1
@reader1.panix.com:

> 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).

Thats a point. It is rather easy though to just use the
reading part of the code.

> 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.

Jupp - I have seen that. Irritating. Very irritating.
Dcraw does not try to find the fields where the sensor
size is stored. Instaed it knows the size. Then you have to
port the program to every new camera that comes out.

> 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.

Hmmmmm ... I get somewhat less sure :) 


/Roland
Anonymous
March 31, 2005 11:27:23 PM

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

In article <Xns962ACD123AEC4klotjohan@130.133.1.4>,
Roland Karlsson <roland_dot_karlsson@bonetmail.com> wrote:
>johnf@panix.com (John Francis) wrote in news:D 2hcrl$jnq$1
>@reader1.panix.com:
>
>> 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).
>
>Thats a point. It is rather easy though to just use the
>reading part of the code.

And do what with it? Incorporate it, at the source level, in
every single RAW-to-RGB converter, so we need to wait for each
converter to be re-released every time there's an update to dcraw
to handle the new file format? That's no better than what we
have today (in fact it's worse, given how little of the file
is actually used by dcraw - a problem that wouldn't be solved
by linking the converter to a dcraw-reader-based library).

Or, perhaps, have a separate RAW file reader utility, that reads
the RAW file, and re-writes a standard manufacturer-independent
RAW file format that can be understood by all the converters?

That's precisely what DNG is supposed to be.

>Dcraw does not try to find the fields where the sensor
>size is stored. Instaed it knows the size. Then you have to
>port the program to every new camera that comes out.

That's just the tip of the iceberg. Theres much more information
in a RAW file; there's useful data in all those EXIF fields (which
need to be copied into any intermediate and/or converted file)

I don't share your optimism that the manufacturers will release
the full specifications of their current raw file formats.
Fortunately there has been considerable progress in reverse-
engineering raw file formats, so it would be quite practical
to write an open source equivalent to the DNG converter.
Anonymous
March 31, 2005 11:49:27 PM

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

johnf@panix.com (John Francis) wrote in news:D 2hiur$dv6$1
@reader1.panix.com:

> I don't share your optimism that the manufacturers will release
> the full specifications of their current raw file formats.

Oh - I don't think they would do that. For some obscure reason
they don't want the files that their cameras output to come
to the full potential. Strange indeed. I think that Canon even
encrypted the first RAW formats. Totally unbelievable.
Crippling their products for no good reasons at all IMHO.

> Fortunately there has been considerable progress in reverse-
> engineering raw file formats, so it would be quite practical
> to write an open source equivalent to the DNG converter.

OK - sounds interesting. Any pointers?

There are two main reasons for my scepticism about DNG.

1. Everything that Adobe makes and touches is very expensive somewhere.
DNG (being an open format) might be different. But ... in some way you
need to convert the RAW files to DNG. And ... . just call me paranoid,
but I sense some hundreds of dollars that I have to pay somewhere
here.

2. The name D and the N in DNG are ... ehem ... big words: digital
negative. Currently the RAW format Bayer cameras are dominating
the market - and there are really very few sensors used and the
spread in funtionality is limited. But ... for how long. Whats
coming next? Is Bayer going to be the dominating format? Is even
a regular grid going to survive - how about random grids.
Standardizing too early might lead to stagnation. We might miss
fantastic things.


/Roland
Anonymous
March 31, 2005 11:49:28 PM

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

Roland Karlsson wrote:

> 1. Everything that Adobe makes and touches is very expensive somewhere.
> DNG (being an open format) might be different. But ... in some way you
> need to convert the RAW files to DNG. And ... . just call me paranoid,
> but I sense some hundreds of dollars that I have to pay somewhere
> here.

PDF. I've never paid a dime for it, but I've benefitted countless times
from people/companies using it to publish useful docs. With Elements
3.0 you can write photos to pdf, so I guess I'll finally be paying a
small fraction for it.

>
> 2. The name D and the N in DNG are ... ehem ... big words: digital
> negative. Currently the RAW format Bayer cameras are dominating
> the market - and there are really very few sensors used and the
> spread in funtionality is limited. But ... for how long. Whats
> coming next? Is Bayer going to be the dominating format? Is even
> a regular grid going to survive - how about random grids.
> Standardizing too early might lead to stagnation. We might miss
> fantastic things.

Each RAW decoder has to know the particular arrangement of the sensor.
The sensor makers design the sensor for a physcial goal, not to satisfy
RAW decoders. (The horse is ahead of the cart).

I would contend that as long as there is means to read the original RAW
file from the camera, that is all that is really needed for information
security and whatever creative benefit might come from the image. The
web is a great place for the OEM's to store the algorithms for very long
times. (As Owamanga pointed out, there is lots of support for micros
from 20+ years ago).

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).


--
-- 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.
Anonymous
April 1, 2005 12:07:28 AM

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
Anonymous
April 1, 2005 12:14:02 AM

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:
>johnf@panix.com (John Francis) wrote in news:D 2hiur$dv6$1
>@reader1.panix.com:

>> I don't share your optimism that the manufacturers will release
>> the full specifications of their current raw file formats.

>Oh - I don't think they would do that. For some obscure reason
>they don't want the files that their cameras output to come
>to the full potential. Strange indeed. I think that Canon even
>encrypted the first RAW formats. Totally unbelievable.
>Crippling their products for no good reasons at all IMHO.

There is Great Fear in corporations (mainly by sales
executives) that if they were to release the information
*somebody* might write a killer application of some sort
using the RAW data directly.

I think that corporations ought to decide what business
they are in. Canon is not really a software company.
Any killer software application will only increase
the level of hardware sales.

Or so I think.

---- Paul J. Gans
Anonymous
April 1, 2005 12:16:55 AM

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

On 31 Mar 2005 19:49:27 GMT, Roland Karlsson
<roland_dot_karlsson@bonetmail.com> wrote:
>
> There are two main reasons for my scepticism about DNG.
>
> 1. Everything that Adobe makes and touches is very expensive somewhere.

Not exactly. They give things away when it suits their interests.
For example, they give away Acrobat Reader because that helps sell
the tools that are used to generate PDFs.

I see DNG Converter as a similar thing. If they can get the camera
manufacturers to support it natively, then they won't have to scramble
to support new RAW formats with every camera release. This would free
up engineering resources for, you know, actual productive stuff. :-)

Charging money for DNG Converter would not serve this goal, so I
don't think they'll do it. And if the goal is ever achieved, then
there won't be any market for DNG Converter, so it's not like
they're going to start charging for it in the future.

> 2. The name D and the N in DNG are ... ehem ... big words: digital
> negative. Currently the RAW format Bayer cameras are dominating
> the market - and there are really very few sensors used and the
> spread in funtionality is limited. But ... for how long. Whats
> coming next? Is Bayer going to be the dominating format?

DNG Converter supports the Sigma DSLRs, so I don't think it's
married to Bayer formats. If you have reason to believe otherwise,
I'd be interested to hear it.

--
Ben Rosengart (212) 741-4400 x215
Sometimes it only makes sense to focus our attention on those
questions that are equal parts trivial and intriguing.
--Josh Micah Marshall
Anonymous
April 1, 2005 12:33:50 AM

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

Ben Rosengart <br+rpdss@panix.com> wrote in
news:slrnd4omln.4vp.br@panix5.panix.com:

> Not exactly. They give things away when it suits their interests.
> For example, they give away Acrobat Reader because that helps sell
> the tools that are used to generate PDFs.

Ahhhh ... but that was exactly what I meant. They give away the reader
and charges premium for the writer.

> I see DNG Converter as a similar thing. If they can get the camera
> manufacturers to support it natively, then they won't have to scramble
> to support new RAW formats with every camera release. This would free
> up engineering resources for, you know, actual productive stuff. :-)

Maybe. Sounds too good to be true though :) 

> DNG Converter supports the Sigma DSLRs, so I don't think it's
> married to Bayer formats. If you have reason to believe otherwise,
> I'd be interested to hear it.

The Bayer output can be stored in a B&W TIF. The Sigma can be stored
in a color TIF. In both cases you must tell someone how to make the
conversion to correct RGB format. The Fuji strange thingies can be stored
in .. ehem .. don't know :) 

As I understand it - the DNG is open ended (just like TIF) so you can
add new kind of formats. One onders why they did not simply use TIF
with some new info fields etc.


/Roland
Anonymous
April 1, 2005 12:33:51 AM

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

Roland Karlsson wrote:

> Ben Rosengart <br+rpdss@panix.com> wrote in
> news:slrnd4omln.4vp.br@panix5.panix.com:
>
>
>>Not exactly. They give things away when it suits their interests.
>>For example, they give away Acrobat Reader because that helps sell
>>the tools that are used to generate PDFs.
>
>
> Ahhhh ... but that was exactly what I meant. They give away the reader
> and charges premium for the writer.

Acrobat (the writer) is US$299 which is a tiny drop in the bucket for an
enterprise. It's not needed at every desk, only those depts. that
publish docs. Schools can get it cheaper.


--
-- 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.
Anonymous
April 1, 2005 12:49:10 AM

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.
Anonymous
April 1, 2005 12:49:11 AM

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.
Anonymous
April 1, 2005 12:54:40 AM

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/05033002adobe_directo...
> >
> > 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
Anonymous
April 1, 2005 1:37:40 AM

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

Roland Karlsson <roland_dot_karlsson@bonetmail.com> wrote:

> As I understand it - the DNG is open ended (just like TIF) so you can
> add new kind of formats. One onders why they did not simply use TIF
> with some new info fields etc.

DNG uses TIFF containers, if I understand it correctly.

By the way, do you know that Adobe owns the TIFF format, too? And they
don't seem to have done anything evil with that, which sets a good
precedent for DNG, no?

--
Jeremy | jeremy@exit109.com
Anonymous
April 1, 2005 1:45:09 AM

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

In article <Xns962AE58906C56klotjohan@130.133.1.4>,
Roland Karlsson <roland_dot_karlsson@bonetmail.com> wrote:
>
>As I understand it - the DNG is open ended (just like TIF) so you can
>add new kind of formats. One onders why they did not simply use TIF
>with some new info fields etc.


That's precisely what they did.

A DNG file *is* a TIF with some new info fields. All the DNG spec
does is to assign the tags and encodings for those new info fields,
and to state which of them must be present in a baseline DNG.

Basically, just about what the EXIF spec does for those new fields.

I really think you might read the DNG spec before arguing against it.
Anonymous
April 1, 2005 2:02:53 AM

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?
Anonymous
April 1, 2005 2:02:54 AM

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.
Anonymous
April 1, 2005 2:08:07 AM

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

"shesso" <shessochi@nospam.hotmail.com> wrote in message
news:ksZ2e.31671$191.8433@trnddc02...
> looks like the problem adobe is trying to solve is the prevalence of
> bootleg
> versions of ps.
> i expect they'll ask for yovr ps registration b4 they list yov in their
> directory, no?

By Jove i think yov have it.

I'd settle for a disk only oem copy. They don't sell them in the vk. Saw
one link somewhere bvt forgot. Don't particvlarly trvst that sort of thing.
At least i know not to trvst anyone who only accepts payment from wetern
vnion.
Anonymous
April 1, 2005 2:42:15 AM

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

In article <d2hst9$pu6$1@inews.gazeta.pl>,
Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>John Francis wrote:
>
>> HOL?
>
>High Order Language (C, Ada, many others)

Ah. I'm used to seeing HLL (High Level Language)

>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.

. . .

>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.

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.

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.
Anonymous
April 1, 2005 2:42:16 AM

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.
Anonymous
April 1, 2005 3:26:15 AM

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

In article <d2hv2e$3s4$1@inews.gazeta.pl>,
Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>>
>> 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.

That's not the point. If you've got an image reconstruction algorithm
that's based on data cells on a rectangular grid, what's it going to do
with sensors using a different pattern? If you process or interpolate
the data in any way, you're imposing your own choice of algorithms.

The HOL effectively defines an API. If your algorithm and/or sensor
don't match the underlying assumptions of that API, you're in trouble.
(In other words: there's no such thing as a "Can't miss" interface)

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).
Anonymous
April 1, 2005 3:44:36 AM

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

On 31 Mar 2005 20:33:50 GMT, Roland Karlsson
<roland_dot_karlsson@bonetmail.com> wrote:
> Ben Rosengart <br+rpdss@panix.com> wrote in
> news:slrnd4omln.4vp.br@panix5.panix.com:
>
>> Not exactly. They give things away when it suits their interests.
>> For example, they give away Acrobat Reader because that helps sell
>> the tools that are used to generate PDFs.
>
> Ahhhh ... but that was exactly what I meant. They give away the reader
> and charges premium for the writer.

Ok, and in this case, the reader is Photoshop, for which yes, they
certainly do charge a premium.

So it seems to me that you have nothing to worry about with regard
to DNG, since the scenario you fear has already come to pass. :-)

--
Ben Rosengart (212) 741-4400 x215
Sometimes it only makes sense to focus our attention on those
questions that are equal parts trivial and intriguing.
--Josh Micah Marshall
Anonymous
April 1, 2005 3:54:18 AM

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

On Thu, 31 Mar 2005 17:17:15 -0500, Alan Browne
<alan.browne@freelunchVideotron.ca> wrote:
> John Francis wrote:
>
>> HOL?
>
> High Order Language (C, Ada, many others)

C, a high-level language? Well, relative to assembler, I guess ...
but I think for what you're talking about, a domain-specific
language would be in order. I would *not* want RAW/DNG files with
hunks of C code in them; next think you know, someone would embed
malware in one.

--
Ben Rosengart (212) 741-4400 x215
Sometimes it only makes sense to focus our attention on those
questions that are equal parts trivial and intriguing.
--Josh Micah Marshall
Anonymous
April 1, 2005 4:11:33 AM

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

On Thu, 31 Mar 2005 17:02:19 -0500, McLeod <cerveza@xplornet.com> wrote:
> On Thu, 31 Mar 2005 17:23:25 +0000 (UTC), Ben Rosengart
><br+rpdss@panix.com> wrote:
>
>>The real win with DNG will come when it's adopted as the native RAW
>>format of most cameras.
>
> The problem with that is that the camera manufacturers will never go
> for it.

Maybe not, out of the same bull-headedness that causes them to keep
their current RAW formats proprietary -- but I am hopeful. It would
save them programming resources as well, and eliminate an inconvenience
for their customers. I haven't figured out any way to communicate
my support for this step to the manufacturers, but if and when I do,
I will certainly advocate it to them.

Once the dam breaks and one or two manufacturers give it a try, I
expect the others will come through pretty quickly.

> The Sony 6.1 Megapixel sensor is in a lot of cameras, but the
> image file looks different out of every camera

I don't see the relevance.

--
Ben Rosengart (212) 741-4400 x215
Sometimes it only makes sense to focus our attention on those
questions that are equal parts trivial and intriguing.
--Josh Micah Marshall
Anonymous
April 1, 2005 6:51:31 AM

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.
Anonymous
April 1, 2005 6:51:32 AM

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.
Anonymous
April 1, 2005 8:02:49 AM

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

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.
Anonymous
April 1, 2005 8:05:34 AM

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.
Anonymous
April 1, 2005 8:05:35 AM

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

In article <n2bp411mvr3flfq6g3suoj1n50f836i8i1@4ax.com>,
Mxsmanic <mxsmanic@hotmail.com> wrote:
>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.

Well, yes.
Especially if they produced the output on a continuous medium.

Unfortunately, they don't. So we have all the problems of image
reconstruction from point-sampled data, with the added complexity
that quite often the sampling sites are not co-located, or even
located at sites which correspond to output "pixels"

This is good news for post graduate students looking for a thesis.

For the rest of us, we're simply living in interesting times.
Anonymous
April 1, 2005 8:07:56 AM

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

Paul J Gans writes:

> There is Great Fear in corporations (mainly by sales
> executives) that if they were to release the information
> *somebody* might write a killer application of some sort
> using the RAW data directly.

Or somebody might see just how limited the camera actually is.

RAW formats exist because digital cameras don't produce true RGB output.
If they did, you wouldn't need any kind of conversion to squeeze a
semblance of quality out of essentially incomplete data.

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