On Tue, Jan 31, 2017 at 12:23 PM, Tobias Ellinghaus wrote:
> 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
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 the tradition o
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 time in three se
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 wrote:
>
> Great, this
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
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
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
On Mon, Jan 30, 2017 at 5:38 PM, Dan Torop wrote:
> I should also mention that the Bayer downscale code for th
I should also mention that the Bayer downscale code for the previews is, as it
stands, something of a stopgap. It produces fewer edge artifacts (confetti)
than the prior code, but still isn't ideal. There does seem to be a way to make
it better, and that work could translate back to the X-Trans
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 dark
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 digitall
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 wo
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 [01-29
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 07dc9664df548c7f775ade36cbdb7875a4aa4c9
* 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 to
> a crash when switching ima
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 ver
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 to a crash when switching images in the darkroom.
As I have just mov
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 darkroom.
Looks like the cras
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 uncommo
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
20 matches
Mail list logo
