Re: [darktable-dev] TIFF compression level

[Pascal Obry]

Hi  Diederik,

There was a missing reset=1 / reset=0 pair around the gui_init() call
to the format plug-ins. Your message put me on the track.

This is now fixed.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] TIFF compression level

[Timur Irikovich Davletshin]

Hi Diederik!

Well, this is what I see every start. System: Debian 10, I tried
starting with empty profile. Will you remove that single line of code?

Thanks for quick reply,

Timur.

On Mon, 2019-11-18 at 21:23 +, Diederik ter Rahe wrote:
> Hi Timur, Pascal,
> 
> I used to see this when I was working on the patch. At the time,
> there was an issue caused by some module->gui_init routines
> resetting darktable.gui->reset to 0 on exit, rather than resetting it
> to the value it had on entrance. Which would lead the next gui_init
> routine to be called with reset=0 and this would then start showing
> toasts.
> See here 
> https://github.com/darktable-org/darktable/pull/2788#issuecomment-513164959
> 
> I thought I had cleaned all of these cases up, so there wasn't
> anything left to fix at start time and I don't see any spurious
> toasts myself (Windows rc1 build). Do you see it in latest master?
> There may have been a regression regarding this in any of the modules
> called before "TIFF module->gui_init". TIFF is just the last one in
> the loop, I believe, which is why that's the toast that remains on
> the screen. Unfortunately I haven't got a build environment set up at
> the moment so can't quickly check...
> 
> Best,
> Diederik
> 
> 
> On Monday, 18 November 2019, 18:38:18 GMT, Pascal Obry <
> pas...@obry.net> wrote:
> 
> 
> Hi Timur,
> 
> > What is the point of giving user notification on dt start about
> TIFF
> > compression level? 
> 
> No point. That's a side effect of the toast being displayed when
> changing module sliders from a key without opening the module.
> 
> Some of this has already been fixed by Diederik (in CC).
> 
> There is more to fix at start time.
> 
> I don't have time to look at this. Diederik, do you think you can
> have
> a look?
> 
> Thanks,
> 
> -- 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
>   The best way to travel is by means of imagination
> 
>   http://www.obry.net
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
> 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] Re: lowpass bilateral filter → banding artifacts

[Timur Irikovich Davletshin]

https://github.com/darktable-org/darktable/issues/3435 — this issue can
be closed, was fixed by 
https://github.com/darktable-org/darktable/commit/d4156db4a3ebc8df7f872eb04bcef6530a2f4f70

Thanks a lot!

Timur.

On Sat, 2019-11-16 at 17:33 +0300, Timur Irikovich Davletshin wrote:
> Christian, thanks!
> 
> Timur.
> 
> On Sat, 2019-11-16 at 14:38 +0100, Christian wrote:
> > Timur,
> > I've opened a ticket for this issue:
> > 
> > https://github.com/darktable-org/darktable/issues/3435
> > 
> > christian
> > 
> > Am 16.11.2019 um 08:31 schrieb Timur Irikovich Davletshin:
> > > So I played around with different pictures and modules and these
> > > are
> > > some results:
> > > 
> > > 1. no link with memory tiling settings
> > > 2. no link with sensor type or demosaic settings (visible on
> > > pictures
> > > with monochrome sensors)
> > > 3. visible on all pictures with big blocks of dark and bright
> > > small
> > > objects
> > > 3. distance between artifact lines is linked with radius setting
> > > of
> > > bilateral filter.
> > > 4. visible in exported pictures
> > > 5. shadows and highlights with bilateral filter has similar
> > > bug...
> > >   a) it is not visible in exported pictures
> > >   b) it is not visible in low zoom factors
> > >   c) visible on screen in zoom factors 50-100%
> > > 
> > > This last one may give some clues.
> > 
> > ___
> > __
> > __
> > darktable developer mailing list
> > to unsubscribe send a mail to 
> > darktable-dev+unsubscr...@lists.darktable.org
> > 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Pascal Obry]

Le lundi 18 novembre 2019 à 20:13 +0100, Aurélien Pierre a écrit :
> Don't, it's fine.
> 
> But serious bug reports like crashes, regressions, Mac/Win/Nux and
> CPU/GPU inconsistencies do pile up faster than fixes, so all the
> cosmetic talk about the proper way to write grey is kind of
> hilarious. I wonder sometimes if users realize we are just a handful
> working on a day-to-day basis on darktable, and we are already
> swamped.

I fully agree, we need more man power than report at this time! I have
been a bit rude those days about reports without any thinking before or
trying to present the bug as simple as possible. We really don't have
time to try to understand the problem, it should be obvious from the
report.

So please, yes do try to at least create the shortest reproducer for
the issue.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Aurélien Pierre]

Don't, it's fine.

But serious bug reports like crashes, regressions, Mac/Win/Nux and
CPU/GPU inconsistencies do pile up faster than fixes, so all the
cosmetic talk about the proper way to write grey is kind of hilarious. I
wonder sometimes if users realize we are just a handful working on a
day-to-day basis on darktable, and we are already swamped.

Le 18/11/2019 à 17:55, Julian Rickards a écrit :
> My apologies
>
> On Mon, Nov 18, 2019 at 10:58 AM Aurélien Pierre
> mailto:rese...@aurelienpierre.com>> wrote:
>
> Forget about segfaults and crashes, our first priority is now to
> make every native English speaker feel respected in his difference
> and identity, offering fully differentiated support of every
> English dialect : en_GB, en_AU, en_US, en_ZA, en_CA, en_NZ, en_FJ…
>
> Meanwhile, people speaking languages for which darktable is
> partially or even not translated can die screaming, we are too
> busy fixing gr(e|a)ys. Come back later (or preferably never).
>
> Next top-priority project : translating dt in signs language. The
> chief-translator position is open, send your resumes now.
>
> Obligatory mention :
>
> "We are a dynamic team of motivated people trying to change the
> world one step at a time. Join us to expand your horizons in an
> exciting opportunity to face new challenges and give a new start
> to your carreer."
>
>  Le 18/11/2019 à 16:30, Richard Hobday a écrit :
>> -- Tongue firmly in cheek --
>> en-GB or en-US ?
>> That is the real question.
>> They are two very different languages, at present darktable seems to
>> assume they are the same!
>>
>> R.
>>
>> On 18/11/2019 14:36, Julian Rickards wrote:
>>> grAy is the American spelling and there's nothing wrong with that
>>> (despite being a Canadian and using British spelling, LoL) but
>>> Timur is
>>> correct, there should be consistency and, in addition to
>>> sticking to the
>>> same spelling of gray/grey, I think that that the English
>>> version of the
>>> documentation (and GUI) should be either all British or all
>>> American
>>> English spelling, not just American for some and British for
>>> others.
>>>
>>> On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin
>>> mailto:timur.davlets...@gmail.com>
>>> 
>>> > wrote:
>>>
>>>     Actually I agree. Darktable lacks of terminology unification
>>> across
>>>     modules. E.g. AFAIR there are around 6 different names for
>>> 18% gray. In
>>>     some places it is "grey" but in others it is "gray".
>>>
>>>     Timur.
>>>
>>>     On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
>>>  > On 15.11.19 12:02, parafin wrote:
>>>  > > I think these numbers don't have units, so why do
>>> expect them to
>>>  > > mean
>>>  > > the same thing in different modules, even if we ignore
>>> the pipe
>>>  > > order?
>>>  >
>>>  > Because that's the most basic requirement of usability.
>>> That things
>>>  > named the same way act the same way and mean the same
>>> thing across a
>>>  > single app – at the very least.
>>>  >
>>>  > > It's not promised anywhere in the documentation as far
>>> as I can
>>>  > > see.
>>>  >
>>>  > 
>>>  > I went through the Photoshop & Lightroom docs and I can't
>>> find any
>>>  > promise in the entirety of them that slider ranges of
>>> things sharing
>>>  > a
>>>  > name will match in range & effect.
>>>  > Yet they do.
>>>  > Go figure ...
>>>  > 
>>>  >
>>>  > Beers,
>>>  >
>>>  > .mm
>>>  >
>>> _
>>>
>>>  > __
>>>  > darktable developer mailing list
>>>  > to unsubscribe send a mail to
>>>  > darktable-dev+unsubscr...@lists.darktable.org
>>> 
>>>     
>>> 
>>>  >
>>>
>>>    
>>> 
>>> ___
>>>     darktable developer mailing list
>>>     to unsubscribe send a mail to
>>>     darktable-dev+unsubscr...@lists.darktable.org
>>> 
>>>     
>>> 
>>>
>>>
>>> 
>>> ___
>>>
>>> darktable developer mailing list to unsubscribe send a mail to
>>> 

Re: [darktable-dev] TIFF compression level

[Pascal Obry]

Hi Timur,

> What is the point of giving user notification on dt start about TIFF
> compression level? 

No point. That's a side effect of the toast being displayed when
changing module sliders from a key without opening the module.

Some of this has already been fixed by Diederik (in CC).

There is more to fix at start time.

I don't have time to look at this. Diederik, do you think you can have
a look?

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Julian Rickards]

My apologies

On Mon, Nov 18, 2019 at 10:58 AM Aurélien Pierre 
wrote:

> Forget about segfaults and crashes, our first priority is now to make
> every native English speaker feel respected in his difference and identity,
> offering fully differentiated support of every English dialect : en_GB,
> en_AU, en_US, en_ZA, en_CA, en_NZ, en_FJ…
>
> Meanwhile, people speaking languages for which darktable is partially or
> even not translated can die screaming, we are too busy fixing gr(e|a)ys.
> Come back later (or preferably never).
>
> Next top-priority project : translating dt in signs language. The
> chief-translator position is open, send your resumes now.
>
> Obligatory mention :
>
> "We are a dynamic team of motivated people trying to change the world one
> step at a time. Join us to expand your horizons in an exciting opportunity
> to face new challenges and give a new start to your carreer."
>  Le 18/11/2019 à 16:30, Richard Hobday a écrit :
>
> -- Tongue firmly in cheek --
> en-GB or en-US ?
> That is the real question.
> They are two very different languages, at present darktable seems to
> assume they are the same!
>
> R.
>
> On 18/11/2019 14:36, Julian Rickards wrote:
>
> grAy is the American spelling and there's nothing wrong with that
> (despite being a Canadian and using British spelling, LoL) but Timur is
> correct, there should be consistency and, in addition to sticking to the
> same spelling of gray/grey, I think that that the English version of the
> documentation (and GUI) should be either all British or all American
> English spelling, not just American for some and British for others.
>
> On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin
> mailto:timur.davlets...@gmail.com>
> > wrote:
>
> Actually I agree. Darktable lacks of terminology unification across
> modules. E.g. AFAIR there are around 6 different names for 18% gray.
> In
> some places it is "grey" but in others it is "gray".
>
> Timur.
>
> On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
>  > On 15.11.19 12:02, parafin wrote:
>  > > I think these numbers don't have units, so why do expect them to
>  > > mean
>  > > the same thing in different modules, even if we ignore the pipe
>  > > order?
>  >
>  > Because that's the most basic requirement of usability. That things
>  > named the same way act the same way and mean the same thing across
> a
>  > single app – at the very least.
>  >
>  > > It's not promised anywhere in the documentation as far as I can
>  > > see.
>  >
>  > 
>  > I went through the Photoshop & Lightroom docs and I can't find any
>  > promise in the entirety of them that slider ranges of things
> sharing
>  > a
>  > name will match in range & effect.
>  > Yet they do.
>  > Go figure ...
>  > 
>  >
>  > Beers,
>  >
>  > .mm
>  >
> _
>  > __
>  > darktable developer mailing list
>  > to unsubscribe send a mail to
>  > darktable-dev+unsubscr...@lists.darktable.org
> 
> 
>  >
>
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
> 
> 
>
>
> ___
>
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>
> --
> http://lukecarville.jalbum.net
> https://facebook.com/rlc.hobday
> ___
>
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>
> ___
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

[darktable-dev] A simple but good advice

[meili]

Hi there!

A simple proposal from photographers point of view:

There is a tip tool when editing BASE CURVE points with a mouse, which 
says; abcissa: input, ordinate: output etc
THAT is useless! Instead SHOW x and y VALUES, when moving a point with a 
mouse! That would be very useful, for us photographers! Some profiling 
softweare include curve points in the profile, where they can be 
extracted like you can see below: (colon is a decimal character here). 
Making a base curve from those values is impossible with Darktable. IF x 
and y values are not shown WHEN EDITIN A BASE CURVE! Another method 
would be a way to import base curve points from a text file.


Also my opinion is, that instead of gray grey wars and programming 
issues please concentrate to the basic photographer's needs, for example 
DCP-profiles should be accepted too. :)


Anyway, thank you for the promising RAW editor!

0,00 0,00
0,031373 0,031373
0,058824 0,070588
0,137255 0,211765
0,239216 0,368627
0,33 0,501961
0,439216 0,611765
0,556863 0,729412
0,619608 0,792157
0,752941 0,886275
0,870588 0,960784
1,00 1,00

Oiva Hakala, Finland

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Aurélien Pierre]

Forget about segfaults and crashes, our first priority is now to make
every native English speaker feel respected in his difference and
identity, offering fully differentiated support of every English dialect
: en_GB, en_AU, en_US, en_ZA, en_CA, en_NZ, en_FJ…

Meanwhile, people speaking languages for which darktable is partially or
even not translated can die screaming, we are too busy fixing gr(e|a)ys.
Come back later (or preferably never).

Next top-priority project : translating dt in signs language. The
chief-translator position is open, send your resumes now.

Obligatory mention :

"We are a dynamic team of motivated people trying to change the world
one step at a time. Join us to expand your horizons in an exciting
opportunity to face new challenges and give a new start to your carreer."

 Le 18/11/2019 à 16:30, Richard Hobday a écrit :
> -- Tongue firmly in cheek --
> en-GB or en-US ?
> That is the real question.
> They are two very different languages, at present darktable seems to
> assume they are the same!
>
> R.
>
> On 18/11/2019 14:36, Julian Rickards wrote:
>> grAy is the American spelling and there's nothing wrong with that
>> (despite being a Canadian and using British spelling, LoL) but Timur is
>> correct, there should be consistency and, in addition to sticking to the
>> same spelling of gray/grey, I think that that the English version of the
>> documentation (and GUI) should be either all British or all American
>> English spelling, not just American for some and British for others.
>>
>> On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin
>> mailto:timur.davlets...@gmail.com>> wrote:
>>
>>     Actually I agree. Darktable lacks of terminology unification across
>>     modules. E.g. AFAIR there are around 6 different names for 18%
>> gray. In
>>     some places it is "grey" but in others it is "gray".
>>
>>     Timur.
>>
>>     On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
>>  > On 15.11.19 12:02, parafin wrote:
>>  > > I think these numbers don't have units, so why do expect
>> them to
>>  > > mean
>>  > > the same thing in different modules, even if we ignore the pipe
>>  > > order?
>>  >
>>  > Because that's the most basic requirement of usability. That
>> things
>>  > named the same way act the same way and mean the same thing
>> across a
>>  > single app – at the very least.
>>  >
>>  > > It's not promised anywhere in the documentation as far as I can
>>  > > see.
>>  >
>>  > 
>>  > I went through the Photoshop & Lightroom docs and I can't find
>> any
>>  > promise in the entirety of them that slider ranges of things
>> sharing
>>  > a
>>  > name will match in range & effect.
>>  > Yet they do.
>>  > Go figure ...
>>  > 
>>  >
>>  > Beers,
>>  >
>>  > .mm
>>  >
>> _
>>  > __
>>  > darktable developer mailing list
>>  > to unsubscribe send a mail to
>>  > darktable-dev+unsubscr...@lists.darktable.org
>>     
>>  >
>>
>>    
>> ___
>>     darktable developer mailing list
>>     to unsubscribe send a mail to
>>     darktable-dev+unsubscr...@lists.darktable.org
>>     
>>
>>
>> ___
>>
>> darktable developer mailing list to unsubscribe send a mail to
>> darktable-dev+unsubscr...@lists.darktable.org
>
> -- 
> http://lukecarville.jalbum.net
> https://facebook.com/rlc.hobday
> ___
>
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] import folder → file count

[Timur Irikovich Davletshin]

No, dt will say that you're importing 400 files, but in fact 200 will
be imported.

Timur.

On Mon, 2019-11-18 at 10:36 -0500, Julian Rickards wrote:
> Perhaps: 200 RAW (200 JPG, ignored)
> 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] import folder → file count

[Julian Rickards]

Perhaps: 200 RAW (200 JPG, ignored)


On Mon, Nov 18, 2019 at 9:41 AM Timur Irikovich Davletshin <
timur.davlets...@gmail.com> wrote:

> Well, I agree it's not a big deal. But if one shoots (just as example)
> raw+jpeg and then tries to import only raw files... — he will get
> message of importing, let's say, not 200 raw files but 400. At least
> once I was a bit confused — did I forget to click "ignore JPEGs"? So I
> canceled import. But it turned out that I was correct. It was dt
> reporting wrong number of raw files.
>
> Timur.
>
> On Mon, 2019-11-18 at 15:33 +0100, Christian wrote:
> > Timur,
> >
> > I tested this and can't see an issue.
> >
> > DT is showing "Importing .. images" during Import and afterwards this
> > message disappears, so depending on the number of files it's hardly
> > to notice at all.
> >
> > So, first DT is importing the images and afterwards the duplicate
> > filter is applied.
> >
> > christian
> >
> >
> >
> > Am 18.11.2019 um 10:59 schrieb Timur Irikovich Davletshin:
> > > Another small issue I noticed. This time in folder import.
> > >
> > > Steps to reproduce:
> > >
> > > 1. Create folder with, let's say, DSC_.RAW and DSC_.JPG
> > > 2. Choose import → folder... and select ignore JPG files in import
> > > settings, press import button.
> > >
> > > Problem:
> > >
> > > Import status in left bottom corner shows 2 files but imports only
> > > one.
> > > If JPGs are not ignored, file count is correct. Looks like the part
> > > of
> > > code which counts files ignores import dialog settings.
> > >
> > _
> > __
> > darktable developer mailing list
> > to unsubscribe send a mail to
> > darktable-dev+unsubscr...@lists.darktable.org
> >
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Richard Hobday]

-- Tongue firmly in cheek --
en-GB or en-US ?
That is the real question.
They are two very different languages, at present darktable seems to
assume they are the same!

R.

On 18/11/2019 14:36, Julian Rickards wrote:

grAy is the American spelling and there's nothing wrong with that
(despite being a Canadian and using British spelling, LoL) but Timur is
correct, there should be consistency and, in addition to sticking to the
same spelling of gray/grey, I think that that the English version of the
documentation (and GUI) should be either all British or all American
English spelling, not just American for some and British for others.

On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin
mailto:timur.davlets...@gmail.com>> wrote:

Actually I agree. Darktable lacks of terminology unification across
modules. E.g. AFAIR there are around 6 different names for 18% gray. In
some places it is "grey" but in others it is "gray".

Timur.

On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
 > On 15.11.19 12:02, parafin wrote:
 > > I think these numbers don't have units, so why do expect them to
 > > mean
 > > the same thing in different modules, even if we ignore the pipe
 > > order?
 >
 > Because that's the most basic requirement of usability. That things
 > named the same way act the same way and mean the same thing across a
 > single app – at the very least.
 >
 > > It's not promised anywhere in the documentation as far as I can
 > > see.
 >
 > 
 > I went through the Photoshop & Lightroom docs and I can't find any
 > promise in the entirety of them that slider ranges of things sharing
 > a
 > name will match in range & effect.
 > Yet they do.
 > Go figure ...
 > 
 >
 > Beers,
 >
 > .mm
 > _
 > __
 > darktable developer mailing list
 > to unsubscribe send a mail to
 > darktable-dev+unsubscr...@lists.darktable.org

 >

___
darktable developer mailing list
to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org



___
darktable developer mailing list to unsubscribe send a mail to
darktable-dev+unsubscr...@lists.darktable.org


--
http://lukecarville.jalbum.net
https://facebook.com/rlc.hobday
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Timur Irikovich Davletshin]

Well, my point was not about American vs British. It was just an
example of inconsistency. And odd tradition of lowercasing all capitals
make it only worse. Regarding this particular case... Well I think this
information (colorspace, type of curve) somehow must be delivered to
user. Otherwise developers will be asked same questions over and over.
They'll become annoyed, start being aggressive, users will be confused
even more and leave for another software :)

Timur.

On Mon, 2019-11-18 at 09:36 -0500, Julian Rickards wrote:
> grAy is the American spelling and there's nothing wrong with that
> (despite being a Canadian and using British spelling, LoL) but Timur
> is correct, there should be consistency and, in addition to sticking
> to the same spelling of gray/grey, I think that that the English
> version of the documentation (and GUI) should be either all British
> or all American English spelling, not just American for some and
> British for others.
> 
> On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin <
> timur.davlets...@gmail.com> wrote:
> > Actually I agree. Darktable lacks of terminology unification across
> > modules. E.g. AFAIR there are around 6 different names for 18%
> > gray. In
> > some places it is "grey" but in others it is "gray".
> > 
> > Timur.
> > 
> > On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
> > > On 15.11.19 12:02, parafin wrote:
> > > > I think these numbers don't have units, so why do expect them
> > to
> > > > mean
> > > > the same thing in different modules, even if we ignore the pipe
> > > > order?
> > > 
> > > Because that's the most basic requirement of usability. That
> > things 
> > > named the same way act the same way and mean the same thing
> > across a 
> > > single app – at the very least.
> > > 
> > > > It's not promised anywhere in the documentation as far as I can
> > > > see.
> > > 
> > > 
> > > I went through the Photoshop & Lightroom docs and I can't find
> > any 
> > > promise in the entirety of them that slider ranges of things
> > sharing
> > > a 
> > > name will match in range & effect.
> > > Yet they do.
> > > Go figure ...
> > > 
> > > 
> > > Beers,
> > > 
> > > .mm
> > >
> > ___
> > __
> > > __
> > > darktable developer mailing list
> > > to unsubscribe send a mail to 
> > > darktable-dev+unsubscr...@lists.darktable.org
> > > 
> > 
> > ___
> > 
> > darktable developer mailing list
> > to unsubscribe send a mail to 
> > darktable-dev+unsubscr...@lists.darktable.org
> > 
> 
> _
> __ darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Julian Rickards]

grAy is the American spelling and there's nothing wrong with that (despite
being a Canadian and using British spelling, LoL) but Timur is correct,
there should be consistency and, in addition to sticking to the same
spelling of gray/grey, I think that that the English version of the
documentation (and GUI) should be either all British or all American
English spelling, not just American for some and British for others.

On Mon, Nov 18, 2019 at 8:29 AM Timur Irikovich Davletshin <
timur.davlets...@gmail.com> wrote:

> Actually I agree. Darktable lacks of terminology unification across
> modules. E.g. AFAIR there are around 6 different names for 18% gray. In
> some places it is "grey" but in others it is "gray".
>
> Timur.
>
> On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
> > On 15.11.19 12:02, parafin wrote:
> > > I think these numbers don't have units, so why do expect them to
> > > mean
> > > the same thing in different modules, even if we ignore the pipe
> > > order?
> >
> > Because that's the most basic requirement of usability. That things
> > named the same way act the same way and mean the same thing across a
> > single app – at the very least.
> >
> > > It's not promised anywhere in the documentation as far as I can
> > > see.
> >
> > 
> > I went through the Photoshop & Lightroom docs and I can't find any
> > promise in the entirety of them that slider ranges of things sharing
> > a
> > name will match in range & effect.
> > Yet they do.
> > Go figure ...
> > 
> >
> > Beers,
> >
> > .mm
> > _
> > __
> > darktable developer mailing list
> > to unsubscribe send a mail to
> > darktable-dev+unsubscr...@lists.darktable.org
> >
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Timur Irikovich Davletshin]

Maybe it's time to choose project leader and start collecting
donations?

On Mon, 2019-11-18 at 15:11 +0100, Aurélien Pierre wrote:
> darktable also lacks a board of investors, a CTO, a head of UX, a
> project management, a panel of test users, a famous photographer as a
> brand ambassador, many tracking features to collect statistics on
> usage "to improve the performance", an annual coding sprint in the
> Bahamas and a couple of off-shore accounts to pay for the whores and
> whisky during that sprint. 
> Until that, darktable is done be piling up code randomly produced by
> random people, 90% of them being non-native English speakers, some
> writing grey, some writing gray, and contrast still means "pushing
> whites further away from blacks" with no implication on the actual
> algorithm or colour space used to do so.
> By the way, changing strings variables in C code does not actually
> require coding knowledge (just how to use grep and git - which might
> be worse than actually coding) and only needs a proper design backed
> with some argumentation (same-named settings having the same effect
> is a very good argument, now how do we actually fix the soft in a UI-
> consistent yet technically-accurate way ?). I'm waiting for the pull
> requests…
> Le 18/11/2019 à 14:29, Timur Irikovich Davletshin a écrit :
> > Actually I agree. Darktable lacks of terminology unification across
> > modules. E.g. AFAIR there are around 6 different names for 18%
> > gray. In
> > some places it is "grey" but in others it is "gray".
> > 
> > Timur.
> > 
> > On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
> > > On 15.11.19 12:02, parafin wrote:
> > > > I think these numbers don't have units, so why do expect them
> > > > to
> > > > mean
> > > > the same thing in different modules, even if we ignore the pipe
> > > > order?
> > > 
> > > Because that's the most basic requirement of usability. That
> > > things 
> > > named the same way act the same way and mean the same thing
> > > across a 
> > > single app – at the very least.
> > > 
> > > > It's not promised anywhere in the documentation as far as I can
> > > > see.
> > > 
> > > 
> > > I went through the Photoshop & Lightroom docs and I can't find
> > > any 
> > > promise in the entirety of them that slider ranges of things
> > > sharing
> > > a 
> > > name will match in range & effect.
> > > Yet they do.
> > > Go figure ...
> > > 
> > > 
> > > Beers,
> > > 
> > > .mm
> > > _
> > > 
> > > __
> > > darktable developer mailing list
> > > to unsubscribe send a mail to 
> > > darktable-dev+unsubscr...@lists.darktable.org
> > > 
> > 
> > ___
> > 
> > darktable developer mailing list
> > to unsubscribe send a mail to 
> > darktable-dev+unsubscr...@lists.darktable.org
> > 
>  
> _
> __ darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Aurélien Pierre]

darktable also lacks a board of investors, a CTO, a head of UX, a
project management, a panel of test users, a famous photographer as a
brand ambassador, many tracking features to collect statistics on usage
"to improve the performance", an annual coding sprint in the Bahamas and
a couple of off-shore accounts to pay for the whores and whisky during
that sprint.

Until that, darktable is done be piling up code randomly produced by
random people, 90% of them being non-native English speakers, some
writing grey, some writing gray, and contrast still means "pushing
whites further away from blacks" with no implication on the actual
algorithm or colour space used to do so.

By the way, changing strings variables in C code does not actually
require coding knowledge (just how to use grep and git - /which might be
worse than actually coding/) and only needs a proper design backed with
some argumentation (same-named settings having the same effect is a very
good argument, now how do we actually fix the soft in a UI-consistent
yet technically-accurate way ?). I'm waiting for the pull requests…

Le 18/11/2019 à 14:29, Timur Irikovich Davletshin a écrit :
> Actually I agree. Darktable lacks of terminology unification across
> modules. E.g. AFAIR there are around 6 different names for 18% gray. In
> some places it is "grey" but in others it is "gray".
>
> Timur.
>
> On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
>> On 15.11.19 12:02, parafin wrote:
>>> I think these numbers don't have units, so why do expect them to
>>> mean
>>> the same thing in different modules, even if we ignore the pipe
>>> order?
>> Because that's the most basic requirement of usability. That things 
>> named the same way act the same way and mean the same thing across a 
>> single app – at the very least.
>>
>>> It's not promised anywhere in the documentation as far as I can
>>> see.
>> 
>> I went through the Photoshop & Lightroom docs and I can't find any 
>> promise in the entirety of them that slider ranges of things sharing
>> a 
>> name will match in range & effect.
>> Yet they do.
>> Go figure ...
>> 
>>
>> Beers,
>>
>> .mm
>> _
>> __
>> darktable developer mailing list
>> to unsubscribe send a mail to 
>> darktable-dev+unsubscr...@lists.darktable.org
>>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[parafin]

Well, that’s the problem with basic adjustment module - IMHO it shouldn’t 
exist, because it duplicates functionality of other modules, while adding 
problems like the one discussed here.


> On 18 Nov 2019, at 16:13, Moritz Moeller  wrote:
> 
> On 15.11.19 12:02, parafin wrote:
>> I think these numbers don't have units, so why do expect them to mean
>> the same thing in different modules, even if we ignore the pipe order?
> 
> Because that's the most basic requirement of usability. That things named the 
> same way act the same way and mean the same thing across a single app – at 
> the very least.
> 
>> It's not promised anywhere in the documentation as far as I can see.
> 
> 
> I went through the Photoshop & Lightroom docs and I can't find any promise in 
> the entirety of them that slider ranges of things sharing a name will match 
> in range & effect.
> Yet they do.
> Go figure ...
> 
> 
> Beers,
> 
> .mm
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
> 
> 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Timur Irikovich Davletshin]

Actually I agree. Darktable lacks of terminology unification across
modules. E.g. AFAIR there are around 6 different names for 18% gray. In
some places it is "grey" but in others it is "gray".

Timur.

On Mon, 2019-11-18 at 14:03 +0100, Moritz Moeller wrote:
> On 15.11.19 12:02, parafin wrote:
> > I think these numbers don't have units, so why do expect them to
> > mean
> > the same thing in different modules, even if we ignore the pipe
> > order?
> 
> Because that's the most basic requirement of usability. That things 
> named the same way act the same way and mean the same thing across a 
> single app – at the very least.
> 
> > It's not promised anywhere in the documentation as far as I can
> > see.
> 
> 
> I went through the Photoshop & Lightroom docs and I can't find any 
> promise in the entirety of them that slider ranges of things sharing
> a 
> name will match in range & effect.
> Yet they do.
> Go figure ...
> 
> 
> Beers,
> 
> .mm
> _
> __
> darktable developer mailing list
> to unsubscribe send a mail to 
> darktable-dev+unsubscr...@lists.darktable.org
> 

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] basic adjustments

[Moritz Moeller]

On 15.11.19 12:02, parafin wrote:

I think these numbers don't have units, so why do expect them to mean
the same thing in different modules, even if we ignore the pipe order?


Because that's the most basic requirement of usability. That things 
named the same way act the same way and mean the same thing across a 
single app – at the very least.



It's not promised anywhere in the documentation as far as I can see.



I went through the Photoshop & Lightroom docs and I can't find any 
promise in the entirety of them that slider ranges of things sharing a 
name will match in range & effect.

Yet they do.
Go figure ...


Beers,

.mm
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Fwd: [darktable-dev] Adobe Bridge Keyword Import Fail

[Bruce Williams]

And if that is what the issue is (the extra file extension component in the
filename), I am pretty sure I addressed that in my video.
A simple rename routine to remove that from your xmp files will sort it out.
Cheers,
Bruce Williams.

-- Forwarded message -
From: Bernhard 
Date: Mon., 18 Nov. 2019, 18:53
Subject: Re: [darktable-dev] Adobe Bridge Keyword Import Fail
To: 




Patrick Shanahan schrieb am 17.11.19 um 22:47:
> * Ron Wis  [11-17-19 15:27]:
>> Hello,
>>
>>
>>
>> I used Adobe Bridge to enter my keyword tags in the past. Having no luck
>> getting keywords into DT 2.6.3 from Adobe Bridge 9.1.0.338. Seems that DT
>> ignores the Bridge .xmp file (Bridge, by default generates the .xmp next
to
>> the raw file in the same folder- so the .xmp is available to DT) .
> having no experience with adobe bridge and not much more windows, it is
> quite possible that the xmp files do not follow the same standard as
> darktable.  and you will receive more attention from the developers if you
> file and issue on github,
>https://github.com/darktable-org/darktable/issues
>
perhaps a problem of naming conventions?
What is a RAW file named?
How is the Filename of the corresponding xmp?

There are mainly 2 possibilities:

weird1234.nef
weird1234.xmp

or

weird1234.nef
weird1234.nef.xmp

and perhaps others?
darktable uses the second version.

-- 

regards
Bernhard

https://www.bilddateien.de

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org