@chroma_ghost You’re probably aware of this but It happened frequently with me until I sorted out that I had deleted a layer that was referenced above by a mask. When I cleaned the mask’s reference, it stopped crashing.
Yeah I had that with buffer layers… don’t think is the case here; thanks though.
I’ll have to collect more cases, right now I just want to edit so I’ll leave this for a bit
1 Like
Does it crash when you try to restored the crashed edit, or when loading the original .pfi?
You could try to send me the most recent files in your ~/.photoflow/cache/ folder, so that I can try to have a look into the failing backup file…
Does it crash when you try to restored the crashed edit, or when loading the original .pfi?
Don’t think I follow Andrea. There’s a raw and then when I save the edit there’s a raw.pfi
If by any reason photoflow had to be forced quit / kill; when I try ro reload the raw.pfi with the edit it crashes immediately. This didn’t happen before.
cache folder
cache.zip (2.9 KB)
Th is how it works: each time the processing pipeline is successfully built after a modification of some parameter, the software saves it as a temporary .pfi file in the cache folder, and associates this temporary file with the name of the file being processed. So if you have a crash you should be able to re-load the last non-corrupted editing status.
Now it seems that in your case the backup is corrupted as well, but I do not yet know why. So what I would need from you is to send me the contents of the cache folder after a crash that you know will likely not be recoverable, and you tell me the name of the file you were editing.
Then I can have a look at the corrupted backup file…
Th is how it works: each time the processing pipeline is successfully built after a modification of some parameter, the software saves it as a temporary .pfi file in the cache folder, and associates this temporary file with the name of the file being processed. So if you have a crash you should be able to re-load the last non-corrupted editing status
pfi file was not created after cache was “ready”
contents of the cache folder after a crash that you know will likely not be recoverable, and you tell me the name of the file you were editing.
cache_and_pfi.zip (11.8 KB)
file being edited is _DSC0438.NEF
Just to be clear I forced the crash (after cache was “ready”)
Hi.
I’m still unable to manually select a camera model in the RAW developer layer.
While executing PF, I noticed that the following file shows up:
It contains the similar model that i use to make geometric corrections:
However, even when I uncheck auto matching and/or match camera, nothing happens when I click both Unknown camera and Unknown lens.
I found a line in the log file that I thought might be a clue (there are two backslashes instead of one):
Can this be the reason why the camera/lens dialog doesn’t open?
anyway, here’s the full logfile
log1.txt (41.3 KB)
I don’t know but it seems that there is something broken in lens corrections.
– If I understand you correctly, you cannot open the context menu when you click on the boxes, as I have suggested previously.
– And I have opened many PlayRaws with known camera and lens but all corrections doesn’t do a thing, except for the a little budging of the preview image and it returning to the same state. (I know I am bad at keeping track and reporting; sorry.)
The suspicious line in the log file is for the RawSpeed camera DB, and is harmless (two slashes under Unix are OK, and equivalent to one).
I have just tried the RAW sample file that you send me a while ago, and it works for me. This is what I get when I click on “Unknown camera”:
Is is really strange… you are under Ubuntu 18.04, right? I will try to reproduce on the same system…
Okay, I will give you an example: [PlayRaw] Long exposure of waterflow, to process or not to process. This one does have changes but is just not very noticeable until I flip it back and forth outside of PhotoFlow. I think it has to do with the rocking and redrawing of the preview image that confuses the eye.
– The distortion adjustment for this particular image is also small.
– The vignetting adjustment seems to be non-existent, at least the samplers don’t change.
– This is the most noticeable when I difference the output images, so I will likely use this one only.
PS I mentioned this before. The sampler visible space is very small on my screen. Could you please make it adjustable vertically or provide an option to make it a floating window? It would be great if I could at least see the info of two samplers.
PPS After doing the the PF only PlayRaw entry, I noticed that the export image dialogue settings isn’t saved in the PFI. I am pretty sure it isn’t saved in other raw processors either. So I had to point out that I didn’t use post-resize sharpening because anyone looking at the PFI wouldn’t know. This is just a discussion point. I wonder whether that info should be included.
Also, I don’t remember whether you fixed the path issue. When I share the PFI, the path would inevitably be different on another user’s computer: is there a prompt to ask the user to select the path of the raw?
The problems when deleting a layer that is cloned somewhere in the pipeline should be fixed by this commit. Could you please check if this works for you as well?
Thanks!
I have just tried one on those RAWs. I was able to manually select the right lens by de-selecting “match camera” and “auto matching”, but the changes are quite subtle (I guess this is due to the good quality of the lens itself):
I have modified the code so that the samplers widget is now detachable. If you double-click on the tab widget label (“samplers”) the tab disappears and the samplers are moved into a separate dialog. Closing the dialog brings the samples back into the tab widget…
I am still fighting with the missing “close” buttons for dialogs, I hope to find an explanation soon…
Yes, this is currently the case. I am thinking about the best way to incorporate this information on a per-image basis… currently my idea would be to write the information into the sidecar .pfi files that can be created when exporting an image. Does this make sense?
This works already correctly when exchanging files between windows systems or between Linux/OSX ones, but not yet when going for Win to Linux/OSX or vice-versa. I am also trying to get this fixed…
Do you mean it works if they are in the same folder but different than when saved? I haven’t tested that but I will take your word for it. What I have tried is to move or change the name of the raw file and then try opening the PFI. In this case, it seems that PF ends up constantly searching but not finding. Ideally, there should be an alert that says the raw couldn’t be found and even better present an open dialogue for the user to link the file.
1 Like
+1
Got a few warnings and errors:
- OpenColorIO Error
- (photoflow.exe:3104): VIPS-WARNING **
At the end of the output, PhotoFlow stalls. I either have to close it or wait a long time.
Saving image to file X:\_px\_pr\a.jpg...
OCIOFilmicPar: config=0x16d80300
OCIOFilmicPar: device=sRGB
OCIOFilmicPar: transformName=Filmic Log Encoding Base
OCIOFilmicPar: displayColorSpace=Filmic Log Encoding
OCIOFilmicPar: lookName=Very High Contrast
OCIOFilmicPar: processor=0x16d7ff20
ColorCorrectionPar::build(): 0.5 0 0.5
OCIOFilmicPar: config=0x16d82680
OCIOFilmicPar: device=sRGB
OCIOFilmicPar: transformName=Filmic Log Encoding Base
OCIOFilmicPar: displayColorSpace=Filmic Log Encoding
OCIOFilmicPar: lookName=Very High Contrast
OCIOFilmicPar: processor=0x16d82640
ColorCorrectionPar::build(): 0.5 0 0.5
Image size: 1152,864
Shrink factor: 0.674769
ImageArea::update(): before vips_resize()
ImageArea::update(): after vips_resize(), outimg: 0xa8464b0 outimg2: 0xa846320
OCIOFilmicPar: config=0x16d7c370
OCIOFilmicPar: device=sRGB
OCIOFilmicPar: transformName=Filmic Log Encoding Base
OCIOFilmicPar: displayColorSpace=Filmic Log Encoding
OCIOFilmicPar: lookName=Very High Contrast
OCIOFilmicPar: processor=0x16d7c2c0
ColorCorrectionPar::build(): 0.5 0 0.5
OpenColorIO Error: Error could not read 'X:\photoflow-w64-20190210_2203-git-stable-cc18b4ef5323b01d6710a696831befa82280ed8d\bin\..\share\photoflow\\ocio-configs\filmic-blender-master\config.ocio' OCIO profile.
OCIOFilmicPar: config=0xa895fc0
OCIOFilmicPar: device=sRGB
OCIOFilmicPar: transformName=Filmic Log Encoding Base
OCIOFilmicPar: displayColorSpace=Filmic Log Encoding
OCIOFilmicPar: lookName=Very High Contrast
OCIOFilmicPar: processor=0xa895e10
ColorCorrectionPar::build(): 0.5 0 0.5
Image::do_export_merged(): ext=jpg
output size: 9
width=1920 height=1200
ScalePar::build(): scale=0.347222 kernel=4
SharpenPar::propagate_settings(): usm_radius=0.8
SharpenPar::compute_padding(): method.get_enum_value().first=0
GaussBlurPar::compute_padding(): radius=0.8 level=0 radius2=0.8
GaussBlurPar::build(): radius2=0.8 accuracy=0.01
GaussBlurPar::build(): convsep mask size=5 1
Image::do_export_merged(): profile_type=3 trc=0
Embedded profile found: sRGB-elle-V4.icc
Image::do_export_merged(): Q=100 no_subsample=1
(photoflow.exe:3104): VIPS-WARNING **: 15:23:12.120: ignoring trellis_quant
(photoflow.exe:3104): VIPS-WARNING **: 15:23:12.120: ignoring overshoot_deringing
(photoflow.exe:3104): VIPS-WARNING **: 15:23:12.120: ignoring optimize_scans
(photoflow.exe:3104): VIPS-WARNING **: 15:23:12.136: ignoring quant_table
Jpeg image saved in 43.6272 s
do_export_merged took 46199 ms
Warning: Exif tag Exif.Olympus2.ThumbnailImage not encoded
Warning: Exif tag Exif.OlympusCs.PreviewImageLength not encoded
Warning: Exif tag Exif.OlympusCs.PreviewImageStart not encoded
Warning: Exif tag Exif.OlympusCs.PreviewImageValid not encoded
Warning: Exif tag Exif.Photo.MakerNote not encoded
Warning: Exif tag Exif.OlympusIp.0x0635 not encoded
Warning: Exif tag Exif.OlympusIp.0x0636 not encoded
Warning: Exif tag Exif.OlympusIp.0x1103 not encoded
Warning: Exif tag Exif.OlympusIp.0x1104 not encoded
RawLoaderPar::~RawLoaderPar(): raw_image=0xb75a010
RawLoaderPar::~RawLoaderPar(): raw_image->get_nref()=3
~OpParBase(): deleting operation 0xb5c8c20 (raw_loader)
~OpParBase(): deleting operation 0x136bc400 (uniform)
~OpParBase(): deleting operation 0x212299b0 (blender)
~OpParBase(): deleting operation 0x10e47b70 (raw_developer_v2)
PS Following up with closing floating windows, Esc doesn’t work when dealing with layers in mask mode. Unsure whether it happens all the time, but when it does, only the first floating window in mask mode cannot be closed. Subsequent ones can. Also, when I toggle show mask a few times, it either doesn’t work or it crashes PF. (I have reported this one before.) Unsure whether a floating window needs to be open for that to happen. I don’t know what triggers the two issues, but they happen often.
PPS Actually, masking doesn’t work for me. It only works after PF crashes and later asks me to recover. Then white rectangle turns into a marked (gradient) rectangle.
“Doesn’t work” means that the mask is not applied? Which kind of mask are you trying to create?
Yes, I mean that it isn’t being applied and that there is a lot of crashing going on (from toggling the show mask, layer check boxes or clicking the back button). Sorry that I haven’t share the output before the 6 crashes I experienced today… It isn’t a new problem; I rarely use masking though. Oh, the white rectangle means there is no mask, right? This rectangle only has a gradient fill appearance when PF crashes and I opt to recover.
@afre
I have found and fixed a crash that occurred when deleting a layer, specifically when a tool dialog of one of the mask layer associated to the deleted one was opened.
There are probably other sources of crashes, but that was a clear one…
I have also added a “close” button to the tool dialogs, and fixed the propagation of keyboard events that prevented the Esc button to work properly in the case of the curves dialog. If other dialogs show a similar problem please let me know, I will fix them as well.
I still don’t know why the “x” button does not properly close the tool dialogs on Win, and also why it is not showing when using Wayland, but I’m investigating.
1 Like
One less bug is still an improvement. 
I haven’t downloaded the latest commit yet. I am being more careful about staying within my monthly bandwidth limits.
In the prior commit, this is what the windows look like. Top is PF’s main window. You have minimize, maximize and close. Middle is the module parameters window. Notice that the x is really and permanently faded; means that it is disabled. Mouse over doesn’t light it up either. The next one is an active open window. Active buttons are bright. If you could make the parameters window behave the same way as the open window, that would be great.
PS I downloaded the latest commit. It took a much longer to decompress; might be the way it was packaged or due to Defender (my recent thread Reasons the app isn't running well on Windows). The startup time is much quicker now. 
I like the close button. Unfortunately, it is out of sight, in the bottom right corner.
PPS Might be too soon to try [tools/OCIO transform] initial implementation]. When I create the layer, the preview gets distorted with all sorts of things, depending on what I select; e.g., tiles, dots, etc. Clicking on one of the boxes in the GUI crashes the app. Each time I try again, the distortion is very different in appearance.