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.
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.
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
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
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.
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.
There is nothing to show up, nor any changes needed for darktable. Use exiftool to fix your existing DNG files, or use the updated version of PixelShift2DNG for new ones or to regenerate the previous ones and that’s it.
Edit: I just realized you meant the new functionality @maruncz is working on, sorry.
When using 16 Bit TIFF from rawtherapee, I wasn’t able to use filmic i.e… Other RAW modules we’re not active either. I assumed this to be an effect of Not using a RAW file.
Strange that you cannot use filmic. Of course, if your file doesn’t contain raw data, a few modules make no sense (any module that works on raw data, like mosaic, raw denoise, etc.) but filmic is not one of those.
That doesn’t mean filmic gives anything usable or makes sense: filmic handles the transition from scene-referred to display-referred, and a TIFF file can be either (I don’t know rawtherapee, but I’d expect its output to be display-referred).
Filmic RGB is transferring my workflow to Display referred? That’s the first time, I heard that. I always thought of filmic as a kind of tonemapping tool.
It does tone mapping. It has to, as it has to fit the dynamic range of the scene-referred image to the range of the display (so 0…x → 0…1). But in addition, it does a log transform (output = log(input).
So it’s not a module you just use for tonemapping. Tone equaliser would be better for that use, or exposition with masking, perhaps others.
(If you want to check what a module expects as input, and gives as output, hover the mouse cursor over its title bar. Or check the manual, I suppose)
I think the better way to characterize this is that filmic ‘takes it out of scene-linear’, or ‘scene-referred’. The final transition to display-referred occurs 1) in the display transform and, 2) in the file export transform. Those two transforms are the ones that are sensitive to the render-for-viewing requirements.
I’m using this workflow occasionally for pixelshift images: On Rawtherapee’s color management, I set the input profile to ‘Camera standard’ (a simple matrix profile), working profile and output profile to e.g. ‘RTv4_Rec2020’, set ‘Tone response curve’ to ‘None’, so things should stay linear, and export in 16bit TIFF. I can open this in Darktable and turn on Filmic RGB just fine, with the expected results, including image metadata. Of course modules, which depend on the raw data before de-mosaic, such as hot pixel removal, will not work, but then this should be taken care of in Rawtherapee in this combined workflow.
