Ability to safe out remappend and merged images as RAW
Camera app for Android.
Brought to you by:
mark-h
Menu
▾
▴
(tried creating this topic earlier today but can't see it so im trying it again now, also expaned the description a bit)
I've not been able to find a somewhat reliable automatic image alignment tool that is FOS software.
So, if open camera app has this capability it would be fantastic if it could be told to just do that itself when using bracketing/HDR/NR and similar modes.
In other words: It would be great if there was a way to get:
1. aligned unmerged images as dng.
2. a merged image as dng.
Both of course without any tonemapping being applied, since its RAW, but already demosaiced, since alignment is probably not otherwise possible.
The underlying Idea is to separate processing steps that are purely technical in nature such as exposure, stacking and stitching, which are all basically just steps in the process of measuring the incident light, from those steps which are artistical in nature (e.g. tonemapping). If there is any aberration correction / vignetting correction / distortion correction / denoising / flare correction then I would count those things as part of the light measurement process, basically every processing step whose point is to overcome shortcomings of the camera hardware.
So the camera/app would as much as possible do the technical things automatically, while leaving all creative decisions to the user. Currently one has the tradeoff between either doing all processing manually, or everything being automatic.
A pre-demosaiced raw seems to me like a good file format to store this intermediate processing step.
Open Camera has auto-alignment as part of its HDR algorithm, but this works on bitmaps (generated from the JPEG), not on RAW/DNG images I'm afraid.
Not sure if im understanding your answer correctly. It's possible to store demosaiced images as dng files! I dont see why one couldn't also do this with data coming from jpg (but it needs to be communicated clearly to the users!).
But if I iunderstand your answer correctly this isnt the issue, rather the issue is that the input of the hdr-algorithm already had tonemapping applied. Thus there is not so much point in storing it as dng anymore since the main reason to do so would be to allow custom tonemapping.
Hi, I mean that Open Camera's HDR works on the bitmaps generated from the JPEGs.
I dont see how whether or not the bitmap was previously encoded as jpg changes the ability to store it in a dng file. The question is whether there is a point in doing so. If the bitmap represents linear light values then I'd say the answer to that is yes. Whether or not the jpg values represent linear light depends on what processing was applied when the jpg was created (which I dont know).
Again: the whole point of this is to get access to the linear light values of the merged (and/or remapped) image so one can apply custom tonemapping. Dng is just a convenient file format for this because raw conversion software is designed to work with linear light values and perform custom tonemapping. But of course other file formats (e.g. 16 bit png) would also be a useful alternative.