Re: [darktable-dev] Only write xmp file on export

2021-02-21 Thread Bertwim

Hi Greg,

Thanks for responding and thanks for sharing your workflow. I'll need to 
study it in a bit more detail, to see if it will work for me.


So far, I have always considered the triplet of files (raw + the 
corresponding jpg  (possibly with edits, but fullsize!) + associated 
xmp, if available) as the files I want to store and keep together. They 
form a consistent set.  I know there is a redundancy here, but I do not 
really care.  I find it a comforting thought to always have a fullsize 
nice jpg at hand, although I know that when I have DT available, I can 
regenerate a new jpg from the raw+xmp. My automatic workflow does 
include that case using the command line version of DT, but this takes 
additional time. I find the easy availability is worth the extra cost of 
disk space, but of course this is a personal choice.


Further processing of the images to make the "edited originals" , i.e. 
the fullsize jpgs fit for a specific purpose (local album, webalbum, 
screen, thumbnails, ...)  (e.g.. reduction in size (due to both 
different geometry as well as jpg-compression reduction, or exif data 
extraction) is all done outside DT, automatically, in a series of 
operations running in the background on my linux machine. I found this 
far more powerful than using DT for that.


Kind regards
Bertwim

On 2/20/21 11:32 PM, Andrew Greig wrote:


Hi Bertwim,

Before I moved to Darktable from Corel AftershotPro 3, I was shooting 
RAW + jpg. And I stored my image files separately, thus


20210221-modelname

20210221-modelname-RAW; 20210221-modelname-jpg; 
20210221-modelname-exported


20210221-modelname-exported has  3 children

  20210221-modelname-exported-Fullsizejpg

  20210221-modelname-exported-Proofs  (2000pxx2000px at 93%) 
(watermarked)


  20210221-modelname-exported-Instagram (1599px x 1500px 
(watermarked and framed)


My in-camera jpgs are large because their only purpose is to live 
until I have edited my RAW images and successfully exported them to my 
RAID drive. And then I discard them. Because of the work I do I edit 
every image. By keeping my camera jpgs separate from the RAW files 
they do not have .xmp files.


I am fortunate that a Linux Sys Admin friend of mine has set up my 
Folder Heirarchy to populate under the parent, automatically, so all I 
have to do is copy my RAW files to their folder, copy the jpg files to 
their folder, return the memory card to the camera and immediately 
format it. So the folder from which I import to DT is my RAW files folder.


It may seem long winded, but the automated tasks speed things up 
considerably.


Of course the DT film rolls get really messed up because I work on my 
files from an SSD, and then I store the output on a RAID 1 array. I 
rarely revisit my work. From watching Bruce Williams videos on 
Understanding Darktable I believe that my files could be better 
handled, but I have no need to find "Megan, red dress, overcast day, 
park". Maybe I /should/ tag.


I hope this may give you an alternative approach.

Andrew Greig


On 20/2/21 11:40 pm, Bertwim wrote:

I do not import jpgs. Only raws.

On 2/20/21 12:48 PM, Bernhard wrote:



Bertwim schrieb am 20.02.21 um 12:35:
Such a default .xmp is misleading: if one would create a jpg-image 
using the info from such a default generated xmp, this generated 
'default jpg"  is (very) different from the camera generated one. 
Which is understandable, as the camera has its built-in knowledge 
how to create the jpg, which is not necessarily the same as the 
default actions DT would do. 

This is also not correct.
An imported jpg never gets any "treatment" within darktable - no 
demosaiking, no base curve, no sharpening, nothing.
So the export is simply the imported jpg compressed a second time - 
which of course is deteriorating the overall quality if set too low.




___ 


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] Only write xmp file on export

2021-02-21 Thread Bertwim

Andrew,

Apologies. I called you "Greg" in my reply.
This was not very thoughtful.

Regards
Bertwim


On 2/20/21 11:32 PM, Andrew Greig wrote:


Hi Bertwim,

Before I moved to Darktable from Corel AftershotPro 3, I was shooting 
RAW + jpg. And I stored my image files separately, thus


20210221-modelname

20210221-modelname-RAW; 20210221-modelname-jpg; 
20210221-modelname-exported


20210221-modelname-exported has  3 children

  20210221-modelname-exported-Fullsizejpg

  20210221-modelname-exported-Proofs  (2000pxx2000px at 93%) 
(watermarked)


  20210221-modelname-exported-Instagram (1599px x 1500px 
(watermarked and framed)


My in-camera jpgs are large because their only purpose is to live 
until I have edited my RAW images and successfully exported them to my 
RAID drive. And then I discard them. Because of the work I do I edit 
every image. By keeping my camera jpgs separate from the RAW files 
they do not have .xmp files.


I am fortunate that a Linux Sys Admin friend of mine has set up my 
Folder Heirarchy to populate under the parent, automatically, so all I 
have to do is copy my RAW files to their folder, copy the jpg files to 
their folder, return the memory card to the camera and immediately 
format it. So the folder from which I import to DT is my RAW files folder.


It may seem long winded, but the automated tasks speed things up 
considerably.


Of course the DT film rolls get really messed up because I work on my 
files from an SSD, and then I store the output on a RAID 1 array. I 
rarely revisit my work. From watching Bruce Williams videos on 
Understanding Darktable I believe that my files could be better 
handled, but I have no need to find "Megan, red dress, overcast day, 
park". Maybe I /should/ tag.


I hope this may give you an alternative approach.

Andrew Greig


On 20/2/21 11:40 pm, Bertwim wrote:

I do not import jpgs. Only raws.

On 2/20/21 12:48 PM, Bernhard wrote:



Bertwim schrieb am 20.02.21 um 12:35:
Such a default .xmp is misleading: if one would create a jpg-image 
using the info from such a default generated xmp, this generated 
'default jpg"  is (very) different from the camera generated one. 
Which is understandable, as the camera has its built-in knowledge 
how to create the jpg, which is not necessarily the same as the 
default actions DT would do. 

This is also not correct.
An imported jpg never gets any "treatment" within darktable - no 
demosaiking, no base curve, no sharpening, nothing.
So the export is simply the imported jpg compressed a second time - 
which of course is deteriorating the overall quality if set too low.




___ 


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] Review: Translating the new darktable documentation

2021-02-21 Thread Mica Semrick

Hi all,

I've made a pull request that will integrate the necessary scripts to 
enable translation for the new markdown-based documentation.


Please provide any feedback you may have by reviewing the PR: 
https://github.com/darktable-org/dtdocs/pull/221


Due to the nature of translation, it will not be trivial to change the 
process after this. Please make your comments heard now by leaving 
comments on the PR.


Thanks!

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



Re: [darktable-dev] Darktable 3.4.1 - darkroom histogram disappears

2021-02-21 Thread Matteo Mardegan
In data sabato 20 febbraio 2021 21:36:22 CET, Matteo Mardegan ha scritto:
> OS: Debian testing bullseye
> Kernel: x86_64 Linux 5.8.0-3-amd64
> DE: KDE 5.78.0 / Plasma 5.20.5
> 
> After the update to Darktable 3.4.1 (from repository), there is a little
> issue. When I open an image in darkroom I don't see the histogram.
> I resolve opening the preferences, general tab and de-selecting "modify the
> selected them with CSS tweaks below". After that the theme changes and the
> histogram appears in the background darkroom window.
> Everyting is alright until the next restart.
> Bye, thank you.

Maybe it is usefull for someone else. 
I deleted this file user.css in /home/user/.config/darktable/
Now the issue is definitively resolved.



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