DNG problem converting from Flexcolor

[Weldon Brewster]

I’m having a problem with DNG files that are converted out of Flexcolor.  The DNG files are exhibiting ‘jpeg artifact’ type noise in the shadow areas when processed by both PS and LR.  It manifests as a cross hatch pattern in the shadow areas that is not present on Flexcolor processed Tifs.  Has anyone else had this problem?

Equipment:  Imacon 96c mounted on a Contax.  Here’s what I tried:  Two different Macs, Flexcolor 4.6.7 and 4.5.4, with and without the back being plugged in, no sharpening or noise reduction in either FC, PS or LR, 6 files sampled from the last couple of years, different versions of PS and converting the DNG from both the scratchpad and the Imagebank.

I normally work with Flexcolor and output Tiffs to use in PS so I had never noticed this before.  My understanding from Adobe and Hasselblad’s propaganda is that the DNG’s were just as good as the raw files that came out of the camera.  Is this true only for certain cameras?

Thanks,
Weldon

P.s. Here are the links to the sample photos that illustrate this problem. (I know, I know, the color balance is off.)  The side by side is a 100 percent crop, I’ve also included a tif of that one.

http://www.weldonbrewster.com/clients/dngp...ide_by_side.jpg
http://www.weldonbrewster.com/clients/dngp...if_from_dng.jpg
http://www.weldonbrewster.com/clients/dngp...rom_flexclr.jpg
http://www.weldonbrewster.com/clients/dngp...ide_by_side.tif

[Sisyphus]

Weldon,

   I think I am seeing the problem you described but I want to be sure. I saw RGB separations in the fine hairs with greater concentration around the eyes. Are these the Artifacts you are describing?

  I am detecting these artifacts in all of the images you posted, do you have a control that has been processed from the 3f file to Tiff or Jpeg using FlexColor that we could look at ?

Brian

[marc gerritsen]

Yes that is the problem with dng from Hasselblad.
I never export dng files only when I need to get more information out of an overexposed sky or so and then blend it with a tif file from an fff raw file.
Also the size of the dng file comapred with the fff is slightly different, so you have to resize before blending.

[GLJ]

I’m having a problem with DNG files that are converted out of Flexcolor.  The DNG files are exhibiting ‘jpeg artifact’ type noise in the shadow areas when processed by both PS and LR.  It manifests as a cross hatch pattern in the shadow areas that is not present on Flexcolor processed Tifs. 
My understanding from Adobe and Hasselblad’s propaganda is that the DNG’s were just as good as the raw files that came out of the camera.  Is this true only for certain cameras?

[a href=\"index.php?act=findpost&pid=115176\"][{POST_SNAPBACK}][/a]

Hi Weldon,

While I unfortunately don't have the same camera system as you (LOL), I might be able to shed some light on this.

Many cameras suffer from this cross hatch problem when you convert RAW files using ACR, its an Adobe issue. If you normally generate TIFFs from Flexcolour, then this is doing the RAW conversion. If you are now outputting DNG files, I would imagine this is just the RAW data in a DNG wrapper (and there is indeed no loss of quality) however you now have to use the ACR engine to do all the demosaicing etc and that's where the problem lies.
You can alleviate the pattern noise by not using any RAW presharpening in ACR, but then you have to apply some sort of sharpening yourself after the conversion. A very light noise reduction before this helps as well, but I'm still experimenting with this myself.
Its not ideal and really its an issue for Adobe to sort out. Some other RAW converters give you more control over the conversion process in terms of the pattern noise, but its currently fixed in ACR.

Cheers
Gareth

[rainer_v]

but aside from this explanation ( which is now solved in cs3 and lightroom ) dng is not dng.
often the companies just implement the dng conversion as a nice marketing extra to show
1. their "opened" sw- plattform and 2. that their own converter delivers better results than others.

in fact it is very sophisticated to convert raws in hi-quality dng files and as it seems no company is willed to invest much resources  in the dng programming, so they do it as simple as it can be done.

the quality differences between "good" programmed dngs and "bad" programmed dngs is very high.

[GLJ]

but aside from this explanation ( which is now solved in cs3 and lightroom ) dng is not dng. ......

the quality differences between "good" programmed dngs and "bad" programmed dngs is very high.
[a href=\"index.php?act=findpost&pid=117574\"][{POST_SNAPBACK}][/a]

Hi Rainer,
Sorry to be a bit ignorant here, but what has changed in CS3 and lightroom?
(Being an RSP user, I've actually got a licensed copy of lightroom and am waiting a couple of books on it to arrive, but I've not had time to play around with the software much yet).

I'm also unclear as to your comment about good and bad programmed DNGs. Are you talking about the originating software encoding and changing data ( to linear maybe?) in a DNG file, or something happening when it packages up the RAW data. I was under the impression that most DNG files are simply the RAW data from the camera, in a wrapper with header file info that tell the subsequent software info such as how the bayer filter pattern is arranged etc. Thus once it knows this, it shouldn't make any difference whether the software (say ACR) is decoding a DNG file, or the proprietary RAW file, they should both look exactly the same.
Granted though that the output WILL be different with different converters, but then I guess one should say 'there is a difference in quality between RAW converters' not specifically DNG.
Or is that not what you were meaning?

PS and OT
Just coincidentally I'm looking at "Kaiser Wilhelm Gedächtniskirche Berlin" in the very first Kodak challenge!
It would be great if you still entered. Remember that if you placed in the top three or whatever you can submit photos with any camera. Quentin sticks ZD stuff in now :-)

Cheers
Gareth

[rainer_v]

hi gareth,
thanks for the invitation.... maybe i find time to enter again some images,
i am very busy the last months and still i am, so i read often LL at night in some hotel....

about the dng files:
no, dng is not the pure raw data.

a sti mos or a mos or a cr file or whatever has not to be a real raw file, it already is a rendered raw data whcih than can be interpretated by the raw software,- the original raw data may consist a.e. ( in case of sinar ) in the camera in form of one or two files for each image, for making noise calibration of the file. this data is translated than in the "raw" file which is used by the company- software  capture shop ( in case of sinar , but its thesame for all mf backs ).

the dng data may contain the same amount of information, or less info or even more than the companie- raw format ( which also is not raw as i described above ).
in the companie- raw file may be calculated in some noise reduction, some  white or black references, some LCC or gain adjuster datas or centerfold corrections, which all are not done in the original camera raw data. so what seems to be raw often is not pure raw anymore.

e.g. to explain that in one  detail:
what will happen in the highlights and its recovery by the raw develloper software is a very important feature which is determined by the data itself, or better by the "translation" of the original raw data to the readable data format as dng, sti, mos and so on.

e.g. you have the possibilities to cut all three channels as son one exceed "255", to avoid color shifts in the highlights ( as described some treats before from a leaf user.... read there what stephan "brumbaer" hess answered and you will know more about that phenomen ). the two not overexposed channels are not cut in the camera raw data, but something has to be done with this data, otherwise you will end up with unusuable color shifts as soon as one channel is overexposed.
so you either cut the two channels as soon one is overexposed
or you programm a more sophisticated data interpretations where you pull out information of the two or the one remaining channel and interpolate this data to the one or two outblown channels, in this you will get color- neutral info as long as one channel still holds some information ( easy describedm cause the things are complicate cause the color temperature is different, so what is equal info at 5500k is very different at 3000k ).
this renderings are not done by the raw sw , this has to be done in the file which is delivered to the sw. and the programing for things like that is not easy,- and the quality difference might be immense. in case of the described different highlight renderings it is  in normal cases between one till two stops in the highlights, in extreme cases three stops. the raw data in every case  contains the same information, but the form how it is translated in the so-called raw data ( mos. sti., dng or whatever) makes the difference.
the centerfold issue and color shifts over the image aerea  are another examples.
this image issues   can be removed by "translating" the raw data in the dng file and correcting them at the same time. so the cf or colorshift exists in the raw data in every case, but it is removed in the dng file by translating the data , e.g. stephans brumbaer software is doing that with the sinar emotion files. this software also writes corrected dng files which contain white reference files ( if you have shit them before ) , so the dng is 100% color neutral over the whole image field,- the raw data not.
all this things together create an usuable dng file, because a dng file which still contains color shifts ( flexcolor, c1 ) or centerfold issues is not usuable, at leats it does not make much sense to use it. and a dng file which cuts the highlights ( this are doing all except brumbaers sw ) need to be shot with much more care not to overexpose the shot, than you can shoot knwoing that you have allways enough space in the highlights even, if some red blinking in the display shows you that the clouds in the sky are "over".
i am sorry not to be able to speak better english.... in german it would be more easy to explain in an understandable form.....