I have finally managed to prepare and publish the next PhF release, v0.2.6.
You will find more details and a full changelog in the blog or the github release page.
Any feedback is really appreciated.
Thanks for looking!
5 Likes
For Windows 32 bit.
CHANGELOG:
New features:
Implemented GIMP plug-in
Where is this file (pfgimp.exe?) - or is supposed to work differently - how?
Hello,
To begin with, THANKS a lot indeed for this release: it is chock-full of very interesting features 
I have just downloaded the zip file (from github): photoflow_0.2.6 setup.
Unfortunately, It doesn’t work on Windows 7 - 64 bit.
In short:
The launcher is unable to conclude its job (to install photoflow).
Here you can see a screenshot with the error:
EDIT: OK. Now it works !
I have realized that you are forced to launch the .exe with “Administrator privilege” (otherwise you get the error above-mentioned).
EDIT: just got the first crash
It occurs while working with the Clone-Tool.
I am going to test a little longer this new version on W7 and report back here all my notes.
On the whole it looks quite promising and powerful !
I was about to write you about the solution you found…
The windows version is the least tested, because I have no windows machine myself.
If you would be willing to do some tests and report things back, I can provide you a version compiled with debugging information as well as a gdb.exe, much like the RawTherapee guys are doing with their development versions for windows…
Thanks!
I realise that this information is completely missing from my announcement, thanks for the heads up!
I’m not shipping the GIMP plug-in myself, as I would need the GIMP development libraries under Windows and OSX, which I do not have yet.
However, Partha is kindly providing GIMP 2.9 versions for Windows and OSX which now include the photoflow plug-in as the default RAW loading interface.
For Ubuntu users, Thorsten Stettin is working on a plug-in package for his gimp-edge PPA, but things are not working properly yet, so I would suggest to wait for the next updates.
I’ll put this informations in the blog post.
Gave the Ubuntu build a quick try.
It seems to be very unstable. Had 3 crashes within about 5 minutes. 
I couldn’t reliably reproduce the issues but given the frequency of the crashes it should be quite easy to catch them in a debugger.
Also: ImagePyramid: cache file: /home/jonas/.photoflow/cache/pfraw-jBXFoS
It would be really nice if photoflow could follow the XDG Base Directory Specification.
In other words write to ($XDG_CACHE_HOME || $HOME/.cache )/photoflow/ instead of ~./photoflow/cache/.
Uhmmm… the current version is working quite stable for me, so you must be doing something I don’t usually do myself, which is good!
The Ubuntu builds do not have debugging symbols. Should I ask darius Duma to try setting up a debugging package in your PPA, or would you be able to compile the sources? In which case,
-DCMAKE_BUILD_TYPE=Debug
will be enough to get an executable for debugging ?
Agree, I will do that before next release.
Thanks for looking!
Hello everyone,
I am continuing my tests on Windows 7 (64 bit)
CPU Intel core I7
8 Gb RAM
Gpu Nvidia Graphic card
First impressions:
- Opening a Raw (NEF - DNG from Nikon D700) image, no matter what, requires quite a lot of time : always more than 10 seconds whereas with Rawtherapee they open super fast.
- Ctr+O: doesn’t work as a shortcut (to open my images). I suppose this shortcut is not implemented yet
- PhotoFlow displays some of my DNG weirdly (while Rawtherapee is fine).
See this screenshot to compare the results:
Here you can get this same Dng image to test yourself:
https://dl.dropboxusercontent.com/u/3095134/BUGS_REPORT/PHOTOFLOW/GLOBODERA_ROSTOCHIENSIS_CISTI_PATATA_5X.dng
-
When I open a folder to load my images with PhotoFlow I am always forced to click on the lower-left to select “All images” in order to also visualize my raw images (not only my jpeg images) and this is a bit time-consuming
-
To usually crash PhotoFlow on Windows 7 I only need to open a Raw image (NEF - DNG) and, once it is opened on the GUI, suddenly click on the icon “Exit PhotoFlow”. Most of the time the software crashes here.
-
As regards a new experimental version (with GDB included) I am already able to test softwares on Linux to get some useful backtraces.
Currently, I don’t have at hand a virtual machine (via Vbox) installed on Windows 7 (as guest) to test PhotoFlow on Ubuntu (Kubuntu 15.10) as well. However, there are plenty of Linux users on this forum…
THANKS a lot for your work on Photoflow : it is really appreciated !
Hello Silvio!
quick answers to the points you raised:
-
this is the consequence of the disk caching photoflow performs of the RAW data. Image versions at various scales are pre-computed and stored to disk, to speed-up the display of zoomed-out previews.
This also reduces the memory consumption, because only small portions of the image data are fetched from disk during computations. This becomes important when merging several images together: I’ve been able to merge three D810 full-res images on a virtual machine with 2GB of memory, and PhF was far from saturating the available memory. -
definitely something to be added in the near future
-
DNG loading: it’s not normal, I will look into that. Do you have the same problem opening the original D700 NEF file?
3b) I still have a problem with MIME types under windows, hope to fix that for next release
- For this, a debugging version run through gdb would greatly help, as I do not see such crashes under Linux and OSX
Thanks for the feedback!
Hello Carmelo_DrRaw,
As regards my Dng images everyone of them looks “purplish” on PhotoFlow.
I have converted them on Windows through “Adobe Dng Converter”.
They all look fine with Rawtherapee and Picasa (Google software).
Their corresponding NEF image (from Nikon D700) is always displayed fine (no color cast) with PhotoFlow.
When I open my Dng images the boxs “Raw developer” and “Raw loader” are both checked (that is, selected).
Actually, I don’t know their real “meaning”.
Lately, I have watched some new YouTube videos about PhotoFlow but their author didn’t load any RAW image on them. Therefore, it is not clear to me whether I should uncheck them or not
I suppose they must be both checked because everything works fine when I load the “same” NEF images with these settings ON.
So, it seems there is some problem in DNG decoding in photoflow… I’ll investigate into that.
By the way, why you convert to DNG? As it was discussed at length in another thread on this forum (I cannot find the link right now, but I’ll eventually post it later), there is practically no advantage in terms of file size and compatibility. Any software will open your original NEF files as good as the DRGs (and sometime even better 
).
They are both needed. In photoflow, the steps of loading the RAW file and of processing it into an RGB image are separated. If you uncheck the raw developer layer, you will be presented with the RAW data “as is”.
The splitting of the loading and processing parts is there to allow some “fancy” tricks like processing the same RAW data twice. You could for example imagine to apply a different white balance to a portion of the image, if the lighting of the scene is complex. For that, you can add a second RAW development of the same image, combined with an opacity mask to restrict the effect to only a specific part of the image.
In future this kind of “tricks” will be made more simple…
Hello Carmelo_DrRaw,
Thanks a lot for your reply !
By the way, why you convert to DNG?
Because, in the future, in case I would buy a Leica camera, they ship this format (DNG) as default with their cameras 
Joking aside, I am not that rich to allow Leica’s gear and I am mostly a Nikon shooter,
I do not use any “Nikon Picture style” on purpose, with my Raws, in order to produce files which are ready to being opened with any Open Source software.
I usually convert them to DNG because it allows me to not have any sidecar file (even though I never delete my Nef image either…).
This being said, in all truth, currently I am not really sure whether this choice (DNG format) is the “correct” one…
By reading the forums you get very mixed opinions on this topic.
In addition, It looks indeed as mostly Open Source softwares sometimes don’t handle this format very well…
IMHO, DNG images are “good” mainly in case you consider to work with Adobe software in the future (especially with Lightroom).
It seems to load the DNGs from my Pentax K10D without problems
[quote=“Carmelo_DrRaw, post:7, topic:1082”]
The Ubuntu builds do not have debugging symbols. Should I ask darius Duma to try setting up a debugging package in your PPA, or would you be able to compile the sources? In which case,
[/quote]I’ll try to build it. The dependencies don’t look to exotic.
Suprise suprise. My own (debug) build does not crash. I just got it to hang up in some way after adding a curves layer on top of some fairly expensive noise reduction. Is it possible that there is some timeout for gmic operations which will never complete if exceeded?
Btw, do you have some documentation somewhere on doing things like deleting layers and curve nodes, moving layers etc. ?
Edit now it crashed again but the stack trace doesn’t look too useful to me:
Error: signal 11:
./bin/photoflow(_Z7handleri+0x2b)[0xbc6bd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x352f0)[0x7f743832b2f0]
./bin/photoflow(_ZN2PF13ProcessorBase7get_parEv+0xc)[0xbe4386]
./bin/photoflow(_ZN2PF11LayerWidget20on_selection_changedEv+0x275)[0xfc2d0b]
./bin/photoflow(_ZNK4sigc18bound_mem_functor0IvN2PF11LayerWidgetEEclEv+0x66)[0xfcf170]
./bin/photoflow(_ZNK4sigc15adaptor_functorINS_18bound_mem_functor0IvN2PF11LayerWidgetEEEEclEv+0x1c)[0xfce862]
./bin/photoflow(_ZN4sigc8internal10slot_call0INS_18bound_mem_functor0IvN2PF11LayerWidgetEEEvE7call_itEPNS0_8slot_repE+0x24)[0xfcd904]
/usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f743a88d4f8]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x10244)[0x7f743c4ca244]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xc06)[0x7f743c4e4a46]
117 objects alive:
...
Didn’t run it in GDB though.
Which noise reduction tool exactly? There is no timeout in the code, so if it freezes this is most likely an issue with threads synchronisation…
Well, it is at least party useful.
I suppose the crash happened when you double-clicked on a layer name in the layer list? Is this reproducible? If yes, could you shortly describe the steps to reproduce the crash so that I can try myself?
Those two lines give a hint of where the problem is:
Sorry, not yet, and this is definitely one of the aspects on which I need to work urgently.
Layers are deleted by clicking on the small trash icon at the bottom of the vertical list of icons at the left of the layer list. Maybe this reference sketch of the UI structure can help:
To move layers you simply drag them in the tree widget.
For curves, points are added with a left click and removed with a right click.
Once a curve point is highlighted, you can move it by
- dragging it with the mouse
- using the up/down/left/right keyboard arrows
- set the horizontal and vertical coordinates in the numerical boxes below the curve
You can also add a curve point by directly sampling the colors in the preview area. In this case, you have to use the Ctrl+Alt+left_click combination on the area of the preview image that you want to sample.
Regarding DNG issues: my GR DNGs (native from the camera) just load as plain uniform gray. Example: http://filebin.net/g69fsk9ims
Additionally, it still can’t fill enough viewport pixels to work maximized on 4k (I’ve mentioned this before), and even just the demosaicing step, no additional layers, on a 12mp image is dreadfully slow when maximized.
Ubuntu 15.10 using photoflow_0.2.6-3dhor~wily.
You’re absolutely right, I keep forgetting about that… I’ve modified the code on github, you should get a 4k-compliant version if you install the photoflow-git package tomorrow or the day after tomorrow.
I do not have such a large display for testing, so I cannot check… is it the initial loading that is slow, or any subsequent adjustment of the RAW processing parameters once the preview image is shown?
Never mind, it’s just the initial loading. A progress bar would be nice, though…Even though Filmulator takes a while, I’ve been told that its progress bar (which is reasonably accurate) appeases impatience nicely.
That could be a challenge, though, given you’d need to essentially benchmark each layer and figure out a seconds-per-megapixel value, and at runtime figure out what size image it’s running on, and dynamically adjust as layers are added and removed…
Not really
The processing of the preview image in photoflow works this way: the requested area is divided into square tiles, and then each tile is processed independently (by as many threads as the number of CPU cores). For each tile, the layers are processed in a top-bottom fashion: each layer requests the pixels of those below it, taking eventually into account the additional border pixels that might be required by the filter.
Therefore I can easily predict how many tiles need to be calculated, and update a progress bar each time a tile is completed. It just takes some programming…
For the initial caching the situation is a bit different, but it might be doable as well.