On Sat, Oct 25, 2014 at 12:43 PM, johannes hanika wrote:
> good, thanks for checking.
>
> we could replace that blocking raw read by a raw-metadata read, if there was
> support for that in rawspeed (and if that would make any sense because it
> would be any faster at all..).
Not right now and the
hey,
i put all the dubious patches in a local branch here:
55d1c92
0c37ddd
31078c9
6697fa5
4e8b208
4d80fef
6d5b72b
6fcecc7
e68c272
89aae89
157cabb
67c7855
632d76d
f22f041
8611850
22e44ab
d1dd982
3dd24f6
bea8972
8aa6adb
5f46f0a
164ad8c
branching off from before 699: 86f353f98d58c7940a09b432f5c4bd
hi all.
could you two tell me how to reproduce the lens correction/crash issues? i
pretty much reverted everything reload_defaults related already. the only
thing that should be in master (and could stay imho, don't see how it would
cause problems) is the blocking loading of the full buffer via ra
On Thu, Oct 23, 2014 at 9:15 PM, Ulrich Pegelow
wrote:
> My impression: we either shift 1.6 by at least 2 months until everything
> is sorted out, or we urgently need to revert the latest commits to bring
> us back to a working state :(
Yeah, unless hanatos has an idea on how to fix things we sho
Hi,
I did some further checks on older images.
Frankly speaking, I have to say we are in a deep shit.
Just checked an image where some weeks ago I successfully applied
geometric lens correction. Nothing works now, image is heavily
distorted. Can't even get darktable to detect the lens profile.
well, do you have a fix?
On Thu, Oct 23, 2014 at 10:18 AM, jeremy rosen <
jeremy.ro...@enst-bretagne.fr> wrote:
>
> so, do we stay with that approch for 1.6, or do we try to do a proper fix
> before release ?
>
> I don't mind either, a proper fix can wait for 1.7, just wondering what
> the strat
so, do we stay with that approch for 1.6, or do we try to do a proper fix
before release ?
I don't mind either, a proper fix can wait for 1.7, just wondering what the
strategy is...
On Thu, Oct 23, 2014 at 9:53 AM, johannes hanika wrote:
> cool, thanks for checking.
>
> the problem seems to be
cool, thanks for checking.
the problem seems to be pr 699 and afterwoes.. the core problem is a race
condition on dt_image_t data in the pipeline: some more recent and more
complicated raw tricks (some specific to esoteric sensors, some just about
black/white levels) require rawspeed to load some
Hi Jo,
the reported issue seems to be fixed with current master (commit
164ad8cae3b40017e48581c143084fa3759405b7). I only checked the behavior
of the demosaic module. Please tell me if you need further testing from
my side on other modules.
@Roman:
I noticed the problem with c15f26a6c57fbf5583
sorry, i'm too tired to fix this for real tonight. this reload_defaults
calling order seems to have a ton of non-transparent implications..
reverted a few cleanup commits for now. note that this re-introduces some
problem with input colour profiles when switching images via film strip, if
you're sw
seems it might be related to reload_defaults writing to module->params,
too, not only default_params. in this case it'll touch more than just that
one module (denoise profiled seems to be affected, too).
-jo
On Thu, Oct 23, 2014 at 9:37 AM, Roman Lebedev wrote:
> Hi.
>
> What revision is that?
confirmed, scary indeed. other modules i've tried so far seem to work
though? i didn't touch demosaic in quite some time, maybe it's specific to
that one..
-jo
On Thu, Oct 23, 2014 at 9:24 AM, Ulrich Pegelow wrote:
> Hi,
>
> I just observed a problem in the demosaic module. Changes from the
> d
Hi.
What revision is that?
Before c15f26a6c57fbf5583a98f4de4c2b9d500751fb1 (Merge branch '699') ?
If earlier revision, then it might have already been fixed by that commit.
--
_
Hi,
I just observed a problem in the demosaic module. Changes from the
default settings of a demosaic method seems not to get recorded in the
history stack. When I leave darkroom and come back again the demosaic
method is back to its default (VNG for X-Trans and PPG for the rest).
The same is
14 matches
Mail list logo
