New PhotoFlow windows package for testing

I have prepared a new Windows package for photoflow, compiled in 64-bits mode.

The new experimental package can be downloaded from here. The package is automatically cross-compiled under Linux using Travis-CI, so there should be zero chance of having viruses…
To test the program, just unzip the package and run photoflow.exe from the photoflow-20170531\bin\ folder.

I do not have a windows machine for doing extensive tests of this version, so I need to rely on your help to check that everything works as expected. The executable was compiled with debugging symbols and no optimizations, so that crashes can eventually be tracked down with gdb.

Thanks in advance for checking!

1 Like

I get this:

I’ve not found gdb.exe in the bin folder.
I’ve tried with different nef sizes, even with jpg. Seems to end at the same point.


Same crash here:
Windows 7 - 64 bit
CPU Intel I7
RAM 8 gb

PhotoFlow crashes as soon as you open no matter what image: nef, jpeg etc
Tried with different pictures to no avail :frowning:

The output on a log.txt file is (didn’t find the gdb.exe on the bin folder):
exePath: C:\Downloads\photoflow-20170531\bin
dataPath: C:\Downloads\photoflow-20170531\bin…\share\photoflow
localePath: C:\Downloads\photoflow-20170531\bin…\share\locale
Setting XDG_DATA_HOME to C:\Downloads\photoflow-20170531\bin…\share
System data dirs:
User data dir: C:\Users\silvio\AppData\Local
Loading custom settings…
… custom settings loaded.
get_save_sidecar_files(): 0
Starting image processor…
Image processor started.
locale dir: C:\Downloads\photoflow-20170531\bin…\share\locale
PhotoFlow: is_plugin=0
Open clicked.
File selected: D:\NEF_FILES\FUNGHI_PDA_retro_petri_v1.JPG
ImageEditor::on_realize() called.
Opening raster image D:\NEF_FILES\FUNGHI_PDA_retro_petri_v1.JPG
ImageReaderPar::build(): creating new RasterImage for file D:\NEF_FILES\FUNGHI_PDA_retro_petri_v1.JPG
PreviewScrolledWindow::on_map() called.
ImageReaderPar::build(): RasterImage for file D:\NEF_FILES\FUNGHI_PDA_retro_petri_v1.JPG created
ImageReader: Embedded profile found: sRGB
ImageReaderPar::build(): get_format()=6 image->BandFmt=0
ImageReader: Embedded profile found: sRGB
ImageReaderPar::build(): get_format()=6 image->BandFmt=0

@phweyland @Silvio_Grosso
Thanks for checking… you can get a working gdb.exe executable by following the instructions from the RawTherapee issue tracker:

Direct link:

I would be really interested in seeing where exactly the program crashes!

Meanwhile, I am preparing an updated windows package that fixes a rather nasty bug in the RAW decoder that I found today. I’ll post the link to the new package here as soon as it will be available.


Here is the crash file:
PF_crash-20170531.txt (8.9 KB)

Here is mine (Windows 7 - Intel Cpu I7):

As soon as I have tried to open a jpeg image PhotoFlow crashed (same occurs with Nef files).

Thanks! The crash occurs somewhere in the caching phase of the image… I need to compile VIPS with debugging symbols as well, since the crash happens in the VIPS code.

I will prepare a new package and send it around, if you can do some more tests.

@phweyland your backtrace is truncated… you need to hit return at the GDB prompt until all the output is shown. This is the message you have at the end of your log file:

---Type <return> to continue, or q <return> to quit---


Yes … I thought the first events were enough. Next time I’ll complete the trace.

1 Like

@phweyland @Silvio_Grosso
New package ready for testing:

GDB.exe is this time included in the bin folder, and VIPS was compiled with debugging symbols to better track down the reason for the crashes…


Here is new log file (as usual on Windows 7 with a jpeg image)

Thanks Silvio! Unfortunately this time the backtrace is completely empty… looks like GDB has some troubles under Windows, as it spits a lot of

previous frame inner to this frame (corrupt stack?)

messages… no idea why.

Also, the number of threads seems abnormally large (49?). I am trying to access a windows 7 machine at the moment, and to run some tests on my side.

Maybe you could try to reproduce the crash again, and see if this time you get a meaningful stack trace? You should see at least some lines referring to line numbers in source files.



Tried again on Windows 7:

AND Windows 8.1 (Cpu Intel I7 - RAM 8 gb):

Both on Windows 7 and 8.1 the gdb backtrace is similar:
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I did a quick web search on previous frame inner to this frame (corrupt stack?). I am not a programmer so this link might not be helpful.

@phweyland @Silvio_Grosso @afre
I have finally managed to reproduce the crash with wine under Linux, so now I can debug further… I’ll post here as soon as there is some progress.


@Carmelo_DrRaw Were you able to follow up with the Windows build?

The latest build, photoflow-w64-20170621.., crashes when I try to open a file like the ones here. The last functional version for me is photoflow-20170521.

Here is the output; I added the Windows crash output at the bottom: _log.txt (2.1 KB)

Not yet… I am now pretty convinced that it is a question of 64-bit architecture/tuning at compile time. The build from the 21st of May was a 32-bits one.

Could you try the latest 32-bits build (photoflow-w32-20170621...) and see if it works for you?

Fixing the 64-bits version will take some weeks, so I will probably remove them from the releases page for the moment, if the 32-bits version works fine.

Thanks for reminding me!

Yes, I tried the 32-bit build as well. Here is the output: _log32.txt (2.1 KB)

Which camera model is it?

Thanks for looking into this :slight_smile:.

Hi Carmelo, do you need more gdb runs for photoflow-w64-20170621 ?