Am Dienstag, 31. Januar 2017, 11:52:47 CET schrieb Roman Lebedev:
> On Tue, Jan 31, 2017 at 7:58 AM, Dan Torop wrote:
> > Thank you for the report & the very helpful sample file.
> >
> > I'm mortified, though, that the bug made its way into 2.2.2.
>
> Nah, it's just me continuing
On Tue, Jan 31, 2017 at 7:58 AM, Dan Torop wrote:
> Thank you for the report & the very helpful sample file.
> I'm mortified, though, that the bug made its way into 2.2.2.
Nah, it's just me continuing the tradition of breaking one(?)
stable point release per series. (this was 3rd
Thank you for the report & the very helpful sample file. I'm mortified, though,
that the bug made its way into 2.2.2.
Dan
David Vincent-Jones writes:
> My problem appears to be fixed now ... thanks for the quick work
>
> David
>
> On 01/30/2017 09:31 AM, Ulrich Pegelow
Am Montag, 30. Januar 2017, 19:01:45 CET schrieb PD Dr. Stefan Schmidt:
> Hi
Hi.
> I am just an ordinary user not familiar with the coding details. Version
> 2.2.2 (Ubuntu 16.04) which I installed today closes down or freezes in
> approx. 80% of the cases when I open a picture in darkroom. Also
My problem appears to be fixed now ... thanks for the quick work
David
On 01/30/2017 09:31 AM, Ulrich Pegelow wrote:
Great, this seems to have fixed the issue for me!
Ulrich
Am 30.01.2017 um 09:45 schrieb johannes hanika:
thanks for providing the fix! seems correct to me, since the loop is
ff: Re: [darktable-dev] Re: Unusual stability problem
Great, this seems to have fixed the issue for me!
Ulrich
Am 30.01.2017 um 09:45 schrieb johannes hanika:
> thanks for providing the fix! seems correct to me, since the loop is y
> <= max and y+1 is accessed inside. i pushed this PR t
Great, this seems to have fixed the issue for me!
Ulrich
Am 30.01.2017 um 09:45 schrieb johannes hanika:
thanks for providing the fix! seems correct to me, since the loop is y
<= max and y+1 is accessed inside. i pushed this PR to master. let's
see if it fixes it for everyone.
cheers,
jo
Many apologies. This was carelessness on my part. PR 1431 should fix this.
The bug was in changes I made to the Bayer downscaling code. For certain raw
image dimensions, the downscaling to produce the preview would look at a pixel
past the edge of the image.
Thank you very much for reporting &
A test today: I imported a new folder from today's shoot with my Fuji
(16 Mp.) and was able to fully process all of the files without any
problem. I then closed dt, reopened and moved to an older folder (2012)
where the images were from a Canon (16 Mp.). On this second folder ..
during the
Am Sonntag, 29. Januar 2017, 12:50:55 CET schrieb David Vincent-Jones:
> Is it possible that older sidecar files have compatibility problems with
> gkt3?
Nothing is ever impossible, but I wouldn't know of a way to achieve that.
> David
Tobias
[...]
signature.asc
Description: This is a
Is it possible that older sidecar files have compatibility problems with
gkt3?
David
On 01/29/2017 09:46 AM, David Vincent-Jones wrote:
I am on openSUSE Leap 42.2 with gtk3 3.20.9 and dt
2.3.0+git309.0f2cfb2-1.1 also from Darix's repo. The problem is very
real on my system but seen when
I am on openSUSE Leap 42.2 with gtk3 3.20.9 and dt
2.3.0+git309.0f2cfb2-1.1 also from Darix's repo. The problem is very
real on my system but seen when working on older files and is not seen
on my current images.
David
On 01/29/2017 05:02 AM, Patrick Shanahan wrote:
* Ulrich Pegelow
I checked further and it's obviously not (only) related to my system
upgrade, 'cause if I go back a few commits darktable runs stable.
git bisect helped me to find the offending part:
07dc9664df548c7f775ade36cbdb7875a4aa4c9f is the first bad commit
commit
* Ulrich Pegelow [01-29-17 03:41]:
> I need to investigate a bit further. Different from what I thought before it
> does not seem to be related to specific image dimensions. Several images in
> a recent film roll crash immediately when opening them, many others lead
Hi Ulrich,
> As I have just moved from OpenSUSE 13.2 to Leap 42.1 this might well
> be related to gtk/x as many libraries are now updated.
For the record I'm using GNU/Debian sid and have no crash on my side
using darktable compiled from master (I have used it extensively
yesterday).
My Gtk
On Sun, Jan 29, 2017 at 1:09 AM, Ulrich Pegelow
wrote:
> Same here with current master on specific images with and without OpenCL. I
> have several images from one session, all have the same raw size. One image
> with an uncommon crop crashes whenever I open it in the
Glad it's not just me ... will be patient and wait for future development
David
On 01/28/2017 02:09 PM, Ulrich Pegelow wrote:
Same here with current master on specific images with and without
OpenCL. I have several images from one session, all have the same raw
size. One image with an
Same here with current master on specific images with and without
OpenCL. I have several images from one session, all have the same raw
size. One image with an uncommon crop crashes whenever I open it in the
darkroom.
Ulrich
Am 28.01.2017 um 05:14 schrieb David Vincent-Jones:
Apparently the
Not sure what was going on with either my system or that git version but
eventually I elected to flush my system, install a more recent git plus
a re-import of all my images. I appear to be back to stable again.
David
On 01/27/2017 01:26 PM, David Vincent-Jones wrote:
Not quite sure what
19 matches
Mail list logo