…but remember that these DNG files contain a much higher quality image than what you see in JPEGs coming from the default camera pipeline which is simple and fast rather than good looking, and you can use these DNG files to get better JPEGs afterwards (see Glowup for an example of this, and more photos here).
So if you care about these photos, you may want to archive them somewhere instead of deleting. They should compress fairly well too.
How about fix camera so that there is a setting (maybe by default) where it stores jpgs and dngs - if user wants one or both…? Or even a setting that automatically pushes dngs to pre-set glowup and deletes the original dng after the enhanced jpg/png/tif is processed? Its not user fault the software doesn’t support needs. [I agree, it’s unfortunate dngs go to waste like this]
Camera app’s postprocess pipeline is a bash script that you can edit as you wish. That said, even Glowup’s output, while much better than dcraw’s, is still flawed in several ways, so you’ll still be able to get better results out of the same files in the future once more kinds of lens corrections can be used.
I certainly agree that this situation is sub-optimal and it’s not the user’s fault - but it is how it is. Otherwise I wouldn’t be writing this:)
Yes, there should be such a setting but by default it is always only going to be on the eMMC drive somewhere. So the default setting won’t allow you to reclaim disk space, as per topic title. So the onus would be on the user to put a µSD card in, make sure that it is mounted at boot, and use the setting to store (at least) DNG files on the µSD card. Ideally therefore the app would also revert, probably with error message, to the default setting when the µSD card’s absence, or otherwise, caused the location given by the setting to be unusable.
In the meantime, as was said, hack the postprocess script. (I have hacked it but that is because I was playing around with more advanced QR code support. It should be pretty straightforward to offload images to the µSD card.)
People choosing to do so should be aware that the delay writing DNG to µSD will probably be noticably slower than writing it to EMMC.
While that’s true, it should take about 1 second and there’s kernel’s cache in-between, so impact on the user would probably be negligible (unless you care about unexpected reboots within a second after taking a photo 
)
It’s the implementation - how it’s done.
A) It shouldn’t be that only the more capable are able to hack such - this should be a basic design and feature that all users can use and have easy access (without searching it from forum or elsewhere),
B) “reclaim” is possible up to a point and then you have to manage what you got, so this is relevant to it, as
C) the default could be not to have dngs or to ask user what settings they want - right down to jpg quality/size and captured image size, and
D) error handling is normal - there are several options what to do if SD card isn’t available, including a warning at app startup to set it up if destination is not available, choosing and alternate (also if eMMC or SD is too full), choosing a preference between jpg and dng if only one fits or having dngs only if SD is available, etc.
A disc space warning in camera would be a good idea too (with an option to prevent new images (or just dngs) if X amount of disc space remaining). As there is a usb-c port, even using an external drive would be an option in some (probably video) scenarios when user knows there’s going to be a lot of big files for later post processing. And how about option to save online…
In the bigger picture, although we’ve looked at the camera app, the point is that apps have not been designed to have such options to manage scarce disc space as they are mostly designed with a desktop (and cloud) mindset where the space is almost limitless. It’s unfortunate that this management of scarcity and save destinations can’t be had as a phosh feature (?). Images and flatpaks take the most space in my L5 and it’s those and logs that I can shuffle around. Limited options.
I completely agree. My comment was “in the meantime”.
Actually, I did want to do that eventually i.e. straight to my server. However then it needs to be asynchronous - and that would actually solve some of the challenges that have been highlighted regarding the relatively sluggish µSD card performance and the possibility that the card is absent. So basically the current default location (in the ~ tree) becomes a temporary staging area only (if you so configure).
I don’t imagine taking a photo with a phone with a portable drive hanging out the bottom, particularly if using landscape mode, 
but, again, deferring the copy would allow me to take photos and plug the portable drive in later, and photos would then all move across.
Sorry, but moving this post to a separate thread defeats its whole purpose. It was a warning about reclaiming disk space.