Isn’t that thread about PhotoFlow?
Hello everyone,
Another strange behaviour of PhotoFlow (20170121) occurs with the crop tool.
When I press enter on my keyboard nothing happens. On top of that, the window to open an image pops up…
In all truth, I do not know whether I am supposed to press enter or not to apply my change to the crop tool.
I have recorded a video with all my steps for this problem [1] : enter (with crop tool) > launch the window to open a new image.
@heckflosse
Sorry for the “typo” about Photivo (instead of PhotoFlow) in my previous post.
In the past I have tested this open source software as well (now it is not longer developed)…
Unfortunately, on this forum you can not edit your past messages (in order to amend them).
There should be a small pencil icon that will allow you to edit previous posts you’ve made (this is what it looks like on mobile):
No, there is no automatic crop of the distortion-corrected result, hence the black border when the output image is somewhere smaller than the initial one…
In order to “exit” the cropping mode and actually see the cropped image, you need to select a different layer in the layers list. I am trying to figure out a better way to handle this situation, so that’s how it works in the current version. Suggestions for improvements are welcome… my current idea is to let the user press “Esc” to hide the crop area and show the cropped image.
There is a new version from today available on github, with improved cropping tool (it is now for example possible to drag any of the sides/corners of the crop area in order to modify it). I’d be very interested to know what you think about it…
I have done anything I could imagine to try reproducing this crash, without any luck… maybe you could try running PhF through some memory checker under Windows, and see if this can finally point to the origin of the problem? See here for example for some possible valgrind replacements for Windows.
Does this only happen when you try to open the same image twice, or also with many images that are all different?
There is still a bug that prevents from opening the same image twice… I’ll be looking into this during the week.
Yes, the exposure blending tool only works with the experimental linear_gamma
branch, at least until it will be merged into the stable code.
Hello Carmelo_DrRaw,
Tonight, I have unzipped today’s new version.
I run it on a different computer:
Windows 8.1 (64 bit)
CPU Intel I7
RAM: 8 gb
(my previous attempts were done on Windows 7 - 64 bit)
New crop tool is great !
With your explanations everything is fine now !
The crash with the clone stamp tool is present on Windows 8.1 as well.
As soon as you clone some part of the images (jpeg or nef), Photoflow always stops working and it crashes.
On Windows 8.1, PhotoFlow crashes when you open different images in a row.
To make it crash you need very big images.
With Jpeg images everything is fine.
With my own Nef D700 Raw images everything is fine too (they are around 8-9 Mb each)
With Nef D810 images you are in trouble
To easily reproduce this bug I have downloaded these big Nef Raw samples images from here:
In short, with today’s version, on Windows 8.1, when you open the first big D810 Nef image, everthing is fine. With a second different Nef D810 image PhotoFlow takes forever to open it.
After more than 5 minutes I have stopped it. On the Gdb console there were no segfaults. Only many threads opening forever…
I have tried many D810 images downloaded from this blog and when I opened the second Nef images (around 40-50 mb) in a row PhotoFlow always stopped working (this second image was never available to work with even after many minutes waiting for them)
Btw, I have reproduced also on Windows 8.1 the bug which occurs when you open the same identical image twice. As you know, currently, it is not possible to do so.
Btw, by error, I have opened a Pdf file and PhotoFlow crashed. I suppose it should not do so (crash with Pdf files) even though PhofoFlow is not supposed to open them for sure
All in all, PhotoFlow is indeed extremely powerful !
Congratulations for your work so far !
I agree.
I didn’t experience such problem on my Win 10 64bit. Not sure where the problem might be.
That’s weird… here is a screenshot of the current PhF version under OSX with 7 of those D810 files simultaneously opened. Each has been opened with the same speed, and no crashes. I will do some tests on Windows & as soon as I can get my hands on a Windows PC.
Glad you like it!
This problem is starting to drive me nuts… particularly because I do not manage to reproduce it by any means.
@heckflosse: would you have the possibility to do a quick test on your system? Using the clone-stamp tool is rather easy: you add a clone-stamp layer, you define the stamp size, then you Ctrl-Alt-leftclick on the image to define the source area, and you start left-clicking on other portions of the preview to copy the source area elsewhere…
Thanks!
Hello Carmelo_DrRaw !
Third attempt: this time on Windows 10 - 64 bit
CPU : Intel I7
RAM: 8 gb
GPU: Nvidia graphic card
(previous computers were based on Windows 7 and Windows 8.1 - 64 bit).
Even on Windows 10 (64 bit) all previous bugs are “easily” reproducible : All you need is a little patience to unleash them…
-
The clone stamp tool took me 1:40 minutes to crash PhotoFlow (yesterday’s version)
Here you can take a look at the video [1] together with the gdb backtrace [2] -
To “crash” PhotoFlow with Raw images you need very big images.
I have tried with the Nikon D810 images (around 40 mb).
First image always opened up super fast (no problem at all). But, as soon as I opened a different Nef D810 second image PhofoFlow took forever to open it (without success…). In the end either crashed or I had to stop it (after 10 minutes waiting…).
Here you can take a look at this problem:
Usually there was not a segfault on the gdb console (cmd prompt)…
Therefore I have always been unable to get a proper backtrace…
This being said, IMHO, these are “minor” issues : NO need for you to waste your time on it…
Personally, I only need to work with small Raw images: all my Nikond D700 opened fine (they are only 8-9 mb each). Only Nikon D810 Nef images are troublesome since they are 40-50 Mb each…
On the other hand, the clone stamp tool does not crash when you only clone small part of the images (this time it took me 1:40 minutes to crash PhotoFlow with this tool on Windows 10 as well)
Best regards !
[1] https://dl.dropboxusercontent.com/u/3095134/PC_TRUCCHI/BUG_REPORTS/2016_01_25-logs/CRASH_STAMP_CLONE_TOOL_WINDOWS-10-64bit.mp4
[2] https://dl.dropboxusercontent.com/u/3095134/PC_TRUCCHI/BUG_REPORTS/2016_01_25-logs/crash_clone_stamp_tool_window_10.txt
Sure, which version shall I try?
Could you pick the latest (20170124) one from the continuous github release?
Thanks!!!
I confirm the crash. Now I’ll try to get a bt full
That was easy
Thread 1760 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9808.0x1858]
vips_clone_stamp_gen_template<float> (stop=<optimized out>, b=<optimized out>, a=<optimized out>, seq=<optimized out>, oreg=<optimized out>)
at /home/photoflow/Scratch/build-xroad-w32/source/PhotoFlow/Default/PhotoFlow/src/vips/clone_stamp.cc:259
259 /home/photoflow/Scratch/build-xroad-w32/source/PhotoFlow/Default/PhotoFlow/src/vips/clone_stamp.cc: No such file or directory.
(gdb) bt full
#0 vips_clone_stamp_gen_template<float> (stop=<optimized out>, b=<optimized out>, a=<optimized out>, seq=<optimized out>, oreg=<optimized out>)
at /home/photoflow/Scratch/build-xroad-w32/source/PhotoFlow/Default/PhotoFlow/src/vips/clone_stamp.cc:259
ir = <optimized out>
point_area = {left = -358628364, top = 73603, width = 25, height = 25}
point_clip = {left = 165, top = 73603, width = 0, height = 0}
point_clip_right = <optimized out>
r = <optimized out>
row1 = <optimized out>
image_area = {left = 0, top = 0, width = 1844, height = 1231}
groups = <optimized out>
pi = {_M_node = 0xab000000}
pen_size2 = <optimized out>
in_area = {left = 154, top = 938, width = 170, height = 170}
ch = <optimized out>
row2 = <optimized out>
delta_row = <optimized out>
resized_mask = <optimized out>
y0 = 73615
p = <optimized out>
delta_col = <optimized out>
mx = <optimized out>
pen_size = <optimized out>
out_area = {left = 165, top = 833, width = 170, height = 170}
line_size = <optimized out>
par = <optimized out>
prepared = false
opacity_max = {width = 170, height = 170, r_offset = 833, c_offset = 165, size_allocated = 115600, buf = 0x27b97d00, matrix = 0x2a171208, matrix_shifted = 0x2a1707ac}
clone_stamp = <optimized out>
point_clip_bottom = <optimized out>
x = <optimized out>
my1 = <optimized out>
mask = <optimized out>
x0 = -358628352
y = <optimized out>
my2 = <optimized out>
pout = <optimized out>
bgd = {width = 510, height = 170, r_offset = 833, c_offset = 495, size_allocated = 346800, buf = 0x2aa0ef90, matrix = 0x177a4b40, matrix_shifted = 0x177a40e4}
#1 vips_clone_stamp_gen (oreg=<optimized out>, seq=<optimized out>, a=<optimized out>, b=<optimized out>, stop=<optimized out>)
at /home/photoflow/Scratch/build-xroad-w32/source/PhotoFlow/Default/PhotoFlow/src/vips/clone_stamp.cc:372
ir = <optimized out>
result = 0
#2 0x69ce71cf in ?? ()
No symbol table info available.
#3 0x69ce71cf in ?? ()
No symbol table info available.
#4 0x69ce71cf in ?? ()
No symbol table info available.
#5 0x69ce71cf in ?? ()
No symbol table info available.
#6 0x69ce71cf in ?? ()
No symbol table info available.
#7 0x69ce71cf in ?? ()
No symbol table info available.
#8 0x69ce71cf in ?? ()
No symbol table info available.
#9 0x00000001 in ?? ()
No symbol table info available.
#10 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Looks like a candidate
made a second try. This time two negative coordinates
point_area = {left = -4472912, top = -4472912, width = 25, height = 25}
@Carmelo_DrRaw btw: The size of the stamp was 50. Seems your width and height is more like the radius…
@heckflosse thanks for the quick check! While the large negative numbers look like a good candidate for the crash, I think they are actually harmless, because they get initialized just after the location of the crash and before they are actually used… so unfortunately I think the problem is still somewhere else
I have prepared a special version with no multithreading and many more console messages: https://filebin.net/ywj2pu7aanf2dzog
Could you be so kind to try it and see if it crashes as well? If yes, then a copy of the console messages might be more informative than the GDB bt, since the point there the program crashes does not seem to be very relevant (this is the failing line).
Concerning the size of the stamp and the dimensions of the point_area
, the reason for the difference is that the stamp size is scaled down according to the zoom level of the preview, because the cloning is applied to the zoomed-out preview and not the full-res image…
Thanks!!!
EDIT: @Silvio_Grosso could you also try the test version linked above (https://filebin.net/ywj2pu7aanf2dzog)? I am particularly interested in the console messages, as we have seen that the GDB backtrace is unfortunately not very informative… THANKS!!!
Here you go:
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=71170300 y0=71170313
point @ x0=1004 y0=228
point @ x0=249619290 y0=250291475
point @ x0=-268431392 y0=4379
Segmentation fault