Ah, just catching up. See RYB is merged!
On Tue, Sep 7, 2021, at 10:52 AM, Dan Torop wrote:
> Hi All,
>
> That sounds good. I'll look forward to seeing Aurélien's work.
>
> It's so exciting to see all these changes/developments to the "scopes".
> (T
Hi All,
That sounds good. I'll look forward to seeing Aurélien's work.
It's so exciting to see all these changes/developments to the "scopes". (Though
it looks like RYB may need a bit more rebasing, more work for Philippe...)
At some point, if it doesn't make it into some other changes, I'd lik
Interesting query! In the case of the manual, this would be a subset of the
fourth definition:
4: electronic equipment that provides visual images of varying
electrical quantities [syn: {oscilloscope}, {scope},
{cathode-ray oscilloscope}, {CRO}]
The use of this equipment
I'm interested as well in ways for Filmic 4 to be as responsive as possible for
interactive use. I believe that it's actually quite fast in its core work
(parametrically creating and applying a tone curve to the image), even without
OpenCL. But highlight reconstruction can bog things down, and e
Hi Mario,
Thank you! You should also, certainly, chat with the darktable
developers (IRC?) before going too far. They've been clear in the
past that they don't want someone putting in lots of work on a
feature if they don't think it'll make it in, or make it in in the
initial form. I'd be curious
Hi Mario,
The patch looks sympathetic with the spirit of the darktable code, and you've
clearly gotten deep into the code. A query, from reading it through (I haven't
run it), is about sort order depending upon the setting of "collect images" as
a string:
- What if the user filters the images
Ulrich Pegelow writes:
>>> Please consider that changes in that place also will require changes to
>>> the equivalent OpenCL code which might be anything but trivial.
>>
>> Oh no! I was thinking of the dt_iop_clip_and_zoom_demosaic_{half,third}_*()
>> functions in imageop_math.c. Those don't h
Ulrich Pegelow writes:
> Am 21.06.2017 um 18:03 schrieb Dan Torop:
>>>
>>> I'd say that is well withing the time frame – provided it's not too
>>> invasive.
>>>
>>
>> That is great. Should be a tweak to the Bayer downscale code (ma
Germano Massullo writes:
> Il 21/06/2017 17:43, Tobias Ellinghaus ha scritto
>>> I've also been working on Wayland support
>>> (https://redmine.darktable.org/issues/11535). This is mostly done, but
>>> isn't worth enabling until GTK+ >= 3.22.16 makes its way into
>>> distributions. Wayland suppor
Tobias Ellinghaus writes:
> Am Mittwoch, 21. Juni 2017, 11:39:30 CEST schrieb Dan Torop:
[...]
>> I will be able to get to this again in early July. Is that soon enough to
>> make its way into 2.4.0? Additional improvement would be slightly better
>> quality zoomed-in
Hi Tobias,
I've been working on downscaling mosaiced images without (or with fewer)
artifacts (https://redmine.darktable.org/issues/11167). Right now there's
workable code for Bayer and X-Trans in git master. The main flaw is that
highlights have magenta edges.
It would be great if before 2.4.
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
Trans version as well,
but I'm waiting for a moment for concentration on this...
Dan
Dan Torop writes:
> 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 dimen
to find the offending part:
>
> 07dc9664df548c7f775ade36cbdb7875a4aa4c9f is the first bad commit
> commit 07dc9664df548c7f775ade36cbdb7875a4aa4c9f
> Author: Dan Torop
> Date: Mon Jan 23 21:27:48 2017 -0500
>
> imageop_math: take advantage of CFA pattern on downscale
>
> This incre
gt;
> Am 25.07.2016 um 16:36 schrieb Dan Torop:
> > PR #1230 is a pass at usermanual updates regarding X-Trans. There
> > actually isn't too much that is usermanual-visible. Most of the changes
> > have been bugf
on already processed images, as it works so much
> better now.
>
> Thanks !
>
> On 23/07/2016 02:20, Dan Torop wrote:
> > There should be a fix for this as PR 1225
> > (https://github.com/darktable-org/darktable/pull/1225). The column # was
> > off by one from the c
PR #1230 is a pass at usermanual updates regarding X-Trans. There
actually isn't too much that is usermanual-visible. Most of the changes
have been bugfixes, optimizations, and general fixing up of existing
code.
On Sat, Jul 23, 2016, at 04:52 AM, Ulrich Pegelow wrote:
> Dear all,
>
> I'd like t
se is interested :)
>
> On 21/07/2016 16:51, Dan Torop wrote:
> > Hi Marc,
> >
> > I just tried to download the example RAF you posted, but it seems to be
> > expired already? If you're able to send me another link, I'd be curious to
> > look -- tho
rawprepare gets initialized to the
non-shifted CFA and never catches the shift done in rawprepare? Could there be
a race condition with pipe/iop initializations which could cause this?
This definitely is in a083e4c and successive commits including 5590478.
Roman Lebedev writes:
> On Wed, May 18, 2
>From here a bisect suggests
>https://github.com/darktable-org/darktable/commit/a083e4c0f9ffc0423613f3a75e5e3457aa11430c
> as the troublemaking commit.
Fiddling with color balance seems a good way to cause this. I've also seen it
when fiddling with white balance. The preview in the navigation pa
Hi Ingo,
Likewise, also interested in the improvements. I've been mulling if
there is a quick-and-dirty way to test your code in comparison to
darktable's current demosaic iop. Would it make sense to have a version
which just takes a PPM-ish file of incoming pixel data and outputs the
result in si
ommercial raw converters have quite
> > some difficulties with these x-trans files…
> > Some commercial products try to hide these problems by quite a degree of
> > softening, but they’re still there.
> > You also might want to consider that even Bayer CFAs cause quite
and some more minor tweaking I’m now at 7.6 seconds with my
> not too spectacular laptop hardware.
>
> I also tried DCI for red and blue reconstruction once the green is there, but
> it didn’t look good at all. More false colour artifacts.
>
> Cheers,
> Ingo
>
&g
Hi Ingo,
This is quite interesting work to see... A x-trans demosaic algorithm
which is well described, high quality, open source, and fast is
something which I'm sure many people are awaiting. Though of course
having all of these qualities is a lot to ask! It's great to see
continued work on this
Definitely this doesn't touch the HDR module. Calculating an HDR image
from x-trans data may even work with the existing Bayer math. The
challenge then being to write the results in some form which darktable
can turn around and read. Perhaps this would mean teaching dt to write
DNGs with the x-tran
25 matches
Mail list logo
