Oh, sorry! Forgot about it. Delivery guaranteed.
Thanks a lot, will investigate importing into DT as soon as I find some spare time.
The problem with these DNGs is the invalid
[SubIFD] DefaultCropSize : undef undef (0/0 0/0)
This should be reported to the vendor of PixelShift2DNG please. The Adobe DNG spec does not specify how to handle this undefined value.
In this case you can just remove the offending tag (it is assumed to be equal to image/sensor width x height if not provided) and it’ll load just fine in darktable, e.g.:
exiftool -DefaultCropSize="" "_IMG3235-(1).dng"
Again, 99.99% of the time this is not really an issue. The precision limitation of half float is still well below the human visual system threshold for noticing differences, and is perfectly suitable for storing images of high dynamic range (and was chosen as preferred interchange and archival format as such for ACES workflows in cinematic productions).
Well, 99.99% of the time you don’t use PixelShift 
I meant this isn’t the first time you bring up precision limitations of half float without explaining what that really means in practical terms (and by that I don’t mean the tired “you can’t represent all integers”).
When using PixelShift, you average for example two green raw sensor values.
Let them be 1 and 4 => average is 2.5. In 16 bit integer it will be 2. In 16 bit float it will be roughly 2.5, good, better tan 16 bit integer.
Let them be 4100 and 8000 => average is 6050, In 16 bit integer it will be 6050, in 16 bit float it will be 6048, in 32 bit float it will be 6050, good.
My point is not about using 16 bit float as final format, but directly after the raw processing, storing in 16 bit float for further processing in another software definitely will give a loss in precision.
1 Like
loss yes, but do i care i’m not sure. i can process both in vkdt and default to f16 in many cases now because the result didn’t strike me as different. and a 2x reduction in memory footprint in a bandwidth limited application is something.
1 Like
I’m also not sure, but why should one shoot PixelShift, to gain some information, just to throw parts of it away?
1 Like
Great, thank you so much for your kind help! I will send your Message directly to the Dev’s of PixelShift2DNG, if you don’t mind.
Is the command you posted for a Linux tool? I have a Windows machine. Quite frankly, I have no idea, what you mean by “tag”. However, I do understand, that it’s something in the EXIF data, but there it stops for me. I have used rawtherapee a fewvtimes now, but importing a TIF from there into darktable changes my workflow and feels quite brute-force like.
Thanks again and warm regards
Daniel
Nope, exiftool is available on Windows as well as a self-contained executable.
And, yes, please feel free to pass on the report.
I thought PixelShift was about resolution, not dynamic range?
In any case, nobody is denying there is a mathematical loss w/ half float, just that it is insignificant for the imaging application. 2 out of 6050 is 0.03%; as linked above, your visual cortex can notice around 1% relative difference at best.
(There is of course the tiny risk the error can accumulate to be significant if you do hundreds of processing/storing roundtrips and steps, but we’re talking about extremes here; for that level of paranoia, yes, stick w/ full 32-bit float by all means).
Just saying “half float has limited precision” without any context is akin to spreading FUD, while it is in fact a very useful format when its application and limitations are understood.
Done. I have transferred your message together with a brief summary of the issued.
Sorry to ask again: can I copy and paste that commandline you sent me? Or do I have to fill in values. Oh man, you probably already regret your offer to help
1 Like
Absolutely - the exiftool -DefaultCropSize="" is the key part to keep (basically means remove the existing incorrect information), you just change the name of the DNG file you want to fix after that obviously.
Oh, that’s cool! Thank you!
Here’s, what PixelShift2DNG answered:
Re: [PixelShift2DNG] Possible bug
Alex Tutubalin
Andanielspenner@aol.com& 1 weitere(r)
- Mai um 20:06
Dear Daniel:
We managed to improve PixelShift2DNG in two ways:
-
For unknown cameras: valid ActiveArea and DefaultCrop* tags generated
-
Pentax K-70 added to internal tables to provide same DefaultCrop as original file(s)
New build (1.1.7-102) is available from download page: PixelShift2DNG: Convert Sony and Pentax Pixel Shift Files to DNG | FastRawViewer
Thank you again for the problem report,
Alex Tutubalin, LibRaw LLC
пн, 2 мая 2022 г. в 16:59, Alex Tutubalin <alex.tutubalin@gmail.com>:
I will try that instead of carrying on with Rawtherapee, which doesn’t give me .DNG files to work with. At least until your tool shows up in Darktable
1 Like
I might be wrong and missing something upthread but isn’t a demosaiced or pixelshift-merged DNG just a tiff in a different container?
What do you expect to gain from DNG vs tiff?
DNG is a TIFF-based container. TIFF is not synonymous w/ RGB image (and usually people assume 8-bit and gamma encoded as well), although that’s how we use it most often. ARW is a TIFF. NEF is a TIFF. CR2 is a TIFF. etc.
1 Like