Android gained ability to capture and save RAW images with the introduction of Camera2 API in Lollipop, and it is implemented in most Google’s Nexus devices and some 2016 phones from other manufacturers. This allows users to bypass the default JPEG engine and apply more sophisticated algorithms to process the image. However, the options to edit them on the phone is rather limited, and of course most (all?) of them are proprietary apps.
But do RAW images produced from phone cameras contain enough information to be worth editing? I’m currently developing a preset in RawTherapee that is tailored for Nexus 5’s RAW images, and you can see the result and comparison with the default JPEG output here. RawTherapee is a lot better at handling chromatic noise in the shadows and can recover a lot more details that are either blown out or erased by noise reduction in the JPEG (check out the windows of the train shot, and the background buildings and text on the statue shot). Granted it is not a fair comparison, RawTherapee can use a lot more processing power on the PC while the SOOC JPEG is computed within a fraction of seconds.
This gets me to wonder if anyone tried to port RawTherapee to Android (or other RAW editors, or maybe even write a new one from scratch, but I’m specifically asking about RawTherapee as I want to process using my preset on the phone directly). Obviously there are many technical issues here: The most important one is to make it compile on ARM with Android’s environment which isn’t your typical GNU/Linux setup. The UI also needs to be completely rewritten for touch-friendly input if we want to allow users to edit photos on the phone (though for my purposes being able to process and output an image using pre-supplied PP3 is enough). Most devices also have pretty limited RAM (3~4GB for most current flagships) and processing power (how long would it take on a phone for a photo that takes 15~20 seconds to process on a i7 laptop?) so the engine also needs to be accommodate for that.
Anyway, this is just my mumbling and some food for thought. Let’s see if we can have some discussion and maybe spark some new development.
I don’t have the before image to show you, but it was really dark under that cliff. I pushed it too far in the shadows, yes, but the point is that raw capture was the only way I could get details to show.
I would really be happy for some sort of FOSS raw developer on Android. OpenCamera is really a pretty good FOSS camera app that can capture RAW files, and I think a lot can done with the images. Mobile editing really is the most convenient for me, which is why I do a lot of it in Snapseed even though I greatly prefer to use a FOSS solution like darktable, etc.
Absolutely. Download Snapseed and give it a try. Side load a .dng file, and see how it works for raw development and subsequent editing works and feels. I find the touch interface really intuitive, especially when making local edits with the brush or selective tools.
Nearly all of the recent images on my Flickr were done this way (side loaded the raw files from my real camera, developed in Snapseed). It’s just a lot faster for me, and I can do it before I even get home or get a chance to sit down at a computer. My recent Flickrs.
@Isaac The details you recovered in the cliff area is seriously impressive! I just received my Nexus 6P which shares the same sensor as your 5X and I can’t wait to explore the possibilities of this sensor.
The UX on both Snapseed and Lightroom Mobile is pretty good, though I find editing them on a tiny screen to be quite exhausting, and I don’t think any of these displays are accurately calibrated. That’s why my idea is to adjust the images on a PC and make a few profiles that works well on a variety of scenes, and then process these images on the mobile using those profiles.
On an unrelated note, I really like the selective adjustment tool in Snapseed. You choose a point on the image and it calculates a mask based on color similarity and proximity, then you can adjust brightness/contrast/saturation with that generated mask. I find it a lot more user friendly and intuitive than fiddling with parametric and drawn masks in darktable for localized edits. Are there any chances we can get a similar tool in our RAW editors?
@Tobias Yeah, unfortunately Camera2 API support is mostly restricted to Nexus devices and some flagship phones from other OEMs,
Thanks! Yes, I think cell phone image sensors are just getting better and better these days. Amazing what you can do with the images they capture. Getting used to the touch interface takes some time, but I honestly feel like it’s fast now that I am used to it. Yes, displays are uncalibrated, but ips and other modern phone displays are pretty good to look at. Better than my old laptop, that is for sure! Screen is small, but by zooming in during certain edits you can see what you are doing. Overall, I find it fast to do basic raw development and quick edits on my phone with very satisfactory results.
I did another search through the various Android repos to see if there were any new FOSS photo related apps, and I came across DCraw Mobile in the play store. As far as I can tell, this is a fairly direct port of DCraw wrapped with a minimal Android GUI. It’s released “free” and ad-free on the play store, but I cant figure our the actual license it’s released under, nor could I find the source code, so I can’t say for sure if it is FOSS. It’s based on a FOSS core anyway, and at least is proof of concept that DCraw can be ported to Android.
It does fill an important gap, however, allowing the translation of many camera raw formats to jpeg or tiff. Importantly, this includes 16bit tiff, as well as 8bit. So, combined with open camera, we now have a potential Foss pipeline to produce editable high bit depth TIFF files. We are still missing a good Android editor though, but these tiffs could at least be processed by online tools like the great film emulator made by @Jonas_Wagner and @patdavid.
Nice find! Judging from the screenshots, the UI seems to be much better than I expected (was expecting some horrible Android 2.x style UI ).
Now I wonder if there are small and portable library that performs wavelet processing that can be ported to Android. Following the UNIX philosophy of doing one thing and doing it well, we could combine dcraw (RAW decode and demosaic), the wavelet library (noise reduction, sharpening, local contrast, etc) and haldcluts (tone and color adjustments), hook them up with some UI and we could end up with a basic pipeline for processing RAW images on Android, all done with free software.
My other plan is porting Hugin and Enfuse to Android (AFAIK Hugin has been done by CM). We use Camera2 API to take slightly under-exposed burst images, align them using Hugin and blend them together using Enfuse/Enblend to minimize noise in shadow areas and preserve highlights. This is how Google Camera’s HDR+ works, but the implementation is proprietary and I think it is also tied to the hardware so it can process them very fast.
I just checked that dcraw is licensed under GPLv2, doesn’t that require dcraw mobile to release its source code?
Edit: Okay, reading from the license header of dcraw.c, it seems that one can use it under permissive licenses as long as Foveon support is removed. So I guess an easy test is feeding dcraw mobile Foveon RAWs and see if it works.
Thanks, I found it. I just expected to see it under RAW Development tool. I believe that as soon as you closed RAW development you are basically editing the JPEG, so some details are already lost, am I correct?
That’s a good question. I will say that the processing time for each editing step done on a raw file is longer than when done on a jpeg. It leads me to believe that the entire processing pipeline for a raw image in Snapseed is done at higher bit depth, but I cannot absolutely confirm that. These were just casual tests. I suppose the best way would be to shoot an image with raw + jpeg, and then process both with the same settings (getting as close as possible with the raw development tools) to see if there is a quality difference in the output image.
Thanks for checking this, @Tobias. Too bad! But at least it’s proof of concept. Maybe I will look into what it takes to make this kind of port. I know Java apps are easier to translate to the Android API than are C apps, so maybe that is a place to start…
).