Re: [darktable-dev] Code reformatting...

2023-02-02 Thread Moritz Moeller

On 01.02.23 06:13, Bruce Guenter wrote:

On Mon, Jan 23, 2023 at 11:19:52PM +0100, Pascal Obry wrote:

This has nothing to do with display size. Do you know why news paper
has small columns? Because it is faster to read, that is, the time to
go from the end of line to the start of the new is far easier if the
width is not too large.


Actually, that's a bit of an urban legend.


Actually, it isn't. I studied typography and worked professionally in 
the field for a decade. Just take my word for it. :)



Newspapers have small columns
because wider columns have more unused space, which means less space for
other features and, most importantly, advertisements.


I dunno how newspapers entered this. Take any book, scientific 
publication, etc. They all stick to this rules despite the complete lack 
of advertising space constraints.



Recent studies
point to reading speed going up as line lengths increase, though the
effect is not huge.

https://www.usability.gov/get-involved/blog/2006/08/line-length-and-onscreen-reading.html


I call that BS until you show me a meta-study with overall 
non-contestable sample size and age distribution.

20 college students? Yeah, right.

I would say there isn't a bigger age bias to be had than that. And the 
sample size ... let's not go there. ;)



Beers,

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



Re: [darktable-dev] Code reformatting...

2023-02-02 Thread Moritz Moeller

On 01.02.23 23:04, Mark Feit wrote:
I don't contribute code to darktable often, but I do follow this list 
closely and feel the need to comment on this.  Take it or leave it as 
you wish.


Dito. Let me just clarify some perceived misunderstandings re. my 
previous comments. :)


The darktable source code isn't prose and isn't consumed like it.  I can 
all but guarantee that formatting it according to _all_ of the rules for 
typesetting text and forcing people to work with it would result in a 
lot of screaming.


That's sad and if it were true I'd consider it rather as an indicator of 
what could improved than a counter argument to what I said.

Google 'code as prose'. ;)

A great example is the source to the 'Physically Based Rendering' book(s).


See https://practicaltypography.com/line-length.html


 From that page:

"If you plan to use indenting to distinguish sections or hierarchies 
within your document, take this into account when setting up the initial 
line length. [...]


I agree, this is important.
A good code formatter will have option to make sure that foremost the 
part of the line after the indentation counts towards the line length 
and the indentation either not at all or by some some function of its width.


Modernity doesn't really make a difference here.  Rust didn't invent 
bringing a formatter along with the language and it certainly didn't 
introduce forced formatting for commits. 


I don't recall saying it did in either instance so I'm not sure why you 
mentioned this.
Nor what difference to the validity of what I said it would make in 
regards of whether language X or Y was first or shipped a formatter as 
part of the default toolchain (which is pretty much non-existent for C/C++).


Formatting for comments is off by default in rustfmt btw.

Most C does just fine constrained to 80.  Most parts of darktable I've 
browsed through probably would, too.  But...  In 35 years of writing C 
and seeing C code in the wild, I've run into code bases where formatters 
constrained to short lines made them awkward and difficult to read. 
Constraining darktable's C code base to whatever length some other code 
base in some other language uses as standard is dogma-driven design and 
it's not helpful.


I think Rust and C are very comparable in this regard indeed. After 
almost 35 years of C, 25 of C++ and three of Rust I feel eligible to be 
opinionated here. :)


Especially since Rust encourages heavy code reuse through crates 
('libs') and it is common practice to not omit the namespace when using 
such imported functions/types/methods.
I.e. the 'identifiers may be somewhat long' issue is not uncommon in 
Rust code as well.
The pragmatic approach would be to find something that works for *this* 
code base and *these* developers.


I didn't mean to suggest anything else. I was merely pointing out that 
the reasoning Matthias used is flawed.


As I am a lurker on this list and do not have to touch C code, from 
darktable or otherwise, at all or very often any more, I better shut up 
now. :]



Beers,

.mm



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



Re: [darktable-dev] Code reformatting...

2023-02-01 Thread Moritz Moeller

On 23.01.23 22:12, Matthias Andree wrote:

While the idea is sound, 80 character wide lines seem so... 1980's. Do
people still need to read and edit darktable source code on 640x480
displays?


This has nothing to do with how many character fit on a line on any 
display and everything with legibility.


Just because it's code doesn't mean rules discovered by typographers and 
used for typesetting text for centuries do not apply. ;)


45-90 chars/line is the suggested default for body text.
See https://practicaltypography.com/line-length.html

There are modern languages which enforce a unified code formatting 
style. Rust e.g. hast rustfmt which almost all projects run 
automatically, via githooks or the like. So Rust code is always 
formatted the same way which is extremely helpful when reading other 
people's code (which is, after all, what most software developers do 
most of the time, even if we hate it and hate to admit it even more).


The relevant defaults in rustfmt are:

comment_width = 80 (comments, i.e. text)
max_width = 100 (code)

That said, in three years of using Rust and seeing Rust code in the 
wild, I've never seen 100c/l ever reached because there are other rules 
in rustfmt that commonly prevent this.




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



Re: [darktable-dev] Geotagging module not working with dates < 1970-01-01

2021-11-10 Thread Moritz Moeller

On 8.11.21 13:50, Coding Dave wrote:
Is this a valid usecase? I mean do you really correct digital photos 
with exif information from before epoch 0? What is your usecase?


I have tons of pictures from my parents from the 60's that I digitized 
and timestamped accurate to a month using estimates/labels on the 
negative roll.


Didn't run into this because geotagging is always on the todo list but 
when I will get to it this will become and issue for sure.



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



Re: [darktable-dev] Is it time for a major code overhaul?

2021-06-06 Thread Moritz Moeller

Hello Paul.

You raise some good points imho.

However, what I am replying to here is solely the suggestion of using C++.

You may of course choose to ignore my reply as I'm not a DT developer.
I do have 25+ years of professional experience writing software for 
image processing/generation though. Most of it in C++. So maybe I'm 
worth listening to.


Before I start: I think the choice of C was excellent one of Johannes – 
at the time.


Today I would probably choose Rust for any sort of 
refactoring/architecture/API improvements of any C code base I can think 
of. Including that of DT.


C++ – I do not even know where to start how bad an idea I'd consider that.

But to add some context: There is an ongoing effort from people in the 
Academy of Motion Pictures Software Association (ASWF) to expose all 
functionality as C APIs.
One reason is that all the libs ASWF hosts will be wrapped in safe Rust 
APIs.
What's more: core OpenEXR, just for example, is just being refactored in 
C (current codebase is C++).


These are people relying on such software like OIIO, OCIO, OSL, etc. to 
generate millions of images for motion pictures and series. They are 
turning their backs on C++. It's early days but ... go figure.


My suggestion would be: make a nice, safe RUst API to allow people 
writing modules in that language.


Then, if people really feel the need, refactor DT, bit by bit, into Rust.
Starting with the most hard to read parts of the codebase that someone 
new may want to contribute to.



Just my two c.

Beers,

.mm

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



Re: [darktable-dev] Introducing dtdocs

2020-10-16 Thread Moritz Moeller

On 17.10.20 01:41, Mica Semrick wrote:
You have specifically pointed out where you think markdown is falling 
short in this case.


For me MD vs Sphinx is mostly about roles, extensions, citations, line 
comments, footnotes etc. that you have in Sphinx but not in MD.
MD was designed for writing texts on the Web. ReST + Sphinx was designed 
for writing documentation.


Here is a longer version of that, written by someone else:
https://eli.thegreenplace.net/2017/restructuredtext-vs-markdown-for-technical-documentation/

With that said: I prefer MD syntax over ReST any day as long as it 
doesn't take anything away I think is standard for good documentation.

E.g. being able to have an index auto-generated.

Sadly it does. Worst, there is no real standard in MD.
CommonMarkdown is different everywhere. Maybe a feature you grew fond of 
when using MD in Jupyter Notebooks' MD is not available on GiHub's MD etc.


> Feedback is welcome, but please try to make it actionable. We're
> aiming for improvement.

With the above in mind – if I were to start a documentation project now 
I'd probably use this:

https://myst-parser.readthedocs.io/en/latest/

Which is kinda ReST + MD having a baby. :)

It would mean all the work you done could be used, mostly as-is.
But you would have all the bonuses of ReST + Spinx on top that MD + 
Sphinx would not give you. Even if you switched from MD + Hugo to MD + 
Sphinx.


Oh, and use readthedocs to handle building and serving.

Because, again, that is an ecosystem build for serving documentation as 
static pages online.

Hugo is nice but it was meant to build static websites.
Which surely represent a superset, containing static online 
documentation, but broad enough that it will leave many things to be 
desired, sooner or later.


And btw: https://darktable.readthedocs.io/ is available. ;)


Beers,

.mm


P.S.: For context:
I wrote software documentation in MD several times during the last decade.
I wrote software documentation in ReST using Sphinx several time (that 
was before Sphinx added MD support).

I also have BG writing docs in LaTex from way before.

With that being said I feel entitled to be opinionated about the subject.
And mind you, I am talking about the perspective of the writer, not the 
user.

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



Re: [darktable-dev] Introducing dtdocs

2020-10-16 Thread Moritz Moeller

On 17.10.20 01:30, Mica Semrick wrote:

On 10/16/20 2:12 PM, Moritz Moeller wrote:

THB I think Markdown is a tad limited for docs like this.


Have you had a look at the site yet?


Yes I did.

Though I don't understand how that relates to the part of my reply you 
quoted.


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



Re: [darktable-dev] Introducing dtdocs

2020-10-16 Thread Moritz Moeller

On 16.10.20 19:16, Chris Elston wrote:

Introducing dtdocs (https://github.com/elstoc/dtdocs)…

This project is a complete rewrite of the darktable documentation in 
markdown, providing a number of advantages over the current user manual:


Fantastic! I suggested using Sphinx a few years back but I got ignored.

THB I think Markdown is a tad limited for docs like this.
But if I have to choose between the old doc format and Markdown there is 
no question.
It's one of the reasons I never contributed to the DT docs. That may 
change now. :]


Big thumbs up!!! :)

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



Re: [darktable-dev] Massive rendering issues with UI fonts in Windows 10

2020-07-18 Thread Moritz Moeller

On 18.7.20 19:18, Patrick Shanahan wrote:

but you do not say what version of dt you speak, nor where/how you
obtained dt and how you installed it, 


He is on Windows 10. See subject line of his message.

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



Re: [darktable-dev] 3.0.2 for Mac wont start: file system relative paths not allowed in hardened programs

2020-07-02 Thread Moritz Moeller
I'm running 3.0.2. on 10.15.5 w/o any issues since that DT version was 
released.
Not sure though when I upgraded from 10.15.4. Maybe I had 3.0.2 already 
installed by then.


.mm

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



Re: [darktable-dev] HSL and RGB scene-referred space

2020-04-10 Thread Moritz Moeller

On 10.4.20 11:27, Harold le Clément wrote:

- Is this a real issue or is this a bad usage of darktable? I.e. shall
we never have RGB values higher that 1.0 in the pipe?


As a user I would expect to keep the dynamic range throughout the pipe 
for as long as possible. If a module clips it would actually help if 
this was indicated in the UI. Maybe with a little warning sign icon or 
the like, on the module.



- In the case this should ideally be fixed, I see three possibilities,
are there others?

1. Use another hue/saturation/lightness estimator: HSV (although value
is really different than lightness) or LCh (probably a lot more
computationally intensive), ...


Yes, I would second looking into the cylindrical models, 
LCh/HCL/CIELab/CIELuv, as better alternatives 
(https://arxiv.org/abs/1903.06490).


Just my two c. As I said, I'm just a user of DT.


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



Re: [darktable-dev] HDR and SDR

2019-12-17 Thread Moritz Moeller

On 17.12.19 14:24, Andreas Schneider wrote:

All TIFF files are currently set to SDR ...


That doesn't make sense. I use 16bit EXR when grading 3D rendered stuff 
via DT but someone could as well use 32bit float TIFF.



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



Re: [darktable-dev] UI glitches

2019-11-19 Thread Moritz Moeller

On 19.11.19 14:54, Patrick Shanahan wrote:

ah, when lacking a proper response, divert attention to something else
which is also irrelevant.


That's exactly what you were doing since attachment file sizes are not a 
topic of this thread. Maybe you meant /dev/troll? ;)


The first ting I learned when running my own software company was that 
it doesn't matter what channel users try to reach you. If they reach out 
to you to let you know about something that is broken or could be 
better, be thankful. They mean well.
They care about the software you make for them. What can be better 
testament to the work you do?


Aka: No need to be rude.

Tell them nicely about how to reach you better next time.
You can prepare a nicely written response that outlines Red Mine 
account/ticket creation and procedure that you can C into a reply or 
point them to a website that does so.


That takes 20 minutes.
Obviously doing so will remove the opportunity to be rude to new people 
on this list forever to a large degree.
Maybe the latter is more important to some people than solving the issue 
they purport to have here for once.


On a side note: What's exactly the problem with large file attachments 
in 2019 in the first world?


Yes, it's a bad habit. Does it bother? :)
My email client doesn't load attachments unless I tell it to. Most 
clients nowadays don't.



Beers,

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



Re: [darktable-dev] basic adjustments

2019-11-18 Thread 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



Re: [darktable-dev] darktable 3.0.0rc0 released

2019-11-06 Thread Moritz Moeller

On 6.11.19 14:35, Julian Rickards wrote:
 From my perspective, filmic2 isn't appropriate. I work in the 
publication services section of an Ontario (Canada) government ministry 
and when we assign "2" to a publication, "1" is gone and no longer 
available.


That's the most entertaining reasoning for naming something I've ever 
read on a software mailing list. :D


If the original filmic is gone from this version, then I would just name 
the new one filmic. If the original filmic will also be available, just 
like the various denoise modules, this new filmic should have an 
additional descriptor such as filmic rgb.


How about naming the old module 'filmic (deprecated)' in the UI and the 
new one just 'filmic'.

Behind the scenes (XMP etc.) they can be called 'filmic' and 'filmic2'.


Beers,

.mm


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



Re: [darktable-dev] darktable 3.0.0rc0 released

2019-11-05 Thread Moritz Moeller

On 5.11.19 19:18, Nicolas Auffray wrote:
Anyway, that's not ok as the new UI is now size adjustable (by using 
CSS, not have anymore hardcoded things and use emphasis sizes on most 
parts to adjust correctly). It seems to be a MacOS specific issue...


It's not an issue for me but for a first time user ... they'd probably 
close the app and never open it again. :)


I couldn't even resize the main window to fit my screen. It would lock 
at a width about 20% larger.


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



Re: [darktable-dev] darktable 3.0.0rc0 released

2019-11-05 Thread Moritz Moeller

On 5.11.19 18:42, I wrote:

I have the crazy oversized UI issue on macOS again. :)
Setting the bauhaus/scale in darktablerc doesn't help.


Never mind, setting screen_dpi_overwrite to 80 made the UI kinda the 
right size (except side panels which I had to scale down to 300).


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



Re: [darktable-dev] darktable 3.0.0rc0 released

2019-11-05 Thread Moritz Moeller

Thanks for the great work, guys!

On 4.11.19 18:44, Pascal Obry wrote:


The darktable 3.0.0rc0 release is out.

[...] > This is the first pre-release, test it and please be sure to report
issues you found.


I have the crazy oversized UI issue on macOS again. :)
Setting the bauhaus/scale in darktablerc doesn't help.

I do have the Roboto font installed.

https://pasteboard.co/IFjkPwp.png

Shall I file an issue?

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



[darktable-dev] Lenses in the Lens Correction module

2019-08-20 Thread Moritz Moeller
I was under the impression any lens found in lensfun will be available 
in DT.
I have a Samyang 85mm f/1.4 prime. Samyang is completely missing in the 
Lens Correction module but I see lensfun has many lenses from this 
vendor (and also this lens):


https://github.com/lensfun/lensfun/blob/master/data/db/slr-samyang.xml

Can someone explain?


Cheers,

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



Re: [darktable-dev] DT bad on skin tones?

2019-05-26 Thread Moritz Moeller

On 27.5.19 01:09, Šarūnas wrote:

On 5/25/19 3:11 PM, Christian wrote:

Hi, I re-did the test with the Fuji X-E2 version of the test-chart
shoot and the skin colors are much better.


This interest me to, however it is not obvious, what you [re-]did to get
better colors. Care to elaborate? Thanks!


He just used images from a different Fuji camera.

This means DT will use a different matrix for the conversion.
And it seems that matrix, the one for the X-E2, doesn't have the issues 
OP is seeing with the one DT uses when fed with images from an X-T3.


Beers,

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



Re: [darktable-dev] DT bad on skin tones?

2019-05-24 Thread Moritz Moeller

On 24.5.19 19:26, David Vincent-Jones wrote:
Raw is RAW  without processing. It is up to you to manipulate the 
raw data to achieve the look that you want. [...]


OP clearly said they had no modules that shift color turned on.
The DT processed image clearly has green tint in the shadows.

For giggles, I opened the image in RawTherapee and Capture One and 
neither shows any green tint.


So the conclusion seems to be that something in DT needs fixing.


Beers,

.mm


P.S.:
I am always flabbergasted about the arrogance/passive aggressiveness 
regularly displayed by some people on this list.


Particular when users report bugs or shortcomings of DT.

DT is not perfect. No software is. Get over it.
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] BUG in Exposure (DT 2.6.2)

2019-05-09 Thread Moritz Moeller

Hey Chris,

thanks for the bug report.

On 8.5.19 21:48, Christian wrote:

Hi,
Bug in Belichtung-Module (Exposure) :
[...]
In short: GUI-state of the pipette-icon is not reflecting the real
state.


I created a bug in the DT tracker on Github for you -- 
https://github.com/darktable-org/darktable/issues/2540.


Maybe you could add more details, e.g. on what OS and DT version you are?


Beers,

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



[darktable-dev] Lighttable/Selected/Duplicate broken in 2.6.2 on macOS?

2019-04-30 Thread Moritz Moeller

Can anyone confirm this is or is just my installation?

I get the message 'duplicating 1 image' but no duplicate ever shows up 
in my collection.



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



Re: [darktable-dev] where to discuss big changes

2019-04-17 Thread Moritz Moeller




On 17.4.19 09:16, johannes hanika wrote:
i second the 'getting old' bit. and i really like IRC. 


Maybe you misunderstood my message's intend?
Yes, I too prefer IRC over any 'modern' chat client.

But I agree with parent that it is not the right tool to discuss big 
changes.

IRC has no history. IRC has no message threads.
That's why I mentioned NNTP.
E-mail is the 2nd best alternative.
IRC isn't one at all. IMHO.

Beers,

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



Re: [darktable-dev] where to discuss big changes

2019-04-16 Thread Moritz Moeller
There is this thing called 'a news server' which has all of below but 
has infinite history (for free) and you can actually see who replied to 
whom before even opening/deciding to read a message.


That feature alone makes a news server with a decent client (e.g. 
Thunderbird) a thousand times superior to something like e.g. Slack.


And this stuff has been available since the 70's. For free.
Maybe I'm just getting old. Just my two c.


Beers.

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



Re: [darktable-dev] ATTENTION: darktable master may go unstable.

2019-03-07 Thread Moritz Moeller
On 7.3.19 21:47, Pascal Obry wrote:> - mask history (that is a mask is 
now part of the history and when

changed will not change the same mask in the same module in the
history.
- the possibility to have custom module order (with drag & drop)
- a working color space


Fucking amazing!!! So next DT will get a node editor? :]
Let me know when this is merged, I want to try this immediately!

Beers!

.mm

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



[darktable-dev] Lens correction -- move image center feature?

2018-12-29 Thread Moritz Moeller
I recently started using very shot fisheye lenses (12-14mm) for event 
photography. The idea is that you will never catch the right 
angle/composition/moment all together at a wedding/party etc.


Afterwards, you undistort the images and crop to the region with the 
best composition, to obtain a FOV more like 35mm or 50mm.


The problem is that you also want to shift the image around in the 
distorted space before undistorting & cropping. Not after.


Basically change the center, before undistorting so you don't get the 
extreme proportional changes at the edges of the image (which may, 
because of the region you crop to, end up much closer to the center 
afterwards).


Would it make sense/be possible to add a horizontal/vertical shift to 
the lens undistort module for this?

If so, I'd create a feature request in the tracker with some example RAWs.


Beers,

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



Re: [darktable-dev] Suggestion for improving 'color zones' module

2018-11-29 Thread Moritz Moeller

On 29.11.18 15:00, tikuisik wrote:

[...]
So my strong suggestion and desire for the future releases of darktable 
would be to change the curve system in the 'color zones' module. Another 
mathematical type of curve that could ensure zero bending in the 
outlying region, similar to Adobe's Lightroom or Blackmagic's DaVinci 
Resolve (where upon selecting a particular hue to change, 3 nodes 
appear, the 'active' central one and two outliers that do not allow the 
effect to spread beyond), would be the most welcomed change.


+1.
I often grade footage in Resolve and I'm missing this behavior/type of 
curve too, in DT.
Another, related issue is the size of the widget though. It becomes 
fiddly to adjust this. If the view could be zoomed horizontally, inside 
the widget, that would be a welcome addition too.


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



Re: [darktable-dev] noise

2018-11-05 Thread Moritz Moeller

On 5.11.18 09:34, Rolf Meyerhoff wrote:

if you have followed the UI refactoring discussion lately then you will
have noticed that the intended target audience for DT are programmers
and graphics nerds who really know what each module does, [...]


Rolf nails the issue.

The basic problem this discussion is about is UX created by developers.
Developers usually understand well what an algorithm can do. Let's call 
it the 'domain of possibility'.
Users commonly only need a tiny subset of this domain. One that lets 
them converge /as fast as possible/ to /optimal/ results for the task at 
hand by manipulating the /least/ number of parameters.


Note that with every parameter on must manipulate to get to an optimal 
result, the domain the user has to understand greatly increases. You are 
basically adding a dimension (!) to the parameter vector that governs 
the result.


Most developers, if they can't decide how to map any of an algorithm's 
parameter automatically, to govern an optimal result, will just expose 
that parameter in the UI.
You can look at this from two sides: laziness/ineptitude/reluctance to 
understand what problem the algorithm will solve for the user (vs the 
full domain of problems it can solve) or just giving 'more power' to the 
user because you shouldn't 'assume' what subset of the domain they 
actually need.
The latter is commonly the excuse developers will give but from my own 
experience the main reason is ineptitude. It's just the difference 
between how an artist's/user's brain is wired vs a developer's.


This is the single most common reason UX/UIs of software often suck(s): 
developer's don't understand that users want /less/ parameters.

They naturally think that more power is good thing.

That's why today UX has become a profession. UX people are commonly 
those that are technical enough to understand the domain and at the same 
time the results most users look for. They can map it to the needs of 
the user by producing a minimal UI that is abstracted away from the 
original algorithm.


As DT's main user group are developers or at least people with much 
better than average understanding of the underlying algorithms this is 
not such an issue.


See the screenshot of OP from RawTherapee. There is a single drop-down 
that disables the whole obscure set of parameters driving it's noise 
reduction algorithm and switches it to a mode where it chooses good 
parameters for the user. Aka: RawTherapee's noise reduction module seems 
to have a mode where it has /zero/ parameters the user must adjust, from 
the looks of it!!! Amazing, if this is true.


This would be top notch UX. DT lacks this. By design. Whether this a is 
a good or bad thing is a different discussion.


I have my own opinion about this. I urge interested parties to watch a 
talk on how developers make artists lives harder and how some companies 
(the speaker works for one) are trying to abandoning this practice.


https://www.youtube.com/watch?v=-ihVkVqCOGc=youtu.be=287

This part of the talk made a lot of waves in the VFX world. The number 
of mails the speaker (a friend of mine) got form renowned industry 
professionals, seconding his findings, is overwhelming.


This talk also contained a section where the speaker analyses how bad 
Autodesk Maya's UX is. It was cut by the sponsor, Foundry, because of 
their business ties with Autodesk.



Beers,

.mm

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



Re: [darktable-dev] possible data loss scenario

2017-10-09 Thread Moritz Moeller

On 09.10.17 08:50, Alexander Rabtchevich wrote:

Yesterday I almost lost a three-years work. [...] > If the mouse had shifted 
when I had been typing 1, I
would not be able to recognize my selected works from 3 years anymore.


So you are saying you do not have a backup?

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



Re: [darktable-dev] cannot compile current git

2017-01-28 Thread Moritz Moeller

On 28.1.17 12:06 , Roman Lebedev wrote:

*Please* try building master directly.


I did. Same error.

.mm

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



Re: [darktable-dev] cannot compile current git

2017-01-28 Thread Moritz Moeller

I also have an issue. But it's a different one:

[  6%] Building CXX object 
src/external/rawspeed/src/librawspeed/CMakeFiles/rawspeed.dir/decoders/DngDecoderSlices.cpp.o
/Users/moeller/code/darktable/src/external/rawspeed/src/librawspeed/decoders/DngDecoderSlices.cpp:435:31: 
error: no matching function for call to

  'jpeg_read_header'
if (JPEG_HEADER_OK != jpeg_read_header(, true))
  ^~~~
/opt/local/include/jpeglib.h:1039:13: note: candidate function not 
viable: no known conversion from 'bool' to 'boolean' for 2nd argument

EXTERN(int) jpeg_read_header JPP((j_decompress_ptr cinfo,
^
1 error generated.


I am currently building on the monochrome branch. I did

git pull
git merge origin/master
git submodule update


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



Re: [darktable-dev] Rawspeed from subrepo doesn't find camera

2017-01-12 Thread Moritz Moeller

On 6.1.17 17:33 , Roman Lebedev wrote:

Note that I always convert all my original raws from the camera (.ARW) to
DNGs and have done so from the beginning.

Ah, well, i sure hope that you keep original ARW around :)


No, I don't. I do not see a reason for it.


So if I upload an example, I can't honestly tick the box 'The file is
manually copied from card/camera, without using any software like Nikon
Transfer.' because these files all went through Adobe DNG Converter.

We have a sample SONY ILCE-7M2 ARW, but it is not under CC0.
So if you can, please upload one ARW.
(and do please check if there are any other samples you could share)


I uploaded a .dng originating from a Sony ILCE-7M2 ARW. I will upload an 
ARW when I do my next shoot/


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



[darktable-dev] Liquify feedback

2016-07-27 Thread Moritz Moeller
First of all: this looks awesome! It means yet another reason gone to 
exit DT and open Fusion or, worse, PS. Fantastic work.



Some comments.

The overlay looks nice but hides too much of what is going on in the 
image underneath. It would be great if


- opacity of the color overlay in the circles (or even blend mode)
- density of the arrows
- color of overlay (I guess arrows and circles share this)

could be adjusted. Maybe just add this the global prefs?

Another thing is that often one spends a long time creating a spline 
mask for some effect. Then it not unlikely that there is a shared edge 
between that spline and some liquify effect.


Being able to import from/export to the mask manager would be great thus.

Another important feature is exchange of warp points/lines/splines 
between liquify instances.


Maybe a global liquify manager would hold this data and each instance 
would just let you select which ones to use from the global list and add 
some local modifiers like strength (could be negative to allow inversion).




Cheers,

.mm


P.S.:
In the tool it says

warps|nodes count: X|Y

This is a bit confusing every time I read it because the '|' looks like 
an 'l' or 'I' or a '1'. how about:


warps, nodes: X, Y

or

warps/nodes: X/Y
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org



Re: [darktable-dev] Grayscale, Was: Contribution

2016-06-30 Thread Moritz Moeller

Hey Wolfang,

On 09/05/16 11:46, Wolfgang Mader wrote:

Thanks for the literature. I will have a look at is at soon as possible, and
will come back to you, once there is something do discuss.


I'll have some B images to develop soon. Anything I could test already? :)

.mm

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



Re: [darktable-dev] Grayscale, Was: Contribution

2016-05-09 Thread Moritz Moeller

On 08/05/16 15:10, Wolfgang Mader wrote:

On Friday, May 6, 2016 11:03:18 PM CEST Moritz Mœller wrote:

What is missing is porting one of the contemporary black and white
conversion plugins to be available in DT.

The monochromes module is just very ... traditional.

Some of the recent papers have C code/Gimp plugins. One of them should be
ported to DT. I nan send your some suggestions.


Please do so.


Meta paper, possibly interesting to see what is there and what makes 
most sense to implement:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3254613/

Meta experiment (has links to almost all the interesting papers).
http://cadik.posvete.cz/color_to_gray_overview/

Interesting looking ones; ordered by year of publication:
1. [2008] http://cadik.posvete.cz/color_to_gray_evaluation/

2. [2007] http://www.eyemaginary.com/Portfolio/TurnColorsGray.html


Another two more recent methods that look quite interesting to me. Again 
ordered by year of publication.


1. [2012] http://www.cs.northwestern.edu/~ago820/color2gray/ (has 
source, license is fine for any purpose)


2. [2008] 
http://www.inf.ufrgs.br/~oliveira/pubs_files/MS_C2G/MS_C2G_page.html



Probably, one would want more than one algorithm and then use instances 
and blending for best results. Much like the current Global Tonemap module.



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



Re: [darktable-dev] Anyone with 30-bit color depth?

2016-01-14 Thread Moritz Moeller

On 13/01/16 08:29, Roman Lebedev wrote:

Hello, lists.

darktable's support for 30-bit color depth was again brought up in IRC
channel yesterday.

As far as i'm aware, none of us developers has the hardware (videocard
that supports
30-bit output + 30-bit monitor), so we have no means to test and
develop needed changes.


Isn't Johannes working @ Weta? There should be hardware like this there 
and maybe he could ask nicely to do some tests/dev on it, "after hours". ;)


.mm

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



Re: [darktable-dev] Feature request: preserve luminosity option in channel mixer

2015-11-22 Thread Moritz Moeller

On 22/11/15 23:44, Caio S. Souza wrote:

I took a look at this module's source code and identified the pieces
that must be changed (including the opencl kernel). If you agree this
feature is a good idea, I may help implementing it. What do you think?


+1

.mm

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



Re: [darktable-dev] review

2015-09-10 Thread Moritz Moeller
On 10/09/15 14:15, iormail2...@openmailbox.org wrote:
> I was talking about extensive editing in GIMP/Photoshop after raw
> developing.

What would be great was a way to assign virtual copies of an image, each
using different development settings, to layers of a PSD or XCF file.
Then when I update a virtual copy, I would have an option to 'update'
instead of 'export' and it would update the resp. layer in the PSD/XCF
w/o touching any layer masks or layer order. Layers are identified
through metadata, so if I rename the virtual copy or the layer in
PS/Gimp (or change the ordering), the update can still work.

This would make the DT workflow between those apps 100% easier.

.mm

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