Hi Ulrich,
i made a zip with both RAW and XMP :
http://dl.free.fr/b9aJ2E9m2
Florian
Le 17/01/2013 07:32, Ulrich Pegelow a écrit :
Hi,
both cases would deserve further inspection. The first issue might be
related to hot pixels but it might also be related to our way of
calculating from RGB
On Thu, Jan 17, 2013 at 10:41 AM, Pascal Obry wrote:
>
> Johannes,
>
>> from a design standpoints, it's just a nice thing to have code cleanly
>> separated (you don't like cropping? delete one file!). so even though
>> we could from a practical view just statically compile in all our
>> modules, w
Simon,
Forget about my previous message, I now understand what's wrong.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
--
Johannes,
> from a design standpoints, it's just a nice thing to have code cleanly
> separated (you don't like cropping? delete one file!). so even though
> we could from a practical view just statically compile in all our
> modules, we don't, because it's a nice modular separation of the mess
>
Le 16/01/2013 22:15, Simon Spannagel a écrit :
> Well, as far as I understand the design concept at this edge of the code
> (and this is not too much actually) one of the principles is keeping the
> modules (i.e. IOPs) completely separated from the core components of
> darktable. The core itself do
hey,
On Thu, Jan 17, 2013 at 10:12 AM, Pascal Obry wrote:
>
> Johannes,
>
>> oh, also a not on module versions.
>>
>> first, you're including headers for separately compiled modules in the
>> main compilation unit (libclipping.so and libdarktable.so have now
>> some overlap).
>>
>> this will tota
On Mon, Dec 17, 2012 at 12:40 AM, Pascal de Bruijn wrote:
> Hi,
>
> I created a Orten Slide Sandwich preset using the soften plugin.
>
> That plugin doesn't have to infrastructure yet for providing presets
> yet. And more particularly, using blending.
>
> Generally speaking I've cautioned about us
Hi,
Soon I want to start pushing git master packages again, however once
again I have versioning issue (like any packager would).
My PPAs now have 1.1.2, so I can't push a 1.1+g package, since
1.1.2 is higher, and I can't go backwards.
My proposal is to an alpha release (possibly this we
Am 16.01.2013 22:12, schrieb Pascal Obry:
>
> Johannes,
>
>> oh, also a not on module versions.
>>
>> first, you're including headers for separately compiled modules in the
>> main compilation unit (libclipping.so and libdarktable.so have now
>> some overlap).
>>
>> this will totally crash if a
Johannes,
> oh, also a not on module versions.
>
> first, you're including headers for separately compiled modules in the
> main compilation unit (libclipping.so and libdarktable.so have now
> some overlap).
>
> this will totally crash if a module increases it's version, changes
> the parameter
On Thu, Jan 17, 2013 at 10:02 AM, Pascal Obry wrote:
> Le 16/01/2013 21:57, johannes hanika a écrit :
>> even if it's not at the moment.. i can totally see someone else
>> hacking a back-converter for example, and just using it (and then
>> wondering why it breaks). why not just put it on the stac
On Wed, Jan 16, 2013 at 10:01 PM, Pascal Obry wrote:
> Pascal,
>
>> Have you considered tonecurve as well?
>
> No, not yet but I bet I'll have a need for this at some point.
>
>> BTW, (just thinking out loud), how feasible would (lossy) Lightroom
>> style/lrtemplate import be (with the obvious lim
Le 16/01/2013 21:57, johannes hanika a écrit :
> even if it's not at the moment.. i can totally see someone else
> hacking a back-converter for example, and just using it (and then
> wondering why it breaks). why not just put it on the stack, doesn't
> cost us really.
Sure, will do.
--
Pascal
Pascal,
> Have you considered tonecurve as well?
No, not yet but I bet I'll have a need for this at some point.
> BTW, (just thinking out loud), how feasible would (lossy) Lightroom
> style/lrtemplate import be (with the obvious limitations)? I think
> tonecurve/tsl are very commonly used in lr
On Thu, Jan 17, 2013 at 9:54 AM, Pascal Obry wrote:
>
> Johannes,
>
>> never used lightroom, so can't comment on the functionality, but this:
>>
>> https://github.com/darktable-org/darktable/blob/master/src/develop/lightroom.c#L42
>>
>> is probably a bug (static char makes the function not thread-
oh, also a not on module versions.
first, you're including headers for separately compiled modules in the
main compilation unit (libclipping.so and libdarktable.so have now
some overlap).
this will totally crash if a module increases it's version, changes
the parameters, and is just copied into t
Johannes,
> never used lightroom, so can't comment on the functionality, but this:
>
> https://github.com/darktable-org/darktable/blob/master/src/develop/lightroom.c#L42
>
> is probably a bug (static char makes the function not thread-safe, and
> in dt everything is multithreaded, just get rid
On Wed, Jan 16, 2013 at 8:20 PM, Pascal Obry wrote:
> I have just push some more support for Lightroom import.
>
> We have at the moment:
>
>- crop & flip
>- vignette
>- grain
>- black level
>- tags
>
> If there is needs for other support I'll be glad to work on it but at
> the
hey,
never used lightroom, so can't comment on the functionality, but this:
https://github.com/darktable-org/darktable/blob/master/src/develop/lightroom.c#L42
is probably a bug (static char makes the function not thread-safe, and
in dt everything is multithreaded, just get rid of the static?).
Richard,
> That's my intention, yes.
Great! Then most of my code for computing the aspect ratio can be removed.
Cheers,
Pascal.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.
In message <50f7045f.30...@obry.net> on Wed, 16 Jan 2013 20:49:51 +0100, Pascal
Obry said:
pascal>
pascal> Richard,
pascal>
pascal> > Yes. That's what I was proposing earlier. (although the point that
pascal> > the gui specific parts shouldn't be stored there is very valid)
pascal>
pascal>
Richard,
> Yes. That's what I was proposing earlier. (although the point that
> the gui specific parts shouldn't be stored there is very valid)
Are you going to work on this?
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.o
Le 16/01/2013 20:35, Binoyte a écrit :
> Bibble5 / AfterShot Pro import support will be very welcomed as this
> software was the only pro photographic workflow software on linux.
> Lots of B5/ASP users, as I am, are looking at darktable with a strong
> interest.
Out of the scope of Lightroom suppo
Bibble5 / AfterShot Pro import support will be very welcomed as this
software was the only pro photographic workflow software on linux.
Lots of B5/ASP users, as I am, are looking at darktable with a strong
interest.
cheers
2013/1/16 Pascal Obry
>
> I have just push some more support for Lightro
In message <50f6ea54.7020...@obry.net> on Wed, 16 Jan 2013 18:58:44 +0100,
Pascal Obry said:
pascal> Le 16/01/2013 17:34, Richard Levitte a écrit :
pascal> > Point is, if I've set this aspect ratio, it's pretty likely I'd like
pascal> > to have it if I go back to adjust. If it's suddenly "free"
I have just push some more support for Lightroom import.
We have at the moment:
- crop & flip
- vignette
- grain
- black level
- tags
If there is needs for other support I'll be glad to work on it but at
the moment I think we have good support for the next release.
It has been s
On Wed, Jan 16, 2013 at 11:31 AM, Seweryn Niemiec wrote:
> Hi,
>
> First, DT is a really superb software, I love it and I recommend it to
> all not ossified photographers I know. I'd like to thank all people who
> contributed to the project, you are great. There are few little annoying
> things an
Le 16/01/2013 17:34, Richard Levitte a écrit :
> Point is, if I've set this aspect ratio, it's pretty likely I'd like
> to have it if I go back to adjust. If it's suddenly "free", it will
> screw up the result I wanted.
I agree what I have just implemented is better than before but far from
perfe
In message <50f6cdc3.2020...@obry.net> on Wed, 16 Jan 2013 16:56:51 +0100,
Pascal Obry said:
pascal> Le 16/01/2013 16:47, Richard Levitte a écrit :
pascal> > I'm thinking about custom aspects. Say I fed in 851:315 (the facebook
pascal> > cover image size)
pascal>
pascal> I see, we can ente
Le 16/01/2013 16:47, Richard Levitte a écrit :
> I'm thinking about custom aspects. Say I fed in 851:315 (the facebook
> cover image size)
What we could do is:
- map everything that is not a known aspect ration to free as I have
proposed and is done today.
- add the actual aspect next to
Le 16/01/2013 16:47, Richard Levitte a écrit :
> I'm thinking about custom aspects. Say I fed in 851:315 (the facebook
> cover image size)
I see, we can enter aspect ratio manually! Didn't know :)
Well, now I'm not sure whether we want to save this specific aspect
ratio. Shouldn't it just di
In message <50f6be58.9080...@obry.net> on Wed, 16 Jan 2013 15:51:04 +0100,
Pascal Obry said:
pascal> > What I wonder, though, is what you're thinking of giving as feedback
pascal> > to the user? 5:4 becomes a float of 1.25, the quick and dirty way
pascal> > would be to display 1.25:1 (or 0.8:1
Richard,
> +1, but not enough in my opinion. The actual crop will only tell you
> what the actual crop is... your aspect ratio preset might have been
> "free" just as well as "5:4", which one should the clipping module
> choose for you when you get back in develop mode?
I've just pushed my fix
Richard,
> Yeah ok, using the crop size to get an actual aspect ratio makes
> sense.
Ok.
> What I wonder, though, is what you're thinking of giving as feedback
> to the user? 5:4 becomes a float of 1.25, the quick and dirty way
> would be to display 1.25:1 (or 0.8:1 if it was flipped).
? feed
In message <50f6b5dc.5090...@obry.net> on Wed, 16 Jan 2013 15:14:52 +0100,
Pascal Obry said:
pascal>
pascal> Richard,
pascal>
pascal> > pascal> I think we should initialize the aspect ratio (in the GUI
combo) from
pascal> > pascal> the actual crop of the image, this should be quite easy.
pasc
Am Mittwoch, 16. Januar 2013, 15:03:01 schrub Richard Levitte:
[...]
> - aspect ratio preset (int)
That will break once we change the list in the gui. It's always a bad idea to
make the history stack depend on the gui.
[...]
signature.asc
Description: This is a digitally signed message part.
Richard,
> pascal> I think we should initialize the aspect ratio (in the GUI combo) from
> pascal> the actual crop of the image, this should be quite easy.
>
> +1, but not enough in my opinion. The actual crop will only tell you
> what the actual crop is... your aspect ratio preset might have
Richard,
> That PR, however, doesn't solve what Pascal is complaining about.
Right.
> I'm working on the problem that Pascal mentions as well ('cause it has
> annoyed the hell out of me as well).
> However, there are things related to this that I wonder about... For
> completeness, the followi
In message <50f6a5ee.8080...@obry.net> on Wed, 16 Jan 2013 14:06:54 +0100,
Pascal Obry said:
pascal> I think we should initialize the aspect ratio (in the GUI combo) from
pascal> the actual crop of the image, this should be quite easy.
+1, but not enough in my opinion. The actual crop will onl
That PR, however, doesn't solve what Pascal is complaining about.
I'm working on the problem that Pascal mentions as well ('cause it has
annoyed the hell out of me as well).
However, there are things related to this that I wonder about... For
completeness, the following things would need to be sa
great, thanks
On Wed, Jan 16, 2013 at 2:53 PM, Pascal Obry wrote:
>
> Jeremy,
>
>> there is a PR related to that currently in github
>> (https://github.com/darktable-org/darktable/pull/159)
>>
>> (not the same thing, but same area of code)
>
> Actually I don't think it is the same thing.
>
>> if
Jeremy,
> there is a PR related to that currently in github
> (https://github.com/darktable-org/darktable/pull/159)
>
> (not the same thing, but same area of code)
Actually I don't think it is the same thing.
> if you are in that area, maybe you could review the PR and merge it if
> it's good
On 16/1/13 9:06 PM, Pascal Obry wrote:
> Today the aspect ratio is remembered from previous image and this is
> very annoying. [...]
> I think we should initialize the aspect ratio (in the GUI combo) from
> the actual crop of the image, this should be quite easy.
+1. I too find this heaps annoyin
yes makes sense...
there is a PR related to that currently in github
(https://github.com/darktable-org/darktable/pull/159)
(not the same thing, but same area of code)
if you are in that area, maybe you could review the PR and merge it if
it's good ? that would avoid useless merge conflicts late
Today the aspect ratio is remembered from previous image and this is
very annoying.
Scenario:
- change aspect ratio of image-1 to 3:2
- change aspect ratio of image-2 to 1:1
- go back to image-1, select clipping module, the aspect
ratio of the image is 1:1 loosing your previous c
Hi,
First, DT is a really superb software, I love it and I recommend it to
all not ossified photographers I know. I'd like to thank all people who
contributed to the project, you are great. There are few little annoying
things and maybe some day I'll dig into the code and change them.
Back to
46 matches
Mail list logo
