Re: [darktable-dev] Presets for Storage created via Lua

[William Ferguson]

Hi Kevin,

I think the exporter can only create a preset from the widget's that it
controls.  The exporter can't "see" into enfusePro and since all those
widgets are controlled by enfusePro and not the exporter, the exporter
can't set a preference to control widgets it doesn't have access to.  To do
what you want would require a preset system inside of enfusePro.

Bill

On Mon, Feb 25, 2019 at 8:12 PM Kevin Ertel  wrote:

> All,
>
> I have created a number of lua scripts, some simple, and others more
> complex. The most complex is a cross-platform implementation of Holger
> Klemm's enfusePro. In going through and re-working this some recently I
> thought it would be good to create some presets for this storage with
> various different settings selected/enabled. However, I was suprised by
> dt's behavior here:
> 1) I could only create a single preset for that storage type. The in-built
> storage types (such as file on disc) allow multiple presets to be created,
> each with unique options. When I go to the storage created by my script I
> can make a single preset, and from there on on'y have the options to "edit
> this preset" or "delete this preset"
>
> 2) When creating the preset, my modified values were not saved. I tested
> this by deselecting numerous options, creating a preset, resetting the
> module (which turned all those de-activated options back on), and then
> selecting the previously created preset. None of the options were
> deactivated.
>
> Is this expected behavior for Lua generated storage? As it stands this
> makes "presets" for lua storage types pretty much pointless. Is there a way
> to enable the traditional preset behavior that exists throughout the rest
> of dt?
>
> ___
> 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] Grey theme

[Aurélien Pierre]

Hi,

there are lots of visual artifacts that can result from
background/foreground contrast and the surround lightness adaptation.

Please note that :

  * darktable UI is currently under clean-up to wire every color and
font-size to the CSS sylesheet :
https://github.com/darktable-org/darktable/pull/2037
  * there is a new option in master to switch between themes (hence CSS
sheets). Thanks to Pascal !
  * a grey theme will be added once everything is settled, so you might
not need to bother about CSS anymore.

The general recommendation is to use middle grey (50 % Lab) or light
grey (70 % Lab) backgrounds during editing to minimize the contrast
between image and surround, in order to avoid tricking your eye.
Basically, dark surrounds make images look brighter than they are, but
less contrasted at the same time, which may result in under-exposing
them and crushing their blacks (expect a bad surprise when you print),
but also affects color saturation perception (they look more saturated).
Ignoring that, most photo editors choose to have a dark background, for
marketing reasons : images look prettier (more saturated) out of the box
(so the software should be better, right ?), and interfaces look sexier
(me likes sexy).

More details :

 1. https://xritephoto.com/documents/literature/en/StandardViewingNTK_EN.pdf
 2. Chapters 6-7-8 of

http://last.hit.bme.hu/download/firtha/video/Colorimetry/Fairchild_M._Color_appearance_models__2005.pdf
and more specifically, sections 6.1 (p.111) 6.9 (p.126)

The brightness of your screen should be such that a fully white screen
matches the brightness of a white paper sheet sitting next to your
computer and lit by surround light. Be carefull at night because
domestic lights have a color temperature between 5000 K (high-end
daylight balanced LED lights) and 3000 K (tungsten light bulbs), so they
won't match the D65 illuminant (temperature and light spectrum) on which
your screen should be set and can be very misleading.

Also, don't lose too much time figuring out what your pictures will look
like on other people's display, because it's a lost cause.

Good luck,

Aurélien.

Le 19-02-24 à 07 h 16, KOVÁCS István a écrit :
> Hi,
>
> I've posted this on the users' list a week ago, but have not received
> any reply.
>
> Could you please provide a recommendation for general-purpose
> processing? I mainy post online (on Smugmug, which uses dark
> backgound, but the primary surface are our family blog and Facebook,
> which are both on light background). I mostly edit at night, in a
> quite dark room, with a 'warm-white' LED desk lap illuminating the
> white wall behind the monitor.
>
> Thanks in advance,
> Kofa
>
> -- Forwarded message -
> From: *KOVÁCS István*  >
> Date: Sun, 17 Feb 2019 22:38
> Subject: Grey theme
> To: Darktable Users List  >
>
>
> Hi,
>
> A question has come up on Facebook
> (https://www.facebook.com/groups/darktable/permalink/1200810193417890/)
> about theming. I answered with a link from the announcement of 2.6.0
> (https://www.darktable.org/2018/12/darktable-26/), which provides the
> CSS for a white and a grey theme, adding the following:
> "[regarding the white theme] Note that with such setup, images will
> look darker, hence the aspect of the GUI may push the user to
> over-expose the images. A white background is interesting for people
> working on images meant to be displayed on white background, though.
> To avoid being influenced towards over- or under-exposing pictures, a
> grey theme like the following is much more advisable" - and then the
> article provides a grey theme.
>
> So, returning to the question: if this a recommendation for
> print-oriented people (whom a white theme may push to overexpose
> images)? The text mentions underexposure, too, which I'd link to a
> very dark UI.
>
> If it's for everyone, and it is "much more advisable" (than the
> default black or a custom white theme), why is it not the default with
> 2.6?
>
> Thanks in advance,
> Kofa
>
> ___
> 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] Presets for Storage created via Lua

[Kevin Ertel]

All,

I have created a number of lua scripts, some simple, and others more
complex. The most complex is a cross-platform implementation of Holger
Klemm's enfusePro. In going through and re-working this some recently I
thought it would be good to create some presets for this storage with
various different settings selected/enabled. However, I was suprised by
dt's behavior here:
1) I could only create a single preset for that storage type. The in-built
storage types (such as file on disc) allow multiple presets to be created,
each with unique options. When I go to the storage created by my script I
can make a single preset, and from there on on'y have the options to "edit
this preset" or "delete this preset"

2) When creating the preset, my modified values were not saved. I tested
this by deselecting numerous options, creating a preset, resetting the
module (which turned all those de-activated options back on), and then
selecting the previously created preset. None of the options were
deactivated.

Is this expected behavior for Lua generated storage? As it stands this
makes "presets" for lua storage types pretty much pointless. Is there a way
to enable the traditional preset behavior that exists throughout the rest
of dt?

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

[darktable-dev] [admin] Issue deleted by accident on Redmine

[Aurélien Pierre]

Hi,

I have deleted by accident a bug report on Redmine, by Martin Straeten
(IIRC). Is there any way to restore it ?

My apologies, I thought the "delete" option applied to the (spam)
comment, not to the whole issue. It's not clear when there is only one
comment on the issue.

Aurélien.


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

Re: [darktable-dev] Lens correction with FF lenses used on APS-C

[sturmflut]

Hi,

Am 24.02.19 um 13:32 schrieb Florian W:

> 1 This reasoning is mixing description of digital features with analog
> ones . A lens quality and specs is not defined by MP resolution (rather
> by like purity of the glass, glass curvature homogeneity, CoC, TCA, and
> so on).

You are right, things work a bit differently on the optics side before
the sensor. Hence my use of "oversimplyfing it a bit". But the
resolution of an optical system can still be measured (see e.g. Optical
transer function [1]), and you can specify how much contrast you expect
to see in details and what level of details you expect to still be visible.

It's hard to make exact quantitative statements like "this lens has an
optical transfer function which gives enough contrast for x line pairs
per millimeter, and that would be enough for an x megapixel sensor of
this and this size". Especially because glass quality even differs
within the same manufacturing batch. But for example with my blurry
70-300 it's easy to judge that it would probably be sharp enough for a
12 to 16 megapixel sensor, but nothing better.


> 2 Some of the lenses we're talking about were developed and (partially)
> targeted to FF cameras having a sensor with less MP than a current APS-C
> (for example in Canon, the 6D is a 2012 FF with 20MP).
> 
> If the reasoning is valid, a lens released at times of FF with 24MP or
> higher wouldn't be a good match to the previous cameras with less MP.
> Which doesn't seems to be the case.
>
> What I mean by this is that at some point, to ensure a lens will perform
> well on FF cameras that will be released the following decade, one can
> assume that the optical manufacturing quality is probably one order of
> magnitude above the quality required to fit the current camera sensor
> capabilities. Maybe explaining why you can see problems in older lenses.
I'm not saying that I see a general problem with older lenses, and I
already noted that your prime lenses probably won't cause much of problem.

There's simply a very, very wide range of lenses out there, and the
pricing, engineering and manufacturing decisions can lead to extremely
different optical properties. There are some prime lenses from the 1980s
which are still extremely sharp on today's sensors, but primes are easy.
Most have just seven or eight glass elements.

My Nikon 24-70/2.8 on the other hand has 20 lens elements in 16 groups.
The older Canon 70-200/2.8 has 23 lenses in 19 groups. Even the Nikon
16-35/4 has 17 lens elements. Obviously it is much harder to keep the
optical resolution at the same level when light has to pass through that
many pieces of glass and the lens still has to be affordable. So there
are FF lenses out there which will give good results on APS-C bodies,
but not all will. And you can easily end up getting worse image quality
with a FF lens on an APS-C body when you expected a better one because
the FF lens was more expensive and is supposed to be better.

Also manufacturers don't generally design lenses so thewy will work
perfectly with cameras released a decade later. They will design the
current top model so it has enough room to still be good on the next
model, but they still want you to buy the new "sharper than ever" lens
every five years.

cheers,
Simon










[1] https://en.wikipedia.org/wiki/Optical_transfer_function
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org