PhotoFlow vs Filmulator

Hello

Maybe “vs” is not the right word, but there are these two programs PhotoFlow and Filmulator, and I wonder several things:

  1. How are they different?
  2. How many devs does each one have? Are they both one-man projects?
  3. How do they differ from RawTherapee and darktable?
  4. Is the idea behind either of them to make a usable raw development program, or is the idea and the emphasis behind each to simply practice coding, and the fruits of the coding are the programs? I see a strong ideological difference there.
  5. What justifies their existence considering what’s already on the libre graphics market?
3 Likes

Talking about PhotoFlow, the main difference compared to RT and DT is that the processing is node-based, with the possibility to combine the editing nodes in an arbitrary sequence, group them together and limit their effect using opacity masks.

The nodes are represented in the GUI with layers, because this is more familiar to users and more adapted to image editing.

This approach is quite different compared to the modular structure of RT and DT, where the sequence of editing steps in the pipeline is fixed.
I believe that the adjustment layers way of editing is more flexible than the one based on modules.
An example: the “Orton effect” requires a special module in DT, while it can be realised with a combination of basic tools in photoflow (using layers and layer groups).

At present there is no other open source image editor that provides non-destructive adjustment layers… GIMP is slowly going in this direction with the integration of GEGL, while photoflow already provides this way of editing today :smiley:

Modifying DT or RT to work with layers and layer groups would, as far as I understand, imply an almost complete rewrite of the processing pipeline…

Another difference is that PhotoFlow works mainly in RGB, with the optional possibility to convert and edit in Lab mode (and will soon support CMYK as well).

Concerning manpower, yes, the project is presently a one-man effort… but I’m taking advantage of a lot of the work done in RT and DT, mainly for tools implementation and new cameras support.

Anyhow, my goal is not to practice coding but to create something that is usable and flexible…

1 Like

Thank you for the reply!
I’d like to hear how all this compares to Filmulator, as RT and dt I’m quite familiar with :slight_smile:

###Overview of Filmulator

Filmulator the editor is primarily designed to bring you the Filmulation algorithm, which is an amazingly versatile tone mapping algorithm that gives Filmulator probably the most unique, and in my opinion pleasing, out-of-the-box look of any raw editor. If you exposed well, most scenes shouldn’t need any intervention.

Filmulator is designed to streamline my (personal) workflow, and if that means sacrificing flexibility, so be it. It uses its literal film simulation to make unnecessary most of the tweaking that I used to have to do when I used a conventional photo editor. The basic result should “just look good” assuming you are satisfied with realism.

I’m not a fan of the Instagram/VSCO look with lifted shadows, split toning, added grain, color shifts, and all that, so I don’t include them.

If you want a realistic look, then Filmulator may be for you. If you want flexibility, Filmulator is not for you.

###Differences with PhotoFlow

PhotoFlow has a workflow designed for working with layers in arbitrary sequences. This is powerful, but it takes more mouse clicks to do a basic edit, unless you develop your own presets.
Filmulator doesn’t even have presets; it’s designed so that you can process every image in a way best suited to it without needing presets to speed up the process.

PhotoFlow has no library management. It seems to be “open a file, edit it, export it”.
Filmulator has you import photos from memory cards, stores them in a configurable folder structure on both your main storage and an optional backup, and lets you easily browse your photos. It offers a histogram of how many photos you took per day, and it lets you change the effective time zone to accommodate trips to other parts of the world without confusingly splitting a day’s photos across midnight. It has ratings that let you mark photos you particularly like. Eventually once I figure out the best way to do it I’ll have tags and stuff.

PhotoFlow’s user interface focuses on the tools.
Filmulator’s user interface focuses on the photo: as a result of needing far fewer clicks, I spend far more time inspecting photos than actually changing settings. So Filmulator renders the full photo every time you move a slider, and once it’s done you can pan and zoom freely at 60 fps, even on a high resolution monitor.

###Devs

Filmulator is a 1.5 man project; me and one of my IRL friends who tends to do mainly backend stuff (image processing).

###Differences from RawTherapee and darktable

Filmulator is focused on having as few tools as possible, and in making a decent output possible with as few mouse clicks as possible. It encompasses the full workflow, more similarly to darktable which has a library system.

darktable has a weird learning curve that I was never able to climb successfully. I was never able to get photos to look the way I wanted out of it, even though I know what each individual tool does. I hear that this is because of the base curve which is applied before everything else in the pipeline, therefore making everything else operate in nonlinear space.

RawTherapee has technically high quality output, but it doesn’t give me the look I want as easily as Filmulator does. I used to use it but would spend ten or fifteen minutes per photo, and it still wouldn’t turn out the way I wanted.

###Ideology

Filmulator is first and foremost for me to use.
I want to have a simple-to-use photo editor that does everything I want with minimal interaction.

I find other editors annoyingly slow to use, because the tools I want are scattered among tools I don’t want, and panning around in images is an exercise in patience; I have 16 gigs of ram and they really ought to be able to render the full image in the background so panning doesn’t lag. (Heck, Filmulator stores the full size image at several stages in the pipeline and it uses only around 2 gigs of ram)

There should only be one tool for each job, and it should be the best tool, and it should have an intuitive UI. Anything else has no place.

###Reason for existence

Why does it exist? Because it’s what I wanted to have.

I didn’t believe that other editor projects would be willing to discard most of their tools, so I’d need to fork them to get what I wanted out of an editor. I also wanted to use a modern UI toolkit to make it easier on me; I might as well start from scratch.

I give it away for free because I believe others might find it useful, and because it might inspire the other existing editors to do better (especially UI).

##TL;DR:

It’s the complete opposite of PhotoFlow.

Actually, this is a good topic to build on, thanks for bringing it up @Morgan_Hardwood!

What I mean is that I will be presenting (hopefully) at LGM in April on the state of PIXLS as a community, it’s growth, and the neat things that are going on here for free software using photographers. It seems to me that both Filmulator and PhotoFlow are two brand new projects that have had some growth and engaging community members - so I’d really like to be able to evangelize to the larger free graphics community what they’re about.

I think that @Carmelo_DrRaw is intending to present at LGM already, isn’t that right?
I don’t think @CarVac was going to make it out, but I could be wrong.

Do you think that both of you could provide me a summary of your projects that you’d like me to emphasize and present to the wider libre graphics community at LGM? It doesn’t have to be right now (or even soon) - just before I take the stage at LGM would be best, and maybe a little before to get a nice image or two to go along with it! :slightly_smiling:

I keep finding it hard to summarize Filmulator, because it seems different in so many directions. In different contexts, I’d say different things.

WRT tonemapping and HDR: Filmulator brings subtle tonemapping to every image. It’s surprisingly beneficial even (especially?) on low-dynamic-range scenes. It easily makes the most of modern high dynamic range cameras.

WRT working quickly: Filmulator’s film simulation takes care of many of the local adjustments you might apply manually, so it needs fewer mouse clicks. Even if you want to do them later, it provides a good base.

WRT user interface: Filmulator emphasizes having few tools and being easy to use, with a transparent pipeline. Examining the edited photo is pleasant and quick, with OpenGL acceleration.

WRT photo database: Filmulator makes it easy to manage backups and organize your photos across multiple machines. (Well, that’s the plan, I’m still working on that).

1 Like

There is one more substantial difference I was forgetting about…

PhotoFlow allows to combine several images in one single edit, while RT and DT are limited to one single input image. I don’t honestly know about Filmulator though.

Think about exposure blending through luminosity masks: in PhotoFlow, that can be done directly from the RAW files, and in a totally non-destructive way. For example, you have unlimited freedom to modify the exposure blending mask after it has been created, until you are fully satisfied. The mask can be tweaked with curves, threshold, blurs (gaussian and/or bilateral or else), etc… and combined with gradients, hand-painted masks or spline-based fuzzy selections.

Do Filmulator and PhotoFlow support HDR DNG?
http://filebin.net/ebwcyep3gj
I’m especially curious about how Filmulator’s tone-mapping operator would deal with it.

For reasons of “I need to come up with a good interface” there are several things I plan to, but have not yet, implement in Filmulator.

Among these will be combining multiple exposures.

  1. HDR merging. This isn’t going to be arbitrary masking, it’ll be ideal-minimum-noise merging; a brighter exposure gets more weight than a darker exposure, as long as the brighter exposure isn’t clipped on that pixel. The CLI version of Filmulator was able to do this but it is incredibly cumbersome to use, and it was I think too conservative about avoiding clipping. You will be able to do all one brightness (stacking), or you would be able to do bracketed exposures. And it ought to be able to handle misaligned images too.
  2. Panorama merging. Hugin…works well, but it could use a completely rethought interface, IMO, possibly involving adding one image at a time so that you can ensure its fit with respect to previous images is “sane”. Plus, with modern computers have massive amounts of ram, Hugin’s method of writing everything out to disk is unnecessarily slow. It could use some optimization, at least.

@Morgan_Hardwood: If LibRaw and Exiv2 support it, Filmulator supports it. Seems like LibRaw doesn’t like those. It complains about the dimensions being too big…is it embedding separate image planes into one DNG, or is it merging them into one image plane like how I described in (1) above? The latter should be easily handled by Filmulator’s tonemapping algorithm.
Do note that for now I don’t really have error handling everywhere; it currently crashes when you try to import them.

Not yet for PhotoFlow, although this and OpenEXR support is in my future plans. Particularly since I’m presently modifying several tools to work in unclamped (and optionally linear) RGB mode, which is more suited for scene-referred editing, and to do unclamped colorspace conversions…

Looks like LibRaw won’t support HDR DNG in the foreseeable future…

Hmmm…it’d probably be easier to use 16 bit integer tiffs as if they’re a logarithm.

Ah yes, I should add “lack of floating-point DNG support” to the list of reasons not to use libraw if RawTherapee turns away from dcraw.

@CarVac it’s a single plane plain old not-demosaiced image with floating point precision. Obeys the DNG standard, I’m told.

PhotoFlow has recently switched to RawSpeed for the RAW decoding, and as far as I understand RawSpeed allows opening HDR DNGs, but I should make some test to see if that is really the case.

@Morgan_Hardwood Uhmmm… looks like I was wrong: RawSpeed does not recognize your files, and also Darktable does not want to open them.

However, I can rather easily switch to RawTherapee’s RAW loading backend for files that are not properly handled by RawSpeed, like in this case. Would you consider this an acceptable solution?

In fact, I think that RAW file loading in the OpenSource world is still quite a mess :astonished:

There are several courses of action here for Filmulator.

The first one is something I’ll do regardless: I’ll catch the crashes and not accept floating point DNG files, and instead simply offer stacking and bracket blending within Filmulator to achieve the same purpose.

The next is to accept high dynamic range non raw formats like EXR and a logarithmic integer tiff and maybe floating point tiff as well, and also have them be available as outputs from the initial loading stage for stitching. I’m hesitant but at the same time likely to do this. It’ll be effective and easier than completing built in stitching, but in terms of the program structure, inelegant and kludgy.

The last is to switch raw loading libraries. This might take some time, because right now I rely on LibRaw to perform demosaicing. My Halide implementation of LMMSE isn’t finished (it gives valid output but needs optimization), and I need to figure out highlight recovery, but once I do, that will give a large boost in performance especially when we get gpu acceleration working.

@Carmelo_DrRaw as a user any method is fine as long as it works :slight_smile:

@CarVac I don’t understand your stance - willing to support messy log and fp TIFFs which could be anything while not wanting to support fp DNG covered by the DNG Version 1.4 specification. But then you did write, [quote=“CarVac, post:4, topic:688”]
Filmulator is first and foremost for me to use.
[/quote]

@Morgan_Hardwood
Talking about HDR and floating-point formats, I am currently working on an experimental branch that not only supports reading and writing unclamped floating-point TIFFs, but also implements unclamped (i.e. HDR) editing for several tools (for example you can apply a negative exposure compensation to a floating point TIFF image to recover the details that were originally >1.0).

There I plan to include EXR and HDR DNG support as well (at least for reading).

This seems to be particularly interesting for scene-referred editing in the VFX industry, but probably it can be significantly useful for more “normal” photographers as well…

Sure! I’ll try to prepare some nice screenshot to show how the interface looks like, and few sentences to summarise the main features. This independently of a possible dedicated talk.

Thanks!

It’s a matter of code cleanliness and performance consistency. I don’t want cascades of different raw handling libraries that won’t necessarily give equivalent results.

You’re right about hacked log tiff being a bad idea though, I’ll completely scratch that.

The whole file format situation we’re in is appalling. As with many things in life, you can make a triangle out of this situation. In this case, in the corners you have: image storage options, metadata support, and licence situation. You can have a great format like BPG which supports various storage options (lossy, lossless, various bit depths, etc), great metadata support, but you can’t use it because patents. You can have OpenEXR, no licencing issues, good image storage options, but doesn’t support Exif, IPTC nor XMP (as far as I know - please prove me wrong!). Then there’s a bunch of formats with free licences and support for metadata, but image storing options from the dark ages. Ugh. There’s a bunch of good technologies which aren’t being widely used because some company demands exorbitant licencing and royalty fees, so they’d rather sink and take our generation down with them instead of facing facts and releasing the technology openly because they won’t make a dime off of it anyway. Oof.

Nice thing about HDR DNG is that it has all the benefits of typical DNG - great metadata support, various storage options, no licencing issues I know of, the files are very small - a 16-bit floating point HDR DNG made from five 12MB raw photos ends up taking about 14MB - so much space saved! And yes, 16-bit with floating-point precision is all you need.