RAW file support

[SmilyOrg]

Is your feature request related to a problem? Please describe. RAW files are completely unsupported right now so it's not possible to see them at all.

Describe the solution you'd like Transparent support for common formats so that they just look like any other photo. Depending on how long it takes to convert, this might need thumbnail generation (issue TBD). I believe often they are also paired with JPEGs, which would be nice to take into account.

Additional context Can be a deal breaker for many if not supported, see HQ's comment

[ckyb]

I'd like to take a stab at working on this. A lot of projects seem to use darktable for handling RAW images. I use it personally for managing photos locally.

My approach would be to implement a io/darktable/darktable.go module that uses the darktable-cli with any configuration applicable (eg. specifying an icc profile, default extension, resampling, height/width, ...) and any supported files, then reflecting any changes in image/source.go, image/sourceConfig.go, and applicable tests.

The output would be similar to ffmpeg - thumbnail and image previews.

A secondary addition (not necessarily tied to raw images) would be to configure exporting/download images - eg. "Download as RAW", "Download as JPG", "Download as ... (configure)"

[SmilyOrg]

Hey, that would be great, thanks!

I experimented a bit with imagemagick as it seems to support a lot of RAW files as well (as noted by @DawidPietrykowski in https://github.com/SmilyOrg/photofield/issues/55#issuecomment-1509874706). As a bad developer I didn't integrate it into master and only pushed it as a branch now, sorry about that 🙈. The reason is that it works "ok", but it's quite heavy/slow, so probably not a great experience.

In any case, you have the right idea on how to add it and perhaps the imagemagick commit above can serve as a further example. I'd be most interested in knowing how it behaves in a "real-time" scenario, i.e. you have a view with 10 photos, so darktable-cli gets run 10 times in parallel.

On the secondary download button idea, it's a bullet point in https://github.com/SmilyOrg/photofield/issues/26. I implemented a crude version at some point, but I didn't like how it looked, so I left it in, but commented out (great I know!). It only exposes all the sources right now, but with some extension it might be useful as a general "export" function too.

Let me know if you need some support on the implementation and I'll try to help!

[ckyb]

Oh awesome, thank you for all that info. That would actually help quite a bit.

Darktable-cli supports multiple --import arguments to batch raw file conversion in one go. My approach would be to configure how many to batch at a time, and eventually configure parallelizing darktable processes if desired.

For me, with highquality resampling, it takes 4-5 seconds per raw CR2 and CR3 photo (~28MB-32MB files) to convert them on an i5-8350U laptop CPU. Darktable takes about 1-2 seconds to start before converting. Without highquality resampling, it takes half the time. Exporting only --width 256 cuts that down a considerable amount too, maybe 1 second per photo (great for thumbnails). By default, darktable outputs a 1:1-ish conversion, so the resulting jpeg (without any options and hq resampling) is pretty hefty (~16MB from a 28MB raw).

Image Magick support is something I'm interested in as well for providing previews to Photoshop's PSD files.

[SmilyOrg]

Good findings, thanks! So it's not super fast, but also not too bad. Would still be interesting to try it out as an on-the-fly decoder.

I wonder if you can make it spit out a photo as a "raw" (for the lack of a better term) RGB image. While that's not practical for saving the file, my guess is that it'll be faster to read/copy that in as a Go image as you avoid the jpeg encode and decode step. That's what the ffmpeg/imagemagick implementations do via PAM files, which are just RGB with a text header.

Similarly you might want to avoid decoding to the original resolution if it's not needed (loading an 8k photo to show on a 720p phone is a waste), check the ffmpeg/imagemagick configs on how to set up the different scales.

I haven't tried the imagemagick branch on PSDs, let me know if you give it a spin. And again, happy to support in case of questions! 😄

[ckyb]

Yeah, a lot of my raw photos are typically coupled with jpgs anyway (usually shoot in both raw and jpg since it makes previews much quicker and it's easy to send off "proof" photos quickly), so dark-table would be more on-the-fly and for raws that don't have an accompanying jpg.

The above use case actually brings up the question (which I guess loops back to the "Download as" option in #26), where it may be worthwhile to have an option to group similar-titled images and assume they're related (eg. "IMG_0001.JPG" is related to "IMG_0001.RAW", so we can show the raw as a download option).

I didn't see a way to export from darktable other than jpg/png, but there's bound to be something there. I'll try implementing this within the next few days (if I don't get side tracked playing around with other features...)

[SmilyOrg]

Yeah grouping those is a good idea, though personally I don't have many cases for that right now. I have been thinking of a deduplication feature, it could be related to that as well. Dedup to not show the same photo multiple times + include related media in the download section.

Just FYI I might be a bit less responsive in the next 1-2 weeks, but I'll try my best :)

[SmilyOrg]

Hi @ckyb! Just following up, did you get the chance to look into this? :) I can help you get set up if you'd like.

[ckyb]

Hey Miha, I'm finally allocating some free time for development. I'll be able to work on expanding RAW support this weekend - and I wanted to try and add in grouping - where similar-named images can be grouped and provide a "Download JPEG | Download RAW" option, instead of showing duplicate images in the view.

I'll push up a fork tracking the work when I get started, and hopefully open up a PR for review.

[SmilyOrg]

Hey there! That's great to hear! Just as a heads up, I'll be a bit busy for the next month or so, so I might not be able to respond quickly. Feel free to join the Discord if you'd like a more freeform chat that you don't want to do over GH issues as well.

As for RAW support, you could look into supporting that as a "variant" of the jpeg. For example, all thumbnails are just considered variants of the same photo and they are used for rendering, but otherwise don't really show up as duplicates anywhere. The same goes for the different video variants that Synology Moments creates (eg an h264 version) that are used as fallbacks in case the original doesn't play well in the browser.

All of the variants should also already be available in the right-click context menu, so if you add RAW as a variant, even if the data itself is not used anywhere, it would be an easy way to make it downloadable.

I also tried once to add a more explicit download button to the fullscreen photo view and there might be commented out code there to this effect, but it didn't look right at the time. You could revive that as well if you're interested :)