Processing RAW images to get to the look of the jpg preview

[S. Burmeister]

Hey everybody!

I have a Panasonic LX3 and shoot RAW pictures. Compared to the jpg preview the
RAWs are always darker, no matter whether I pick 8 or 16bit for demosaicing.

I do see that "dark" has the advantage of showing more details (e.g. on the
pink flower bits), especially in bright areas but I would like to be able to
get to almost the same picture from the RAW as the jpg preview shows.

So I'd like to know what others do for processing their RAW pictures and
whether the darker is better or inevitable in your opinion or whether I'm
doing something wrong.

I have added a few pictures to a flickr album. The jpg is the embedded preview
and the -raw is the demosaiced RAW picture with no post-processing but only
resized. http://www.flickr.com/photos/34017986@N05/sets/72157626996362812/

For me enhance > local contrast works quite well to get closer to the preview
but has side effects, especially for highlights. Using other methods than
"solid white" while demosaicing makes the picture even darker. So e.g. getting
the wall of the building as bright as in the preview makes the clouds look bad
because they do not blend. Also very good visible in the DSC_xyz crops. The
jpg is brighter but does still blend the highlights better than if I take the
-raw and apply local contrast or any other tool to get the picture brighter.

Also, colours > levels adjust or auto-correction (auto-exposure) do work
towards the preview but don't get there. Especially the sky does not get that
bright blue from the preview.

I also tried white-balance (sun) but that makes the picture a bit too blue.

Colours > Hue/Saturation/Lightness also helps regarding vibrance and
saturation.

So what do you do with your pictures? Do you also see that "always darker"?

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

on Sunday 19 June 2011, Sven Burmeister wrote:
> Hey everybody!
>
> I have a Panasonic LX3 and shoot RAW pictures. Compared to the jpg preview
the
> RAWs are always darker, no matter whether I pick 8 or 16bit for demosaicing.
>
> I do see that "dark" has the advantage of showing more details (e.g. on the
> pink flower bits), especially in bright areas but I would like to be able to
> get to almost the same picture from the RAW as the jpg preview shows.
>
> So I'd like to know what others do for processing their RAW pictures and
> whether the darker is better or inevitable in your opinion or whether I'm
> doing something wrong.

Usually I need to adjust levels and saturation, sharpen, and use an S-shaped
curve adjust. Also, gamma has to be adjusted to 2.2 (esp. when using blend or
unclip, not sure about 'solid white'). Those steps are all applied 'in-camera'
when you shoot in jpeg, and for the jpeg preview embedded in the RAW.

The gamma and saturation can be adjusted in the RAW developer, the others I
prefer doing afterwards.

Note that you should use the white balance from the camera to get the same
result as the embedded preview (in first approximation), as that is the one
used to generate the preview you try to imitate.

I usually don't aim to imitate the camera JPEG (for that I'd better shoot
RAW+JPEG or just JPEG ;) ).

As to the 'why' of the darker RAW images, have a look at the Dcraw website
http://www.cybercom.net/~dcoffin/dcraw/

regards,

Remco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Sonntag, 19. Juni 2011 schrieb Sven Burmeister:

> Hey everybody!
>
> I have a Panasonic LX3 and shoot RAW pictures. Compared to the jpg
> preview the RAWs are always darker, no matter whether I pick 8 or
> 16bit for demosaicing.
>
> I do see that "dark" has the advantage of showing more details
> (e.g. on the pink flower bits), especially in bright areas but I
> would like to be able to get to almost the same picture from the
> RAW as the jpg preview shows.
>
> So I'd like to know what others do for processing their RAW
> pictures and whether the darker is better or inevitable in your
> opinion or whether I'm doing something wrong.
>
> I have added a few pictures to a flickr album. The jpg is the
> embedded preview and the -raw is the demosaiced RAW picture with
> no post-processing but only resized.
> http://www.flickr.com/photos/34017986@N05/sets/72157626996362812/
>
> For me enhance > local contrast works quite well to get closer to
> the preview but has side effects, especially for highlights. Using
> other methods than "solid white" while demosaicing makes the
> picture even darker. So e.g. getting the wall of the building as
> bright as in the preview makes the clouds look bad because they do
> not blend. Also very good visible in the DSC_xyz crops. The jpg is
> brighter but does still blend the highlights better than if I take
> the -raw and apply local contrast or any other tool to get the
> picture brighter.
>
> Also, colours > levels adjust or auto-correction (auto-exposure) do
> work towards the preview but don't get there. Especially the sky
> does not get that bright blue from the preview.
>
> I also tried white-balance (sun) but that makes the picture a bit
> too blue.
>
> Colours > Hue/Saturation/Lightness also helps regarding vibrance
> and saturation.
>
> So what do you do with your pictures? Do you also see that "always
> darker"?

If I use auto exposure I always (almost) get darker images. This is
due to avoid clipping highlighted areas. If you clip those areas you
will never get the information back afterwards (like structures in
clouds). This becomes a problem if there are over exposed areas in the
picture without any interest for the picture itself (background clouds
or foreground while using a flash). This is nothing the automatic
exposure handling can do about.

For raw processing I use a specialist in this area (ufraw in the past,
darktable since about a half a year). These programs have much more
options to get a pleasing photo. All the other stuff (organizing and
tagging) I do with digikam.

Another advantage: both programs stores the settings for the raw file
in an extra file. So if you have to readjust the white balance it is
much easier than redo all settings with digikam. (This may be true for
digikam 1.x only as I don't know digikam 2.x). And at least darktable
has many options to get maximum out of your raw file and by default
produces results similar to the buildin jpeg.

Martin

>
> Sven
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Sonntag, 19. Juni 2011, 15:30:32 schrieb Remco Viëtor:
> Usually I need to adjust levels and saturation, sharpen, and use an S-shaped
> curve adjust. Also, gamma has to be adjusted to 2.2 (esp. when using blend
> or unclip, not sure about 'solid white'). Those steps are all applied
> 'in-camera' when you shoot in jpeg, and for the jpeg preview embedded in
> the RAW.
>
> The gamma and saturation can be adjusted in the RAW developer, the others I
> prefer doing afterwards.

These were some really useful hints! I did not think about using gamma to work
against the darkness from the highlight rebuilding before. This works really
well! Though I do not need 2.2 but just 1,7. For contrast 15, saturation 1,1
and exposure 0,5. This brings me pretty close to what the preview jpg shows.

Does using that much gamma not have any side-effects regarding noise?

> I usually don't aim to imitate the camera JPEG (for that I'd better shoot
> RAW+JPEG or just JPEG ;) ).

Me neither but I want to be able to do so.

> As to the 'why' of the darker RAW images, have a look at the Dcraw website
> http://www.cybercom.net/~dcoffin/dcraw/

I read that before but I just wanted to know how I could get close to the
preview in case I wanted to. Digikam is full of options and I'm still learning
how to combine them in order to get to where I want with a picture. :)

Thanks!

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Sonntag, 19. Juni 2011, 16:40:26 schrieb Martin:
> For raw processing I use a specialist in this area (ufraw in the past,
> darktable since about a half a year). These programs have much more
> options to get a pleasing photo. All the other stuff (organizing and
> tagging) I do with digikam.

I'll try those two and see whether I can get better results as with digikam.
Though I guess my "needs" are rather basic compared to the functionality of
those applications.

> Another advantage: both programs stores the settings for the raw file
> in an extra file. So if you have to readjust the white balance it is
> much easier than redo all settings with digikam. (This may be true for
> digikam 1.x only as I don't know digikam 2.x). And at least darktable
> has many options to get maximum out of your raw file and by default
> produces results similar to the buildin jpeg.

I could not find any way to use the versioning of digikam 2 to re-adjust the
settings applied in a filter or tool. But that might indeed be something to
suggest for future releases.

Thanks!

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Yngve I. Levinsen]

Søndag 19 juni 2011 16.40.26 skrev Martin (KDE) :

> For raw processing I use a specialist in this area (ufraw in the past, 

> darktable since about a half a year). These programs have much more 

> options to get a pleasing photo. All the other stuff (organizing and 

> tagging) I do with digikam.

Hello,

I also have been using ufraw to convert my raw images before organizing in Digikam. This command works pretty well for me:

ufraw-batch --wb=camera --rotate=camera --out-type=jpeg --out-path=jpeg/ nef/*.NEF

I then have one folder nef for the raw images and one jpeg for my converted images. Afterwards I go through the jpeg's and

if some did not have a pleasing conversion I try to improve manually using the GUI of ufraw.

Did not know about darktable, I'll have a look.

Cheers,

Yngve

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am 20.06.2011 10:27, schrieb Yngve Inntjore Levinsen:

> Søndag 19 juni 2011 16.40.26 skrev Martin (KDE) :
>
>> For raw processing I use a specialist in this area (ufraw in the past,
>
>> darktable since about a half a year). These programs have much more
>
>> options to get a pleasing photo. All the other stuff (organizing and
>
>> tagging) I do with digikam.
>
>
>
> Hello,
>
>
> I also have been using ufraw to convert my raw images before organizing
> in Digikam. This command works pretty well for me:
>
>
> ufraw-batch --wb=camera --rotate=camera --out-type=jpeg --out-path=jpeg/
> nef/*.NEF
>
>
> I then have one folder nef for the raw images and one jpeg for my
> converted images. Afterwards I go through the jpeg's and
>
> if some did not have a pleasing conversion I try to improve manually
> using the GUI of ufraw.
>
>
> Did not know about darktable, I'll have a look.

Darktable has more powerfull options than ufraw but it is different.
Best to take a look at the darktable homepage and follow the links to
the screencasts from Pascal where many of the darktable details are
explained. And darktable has a very active developer community. If you
don't mind compiling, try the git version of it.

Martin

>
>
> Cheers,
>
> Yngve
>
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Sonntag, 19. Juni 2011, 16:40:26 schrieb Martin:
> For raw processing I use a specialist in this area (ufraw in the past,
> darktable since about a half a year). These programs have much more
> options to get a pleasing photo. All the other stuff (organizing and
> tagging) I do with digikam.

I tried darktable and I like the default results. It performs better at
handling highlights (even when clipping! and even if one uses unclipping there
is no need to apply gamma) and its colours are better. Since if I understood
correctly it also uses libdcraw, how come its results are better?

Or to put it the other way around. Why do I not have to use gamma when working
with highlights and why is there no way for me to get the colours the same way
with digikam's demosaicing?

I noticed that using the camera's whitebalance shows three sliders for the
colours, i.e. it seems to read values for red, green and blue from the
camera's whitebalance. Does digikam maybe fail at doing so?

Also, there is a noise reduction module but it is labeled as obsolete and it
seems that there is no other module for noise reduction yet the noise
reduction works very well nonetheless.

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Donnerstag, 23. Juni 2011, 10:45:39 schrieb Sven Burmeister:
> Or to put it the other way around. Why do I not have to use gamma when
> working with highlights and why is there no way for me to get the colours
> the same way with digikam's demosaicing?
>
> I noticed that using the camera's whitebalance shows three sliders for the
> colours, i.e. it seems to read values for red, green and blue from the
> camera's whitebalance. Does digikam maybe fail at doing so?

This image shows the sliders missing in digikam, i.e. the colours and tint.

http://darktable.sourceforge.net/usermanual/ch03s04s04.html

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Dmitri Popov]

Hi Sven,

If I remember correctly, the noise reduction plugin in darktable has been replaced with the Equalizer plugin which handles both sharpening and noise reduction.

Best,
Dmitri


----- Original Message -----
From: Sven Burmeister <[hidden email]>
To: [hidden email]
Cc:
Sent: Thursday, June 23, 2011 10:45 AM
Subject: [Digikam-users] Re: Processing RAW images to get to the look of the jpg preview

Am Sonntag, 19. Juni 2011, 16:40:26 schrieb Martin:
> For raw processing I use a specialist in this area (ufraw in the past,
> darktable since about a half a year). These programs have much more
> options to get a pleasing photo. All the other stuff (organizing and
> tagging) I do with digikam.

I tried darktable and I like the default results. It performs better at
handling highlights (even when clipping! and even if one uses unclipping there
is no need to apply gamma) and its colours are better. Since if I understood
correctly it also uses libdcraw, how come its results are better?

Or to put it the other way around. Why do I not have to use gamma when working
with highlights and why is there no way for me to get the colours the same way
with digikam's demosaicing?

I noticed that using the camera's whitebalance shows three sliders for the
colours, i.e. it seems to read values for red, green and blue from the
camera's whitebalance. Does digikam maybe fail at doing so?

Also, there is a noise reduction module but it is labeled as obsolete and it
seems that there is no other module for noise reduction yet the noise
reduction works very well nonetheless.

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Donnerstag, 23. Juni 2011 schrieb Sven Burmeister:

> Am Sonntag, 19. Juni 2011, 16:40:26 schrieb Martin:
> > For raw processing I use a specialist in this area (ufraw in the
> > past, darktable since about a half a year). These programs have
> > much more options to get a pleasing photo. All the other stuff
> > (organizing and tagging) I do with digikam.
>
> I tried darktable and I like the default results. It performs
> better at handling highlights (even when clipping! and even if one
> uses unclipping there is no need to apply gamma) and its colours
> are better. Since if I understood correctly it also uses libdcraw,
> how come its results are better?

Not exactly. Darktable uses two different raw libs (libraw and
rawspeed). Usage depends on the camera. Raw development is a very
complex process. I only know part of this, but the main author of
darktable build a postscript picture of the modules a raw picture will
pass until it gets a final jpeg. It is big and very
complicated/confusing but alas it works.

I don't think your problem is gamma only. The gamma curve only depends
on the colour model you use to view the picture (sRBG, Adobe RBG,
Apple RGB ...). It should almost never be necessary to adjust this by
hand. But I have no clue what the problem of digikam is here.

Darktable uses a good sets of defaults and by default the base curve
is not linear. this may be one main difference.

>
> Or to put it the other way around. Why do I not have to use gamma
> when working with highlights and why is there no way for me to get
> the colours the same way with digikam's demosaicing?
>
> I noticed that using the camera's whitebalance shows three sliders
> for the colours, i.e. it seems to read values for red, green and
> blue from the camera's whitebalance. Does digikam maybe fail at
> doing so?

I don't think so. This sliders results from the colour temperature and
the tint slider, which are present in darktable as well. Internally
all dcraw based software will use this three colour sets (afaik). But
it is way to complicated to set these by hand so on most systems the
temperature (for red-blue) and the tint for green setup is used.
Usually one value is always set to 1 (in most cases this is green).
red and blue values are set "relative" to green. If you want to
increase green you will in fact reduce blue and red.

>
> Also, there is a noise reduction module but it is labeled as
> obsolete and it seems that there is no other module for noise
> reduction yet the noise reduction works very well nonetheless.

Ah, there is a noise reduction plugin. There are at least three ways
to reduce the noise.
- Raw denoise
- Equalizer (a preset for denoise is available)
- denoise (very slow) (may be available in git only)

Equalizer is the most complex one thou. Here you can play with luma
and chroma noise independently.

I don't know if I mentioned it: darktable can store presets of almost
all modules. So if you took the time to find a really good equalizer
setup you can store this and later on use this on other photos without
fiddling with the values.

Regards
Martin

>
> Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Donnerstag, 23. Juni 2011, 11:48:20 schrieb Martin:
> Not exactly. Darktable uses two different raw libs (libraw and
> rawspeed). Usage depends on the camera. Raw development is a very
> complex process. I only know part of this, but the main author of
> darktable build a postscript picture of the modules a raw picture will
> pass until it gets a final jpeg. It is big and very
> complicated/confusing but alas it works.

I have pictures from a Nikon D90 and a Panasonic LX3, so it might indeed use
rawspeed for those.

> I don't think your problem is gamma only. The gamma curve only depends
> on the colour model you use to view the picture (sRBG, Adobe RBG,
> Apple RGB ...). It should almost never be necessary to adjust this by
> hand. But I have no clue what the problem of digikam is here.

You can try this. In digikam, open a RAW image that has visible highlights
with the demosaicing tool and set highlights to "rebuild" or "blend". You will
get a very dark image and thus need gamma. In darktable you get the same
results regarding highlights (or better) but without a dark image or having to
apply gamma and I would like to understand why because it would make RAW
demosaicing in digikam easier if it worked as it does in darktable, regarding
colours and highlights.

> Darktable uses a good sets of defaults and by default the base curve
> is not linear. this may be one main difference.

Yes, it's that base curve. Is this the equivalent of the curve in digikam's
demosaicing tool? Did you ever use any curves in digikam? When I tried
handling the points on the curve, i.e. placing them by dragging, seemed very
hard to me and I often get lines curves that have sharp bends whereas the
"sliders" in darktable's curve-tool seem to work better for me. If I'm not the
only one, I would file a request to enhance the usage of digikam's curves.

And I noticed that darktable has presets for different kind of cameras for
that curve. Having that in digikam would also be helpful I think.

> Ah, there is a noise reduction plugin. There are at least three ways
> to reduce the noise.
> - Raw denoise
> - Equalizer (a preset for denoise is available)
> - denoise (very slow) (may be available in git only)
>
> Equalizer is the most complex one thou. Here you can play with luma
> and chroma noise independently.

I'll try that out. Equaliser did not sound like anything noise-related to me.
RAW denoise is marked as obsolete which is why I did not try it. The third
option is not present in my 0.8 package.

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Donnerstag, 23. Juni 2011 schrieb Sven Burmeister:

>
> > I don't think your problem is gamma only. The gamma curve only
> > depends on the colour model you use to view the picture (sRBG,
> > Adobe RBG, Apple RGB ...). It should almost never be necessary
> > to adjust this by hand. But I have no clue what the problem of
> > digikam is here.
>
> You can try this. In digikam, open a RAW image that has visible
> highlights with the demosaicing tool and set highlights to
> "rebuild" or "blend". You will get a very dark image and thus need
> gamma. In darktable you get the same results regarding highlights
> (or better) but without a dark image or having to apply gamma and
> I would like to understand why because it would make RAW
> demosaicing in digikam easier if it worked as it does in
> darktable, regarding colours and highlights.

I try digikam for raw development every now and then. But for me it is
to limited. That's the reason for using ufraw and darktable in the
last three years.

>
> > Darktable uses a good sets of defaults and by default the base
> > curve is not linear. this may be one main difference.
>
> Yes, it's that base curve. Is this the equivalent of the curve in
> digikam's demosaicing tool? Did you ever use any curves in
> digikam? When I tried handling the points on the curve, i.e.
> placing them by dragging, seemed very hard to me and I often get
> lines curves that have sharp bends whereas the "sliders" in
> darktable's curve-tool seem to work better for me. If I'm not the
> only one, I would file a request to enhance the usage of digikam's
> curves.

Curves are a complicated matter. Using a curve in digikam with a
similar shape as the base curve in darktable will most likely lead to
different results. One curve works on linear data and others after
colour space is applied.

>
> And I noticed that darktable has presets for different kind of
> cameras for that curve. Having that in digikam would also be
> helpful I think.

But I don't think that this will ever happen. To get digikams raw part
to a similar state as darktable already has is to much of work and
will confuse to many users. And the Unix philosophy is against this.
Use one tool for one problem but use the best. And to my point of view
for raw development this is darktable.

What I hope for is a better "integration" of darktable and digikam.
Both use (or will use) xmp sidecar files and it would be great if they
can use the same file and share basic settings where the special
settings of the other program will not be destroyed.

>
> > Ah, there is a noise reduction plugin. There are at least three
> > ways to reduce the noise.
> > - Raw denoise
> > - Equalizer (a preset for denoise is available)
> > - denoise (very slow) (may be available in git only)
> >
> > Equalizer is the most complex one thou. Here you can play with
> > luma and chroma noise independently.
>
> I'll try that out. Equaliser did not sound like anything
> noise-related to me.

I first ignored the equalizer as well but it is a great tool. try it
out. There are presets for denoise alone and combined with sharpen.

> RAW denoise is marked as obsolete which is
> why I did not try it. The third option is not present in my 0.8
> package.

That's the reason I suggested the git version (or, if you use ubuntu,
take Pascal's packages). The git version is way ahead. Darktable made
amazing progress. I tried revision 0.5 about one year ago and to me it
was not usable. With revision 0.7 (about November 2010) I completely
switched to darktable for raw processing. and raw denoise may be
available in git version only as well.

>
> Sven

Martin
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Gilles Caulier-4]

2011/6/23 David Vincent-Jones <[hidden email]>

Please NO ..... the curves tool in darktable lack real flexibility when
working to manipulate small tonal areas. With colour it (sort-of) works;
with black and white it is a disaster.

The only thing missing in the digikam setup is the tone reference guide
between the image and the curve. We had that not so long ago and Gilles
has said that it would be replaced (there is a bug report in place).

For that, i'm waiting some progress into libraw in this way. It's not yet done, but i know that ALex Tutubalin (libraw author) work on this suject.

I won't implement it directly in digiKam core. All raw algorithms must be done in libraw, to share it with the rest of the world. Like this implementation tuning/improvements will be faster.

Gilles Caulier

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Donnerstag, 23. Juni 2011, 22:13:49 schrieb David Vincent-Jones:
> Please NO ..... the curves tool in darktable lack real flexibility when
> working to manipulate small tonal areas. With colour it (sort-of) works;
> with black and white it is a disaster.

Can you explain that? In digikam I almost always get sharp bends which I think
does not make sense. And moving the points around never gives me what I
wanted, in terms of how I would like the curve to look like. I would like to
be able to move some region of the curve up, as easy as it works in darktable.

I can supply some screenshots in order to show what I mean by "moving points
never gives me what I want".

So even if not the darktable way, I think that there is a need for improving
the handling of curves in digikam. Darktable might be too simple, but it would
be a good start in terms of ease. Adding complexity of usage can always be
done.

Ah – and btw. which curve is the darktable's base-curve in digikam's RAW
module?

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Rinus]

Op 23-06-11 22:51, Sven Burmeister schreef:

> Am Donnerstag, 23. Juni 2011, 22:13:49 schrieb David Vincent-Jones:
>> Please NO ..... the curves tool in darktable lack real flexibility when
>> working to manipulate small tonal areas. With colour it (sort-of) works;
>> with black and white it is a disaster.
> Can you explain that? In digikam I almost always get sharp bends which I think
> does not make sense. And moving the points around never gives me what I
> wanted, in terms of how I would like the curve to look like. I would like to
> be able to move some region of the curve up, as easy as it works in darktable.
>
> I can supply some screenshots in order to show what I mean by "moving points
> never gives me what I want".

At least in 2.0.0 beta 6 there is an option beneath the curve to have
sharp are smooth bends. I you have choosen the smooth bends, it is up to
you how many bend points you make, this way you can do anything you want
and in fact, however darktable looks nicer, it would for complex
manupilation be harder to get the same result.

Rinus

> So even if not the darktable way, I think that there is a need for improving
> the handling of curves in digikam. Darktable might be too simple, but it would
> be a good start in terms of ease. Adding complexity of usage can always be
> done.
>
> Ah – and btw. which curve is the darktable's base-curve in digikam's RAW
> module?
>
> Sven
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[S. Burmeister]

Am Freitag, 24. Juni 2011, 10:19:10 schrieb sleepless:
> At least in 2.0.0 beta 6 there is an option beneath the curve to have
> sharp are smooth bends. I you have choosen the smooth bends, it is up to
> you how many bend points you make, this way you can do anything you want
> and in fact, however darktable looks nicer, it would for complex
> manupilation be harder to get the same result.

There were too many points on the curve. If one clicks on sharp bends and then
on smooth bends you get a lot of points. Not sure why I never tried reset,
since that only gives me three points which I can handle a lot better. I also
found that one can get rid of points by moving them outside the histogram –
which is not too obvious in my opinion.

So I would opt for less points (3 on the curve and one at each end) as default
since adding points by clicking is more obvious than removing them by dragging
them outside the histogram. Start less-complex. :)

Thanks for the hints!

Sven
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users