uploaded to RPU
Oops, sorry, what I said applied to my own DNG, but it seems that it’s probably a different issue since OP’s is displayed correctly in RawDigger regardless of that opcode setting. Mine does have an “OpcodeList3” in the full-size subimage.
noticed an interesting thing. If I enable “show preview frames” in RawDigger my dng has strong magenta tint:
disabling the “show preview frames” renders the dng properly:
Is there no image size setting? It’s already not a raw?
It’s an HDR dng produced in Lightroom from 5 bracketed raw files
Well, definitely there is something wrong with HDR dngs in darktable. Lightroom shows only noise if I try to open an HDR dng generated in darktable…
Maybe darktable doesn’t fully support Sony Alpha cameras?
The problem is with DNG compatibility, not the camera.
1 Like
Please reread my initial comment.
I don’t understand what do you mean. image size setting where ? As I said this dng is a combined image from 5 raw files generated in Lightroom. Please clarify what info do you need.
There is already an iPhone 12 ProRAW DNG on RPU that has this, but not sure if it can be of use since black level values are 0?
Perhaps you can generate a smaller file with the same problem by doing an HDR merge with only two source files?
The count of images used to create the HDR isn’t the problem, it doesn’t really affect filesize,
the image area/pixel count is the problem i’m talking about – is there no way to downscale
the image in the program? Something closer to the usual 25Mb filesize would be nice.
the images that i have converted from RAW to DNG via lightroom does not render properly in Darktable 3.4. The images show are unedited yet. I think the issue might bee due to the black level not being taken into account when decoding the RAW file. I cam to this conclusion as when i adjust the black levels in the RAW Black/White Point Module i could remove the magenta cast. but every image seem to be different. checking the exif the black level of the images are different .
hope this information can help in solving this issue
the images that i have converted from RAW to DNG via lightroom
I don’t think I understand what the user case is here. If you have a raw file and DT, why do you convert to DNG to begin with? If you use Lightroom to convert a raw file to DNG, why not use it for the final conversion to tif/jpg/png as well?
The whole problem with DNG is these weird interactions, whether due to LR or DT is really no longer the issue. One never knows if the DNG is a ooc raw file, a converted ooc raw file or demosaiced non-raw data in a DNG container.
To me DNG still stands for “Do Not Go” and exchanges such as this thread only seem to confirm that. Luckily, my Pentax bodies all have the option to set the native PEF raw format but my Ricoh GR uses DNG as sole raw format. Never had any issue with the latter because it is ooc DNG but the whole conversion bit has never made sense to me. Is it just an Adobe ploy to restrain users from migrating to other, better software at a future point? Who knows…
1 Like
i do understand where you are coming from these are old files that i have converted from RAW to DNG lossy compression for archiving purpose. when i converted it i was using Lightroom as my primary raw converter. i have found darktable to be very interesting so i want to use it for my RAW processing for the near future. if i continue to open the files via adobe software it will still open correctly. i think if you are trying to attract lightroom users it would great if the DNG will open properly in darktable. If the dev does not think this is a priority thats fine. i am just a user so i can only report the issues.
Instead of a “me too”, it would be even more helpful to provide some detailed information about your DNG files so we can figure out if this is a new or a known issue. Can you please share a sample and/or output of mentioned exiftool -a -u -s -g1 command?
yes definitely here are the exiftool output in txt format and also the DNG file.
hope this help.
P4110037.dng (6.3 MB) P4110038.dng (6.4 MB) P4110037.txt (35.0 KB) P4110038.txt (30.4 KB)
Thanks - yep, looks like the same known bug as already mentioned earlier.
These are not true raw CFA images any more (see the full resolution IFD below). LR did some conversion before saving a demosaiced (3 channel linear raw) and lossy compressed 8-bit image data into a DNG container:
---- SubIFD ----
SubfileType : Full-resolution image
ImageWidth : 4608
ImageHeight : 3456
BitsPerSample : 8 8 8
Compression : Lossy JPEG
PhotometricInterpretation : Linear Raw
SamplesPerPixel : 3
PlanarConfiguration : Chunky
TileWidth : 512
TileLength : 496
TileOffsets : (Binary data 503 bytes, use -b option to extract)
TileByteCounts : (Binary data 383 bytes, use -b option to extract)
BlackLevelRepeatDim : 1 1
BlackLevel : 4 0 2
WhiteLevel : 255 255 255
DefaultScale : 1 1
DefaultCropOrigin : 0 0
DefaultCropSize : 4608 3456
AntiAliasStrength : 1
BestQualityScale : 1
OpcodeList2 : MapPolynomial, MapPolynomial, MapPolynomial
NoiseProfile : 4.25482566567483e-005 4.39294981498392e-008
I believe there are still samples missing on RPU for this to be worked on by the devs, so if you could contribute that would be helpful. I would assume probably without human subjects/faces though…
Noted I will try to upload the images I the rpu by asap
1 Like