I am trying to get ready for a new PhF official release, and I would need help to test the current version on various platforms to see if there are still frequent crashes or not…
I particularly need people testing the recent changes in the lens corrections and the GMIC film CLUTs. The film CLUTs are accessible from the color tab of the tool selection dialog:
while the lens corrections are part of the RAW processing tool:
The Linux AppImage as well as the OSX & Windows packages are available from here (you have to get those tagged 20170119).
The Windows package does not need any installation: just extract the ZIP file anywhere on your hard disk, and run photoflow.exe from the bin sub-folder.
I just installed the Windows package and started it. It shows only jpeg, tiff and png files when I don’t change the selection to All files where it shows all files, means also .pp3 from rt and .zip and so on…
I opened a D800 NEF (took some time, but that’s not the problem). Then I activated ‘hot pixels filter’. Again long time until the ready green appeared, but worked. Then I activated chromatic abberations. Again long time untilt the ready green appeared, but worked. Then I changed ca-correction method from profiled + auto to auto.
=> crash (though this step was much faster )
I have been testing for around an hour PhotoFlow on Windows 7 (64 bit):
CPU: Intel i7
RAM: 8 Gb
I works extremely well: no crash whatsoever and I have tried to test most basic settings. Plus, of course the Gmic film cluts options which work great as well.
I have noticed the size of PhotoFlow, once extraced, is now huge: 570 Mb
All in all the software is extremely powerful indeed !
It even works relatively fast with a GIS Tiff image (around 196 Mb)
Compared to its previous versions it looks even much stabler on Windows.
Most relevant, the way it works with stacked layers is extremely interesting compared to others Open Source Raw softwares.
It reminds me Delaboratory [1] : which is not longer developed (and luckilly PhotoFlow is much more powerful than Delaboratory 0.8, its last open source release).
I’m testing on Win10, Core i7, 64.
All crashes I report were repeatable.
Loaded a .CR2 picture. Ir recognised camera and lens.
when I change the exposure I get some strange pixels in the picture (see bottom). These go away again, when I do something else.
Purple strip on the top when using distortion or all corrections (in all 4 modes); strip is present in exported final image. Tried several images, all same camera and lens. Gmic’s CLUTs appear fine, haven’t test all of them. OSX 10.11.6
First of all, thanks to all of you for the very quick feedback!!!
I’ve put all answers in a single post, for convenience:
Yes, I still have problems with MIME types under Windows… I probably need to check how RT handles this.
The long time between the “orange” state (caching) and the “green” one (ready) is taken by the pre-computation of the whole full-res RAW processing output, which runs in the background… the preview is already updated when the status indicator changes from red to orange.
Ok, that’s where you can really help me… the windows version should contain a gdb.exe executable in the same bin folder as photoflow.exe. Could you re-run PhF through g=GDB and send me a full backtrace of the crash? The I can see where it fails exactly…
This is because the current ackage contains debugging symbols, so that GDB can provide a meaningful backtrace… the final release will of course be stripped and take much less disk space.
In fact, the speed of the preview rendering should be completely independent of the input image size… you could load a 100Mpx image (or even more) and process it on far less than 2Gb of RAM. The program will first of all pre-compute the 1/2, 1/4, 1/8… scaled-down versions, and then use the most appropriate one for processing the scaled-down previews. This is also why loading of images takes a bit of time…
Well, I have actually studied quite in detail the delaboratory sources in the early days of PhF, and took quite some ideas from it…
Could you provide me the CR@ file, or even better run PhF through GDB and send me the full backtrace?
There might still be a bug in the processing of the scaled-down RAW preview… I will have a look.
Good to know, thanks!!!
Could you provide me one sample RAW for this camera/lens combination?
I tried but after thread apply all bt full the window continued writing lines for at least 10 minutes then I just forced a stop. Is that normal?
Looking into the log file it seems there is some usefull information at the beginning.
I can probably do this during the weekend.
Have you tried redirecting the output to a file, like I explained here? I do not know if such a long backtrace is normal, but I’m ready to inspect your log file even if it is very big…
I’ve a couple of odd behaviours on Windows 7/64 bit
I initially get empty space at the top and bottom of the option menus
When using Color>>Emulate Film [Various]
and select Faded (extreme)
I get a faded image as expected.
BUT if I press the reset to default arrow next to opacity, it apparently sets the layer opacity to something very low, and it is not possible to make it opaque again (?) as the gamma and contrast sliders have very little effect. However the brightness and hue adjustments do have an effect!
@paynekj reminded me that something alike happens in OSX too, all of gmic’s dropdown CLUTs’ list get “erratic”, the mouse scroll sometimes is inverted, empty spaces are created, tiny Munch’s screams appear everywhere, evangelists start singing the end of the world
@Carmelo_DrRaw here’s the raw file, not interesting at all but has some straight lines; let me know if you need other human organs… and thank you. BTW, is it me or PF is a tad faster, at least exporting?
@chroma_ghost@paynekj the CLUTs list issue seems to be a gtk bug… looks like I need to find another way to implement those long lists.
I have tried to process this RAW file, but I could not see any purple lines in the exported output (but they are present in the preview). Still investigating…
It could be that PhF is getting faster, as I am trying to optimize things wherever I manage. Glad that this is somehow noticeable
Today, I have downloaded the new Zip installer to try it on Windows 7 - 64 bit
CPU: Intel I7
RAM : 8 gb
There are 2 ways for me to always crash PhotoFlow on Windows 7
Both occurred also in the previous versions but now I got a backtrace
First crash:
Open an image and select the stamp clone tool.
Clone some part of the image: sooner or later PhotoFlow always crashes.
You can get the log text file [1] and a video [2] with all steps to reproduce this glitch.
Second crash:
Open several Nef raw images (Nikon D700).
Sooner or later PhotoFlow crashes when you open one of them. It only suffices to open many images in a row to unleash this crash.
Here is the log text file [3]
BTW, I suppose it is a Gtk problem but I have noticed that when you manually type a value and you press enter to confirm it quite often it is not applied.
For instance, in my video [2] I have changed the size of the circle for the stamp clone, pressed enter to confirm it, but the value was not modified - increased (the cursor was always blinking as busy).
While I could not reproduce your crash, the logs allowed me to spot something that was clearly not correct in the code.
It could be that the program is simply running out of memory, although it should not happen so easily… I will investigate.
@Silvio_Grosso@chroma_ghost could you try the latest builds and see if they solve at least part of the issues, particularly the clone stamp crashes and the corrupted pixels around the image with distortion correction?
Purple’s gone, the “line” is still there now’s black, in some images sits on top only, in others (like the in this flower) is all around. Dunno if PhF is supose to crop that out or not, illustrative screengrab
Tonight, I have downloaded the newest installer, that is 20170121
Unfortunately both crash still occur.
When you open many images in a row (nef - jpeg) PhotoFlow sooner or later stops working. It is very random but still bothering…
Once, the GUI was stuck - freezed but there was not any segfault on the gdb console. I had to kill PhotoFlow manually with the task manager to continue working on my Pc
Here you can get the log file [1] for this crash.
I have always looked at my task manager (for the CPU - RAM usage) and there were not big spikes in their usage (I have got 8 gb Ram and Intel I7 CPU).
This crash is not even related to some specific images (nef - jpeg) because I made PhotoFlow crash with the same Nikon D810 image opened twice in a row (it is around 28 mb). First time it opened without any problem; later, same image, it crashed.
Another nuisance, is the window message which asks me whether I want to recover an image wich has crashed in the past. It always even pops up when I open several times the same image in a row (to test Photoflow…).
Crash when working with clone stamp tool.
This crash has always occurred with every version of Photoflow I have tried in the past.
Here you can get the log [2] and the video with all my steps to unleash it [3].
Thanks a LOT for your hard work: it is really appreciated !
)
