Hi.
How are modules identified? By number, or by name?
* In the database, the `history` table has fields `module` and
`operation`, see SQL stuff below.
Somehow, this naming led me to the assumption that the modules are
identified by number and offer different operations.
* In t
On Thu, Jun 13, 2019, at 12:43, KOVÁCS István wrote:
> On Thu, 13 Jun 2019 at 16:12, Aurélien Pierre
> wrote:
> > [of highlights reconstruction and white balance] until someone is able to
> > tell me what the use case for having them disabled is
>
> One use case is the workaround for the issue d
On Thu, 13 Jun 2019 at 16:12, Aurélien Pierre
wrote:
> [of highlights reconstruction and white balance] until someone is able to
> tell me what the use case for having them disabled is
One use case is the workaround for the issue discussed here:
https://www.mail-archive.com/darktable-dev@lists.d
OK, thanks, that answers that question.
On Thu, Jun 13, 2019 at 12:00 PM William Ferguson
wrote:
> I modify demosiac on a fairly regular basis. I use PPG as the default,
> but on noisy files I use AMAZE. I've created several denoise styles that
> include demosiac changes.
>
> On Thu, Jun 13,
I modify demosiac on a fairly regular basis. I use PPG as the default, but
on noisy files I use AMAZE. I've created several denoise styles that
include demosiac changes.
On Thu, Jun 13, 2019 at 11:55 AM Julian Rickards
wrote:
> Do people modify demosaic, input and output on a regular basis? If
>
> Do people modify demosaic, input and output on a regular basis? If not,
> could the options for each be moved to "Settings" so they aren't listed as
> a module but modifiable when needed?
>
>
___
darktable developer mailin
General means every module should behave the same and avoid the burden
of having to manage them locally and separately, and forget later that
some of them need special care because *there is no dev documentation to
write that on *(that's what happened with the lighttable button).
Now, some modules
Not to throw gas on the fire but it seems to me that some of this is
already done.
In Lighttable, when you wish to copy the history from one image to another,
there are some modules missing (input and output) and also, the "off"
modules aren't included in the possible modules to copy over.
On Thu
Aurélien Pierre (2019-Jun-13, excerpt):
> There is no image if the white balance has been disabled, just random
> bits for debugging purposes. The input color profile expects
> D50-balanced input, and this one is always on. Same with the highlight
> clipping module, most software have it built in t
Just because you don’t agree with some design decisions made previously (I seem
to remember that white balance was always on at some point), doesn’t mean you
should introduce broken code. Correct fix is to add these 2 modules to the
history, as I previously mentioned. Reverting them back to alwa
There is no image if the white balance has been disabled, just random
bits for debugging purposes. The input color profile expects
D50-balanced input, and this one is always on. Same with the highlight
clipping module, most software have it built in the input profile and
don't expose it. Disable th
> On 12 Jun 2019, at 20:21, Aurélien Pierre wrote:
>
> Hi,
>
> I'm the author of the lighttable's compress history button. White balance and
> highlight reconstruction should never be turned off, so what would be
> the purpose of having them disabled in the first place ?
>
Yet they
Hi,
I'm the author of the lighttable's compress history button. White
balance and highlight reconstruction should never be turned off, so what
would be the purpose of having them disabled in the first place ? Then,
we can discuss what the history compression should do/avoid/prevent.
Aurélien.
Le
Edgardo Hoszowski (2019-Jun-12, excerpt):
> > > Edgardo Hoszowski (2019-Jun-11, excerpt):
> > > > I usually want to keep the (off) modules when compressing history,
> > > > so the current behavior should be kept.
> > >
> > > My implementation already takes care about all these exceptional
> > > mod
Edgardo Hoszowski (2019-Jun-12, excerpt):
> > Edgardo Hoszowski (2019-Jun-11, excerpt):
> > > I usually want to keep the (off) modules when compressing history,
> > > so the current behavior should be kept.
> >
> > My implementation already takes care about all these exceptional
> > modules I'm awa
> Patrick Shanahan (2019-Jun-11, excerpt):
> > important is to not *break* already processed images by a change.
>
> Yes, I'm aiming at that. AFAIK, my current implementation would not
> break anything, see below. (The implementation reachable from
> lighttable, which is already in master and was
Patrick Shanahan (2019-Jun-11, excerpt):
> important is to not *break* already processed images by a change.
Yes, I'm aiming at that. AFAIK, my current implementation would not
break anything, see below. (The implementation reachable from
lighttable, which is already in master and was not built
Julian Rickards (2019-Jun-11, excerpt):
> I must say that I've never used the Compress History option in the
> Lighttable, just in the Darkroom. Are there any differences?
[see my reply to thokster]
--
http://stefan-klinger.deo/X
I prefer receiving plain te
thokster (2019-Jun-11, excerpt):
> Hi,
>
> Am 11.06.19 um 15:32 schrieb dt-l...@stefan-klinger.de:
>
> > This option is not about saving disk space, but rather about cleaning
> > up.
>
> Is the "compress history" button in lighttable view doing anything else?
Woha. I have been talking about "comp
On Tue, Jun 11, 2019, at 15:34, Patrick Shanahan wrote:
> I doubt I would ever use "compress history" nor remove dup mod's.
Ok, more specifically, is there anyone who *is* interested in this feature, who
also would prefer that it be implemented as an operation distinct from the
current "compres
* thokster [06-11-19 18:25]:
> Am 11.06.19 um 21:26 schrieb Patrick Shanahan:
> > * Julian Rickards [06-11-19 14:54]:
> > > I must say that I've never used the Compress History option in the
> > > Lighttable, just in the Darkroom. Are there any differences?
> > >
> > > On Tue, Jun 11, 2019 at 1:
I often 'wander' back and forth in my modules and in the process create
many duplicates and 'off' conditions. I generally try to clean-up my
history which is a nuisance. I for one would like/use a cleaning option.
David
On 2019-06-11 3:24 p.m., thokster wrote:
Am 11.06.19 um 21:26 schrieb Pat
Am 11.06.19 um 21:26 schrieb Patrick Shanahan:
* Julian Rickards [06-11-19 14:54]:
I must say that I've never used the Compress History option in the
Lighttable, just in the Darkroom. Are there any differences?
On Tue, Jun 11, 2019 at 1:01 PM jys wrote:
On Tue, Jun 11, 2019, at 07:47, thoks
* Julian Rickards [06-11-19 14:54]:
> I must say that I've never used the Compress History option in the
> Lighttable, just in the Darkroom. Are there any differences?
>
> On Tue, Jun 11, 2019 at 1:01 PM jys wrote:
>
> > On Tue, Jun 11, 2019, at 07:47, thokster wrote:
> >
> > > Is the "compress
I must say that I've never used the Compress History option in the
Lighttable, just in the Darkroom. Are there any differences?
On Tue, Jun 11, 2019 at 1:01 PM jys wrote:
> On Tue, Jun 11, 2019, at 07:47, thokster wrote:
>
> > Is the "compress history" button in lighttable view doing anything el
I can see myself using such an option from time to time, but I usually want
to keep the (off) modules when compressing history, so the current behavior
should be kept.
As already said somewhere here, some (off) modules can't be removed from
history, or it will change the edit. In particular, modul
* jys [06-11-19 13:02]:
> On Tue, Jun 11, 2019, at 07:47, thokster wrote:
>
> > Is the "compress history" button in lighttable view doing anything else?
> > If you use this button you can clean up all selected pictures with one
> > click (incurrent master).
> > I probably totally misunderstood w
On Tue, Jun 11, 2019, at 07:47, thokster wrote:
> Is the "compress history" button in lighttable view doing anything else?
> If you use this button you can clean up all selected pictures with one
> click (incurrent master).
> I probably totally misunderstood what you were up to.
The current impl
Hi,
Am 11.06.19 um 15:32 schrieb dt-l...@stefan-klinger.de:
This option is not about saving disk space, but rather about cleaning
up.
Is the "compress history" button in lighttable view doing anything else?
If you use this button you can clean up all selected pictures with one
click (incurr
Pascal Obry (2019-Jun-10, excerpt):
> Le lundi 10 juin 2019 à 15:05 +0200, dt-l...@stefan-klinger.de a
> écrit :
> >* Maybe "remove unused moduls" and "compress history stack"
> > should be entirely separate operations?
>
> Yes for sure.
Being a good or bad idea in general is a d
On Mon, Jun 10, 2019, at 09:11, dt-l...@stefan-klinger.de wrote:
> I've implemented exceptions for modules 2 (orientation and highlight
> reconstruction) and 3 (white balance), added a checkbox, and added the
> default setting to `darktableconfig.xml.in`.
Rather than a checkbox, I think it woul
Le lundi 10 juin 2019 à 15:05 +0200, dt-l...@stefan-klinger.de a
écrit :
>* Maybe "remove unused moduls" and "compress history stack"
> should be entirely separate operations?
Yes for sure. Remove off module will bring nothing and you lose the
actual setting in this module. So gen
para...@paraf.in (2019-Jun-10, excerpt):
> Another approach is to add exceptions for specific iops, but that’s
> ugly IMHO.
I've implemented exceptions for modules 2 (orientation and highlight
reconstruction) and 3 (white balance), added a checkbox, and added the
default setting to `darktableconfi
I'm not a programmer of any sort so take what I say with a grain of salt.
When I compress the history, I like it to be clean so sometimes, there
is/are module(s) with "(off)" in the compressed history. So what do I do? I
enable them, then turn them off again so that they appear at the top of the
l
para...@paraf.in (2019-Jun-10, excerpt):
> I think we still have default-on modules not recorded in history
> stack (highlight reconstruction and white balance), so removing all
> “off” steps might modify the image.
Hmmm. So if I understand you correctly, the problem is that removing
all unused m
I think we still have default-on modules not recorded in history stack
(highlight reconstruction and white balance), so removing all “off” steps might
modify the image. Therefore I’m afraid your implementation is incorrect. Best
approach would be to record all applied iops to history, but it’s a
Don't have much experience with styles so that point eluded me.
Then it makes sense to have a checkbox to in/exclude the "off" modules.
On Mon, Jun 10, 2019 at 9:21 AM wrote:
> Julian Rickards (2019-Jun-10, excerpt):
> > I have always wondered why "off" modules were included in the compressed
>
Julian Rickards (2019-Jun-10, excerpt):
> I have always wondered why "off" modules were included in the compressed
> history stack so I'm in favour of having them removed. When you compress
> the history stack, you lose the details of the history that took you to the
> final stage so losing the "of
I have always wondered why "off" modules were included in the compressed
history stack so I'm in favour of having them removed. When you compress
the history stack, you lose the details of the history that took you to the
final stage so losing the "off" modules should be a no-brainer.
On Mon, Jun
Hi,
I've drafted [1] an implementation to make "compress history stack" to
also remove all unused modules, i.e., the ones switched off. But
there are some questions:
1. This was so easy to do, maybe it's a bad idea to do this at all?
2. I have derived the SQL from looking at other statement
40 matches
Mail list logo
