DNG or RAW

DNG

22 (26.8%)

RAW

60 (73.2%)

Total Members Voted: 81

[TonyW]

They don't even have to do that. Read Bart's last two posts. The data we're talking about in DNG is raw. It's yet to be rendered.
DNG does allow minimal processing (Lossy DNG) and fully processed data. But that's a different story. All the manufacturer needs to do inside the camera is functionally equivalent of what we do when we convert to DNG in LR or with the standalone DNG converter.

Andrew thanks another brain fart for me - I did know that we are discussing raw DNG data.  Bart, my apologies for not reading fully what you posted.

[papa v2.0]

Hi Andrew.
Yes the matrix can be stored in the DNG there is a tag for it.

DNG is ok if you have a matrix. At the moment the matrix is added by ADOBE at the 'convert to DNG' stage.

Iridient Developer. Do they make their own camera matrix for each camera or use ADOBE'S. ADOBE'S I think (correct me if im wrong).

Again the BIG PROBLEM is getting the matrix from NIKON etc.

I think ADOBE jumped the gun in the DNG spec. I said this when it first came out. MATRIX tags! Thats asking a lot.
What they should have pushed for was a open un-encrypted, matrix free, tiff file. Matrix to be added later by 3rd parties at rendering stage. There would have probably been more of an uptake by manufacturers.

Now ADOBE have to provide colour matrix for all new cameras if they want people to use their DNG spec.

Do you see the problem.

[digitaldog]

Iridient Developer. Do they make their own camera matrix for each camera or use ADOBE'S. ADOBE'S I think (correct me if im wrong).

Both it appears. I know I can load my custom DNG camera profiles built for LR/ACR there and use them. Not sure if that helps any. You can use ICC camera profiles too if you wish.

Do you see the problem

Not really, not yet, sorry. Not that your suggestions about DNG having access to the color matrix shouldn’t be considered. We'd need Eric Chan or someone else to comment on that aspect.

[jrsforums]

I am really at a loss here....and this is a real question....not an attempt to poke at anyone.

If the camera manufacturers put the raw data, as Bart describes, not in their RAW container, but in a DNG container.....and all the proprietary info, wb, filters, matrix, etc. were still kept proprietary....what would be gained?

[digitaldog]

If the camera manufacturers put the raw data, as Bart describes, not in their RAW container, but in a DNG container.....and all the proprietary info, wb, filters, matrix, etc. were still kept proprietary....what would be gained?

The data spit out on day one would be accessible to any raw converter that understands DNG. That's been the issue/problem from post 1 here.
Again, think JPEG accessibility on day one and what a JPEG represents (yes it's rendered but more importantly, the way the container & data is described and defined is such it is accessible in lots of software products the day that camera ships). Further, no one has to continuously update their software. Imagine how Photoshop, Elements, Preview on Mac etc behaved if every JPEG was different such, it wasn't understood. Chaos!

[papa v2.0]

I am really at a loss here....and this is a real question....not an attempt to poke at anyone.

If the camera manufacturers put the raw data, as Bart describes, not in their RAW container, but in a DNG container.....and all the proprietary info, wb, filters, matrix, etc. were still kept proprietary....what would be gained?

What would be gained is that the DNG file is not encrypted like a NEF and as such could be read AND RENDERED by any application that supports DNG.

Proprietary data would have to become open data, no encrptyion

The problem is NIKON wont give all the information needed ie the MATRIX, to be able to RENDER from DNG from the camera.

DNG would be an open format so any 3rd party software could open and render directly from a DNG produce by the camera.
At present the DNG can can only be used after the NEF has been converted by ADOBE DNG to a DNG and the missing MATRIX inserted.
It is then and only then, open format available to everyone who supports DNG.

iain

[ErikKaffehr]

Hi,

The "MATRIX" is just 9 numbers, describing the mapping of RGB values to CIE XYZ coordinates. DNG specifies several matrices, one for 2850 K and another for 6500K and suggests how to interpolate in between. As I have mentioned before, measuring the spectral response of a sensor is not rocket science, check this: http://www.maxmax.com/spectral_response.htm

A monochromator is needed and some other tools, a monochromator is not necessarily very expensive: http://www.edmundoptics.com/testing-targets/spectrometers/manual-mini-chrom-monochromators/1379?#products

Best regards
Erik

What would be gained is that the DNG file is not encrypted like a NEF and as such could be read AND RENDERED by any application that supports DNG.

Proprietary data would have to become open data, no encrptyion

The problem is NIKON wont give all the information needed ie the MATRIX, to be able to RENDER from DNG from the camera.

DNG would be an open format so any 3rd party software could open and render directly from a DNG produce by the camera.
At present the DNG can can only be used after the NEF has been converted by ADOBE DNG to a DNG and the missing MATRIX inserted.
It is then and only then, open format available to everyone who supports DNG.

iain

[papa v2.0]

Hi,

The "MATRIX" is just 9 numbers, describing the mapping of RGB values to CIE XYZ coordinates. DNG specifies several matrices, one for 2850 K and another for 6500K and suggests how to interpolate in between. As I have mentioned before, measuring the spectral response of a sensor is not rocket science, check this: http://www.maxmax.com/spectral_response.htm

A monochromator is needed and some other tools, a monochromator is not necessarily very expensive: http://www.edmundoptics.com/testing-targets/spectrometers/manual-mini-chrom-monochromators/1379?#products

Best regards
Erik

Hi Eric.

Its not rocket science its Colour Science! Boom Boom.

Please refer to a paper I published on Colour Appearance. It contains some extra information on producing a matrix. Not as straight forward as you may think. Response curves are one thing, producing a high quality matrix is another. But dont forget a matrix is only part of the characterisation data needed to produce CIEXYZ coordinates from device RGB.

Iain

[ErikKaffehr]

Hi Iain,

Thanks for the paper! Very interesting! I admit it is not so straight forward as I may have thought.

Best regards
Erik

Hi Eric.

Its not rocket science its Colour Science! Boom Boom.

Please refer to a paper I published on Colour Appearance. It contains some extra information on producing a matrix. Not as straight forward as you may think. Response curves are one thing, producing a high quality matrix is another. But dont forget a matrix is only part of the characterisation data needed to produce CIEXYZ coordinates from device RGB.

Iain

[Tim Lookingbill]

Hi Eric.

Its not rocket science its Colour Science! Boom Boom.

Please refer to a paper I published on Colour Appearance. It contains some extra information on producing a matrix. Not as straight forward as you may think. Response curves are one thing, producing a high quality matrix is another. But dont forget a matrix is only part of the characterisation data needed to produce CIEXYZ coordinates from device RGB.



Iain

Iain, could you post sample color images that show errors created by not getting the color appearance matrix just right and tie it in with their respective associated mathematical formula and/or graphs?

Your PDF is quite a bit over my head but I do get the gist of what you're trying to pin down with regard to matrix driven WB and HSL adjusts in order to achieve predictability in processing data by characterizing a camera sensor's performance. The image sample of the woman at a picnic doesn't make this more understandable nor does it make a direct correlation to the formula's and calculation's influences on results a photographer can use.

Appreciate your hard work on this and posting the pdf here.

[papa v2.0]

Iain, could you post sample color images that show errors created by not getting the color appearance matrix just right and tie it in with their respective associated mathematical formula and/or graphs?

Your PDF is quite a bit over my head but I do get the gist of what you're trying to pin down with regard to matrix driven WB and HSL adjusts in order to achieve predictability in processing data by characterizing a camera sensor's performance. The image sample of the woman at a picnic doesn't make this more understandable nor does it make a direct correlation to the formula's and calculation's influences on results a photographer can use.

Appreciate your hard work on this and posting the pdf here.

Hi
I don't think i have pictures produced with bad matrixes. I dont think i produced any real bad ones. Most were pretty spot on due the the spectral characterisation method employed was quite precise.

The pic of mary is to really do with the local adaptation part of the project and the use of CIECAM02

Again a matrix may be optimised for accurate blues and loose it in the reds or vice versa. it down to the manufactures preference.

iain

[ErikKaffehr]

Hi,

I played a lot with DCP profiles when I started using my P45+ back as Adobe Standard rendered some colours bad. I have posted an article with my results so far, it's a bit messy and needs to be clarified/updated but may give some insight.

I used a ColorChecker Passport with Adobe DNG Editor and also ColoChecker Passport software. I also tried QPCard and it's software.

http://echophoto.dnsalias.net/ekr/index.php/photoarticles/79-p45-colour-rendition

The article begins with some results from using Imatest ColorCheck and ends with a lot of sample.

Best regards
Erik

Iain, could you post sample color images that show errors created by not getting the color appearance matrix just right and tie it in with their respective associated mathematical formula and/or graphs?

Your PDF is quite a bit over my head but I do get the gist of what you're trying to pin down with regard to matrix driven WB and HSL adjusts in order to achieve predictability in processing data by characterizing a camera sensor's performance. The image sample of the woman at a picnic doesn't make this more understandable nor does it make a direct correlation to the formula's and calculation's influences on results a photographer can use.

Appreciate your hard work on this and posting the pdf here.

[Vladimirovich]

Again the BIG PROBLEM is getting the matrix from NIKON etc.

people know that Nikon OEM converter will leave temp files available to grab with their ICC camera profiles during the work,  so how that might be a big problem beats me... surely not documented, but it is available and DNG container can have ICC profiles in it... now the question is as to why ACR/LR will not use ICC camera profiles that are in DNG according to the spec ? what if camera manufacturer does not want to go DCP route ?

[Vladimirovich]

Thanks Andrew, camera support is what I was referring to and I had read some time ago about number of cameras supported and now remember the figure as 350+ .

come on... see how he is making FUD by equating the number of really different __FORMATS__ with a number of different camera models, which totally incorrect approach.

[Vladimirovich]

Absolutely agree.

For archiving it makes no significant difference, conversion to DNG only rearranges the same Camera Raw data to openly documented tagged positions. No real benefits, just a slowdown before industry wide agreement on new tags is reached.

it makes a difference... first of all Adobe along the way changed their approach as to what they transfer to DNG from the data read off sensor and written by camera's firmware in the original raw files (and so there were times when some Camera Raw data was discarded, yes)... that alone shall be enough once and for all to stop discarding original raw files... where I can make DNG file on demand (to use in my workflow), why shall I discard the original data... then why take a risk that there is a bug in Adobe software on top of everything else...

[Vladimirovich]

Tony wrote about 400 cameras that were supported not 400 formats, you popped that in there. I agree with you, 400 isn't correct (it's hardly FUD IMHO), Adobe states more than 350:So there are differences.

like camera model names, yes... a great difference indeed.

[Vladimirovich]

Seems not as we wait weeks and months for updates to our preferred raw converter.

that was supposed to be fixed with that new subscription model... oh wait... we are still getting 4 ACR releases a year and not JIT  ...

[digitaldog]

come on... see how he is making FUD by equating the number of really different __FORMATS__ with a number of different camera models, which totally incorrect approach.

Again, if the formats are not identical, they are different no? If all 350 cameras produced identical files, I'd be kind of shocked. As I said, any difference that results in file A being accessible outside the manufacturer's converter but file B not, it doesn't matter how many cameras or formats you wish to define, the file B can't be accessed until someone alters some code.

[digitaldog]

that was supposed to be fixed with that new subscription model... oh wait... we are still getting 4 ACR releases a year and not JIT  ...

Can you point out where Adobe said that thanks to a subscription model, they will more quickly provide camera support that I submit they shouldn't have to provide in the first place?

So Nikon or Canon comes out with a new camera today. Assuming (big assumption) Adobe and everyone else do NOT have to purchase the camera, all they need is some kind customer to send them a raw, even with a subscription model, support isn't going to be less than weeks! Software has to be updated. Tested. Documented. Installers have to be built. Uploaded. It's still work albet it, thanks to subscription, we might see the support a bit faster. That's not an excuse for the current conditions anyway. No argument you or anyone else has made so far lets the manufacturer off the hook. And the subscriptions model doesn't help our friends at PhaseOne, Dx0, and all the other raw converter software companies.

[Tim Lookingbill]

Hi
I don't think i have pictures produced with bad matrixes. I dont think i produced any real bad ones. Most were pretty spot on due the the spectral characterisation method employed was quite precise.

The pic of mary is to really do with the local adaptation part of the project and the use of CIECAM02

Again a matrix may be optimised for accurate blues and loose it in the reds or vice versa. it down to the manufactures preference.

iain

Guess I should've worded it differently, so I'll ask it this way... Could you induce an error in an image to show how and where in the calculations and formulas all this works?

It's a demo similar to assigning the wrong profile to an image encoded in another space that causes color appearance distortions according to human perception. Maybe show a scene with memory colors that go wacky on account of these distortions.  

Or maybe post images you created using this specific knowledge you've acquired represented in your pdf that you define as correct looking color appearance versus incorrect.