Re: [darktable-user] SDXC Card not detected

[Robert Bieber]

I think it's just an easier way to provide a universal-ish (to the 
extent that libgphoto will recognize your card) mechanism to import 
photos without having to deal with file management



On 05/07/2018 05:57 PM, junkyardspar...@yepmail.net wrote:


On Mon, May 7, 2018, at 17:12, Patrick Shanahan wrote:

* junkyardspar...@yepmail.net  [05-07-18 19:13]:


On Mon, May 7, 2018, at 15:46, Patrick Shanahan wrote:

* junkyardspar...@yepmail.net  [05-07-18 18:05]:

On Mon, May 7, 2018, at 14:12, Patrick Shanahan wrote:


yes, afaik dt uses the systems disk access.  I believe dt uses gphoto2 to
access the camera and the camera contained card(s).

I'm just curious: is this still needed for file access on anything but very old 
cameras? I've always used Olympus cameras that supported USB storage from the 
early days, so I never developed the habit of using any special software for 
this... and haven't really kept track of how the situation has evolved over the 
years.

I understand that the library is still needed for things like tethering, etc.

google and read about gphoto2, http://www.gphoto.org/

Yeah, I'm familiar with the project, I was just hoping for insights, from the 
perspective of developing RAW development software, about how currently 
relevant it is 20 years later *for simple retrieval of files*. I find very 
little discussion about recent cameras not supporting USB storage, whereas 
exFAT currently *does* present some obstacles. In light of that, it seems 
possible that only using gphoto as a fallback when needed might make sense.

can you access the card storage on your camera using your perferred file
management software on your system w/o added software?

might answer your question.

As mentioned above, I've always been able to, with my Olympus cameras, going 
back to at least the turn of the century. :)

I understand that this hasn't been the the case for other brands in the past. I 
was hoping others on the list, who have long term experience with those, might 
have perspective on how much this has or hasn't changed over the years. If not, 
please ignore.




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] SDXC Card not detected

[Robert Bieber]

A friend of mine had this problem recently, I believe the issue was that 
gphoto doesn't recognize SDXC cards, something to do with needing to use 
FUSE.  I could have sworn they got a fix landed for that, but I don't 
know how long it'll take to make it into a release of gphoto and then 
from there to a release of DT



On 05/02/2018 04:26 PM, Abhijit Kshirsagar wrote:

Hello all!

Recently I got a new memory card (SanDisk 64GB U3/V30), and formatted 
it using the camera (Sony A6000). In order to get Ubuntu 16.04 to 
recognize it, I had to install exfat-utils and exfat-fuse packages 
using the default repositories.


Now nautilus is able to recognise and auto-mount the card when 
inserted, but darktable does not see the card; and neither does shotwell
(both Shotwell and darktable work with older, slower cards I have; 
16GB U1/Class 10 or slower)


In disk utility, i can see that the camera has formatted it as an 
exfat partition with a little unused space at the beginning - I'm not 
sure if/why this should cause any issued.


Also, the card is mounted in the usual location 
(/media/username/CardName/); and verified that df shows it correctly 
as well.


Is anyone else having this issue?

Thanks!


 
darktable user mailing list to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Highlight Details

[Robert Bieber]

Don't quote me on this, but since the pixel values are all floats I'm 
pretty sure it's possible for one module to push them beyond the 
"maximum" values and another one to bring them back in with the detail 
still there, as long as everything ends up within the allowable bounds 
by the time it gets converted to int



On 04/08/2018 07:11 PM, Guillermo Rozas wrote:

Can you provide the original DNG so people can play with it?

One think you should take into account is that modules in Darktable 
are applied in a certain order (bottom to top on darkroom). In 
particular, "Exposure" and "Base Curve" come before "Shadows and 
highlights". So, if Exposure pushes the info of the sky past the white 
point, you can not get it back later (at least that's how I understand 
it). Going by the histogram, it looks like this is what happening to 
your picture (there are a lot of pixels close to the right edge): the 
info was there before the exposure (and base curve) modules, but not 
by time you get to the shadows and highlights module.


Two tips I can give you:
- check the RAW over-exposure indicator (small colors icon below and 
to the right of the picture in darkroom). If the area is really 
non-recoverable it will show as over exposed in RAW. If not, there is 
a way to recover it (not always easy, but the info is there)
- my first step when editing complex pictures is to use the exposure 
and black sliders on the Exposure module to fit the data exactly 
inside the histogram (using the normal under/over exposure indicator). 
Then I know I'm working with almost all the info the file have.


Best regards,
Guillermo

On Sun, Apr 8, 2018 at 7:04 PM, Peter Cripps > wrote:


I've seen similar results to Chris. One of the (few) things that
I've found Lightroom does better than darktable is highlight
recovery.

I have noticed that the darktable histogram doesn't seem to show
content at the far right hand side that does show in the Lightroom
histogram. Don't know if this is relevant.

I hesitate to mention this, since I'm very conscious of the fact
that darktable is entirely created by people working on their own
time. It seems ungrateful to pick out one thing that isn't perhaps
as good as with other paid programs.

Peter




On 04/08/2018 02:51 PM, Chris wrote:


Hi,

So the shadows & highlights module also does not seem to full
'reveal' the detail in the clouds that I know exists... it simply
darkens the existing pixels that we can already see. So not
really 'recovering detail' as such.

https://www.dropbox.com/s/u3lo4oy9dokdbwh/darkt_04.jpg?dl=0


and pushed further

https://www.dropbox.com/s/zih4f434frcxizu/darkt_05.jpg?dl=0


obviously I am going to extremes here... but they still just do
not compare to the clarity revealed from LR.

https://www.dropbox.com/s/suw9v3jnsszbsec/lr_02.jpg?dl=0


Thanks,

Chris


On 2018/04/08 02:30 PM, Pascal Obry wrote:

Le dimanche 08 avril 2018 à 14:25 -0700, Chris a écrit :

Anyway, these are my adventures into highlights in DarkTable.

You haven't activate the "shadows & highlight" module, so indeed
nothing done for darktable :)
  




darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org





darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org




 
darktable user mailing list to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] development question

[Robert Bieber]

Interesting, could you link me to that old discussion, by any chance?  
Or do you remember the email title?  I've heard recently that Lightroom 
has some really useful dual-window functionality as well that works 
quite a bit differently from the detachable panels I was working on, so 
I've been meaning to look into how they do it as well.


-Robby


On 03/18/2018 08:47 AM, Tobias Ellinghaus wrote:

Am Samstag, 17. März 2018, 22:12:29 CET schrieb Robert Bieber:

I don't think dual-monitor setups are that uncommon among people doing
serious image editing.  I honestly wouldn't mind trying to pick the
detachable panels thing back up next time I have a little free time,
because it would be a pretty cool thing for multiple screens, but I'm
not sure if the rest of the regular devs would be okay with having to
support the added complexity I'd be merging in.

I don't think that your code from back then was heading in the right
direction. We had some discussions about how to add a 2nd screen mode a short
while ago (I can't find where it took place, maybe mailing list, maybe IRC,
maybe a bug report) and the conclusion was that we would want a 2nd window
that is independently color managed and fed by a new independent darkroom pipe
that can be zoomed and panned independently.

If you feel like working on that we would all be more than happy. :-)

Tobias

[...]



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] development question

[Robert Bieber]

I don't think dual-monitor setups are that uncommon among people doing 
serious image editing.  I honestly wouldn't mind trying to pick the 
detachable panels thing back up next time I have a little free time, 
because it would be a pretty cool thing for multiple screens, but I'm 
not sure if the rest of the regular devs would be okay with having to 
support the added complexity I'd be merging in.



On 03/17/2018 01:27 PM, Maurizio Paglia wrote:
Yes, you are right! I meant multiple windows software are suitable for 
particular situation normal users usually do not have. For this reason 
people are not so interested


Il sab 17 mar 2018, 19:02 Robert Krawitz <r...@alum.mit.edu 
<mailto:r...@alum.mit.edu>> ha scritto:


On Sat, 17 Mar 2018 17:36:50 +, Maurizio Paglia wrote:
> I think software with this feature could be interesting on a two
monitors
> system, but I think only a few users have such configuration at
home...

What about 21:9 monitors -- those are easily wide enough.  Or people
with laptops and external displays (at least if they're calibrated or
at lesat reasonably close)?

> Il sab 17 mar 2018, 18:30 Robert Bieber <d...@biebersprojects.com
<mailto:d...@biebersprojects.com>> ha scritto:
>
>> I actually made a prototype of this back in 2011, what's left
of it is
>> in the "detachable" branch in the git repo.  It's been a
loonng time
>> since it's had master merged into it though, it would probably be a
>> nightmare to try to merge, if you even could. I was really keen
on the
>> idea, but it didn't seem to garner a lot of interest
>>
>>
>> On 03/15/2018 02:56 PM, Fran=C3=A7ois Patte wrote:
>> > Bonjour,
>> >
>> > Is a version of darktable with a separate window for the
photo (as it is
>> > the case for gimp for instance) wil come some day? And when?
>> >
>> > Thank you. Maybe, I have too much curiosity
>> >
>> > Best regards.
--
Robert Krawitz                                   
 <r...@alum.mit.edu <mailto:r...@alum.mit.edu>>

***  MIT Engineers   A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom  -- http://ProgFree.org
Project lead for Gutenprint   -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton





darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] development question

[Robert Bieber]

I actually made a prototype of this back in 2011, what's left of it is 
in the "detachable" branch in the git repo.  It's been a loonng time 
since it's had master merged into it though, it would probably be a 
nightmare to try to merge, if you even could. I was really keen on the 
idea, but it didn't seem to garner a lot of interest



On 03/15/2018 02:56 PM, François Patte wrote:

Bonjour,

Is a version of darktable with a separate window for the photo (as it is
the case for gimp for instance) wil come some day? And when?

Thank you. Maybe, I have too much curiosity

Best regards.




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Anyone know where to find a cie/it8 file for the Color Checker Passport?

[Robert Bieber]

That did it, thanks!


On 02/28/2018 02:53 AM, Tobias Ellinghaus wrote:

Am Mittwoch, 28. Februar 2018, 11:12:57 CET schrieb Tobias Ellinghaus:

Am Mittwoch, 28. Februar 2018, 04:46:26 CET schrieb Robert Bieber:

I'm curious if anyone's had any luck building a profile with dt-chart
using a cie/it8 file for the second step in the process. I've gotten it
to work successfully by using the chart file that ships with Argyll, but
if I try to use the corresponding cie file for the next step, I get an
error message "error with the IT8 file, can't find the SAMPLE_ID column."

I'm guessing that even though the option says cie/it8 file, maybe only
it8 files are well supported?  Or maybe the one that Argyll ships with
is just malformed.  Does anyone have an idea where I might find a usable
it8 file for the ColorChecker passport?  This seems like something that
should be prominently published by the manufacturer, but the only place
I was able to find cht and cie files at all was in the Argyll distribution

The file ColorCheckerPassport.cie as shipped by Argyll uses "SAMPLE_LOC"
instead of "SAMPLE_ID" to refer to the colors. Just changing the line

SAMPLE_LOC XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB_B

to

SAMPLE_ID XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB_B

made it work for me. At least darktable-chart no longer complained. That
being said, the Lab values dt-chart computes from the XYZ reference numbers
look off to me. I'll have a look.

I had a look. It seems that lcms2 fails to properly parse float numbers when
the current locale uses anything else than '.' as the decimal separator. So
please make sure to run dt-chart with LANG=C. :-(


Thanks,
Robby

Tobias



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] Anyone know where to find a cie/it8 file for the Color Checker Passport?

[Robert Bieber]

I'm curious if anyone's had any luck building a profile with dt-chart 
using a cie/it8 file for the second step in the process. I've gotten it 
to work successfully by using the chart file that ships with Argyll, but 
if I try to use the corresponding cie file for the next step, I get an 
error message "error with the IT8 file, can't find the SAMPLE_ID column."


I'm guessing that even though the option says cie/it8 file, maybe only 
it8 files are well supported?  Or maybe the one that Argyll ships with 
is just malformed.  Does anyone have an idea where I might find a usable 
it8 file for the ColorChecker passport?  This seems like something that 
should be prominently published by the manufacturer, but the only place 
I was able to find cht and cie files at all was in the Argyll distribution


Thanks,
Robby


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Generating Base Curve vs Using darktable-chart

[Robert Bieber]

Interesting, thanks for the details!


On 02/18/2018 04:15 AM, johannes hanika wrote:

hi robert,

glad to hear it worked in the end :)

the base- vs tonecurve thing is a philosophical question to some
extent. the main difference is the position in the pipeline: a base
curve makes everything non-linear at a quite early point in the
pipeline. this can be desirable, for instance to compress hdr via
exposure fusion and then work on that with the other tools.

for linear workflows, the tonecurve may be the better choice as it
comes later in the pipeline. when working on shadows/highlights/local
contrast with the "local contrast" module for instance i get much
improved rendition with the tonecurve.

the other big difference is that tonecurve is Lab and basecurve is
camera rgb. with the "auto in RGB" colour adjustment option in the
tone curve, you have pretty much an rgb curve here, too. for the
colour lut to be somewhat portable in theory (and mostly for less
saturated colours where the matrix profiles kind of work best..), the
lut module was implemented in device-independent Lab colour space.
that way you could profile the fuji film emulation styles once and
then apply to your canon or nikon cameras. this only holds when you
profile against pfm which have the matrix profile (from the input
colour profile module) baked in, and of course only within the limits
of matrix profiles.

my guess would be that even if you use an it8 chart, the colour-lut
tone curve would be a bit more approximate than the one you get with
the dedicated curve module? just because there is a limited number of
grey patches in the chart.

hope that helps,
  jo

On Sat, Feb 17, 2018 at 10:43 PM, Robert Bieber <d...@biebersprojects.com> 
wrote:

Today I finally got some free time to try shooting some calibration photos
with my new camera, and I did two things.  Well, three, kind of.

1.First I tried to use the darktable-chart tool to build a full color
correction profile, but this didn't work and I couldn't figure out why,
so...

2. I used the base curve tool with some test chart images and a photo of a
white wall + grid spotted light + some black posterboard and actually came
away with a pretty good base curve that got me a lot closer to what I saw in
the back of my camera (and with the manufacturer's RAW processor if I tried
that) than any of the built-in profiles had done (and rightly so, it looks a
lot different from any of them).

3. I finally realized my mistake from step 1, which is that I'd tried just
using imagick to convert a reference jpeg to pfm, when I needed to import it
to DT so I could export it in Lab colorspace.  Once that was done I managed
to generate a complete style from a color checker shot.

The generated style with its settings for the color LUT module has
drastically improved the color rendering for RAW files from this camera.
What I'm curious about is that the generated style applies a very similar
curve to the base curve that I generated in step 2, but it applies it as a
tone curve and turns the base curve off.

Does anyone know why it does this?  I thought you generally wanted to apply
a base curve that more or less matched the one the manufacturer uses, as a
starting point, but when we generate these styles we're not using one at
all.  I noticed that if I tried turning off the tone curve and applying the
base curve that I generated it seems to make the color LUT do some weird
things, so I'm guessing that has something to do with it?


darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] Generating Base Curve vs Using darktable-chart

[Robert Bieber]

Today I finally got some free time to try shooting some calibration 
photos with my new camera, and I did two things.  Well, three, kind of.


1.First I tried to use the darktable-chart tool to build a full color 
correction profile, but this didn't work and I couldn't figure out why, 
so...


2. I used the base curve tool with some test chart images and a photo of 
a white wall + grid spotted light + some black posterboard and actually 
came away with a pretty good base curve that got me a lot closer to what 
I saw in the back of my camera (and with the manufacturer's RAW 
processor if I tried that) than any of the built-in profiles had done 
(and rightly so, it looks a lot different from any of them).


3. I finally realized my mistake from step 1, which is that I'd tried 
just using imagick to convert a reference jpeg to pfm, when I needed to 
import it to DT so I could export it in Lab colorspace. Once that was 
done I managed to generate a complete style from a color checker shot.


The generated style with its settings for the color LUT module has 
/drastically/ improved the color rendering for RAW files from this 
camera. What I'm curious about is that the generated style applies a 
very similar curve to the base curve that I generated in step 2, but it 
applies it as a tone curve and turns the base curve off.


Does anyone know why it does this?  I thought you generally wanted to 
apply a base curve that more or less matched the one the manufacturer 
uses, as a starting point, but when we generate these styles we're not 
using one at all.  I noticed that if I tried turning off the tone curve 
and applying the base curve that I generated it seems to make the color 
LUT do some weird things, so I'm guessing that has something to do with it?



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] how do I

[Robert Bieber]

If you shot these on a tripod, you can select them both in the light 
table view and click the HDR button.  If it's handheld, I don't think 
Darktable can really do that level of compositing. You'll need to 
manually align them in Gimp or something similar and mask the sky 
appropriately



On 02/11/2018 06:46 PM, Michael wrote:

What steps should I take to put the underexposed sky on the other picture?

--
:-)~MIKE~(-:

 
darktable user mailing list to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] CPU Recommendations

[Robert Bieber]

Interesting, thanks for the rundown.  I don't really like the idea of 
proprietary graphics drivers, but it seems like Nvidia is still my best 
bet.  Hopefully someday the free AMD drivers will be up to par and I can 
switch back to them.


...now I just have to go see if I can get my hands on a decent Nvidia 
card without the bitcoin miners snapping them all up :p



On 02/04/2018 03:19 PM, Guillermo Rozas wrote:

If the operating system and window manager don't have compatibility
issues with the GPU, GPU processing in Darktable works like a charm
(and it's very useful, specially if you intend to hang onto that
computer for 5 years or more).

The caveats regarding Linux-GPU compatibility:
- if you want to use only open source drivers, you have to go to AMD
(NVidia's open source driver is much slower). The same applies if you
want to use Wayland. However, the open source drivers don't provide
OpenCL in a way that Darktable can use them, so you'll need to add
some libraries to get that working (look in Darktable's forum
archives).
- if you don't have problems with using proprietary drivers and X
Window System, I would recommend NVidia due to the longer and more
explicit commitment to provide (proprietary) driver support (important
for a long lifetime machine). Of course, this recommendation assumes
that NVidia will finally release a Wayland-compatible version of its
proprietary driver by the time all major distributions kill X for good
(not before 2023, when Ubuntu 18.04 support ends)

In any case, check Darktable's forum, the question about best GPU pops
every now and then.

Best regards,
Guillermo

On Sun, Feb 4, 2018 at 7:38 PM, Robert Bieber <d...@biebersprojects.com> wrote:

Oh yeah, I'm just talking about the price of the CPU, not the whole PC. I'm
planning on doing all out on RAM and solid state drives as well. I guess GPU
might be of some concern as well, how has GPU processing in dark table on
Linux been going lately? I know it exists, but I'm always scared of anything
to do with graphics drivers on Linux



On February 4, 2018 1:16:22 PM PST, "Šarūnas" <saru...@mail.saabnet.com>
wrote:

On 02/04/2018 02:41 PM, Robert Bieber wrote:

  Hi everyone,

  I think it's time to finally replace the computer I built five-ish years
  ago.  It was a good machine at the time, but since then my RAW files
  have gone from 8MP to 16MP and now to 40, and running more expensive
  iops, especially with masks and so on, is getting to be pretty sluggish.

  I haven't really kept up with PC hardware in the meantime, so I'm
  curious what y'all would recommend for CPUs.  How much is a decent
  amount to spend for something high-end in the US market?  I'm guessing
  that dropping a grand on something/really/ high end is probably
  unnecessary, but maybe I'm wrong.


It may depend on where on Earth, but “grand” as in ~1000USD, will only
get you half-way, at best, to a high end PC...

You may want to check AMD Ryzen 5/7 + some higher-end GPUs, NVMe solid
state storage, healthy amounts of RAM.

--
Šarūnas Burdulis
math.dartmouth.edu/~sarunas



darktable user mailing list to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] CPU Recommendations

[Robert Bieber]

Oh yeah, I'm just talking about the price of the CPU, not the whole PC. I'm 
planning on doing all out on RAM and solid state drives as well. I guess GPU 
might be of some concern as well, how has GPU processing in dark table on Linux 
been going lately? I know it exists, but I'm always scared of anything to do 
with graphics drivers on Linux


On February 4, 2018 1:16:22 PM PST, "Šarūnas" <saru...@mail.saabnet.com> wrote:
>On 02/04/2018 02:41 PM, Robert Bieber wrote:
>> Hi everyone,
>> 
>> I think it's time to finally replace the computer I built five-ish
>years
>> ago.  It was a good machine at the time, but since then my RAW files
>> have gone from 8MP to 16MP and now to 40, and running more expensive
>> iops, especially with masks and so on, is getting to be pretty
>sluggish.
>> 
>> I haven't really kept up with PC hardware in the meantime, so I'm
>> curious what y'all would recommend for CPUs.  How much is a decent
>> amount to spend for something high-end in the US market?  I'm
>guessing
>> that dropping a grand on something/really/ high end is probably
>> unnecessary, but maybe I'm wrong. 
>
>It may depend on where on Earth, but “grand” as in ~1000USD, will only
>get you half-way, at best, to a high end PC...
>
>You may want to check AMD Ryzen 5/7 + some higher-end GPUs, NVMe solid
>state storage, healthy amounts of RAM.
>
>-- 
>Šarūnas Burdulis
>math.dartmouth.edu/~sarunas


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] CPU Recommendations

[Robert Bieber]

Lol, what counts as high end for a desktop CPU?

On February 4, 2018 12:02:49 PM PST, Colin Adams <colinpaulad...@gmail.com> 
wrote:
>A grand wouldn't but anything high end.
>
>On Sun, 4 Feb 2018 at 19:42 Robert Bieber <d...@biebersprojects.com>
>wrote:
>
>> Hi everyone,
>>
>> I think it's time to finally replace the computer I built five-ish
>years
>> ago.  It was a good machine at the time, but since then my RAW files
>have
>> gone from 8MP to 16MP and now to 40, and running more expensive iops,
>> especially with masks and so on, is getting to be pretty sluggish.
>>
>> I haven't really kept up with PC hardware in the meantime, so I'm
>curious
>> what y'all would recommend for CPUs.  How much is a decent amount to
>spend
>> for something high-end in the US market?  I'm guessing that dropping
>a
>> grand on something* really* high end is probably unnecessary, but
>maybe
>> I'm wrong.  I'm also not sure how parallelized DT is in practice, and
>> whether I should be looking for more cores or faster clock speed.
>>
>>
>
>> darktable user mailing list to unsubscribe send a mail to
>> darktable-user+unsubscr...@lists.darktable.org
>>


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] CPU Recommendations

[Robert Bieber]

Hi everyone,

I think it's time to finally replace the computer I built five-ish years 
ago.  It was a good machine at the time, but since then my RAW files 
have gone from 8MP to 16MP and now to 40, and running more expensive 
iops, especially with masks and so on, is getting to be pretty sluggish.


I haven't really kept up with PC hardware in the meantime, so I'm 
curious what y'all would recommend for CPUs.  How much is a decent 
amount to spend for something high-end in the US market?  I'm guessing 
that dropping a grand on something/really/ high end is probably 
unnecessary, but maybe I'm wrong.  I'm also not sure how parallelized DT 
is in practice, and whether I should be looking for more cores or faster 
clock speed.




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] I Think I Misunderstand the Color LUT Module

[Robert Bieber]

I see, thanks.  I was under the impression that it was normal to do the full 
calibration once per scene/lighting setup, but looking around some more I guess 
it's typical just to generate a profile once for the camera and reuse it.  I'll 
go ahead and use the chart tool to generate one for mine :)

On January 25, 2018 12:41:08 AM PST, johannes hanika <hana...@gmail.com> wrote:
>hi robert,
>
>you can use the colour lut module to calibrate to a checker. you'd use
>the darktable-chart utility to create a style for you.
>
>there's some very short example about half way through this:
>
>https://www.darktable.org/2016/05/colour-manipulation-with-the-colour-checker-lut-module/
>
>and if you want a full lut, you may actually do it a bit differently
>(and leave away the white balance and camera matrix processing for the
>input?).
>
>let me know how you go with this, we might be able to help you with
>details (or fix workflow issues in the iop or the darktable-chart
>utility).
>
>cheers,
> jo
>
>
>On Thu, Jan 25, 2018 at 7:23 PM, Robert Bieber <d...@biebersprojects.com>
>wrote:
>> I've gotten my hands on a proper color checker recently, and I wanted
>to try
>> using it with the color look up table module to correct the colors in
>an
>> image.  If I'm understanding it correctly though, it seems like the
>module
>> is the opposite of what I need for this process?
>>
>> If I have it right, you can use the color picker to select colors
>from the
>> image to set as a source, but then you have to manually adjust them
>to get
>> the target color you want from that source. Shouldn't it be the other
>way
>> around, though?  Picking the actual colors captured in the image as
>the
>> source, and automatically setting the target value to be the known
>color of
>> the chart?
>>
>> Am I just fundamentally misunderstanding what this module is for? 
>And if so
>> is there some other one that could do what I'm looking for?
>>
>> Thanks,
>> Robby
>>
>>
>
>> darktable user mailing list
>> to unsubscribe send a mail to
>darktable-user+unsubscr...@lists.darktable.org
>>
>
>darktable user mailing list
>to unsubscribe send a mail to
>darktable-user+unsubscr...@lists.darktable.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] I Think I Misunderstand the Color LUT Module

[Robert Bieber]

I've gotten my hands on a proper color checker recently, and I wanted to 
try using it with the color look up table module to correct the colors 
in an image.  If I'm understanding it correctly though, it seems like 
the module is the opposite of what I need for this process?


If I have it right, you can use the color picker to select colors from 
the image to set as a source, but then you have to manually adjust them 
to get the target color you want from that source. Shouldn't it be the 
other way around, though?  Picking the actual colors captured in the 
image as the source, and automatically setting the target value to be 
the known color of the chart?


Am I just fundamentally misunderstanding what this module is for?  And 
if so is there some other one that could do what I'm looking for?


Thanks,
Robby


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

Okay, cool.  Realistically, do you think you or anyone else will want 
to/be able to get to it in the foreseeable future?  I know it's a pretty 
niche issue, so I'll understand if it's not exactly top of the list



On 11/27/2017 01:12 PM, Roman Lebedev wrote:

On Mon, Nov 27, 2017 at 9:00 PM, Robert Bieber <d...@biebersprojects.com> wrote:

Sorry, what you're looking for is a vertical seam in the center of the
image.  It cuts through the left side of the right bridge tower, and you can
see it everywhere the sky is visible.  Here's a rendering where I messed
with the base curve a little to hopefully make it more visible.

Ah, now i see it, good to know.


On 11/27/2017 12:52 PM, Roman Lebedev wrote:

On Mon, Nov 27, 2017 at 8:44 PM, Robert Bieber <d...@biebersprojects.com>
wrote:

Whoops, I forgot about git annex.  Let's try this again:
https://drive.google.com/open?id=14hjQuEqpvSEC2EDI0Fqv_Vo4qEr-Hnd8

Yep, that downloaded.
However i don't know what i need to look for, so i don't see anything.


I also skimmed through the dcraw source a bit, and I found a function
called
phase_one_correct, which I suspect addresses this issue.  I'm way out of
my
depth trying to interpret it, but I _think_ what it's doing is applying
some
correction factor(s) embedded in the file for the different separate
sections of the sensor.

Yep, sounds plausible.
"RobbieAB" in #darktable was looking into that, and had some success,
but i did not hear back from him for some time.

Roman.


On 11/27/2017 11:51 AM, Roman Lebedev wrote:

Hi.

On Mon, Nov 27, 2017 at 1:22 AM, Robert Bieber <d...@biebersprojects.com>
wrote:

I got my hands on a Leaf Credo 40 digital back a few weeks ago, and so
far
it's mostly worked stunningly with Darktable.  I have noticed, however,
that
in some images, particularly those with bright skies in the background,
I'm
getting a noticeable centerfold effect between the left and right half
of
the sensor. Here's an example of a RAW file and XMP file that produce
the
effect in both the build of Darktable I've been using
(2.3.0+455~g55904ce36)
as well as the current release version 2.2.5:
https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0

$ unzip centerfold_raw.zip
Archive:  centerfold_raw.zip
inflating: 0047_23_46.IIQ.xmp
  linking: 0047_23_46.IIQ  ->


../../../.git/annex/objects/03/Gw/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ
finishing deferred symbolic links:
0047_23_46.IIQ

Somehow i don't think that is what you wanted to upload.


At first I assumed this was just an artifact of the sensor and I'd
simply
have to avoid those situations, but I tried processing the same RAW
file
in
UFRaw and couldn't get the centerfold to appear, no matter what
contortions
I put the image through.  So I guess this is actually an artifact of
the
RAW
processing, presumably a difference between RawSpeed and DCRaw.

I'll defer from any speculations until i actually see the sample.


Does anyone have an idea what might be responsible for the difference,
and
if it's something that might be easily fixable in RawSpeed, or
alternatively
if there's some way I can force DT to use dcraw as a fallback for a
given
image instead of RawSpeed?

dcraw was never ever supported/integrated.
libraw fallback was disabled for quite some time and dropped some time
ago
too.
So nope. RawSpeed is the only raw loader.


Or maybe I'm just missing something and it's my
own image settings that are responsible for the seam showing up.

I also wanted to test the latest trunk build of DT to see if this had
been
fixed since then, but the latest version actually seems to be missing
support for the Credo 40 (trying to click through to darkroom mode on
one
of
my images got me the "Couldn't read white balance information" message
that
you always get with unsupported cameras).  If I get a chance in the
next
couple days I'll try to use git bisect to figure out which revision
broke
support for it.

On Mon, Nov 27, 2017 at 1:58 AM, Robert Bieber <d...@biebersprojects.com>
wrote:

I just uploaded a shot of a color chart a little while ago, not sure
how
long it'll take them to add it to the archive

Usually the time it takes me to notice the new upload, so between 10
minutes and a day :)
Validated, thanks!

On Mon, Nov 27, 2017 at 4:41 AM, Robert Bieber <d...@biebersprojects.com>
wrote:

Actually, scratch that, I somehow screwed up the first bisect.  I went
back
and took another crack at it and found that the offending revision is
actually c8d47ad9c466e6469f518f6826f18b1d9941c65e, which makes sense
because
it updates the Rawspeed version.  Then I went back and tested different
revisions in the RawSpeed repo with that same DT rev, and it looks like
the
revision that broke Credo 40 reading is
65cc3c5e0ccce9bc87c3e80703c7c55e8466c587.  I'm not sure ex

Re: [darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

Whoops, I forgot about git annex.  Let's try this again: 
https://drive.google.com/open?id=14hjQuEqpvSEC2EDI0Fqv_Vo4qEr-Hnd8


I also skimmed through the dcraw source a bit, and I found a function 
called phase_one_correct, which I suspect addresses this issue.  I'm way 
out of my depth trying to interpret it, but I _think_ what it's doing is 
applying some correction factor(s) embedded in the file for the 
different separate sections of the sensor.



On 11/27/2017 11:51 AM, Roman Lebedev wrote:

Hi.

On Mon, Nov 27, 2017 at 1:22 AM, Robert Bieber <d...@biebersprojects.com> wrote:

I got my hands on a Leaf Credo 40 digital back a few weeks ago, and so far
it's mostly worked stunningly with Darktable.  I have noticed, however, that
in some images, particularly those with bright skies in the background, I'm
getting a noticeable centerfold effect between the left and right half of
the sensor. Here's an example of a RAW file and XMP file that produce the
effect in both the build of Darktable I've been using (2.3.0+455~g55904ce36)
as well as the current release version 2.2.5:
https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0

$ unzip centerfold_raw.zip
Archive:  centerfold_raw.zip
  inflating: 0047_23_46.IIQ.xmp
linking: 0047_23_46.IIQ  ->
../../../.git/annex/objects/03/Gw/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ/SHA256E-s40513597--1ef92618cc8c9c90a6c82762be3e8c66023ee8013db9551b64760d41c53fc273.IIQ
finishing deferred symbolic links:
  0047_23_46.IIQ

Somehow i don't think that is what you wanted to upload.


At first I assumed this was just an artifact of the sensor and I'd simply
have to avoid those situations, but I tried processing the same RAW file in
UFRaw and couldn't get the centerfold to appear, no matter what contortions
I put the image through.  So I guess this is actually an artifact of the RAW
processing, presumably a difference between RawSpeed and DCRaw.

I'll defer from any speculations until i actually see the sample.


Does anyone have an idea what might be responsible for the difference, and
if it's something that might be easily fixable in RawSpeed, or alternatively
if there's some way I can force DT to use dcraw as a fallback for a given
image instead of RawSpeed?

dcraw was never ever supported/integrated.
libraw fallback was disabled for quite some time and dropped some time ago too.
So nope. RawSpeed is the only raw loader.


Or maybe I'm just missing something and it's my
own image settings that are responsible for the seam showing up.

I also wanted to test the latest trunk build of DT to see if this had been
fixed since then, but the latest version actually seems to be missing
support for the Credo 40 (trying to click through to darkroom mode on one of
my images got me the "Couldn't read white balance information" message that
you always get with unsupported cameras).  If I get a chance in the next
couple days I'll try to use git bisect to figure out which revision broke
support for it.

On Mon, Nov 27, 2017 at 1:58 AM, Robert Bieber <d...@biebersprojects.com> wrote:

I just uploaded a shot of a color chart a little while ago, not sure how
long it'll take them to add it to the archive

Usually the time it takes me to notice the new upload, so between 10
minutes and a day :)
Validated, thanks!

On Mon, Nov 27, 2017 at 4:41 AM, Robert Bieber <d...@biebersprojects.com> wrote:

Actually, scratch that, I somehow screwed up the first bisect.  I went back
and took another crack at it and found that the offending revision is
actually c8d47ad9c466e6469f518f6826f18b1d9941c65e, which makes sense because
it updates the Rawspeed version.  Then I went back and tested different
revisions in the RawSpeed repo with that same DT rev, and it looks like the
revision that broke Credo 40 reading is
65cc3c5e0ccce9bc87c3e80703c7c55e8466c587.  I'm not sure exactly how, because
all it seems to have done is split the IIQ decoder out into a separate
module, but the one before that is the last one that will read my RAW files.
I'll add a bug to the RawSpeed tracker for that one

Thanks. Should be fixed now.

This is why we have RPU :)
See https://discuss.pixls.us/t/raw-samples-wanted/5420?u=lebedevri

Roman.



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

Actually, scratch that, I somehow screwed up the first bisect.  I went 
back and took another crack at it and found that the offending revision 
is actually c8d47ad9c466e6469f518f6826f18b1d9941c65e, which makes sense 
because it updates the Rawspeed version.  Then I went back and tested 
different revisions in the RawSpeed repo with that same DT rev, and it 
looks like the revision that broke Credo 40 reading is 
65cc3c5e0ccce9bc87c3e80703c7c55e8466c587.  I'm not sure exactly how, 
because all it seems to have done is split the IIQ decoder out into a 
separate module, but the one before that is the last one that will read 
my RAW files.  I'll add a bug to the RawSpeed tracker for that one



On 11/26/2017 06:42 PM, Robert Bieber wrote:
On that second point, I went ahead and git bisected and it seems like 
the problem revision was ff4e77b0ad6e81ca1ced129b465d14730b5338fa.  As 
near as I can tell this has absolutely nothing to do with anything 
that should affect camera support, so I'm assuming that the actual 
problem is the revision of rawspeed that it uses, but I'm not really 
familiar enough with git submodules to be able to figure out which 
rawspeed revision that corresponds to.  Hopefully folks more familiar 
with the project can figure that out.



On 11/26/2017 05:22 PM, Robert Bieber wrote:
I got my hands on a Leaf Credo 40 digital back a few weeks ago, and 
so far it's mostly worked stunningly with Darktable.  I have noticed, 
however, that in some images, particularly those with bright skies in 
the background, I'm getting a noticeable centerfold effect between 
the left and right half of the sensor. Here's an example of a RAW 
file and XMP file that produce the effect in both the build of 
Darktable I've been using (2.3.0+455~g55904ce36) as well as the 
current release version 2.2.5: 
https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0


At first I assumed this was just an artifact of the sensor and I'd 
simply have to avoid those situations, but I tried processing the 
same RAW file in UFRaw and couldn't get the centerfold to appear, no 
matter what contortions I put the image through.  So I guess this is 
actually an artifact of the RAW processing, presumably a difference 
between RawSpeed and DCRaw.


Does anyone have an idea what might be responsible for the 
difference, and if it's something that might be easily fixable in 
RawSpeed, or alternatively if there's some way I can force DT to use 
dcraw as a fallback for a given image instead of RawSpeed?  Or maybe 
I'm just missing something and it's my own image settings that are 
responsible for the seam showing up.


I also wanted to test the latest trunk build of DT to see if this had 
been fixed since then, but the latest version actually seems to be 
missing support for the Credo 40 (trying to click through to darkroom 
mode on one of my images got me the "Couldn't read white balance 
information" message that you always get with unsupported cameras).  
If I get a chance in the next couple days I'll try to use git bisect 
to figure out which revision broke support for it.


 


darktable user mailing list
to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org




 


darktable user mailing list
to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org





darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

On that second point, I went ahead and git bisected and it seems like 
the problem revision was ff4e77b0ad6e81ca1ced129b465d14730b5338fa.  As 
near as I can tell this has absolutely nothing to do with anything that 
should affect camera support, so I'm assuming that the actual problem is 
the revision of rawspeed that it uses, but I'm not really familiar 
enough with git submodules to be able to figure out which rawspeed 
revision that corresponds to.  Hopefully folks more familiar with the 
project can figure that out.



On 11/26/2017 05:22 PM, Robert Bieber wrote:
I got my hands on a Leaf Credo 40 digital back a few weeks ago, and so 
far it's mostly worked stunningly with Darktable.  I have noticed, 
however, that in some images, particularly those with bright skies in 
the background, I'm getting a noticeable centerfold effect between the 
left and right half of the sensor. Here's an example of a RAW file and 
XMP file that produce the effect in both the build of Darktable I've 
been using (2.3.0+455~g55904ce36) as well as the current release 
version 2.2.5: 
https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0


At first I assumed this was just an artifact of the sensor and I'd 
simply have to avoid those situations, but I tried processing the same 
RAW file in UFRaw and couldn't get the centerfold to appear, no matter 
what contortions I put the image through.  So I guess this is actually 
an artifact of the RAW processing, presumably a difference between 
RawSpeed and DCRaw.


Does anyone have an idea what might be responsible for the difference, 
and if it's something that might be easily fixable in RawSpeed, or 
alternatively if there's some way I can force DT to use dcraw as a 
fallback for a given image instead of RawSpeed?  Or maybe I'm just 
missing something and it's my own image settings that are responsible 
for the seam showing up.


I also wanted to test the latest trunk build of DT to see if this had 
been fixed since then, but the latest version actually seems to be 
missing support for the Credo 40 (trying to click through to darkroom 
mode on one of my images got me the "Couldn't read white balance 
information" message that you always get with unsupported cameras).  
If I get a chance in the next couple days I'll try to use git bisect 
to figure out which revision broke support for it.


 


darktable user mailing list
to unsubscribe send a mail to 
darktable-user+unsubscr...@lists.darktable.org





darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

I just uploaded a shot of a color chart a little while ago, not sure how 
long it'll take them to add it to the archive



On 11/26/2017 05:29 PM, Patrick Rudin wrote:

Robert Bieber wrote:

I got my hands on a Leaf Credo 40 digital back a
few weeks ago, and so far it's mostly worked
stunningly with Darktable.

Could you please upload a RAW file tu raw.pixls.us?

regards

Patrick

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

[darktable-user] Centerfolding on Credo 40 Back, Plus Missing Support in Latest Build

[Robert Bieber]

I got my hands on a Leaf Credo 40 digital back a few weeks ago, and so 
far it's mostly worked stunningly with Darktable.  I have noticed, 
however, that in some images, particularly those with bright skies in 
the background, I'm getting a noticeable centerfold effect between the 
left and right half of the sensor. Here's an example of a RAW file and 
XMP file that produce the effect in both the build of Darktable I've 
been using (2.3.0+455~g55904ce36) as well as the current release version 
2.2.5: https://drive.google.com/open?id=1LfP5rGfFkBBPuolZ1NzivgnbhUNX0RI0


At first I assumed this was just an artifact of the sensor and I'd 
simply have to avoid those situations, but I tried processing the same 
RAW file in UFRaw and couldn't get the centerfold to appear, no matter 
what contortions I put the image through.  So I guess this is actually 
an artifact of the RAW processing, presumably a difference between 
RawSpeed and DCRaw.


Does anyone have an idea what might be responsible for the difference, 
and if it's something that might be easily fixable in RawSpeed, or 
alternatively if there's some way I can force DT to use dcraw as a 
fallback for a given image instead of RawSpeed?  Or maybe I'm just 
missing something and it's my own image settings that are responsible 
for the seam showing up.


I also wanted to test the latest trunk build of DT to see if this had 
been fixed since then, but the latest version actually seems to be 
missing support for the Credo 40 (trying to click through to darkroom 
mode on one of my images got me the "Couldn't read white balance 
information" message that you always get with unsupported cameras).  If 
I get a chance in the next couple days I'll try to use git bisect to 
figure out which revision broke support for it.



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org