Sorry, I’m still not sure about that. I don’t know what release is that.
The version from your screenshot doesn’t show among the latest commits (see my previous screenshot, the one from the commits page. As I understand, those are master’s latest versions)
EDIT: my line of thought is: before concluding for a bug, we must be sure that we’re running the latest version. Talking about a bug from older versions doesn’t make sense because it could have been fixed on later versions.
you are making me furious!!! the verson is not the problem. I have tried it today with the latest version, too
1 Like
well, it is a bit strange. Apparently I cannot always reproduce this
edit: I can. It just does not work if I crop the margin away.
yes, on that one you posted in the first thread.
which system are you using?
@betazoid: you are also making me furious then 
"So, as you can see, darktable 2.7 produced a strange light margin on the right edge. "
And many people can’t reproduce. So that’s certainly a configuration issue, computer, graphic card, opencl or not, driver, full history of changes (modules used)… But as in many case people create report as if there was an universal issue!!! How many people will use dt if exporting was producing a “right margin” on all images when denoising was used?
So, we do our best to understand and fix issues, but we also do expect people reporting issue to give a proper context. We cannot guess or read in crystal balls. Thanks.
I do not want to make anybody furious but… I have the feeling that I am not taken seriously. Unfortunately I only have 1 computer so I cannot test on other systems.
I am not a computer scientist/programmer but I am doing my best to help.
Well…
Anyone will be able to judge:
Thank you for that. We all need to be patient. Bugs are hard to reproduce, and while its frustrating to have encountered one, the perseverance to accurately report and then resolve it will benefit us all.
thanks!
I think I have provided all info I can provide.
No you have not, please reread my comments, especially:
I could reproduce the issue again, this time following the “clean” steps suggested by @Pascal_Obry.
Details on my github comment.
Maybe this is nonsense, but may this have to do with spurious leftovers from earlier installs? Did one of those able to reproduce try with a fresh checkout of master, submodules updated, fresh, unused install location and empty directory for database and config?
I removed the ~/.config/darktable working folder.
As for leftovers, is it possible to happen if I update via obs packages, not manual build?
Well the only workaround I know is exporting to something but original size.
- I first of all duplicated my image having the same strange behaviour,
- have discarded the history stack using lighttable
- newly edited the photo
- → et voilá - DONE.
Please see before (damaged) and after (fine)
I think this is specific to individual photos and its histoy stack (had to this for some but not all of previously editied photos …)
I don’t think this is the same.
But how did you duplicate the photo?
We have already tried that to no success. Thanks anyway.
Either in lightable/selected images/duplicate
or in darkroom/duplicate manager
As I understand it, you’re not duplicating the raw file, just the xmp sidecar file, so you can profit from different editing versions of the same raw file. In duplicate manager, you can even name each one of the copies, if you want.
I have this bug on the latest 3.0rc0.
Windows10
Ricoh GRIII
load the raw dng
to reproduce the border
turn on denoise profiled
change to wavelets auto
change the strength to 0.02
export and you will see the border
If you reset the denoise profiled settings the file will export ok.
Hope that narrows it down for you.
The bug was fixed yesterday
3 Likes