From atenrok at gmail.com  Mon Aug  3 02:42:19 2009
From: atenrok at gmail.com (oleksandr korneta)
Date: Sun, 02 Aug 2009 20:42:19 -0400
Subject: [Rawstudio-dev] image display quality
Message-ID: <h55bpc$6cc$1@ger.gmane.org>

RawStudio and Ufraw side by side http://bayimg.com/image/eadljaaca.jpg

I would like to use the former, but on my machine pictures look much 
better in the latter. What am I missing?



-- 
regards,
Oleksandr Korneta

I'm running F9 x86_64 and F10 i386 on x86_64 hardware, should this matter.

/The nice thing about standards is that there are so many to choose from./




From samtygier at yahoo.co.uk  Mon Aug  3 08:45:12 2009
From: samtygier at yahoo.co.uk (sam tygier)
Date: Mon, 03 Aug 2009 07:45:12 +0100
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <h55bpc$6cc$1@ger.gmane.org>
References: <h55bpc$6cc$1@ger.gmane.org>
Message-ID: <h5611o$g1j$1@ger.gmane.org>

oleksandr korneta wrote:
> RawStudio and Ufraw side by side http://bayimg.com/image/eadljaaca.jpg
> 
> I would like to use the former, but on my machine pictures look much 
> better in the latter. What am I missing?


this has come up before.
http://thread.gmane.org/gmane.comp.graphics.rawstudio.devel/730

there is no good solution.

sam



From klauspost at gmail.com  Mon Aug  3 17:08:00 2009
From: klauspost at gmail.com (Klaus Post)
Date: Mon, 3 Aug 2009 17:08:00 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <h5611o$g1j$1@ger.gmane.org>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
Message-ID: <cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>

Hi!

On Mon, Aug 3, 2009 at 8:45 AM, sam tygier<samtygier at yahoo.co.uk> wrote:
> oleksandr korneta wrote:
>> RawStudio and Ufraw side by side http://bayimg.com/image/eadljaaca.jpg
>>
>> I would like to use the former, but on my machine pictures look much
>> better in the latter. What am I missing?
>
>
> this has come up before.
> http://thread.gmane.org/gmane.comp.graphics.rawstudio.devel/730

We are currently working adding camera profiles, and adding a
possibility to have default camera settings, and it is my single major
To-do's before v2.0.

I do feel that sensible defaults, and a possibility to have decent
color profiles are essential, since it makes the workflow and output
so much better.

The easiest workaround I know, is to adjust one image, and paste the
relevant settings (remember not to copy WB) onto all your shots - it
is quite easy, and makes it possible to quickly develop a lot of
images.

That said, we will probably need quite a lot of help to create
profiles when the time comes.


Regards, Klaus Post

http://www.klauspost.com


From martin.sand.christensen at gmail.com  Mon Aug  3 17:21:37 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Mon, 03 Aug 2009 17:21:37 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	(Klaus Post's message of "Mon, 3 Aug 2009 17:08:00 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
Message-ID: <87zlagsz26.fsf@gmail.com>

>>>>> "Klaus" == Klaus Post <klauspost at gmail.com> writes:
Klaus> That said, we will probably need quite a lot of help to create
Klaus> profiles when the time comes.

I've actually given some thought to automating this procedure, and would
have done something about it if Rawstudio could be convinced to do batch
processing from the command line. I've been looking for some sort of
interesting project for genetic algorithms, just to try them out, and
approximating curves (or, in this case, colour profiles) would be a nice
candidate. So if anyone can be arsed to give Rawstudio a suitable
command line interface, I'd be happy to give the rest of the task a
shot.


Martin


From anders at brander.dk  Mon Aug  3 21:35:45 2009
From: anders at brander.dk (Anders Brander)
Date: Mon, 03 Aug 2009 21:35:45 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <87zlagsz26.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com>
Message-ID: <1249328145.13233.5.camel@travelgate2>

Hi,

On Mon, 2009-08-03 at 17:21 +0200, Martin Christensen wrote:
> Klaus> That said, we will probably need quite a lot of help to create
> Klaus> profiles when the time comes.
> 
> I've actually given some thought to automating this procedure, and would
> have done something about it if Rawstudio could be convinced to do batch
> processing from the command line. I've been looking for some sort of
> interesting project for genetic algorithms, just to try them out, and
> approximating curves (or, in this case, colour profiles) would be a nice
> candidate. So if anyone can be arsed to give Rawstudio a suitable
> command line interface, I'd be happy to give the rest of the task a
> shot.

Rawstudio is far from a command line application. Many things are tied
into GTK+ and X.
I'm a bit curious thou, which functionality would you like see
implemented in a CLI interface? Would a D-Bus interface do?

Anders Brander




From anders at brander.dk  Mon Aug  3 21:43:50 2009
From: anders at brander.dk (Anders Brander)
Date: Mon, 03 Aug 2009 21:43:50 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <h55bpc$6cc$1@ger.gmane.org>
References: <h55bpc$6cc$1@ger.gmane.org>
Message-ID: <1249328630.13233.13.camel@travelgate2>

Hi,

On Sun, 2009-08-02 at 20:42 -0400, oleksandr korneta wrote:
> RawStudio and Ufraw side by side http://bayimg.com/image/eadljaaca.jpg
> 
> I would like to use the former, but on my machine pictures look much 
> better in the latter. What am I missing?

UFRaw and Rawstudio are two very different applications with different
rendering algorithms.

Did you enable color management in Rawstudio?
Which color profile did you use in UFRaw? in Rawstudio?
Did you use the "color matrix" option in UFRaw?

Even if you use the same color profiles in both applications, you cannot
be sure that the result will look the same. Using ICC profiles for
developing raw images is a lucky guess at best :)

Anders Brander




From martin.sand.christensen at gmail.com  Tue Aug  4 00:00:53 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Tue, 04 Aug 2009 00:00:53 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <1249328145.13233.5.camel@travelgate2> (Anders Brander's message
	of "Mon, 03 Aug 2009 21:35:45 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
Message-ID: <877hxkftgq.fsf@gmail.com>

>>>>> "Anders" == Anders Brander <anders at brander.dk> writes:
Anders> Rawstudio is far from a command line application. Many things
Anders> are tied into GTK+ and X.

Obviously and thankfully. :-)

Anders> I'm a bit curious thou, which functionality would you like see
Anders> implemented in a CLI interface?

Only the ability to batch process given files based on their current
settings. For what I want to do, I would just want to manipulate the XML
settings files for my target image directly and then have Rawstudio
process the image based on those settings.

Throw in the ability to batch process an entire folder, and preferably
only the files of a given priority in that folder, now that you're at
it; I sorely miss that sometimes. I'd like the ability to put a remote
machine to work without being bound by a low bandwidth or low latency
network connection.

While we're on the topic of batch processing, when can we expect to see
Rawstudio take advantage of multiple cores? Batch processing should
be trivial to do in parallel. Indeed, even the interactive stuff could
probably get an almost linear performance boost from adding more
threads, but it'd probably be a lot harder to implement. Personally,
though, I'd much rather see it in batch processing anyway.

Anders> Would a D-Bus interface do?

I doubt it, but I really couldn't say. I'm a systems guy, and my
programmer's toolbox reflects that. I don't know more about D-Bus than
what would fit in a tabloid headline.


Martin


From anders at brander.dk  Tue Aug  4 05:38:08 2009
From: anders at brander.dk (Anders Brander)
Date: Tue, 04 Aug 2009 05:38:08 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <877hxkftgq.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
	<877hxkftgq.fsf@gmail.com>
Message-ID: <1249357088.9677.7.camel@video64>

Hi,

On Tue, 2009-08-04 at 00:00 +0200, Martin Christensen wrote:
> Anders> I'm a bit curious thou, which functionality would you like see
> Anders> implemented in a CLI interface?
> Only the ability to batch process given files based on their current
> settings. For what I want to do, I would just want to manipulate the XML
> settings files for my target image directly and then have Rawstudio
> process the image based on those settings.

If you're manipulating XML, then you could add your images to
~/.rawstudio/batch-queue.xml - then you would only have to press start
after starting Rawstudio. It's not CLI, but I think it's the best we can
do.

> Throw in the ability to batch process an entire folder, and preferably
> only the files of a given priority in that folder, now that you're at
> it; I sorely miss that sometimes. I'd like the ability to put a remote
> machine to work without being bound by a low bandwidth or low latency
> network connection.

I'm sorry, but I don't think you'll be able to do that in the near
future. Rawstudio really needs an X server.

> While we're on the topic of batch processing, when can we expect to see
> Rawstudio take advantage of multiple cores? Batch processing should
> be trivial to do in parallel. Indeed, even the interactive stuff could
> probably get an almost linear performance boost from adding more
> threads, but it'd probably be a lot harder to implement. Personally,
> though, I'd much rather see it in batch processing anyway.

Current development tree is "very" multithreaded. Both interactive,
background tasks and batch processing. Expect version 2.0 to take
advantage of multiple cores/cpu's.

> Anders> Would a D-Bus interface do?
> I doubt it, but I really couldn't say. I'm a systems guy, and my
> programmer's toolbox reflects that. I don't know more about D-Bus than
> what would fit in a tabloid headline.

Ok.

/Anders Brander


From martin.sand.christensen at gmail.com  Tue Aug  4 09:09:50 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Tue, 04 Aug 2009 09:09:50 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <1249357088.9677.7.camel@video64> (Anders Brander's message of
	"Tue, 04 Aug 2009 05:38:08 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64>
Message-ID: <871vnsm4w1.fsf@gmail.com>

>>>>> "Anders" == Anders Brander <anders at brander.dk> writes:
Anders> If you're manipulating XML, then you could add your images to
Anders> ~/.rawstudio/batch-queue.xml - then you would only have to press
Anders> start after starting Rawstudio. It's not CLI, but I think it's
Anders> the best we can do.

We're talking about thousands of runs. Monkey at keyboard is not an
acceptable solution. Do I really understand you correctly? Are you
telling me that making Rawstudio respond to command line arguments is
horribly difficult, and likewise that making it not show a window while
batch processing would require a lot of work? If so, I would wager that
the code would not be any worse off for a refactoring... :-) MVC and all
that.

>> Throw in the ability to batch process an entire folder, and
>> preferably only the files of a given priority in that folder, now
>> that you're at it; I sorely miss that sometimes. I'd like the ability
>> to put a remote machine to work without being bound by a low
>> bandwidth or low latency network connection.

Anders> I'm sorry, but I don't think you'll be able to do that in the
Anders> near future. Rawstudio really needs an X server.

Why is it necessarily so dependent on one for batch processing. Mind
you, I'm only talking about batch processing, nothing else.

Anders> Current development tree is "very" multithreaded. Both
Anders> interactive, background tasks and batch processing. Expect
Anders> version 2.0 to take advantage of multiple cores/cpu's.

Nifty! I'll try playing around with it. How difficult was it to go from
single-threaded to multi-threaded code? In my experience, if you want to
do properly synchronous code, it's almost a requirement that you
consider it in your design from the very beginning.


Martin


From anders at kvistmail.dk  Mon Aug  3 18:37:29 2009
From: anders at kvistmail.dk (Anders Kvist)
Date: Mon, 03 Aug 2009 18:37:29 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <87zlagsz26.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org>
	<h5611o$g1j$1@ger.gmane.org>	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com>
Message-ID: <4A771249.1060608@kvistmail.dk>

Martin Christensen wrote:
>>>>>> "Klaus" == Klaus Post <klauspost at gmail.com> writes:
> Klaus> That said, we will probably need quite a lot of help to create
> Klaus> profiles when the time comes.
> 
> I've actually given some thought to automating this procedure, and would
> have done something about it if Rawstudio could be convinced to do batch
> processing from the command line. I've been looking for some sort of
> interesting project for genetic algorithms, just to try them out, and
> approximating curves (or, in this case, colour profiles) would be a nice
> candidate. So if anyone can be arsed to give Rawstudio a suitable
> command line interface, I'd be happy to give the rest of the task a
> shot.

Why do you want this? The ability to process on a server or?

I don't know if it's that easy to do with the current rawstudio. It runs a
gtk_init() during startup which requires a running X...

That said, I'll give it a shot if you are willing to give the other things a shot :)

/Anders Kvist


From klauspost at gmail.com  Tue Aug  4 12:53:13 2009
From: klauspost at gmail.com (Klaus Post)
Date: Tue, 4 Aug 2009 12:53:13 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <871vnsm4w1.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org> 
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com> 
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2> 
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64> 
	<871vnsm4w1.fsf@gmail.com>
Message-ID: <cad77fcf0908040353s6be90d87xdc521fd3f574c178@mail.gmail.com>

> Nifty! I'll try playing around with it. How difficult was it to go from
> single-threaded to multi-threaded code? In my experience, if you want to
> do properly synchronous code, it's almost a requirement that you
> consider it in your design from the very beginning.

Some things were very easy, if there are no spatial dependencies, then
you just split the image in vertical slices and have each thread
process each slice, very easy and scales very well.

The sharpen/denoiser required a job/workqueue to be efficient.

The only operation that cannot be multithreaded is image decoding
(Lossless JPEG decoding to be specific), as it is a strictly linear
process, where every pixel in the image is depending on the previous.

Currently these filters are multithreaded:

Basic render (color correct), demosaic, denoise/sharpen, lensfun (the
processing done outside of liblensfun), resample (image resize),
rotate.

Furthermore the RawSpeed loader is multithreaded when possible (DNG images).


> Martin

Regards, Klaus Post

http://www.klauspost.com


From martin.sand.christensen at gmail.com  Tue Aug  4 15:27:34 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Tue, 04 Aug 2009 15:27:34 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <4A771249.1060608@kvistmail.dk> (Anders Kvist's message of "Mon, 
	03 Aug 2009 18:37:29 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <4A771249.1060608@kvistmail.dk>
Message-ID: <87tz0nso8p.fsf@gmail.com>

>>>>> "Anders" == Anders Kvist <anders at kvistmail.dk> writes:
>> So if anyone can be arsed to give Rawstudio a suitable command line
>> interface, I'd be happy to give the rest of the task a shot.

Anders> Why do you want this? The ability to process on a server or?

We're talking Unix. Every client IS a server. :-)

Let's have a use case. I've just shot several different sessions. I do
my usual tweaking of photos in Rawstudio, and by the time I'm done, it's
late. I want to sync with my server and then let the server process the
priority 1 RAWs (both in colour and B/W), zip each series and upload
them to a web server, while I shut down the client and go to bed.

Another use case. I'm visiting the in-laws, and they'd like copies of
some pictures of their most wonderful grandchildren that I took a while
back. They only have a Windows computer and a low-latency connection. I
shell into my server at home and instruct it to process, zip and upload
as above.

The current batch processing implementation is not sufficiently advanced
that I can export to multiple destinations, use different naming patters
different for files/directories etc., and I'm not sure if it's worth it
to add this complexity (both in terms of code and UI clutter). From the
command line, however, it's trivial to do this with a series of calls to
Rawstudio.

Anders> I don't know if it's that easy to do with the current rawstudio.
Anders> It runs a gtk_init() during startup which requires a running
Anders> X...

Then postpone gtk_init() until after command line arguments have been
processed. I've done next to no GUI programming, but for the life of me
I can't imagine that this is particularly difficult.

Anders> That said, I'll give it a shot if you are willing to give the
Anders> other things a shot :)

My vacation's coming up... :-)


Martin


From anders at brander.dk  Tue Aug  4 16:08:06 2009
From: anders at brander.dk (Anders Brander)
Date: Tue, 04 Aug 2009 16:08:06 +0200
Subject: [Rawstudio-dev] Headless Rawstudio, Was: Re:  image display quality
In-Reply-To: <871vnsm4w1.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64>
	<871vnsm4w1.fsf@gmail.com>
Message-ID: <1249394886.3494.6.camel@travelgate2>

Hi,

On Tue, 2009-08-04 at 09:09 +0200, Martin Christensen wrote:
> Anders> If you're manipulating XML, then you could add your images to
> Anders> ~/.rawstudio/batch-queue.xml - then you would only have to press
> Anders> start after starting Rawstudio. It's not CLI, but I think it's
> Anders> the best we can do.
> We're talking about thousands of runs. Monkey at keyboard is not an
> acceptable solution. Do I really understand you correctly? Are you
> telling me that making Rawstudio respond to command line arguments is
> horribly difficult, and likewise that making it not show a window while
> batch processing would require a lot of work? If so, I would wager that
> the code would not be any worse off for a refactoring... :-) MVC and all
> that.

Make Rawstudio accept command line arguments is easy (we already use a
few "hidden" arguments for debugging.
Make Rawstudio not depend on GTK+ is harder. GTK+ code is everywhere -
and GTK+ cannot we initialized without some sort of X display. It's
possible to make all the GTK+ code conditional, but it's not trivial.

> Anders> I'm sorry, but I don't think you'll be able to do that in the
> Anders> near future. Rawstudio really needs an X server.
> Why is it necessarily so dependent on one for batch processing. Mind
> you, I'm only talking about batch processing, nothing else.

It's not needed at all, but as of today it's not trivial.

/Anders Brander




From martin.sand.christensen at gmail.com  Sun Aug  9 14:58:09 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Sun, 09 Aug 2009 14:58:09 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <cad77fcf0908040353s6be90d87xdc521fd3f574c178@mail.gmail.com>
	(Klaus Post's message of "Tue, 4 Aug 2009 12:53:13 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64>
	<871vnsm4w1.fsf@gmail.com>
	<cad77fcf0908040353s6be90d87xdc521fd3f574c178@mail.gmail.com>
Message-ID: <87bpmp9mam.fsf@gmail.com>

>>>>> "Klaus" == Klaus Post <klauspost at gmail.com> writes:
Klaus> Some things were very easy, if there are no spatial dependencies,
Klaus> then you just split the image in vertical slices and have each
Klaus> thread process each slice, very easy and scales very well.

Obviously. Most photo manipulations can be written as transformation
matrices and could in principle be split into a separate thread per
pixel.

Klaus> The sharpen/denoiser required a job/workqueue to be efficient.

Why's that? Isn't that basically just the same thing as above except
with a bit of (read-only) overlap?

Klaus> The only operation that cannot be multithreaded is image decoding
Klaus> (Lossless JPEG decoding to be specific), as it is a strictly
Klaus> linear process, where every pixel in the image is depending on
Klaus> the previous.

Well, if you do manage to parallelise that, I'm sure you'd be in for
some kind of award. :-)

Klaus> Currently these filters are multithreaded:

Klaus> Basic render (color correct), demosaic, denoise/sharpen, lensfun
Klaus> (the processing done outside of liblensfun), resample (image
Klaus> resize), rotate.

What other filters could we expect to be parallelised in future?

Klaus> Furthermore the RawSpeed loader is multithreaded when possible
Klaus> (DNG images).

Why can't they all be multi-threaded?

Thanks for the status update. It's quite interesting.


Martin


From martin.sand.christensen at gmail.com  Sun Aug  9 15:03:24 2009
From: martin.sand.christensen at gmail.com (Martin Christensen)
Date: Sun, 09 Aug 2009 15:03:24 +0200
Subject: [Rawstudio-dev] Headless Rawstudio
In-Reply-To: <1249394886.3494.6.camel@travelgate2> (Anders Brander's message
	of "Tue, 04 Aug 2009 16:08:06 +0200")
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org>
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com>
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2>
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64>
	<871vnsm4w1.fsf@gmail.com> <1249394886.3494.6.camel@travelgate2>
Message-ID: <877hxd9m1v.fsf_-_@gmail.com>

>>>>> "Anders" == Anders Brander <anders at brander.dk> writes:
Anders> Make Rawstudio accept command line arguments is easy (we already
Anders> use a few "hidden" arguments for debugging. Make Rawstudio not
Anders> depend on GTK+ is harder. GTK+ code is everywhere - and GTK+
Anders> cannot we initialized without some sort of X display. It's
Anders> possible to make all the GTK+ code conditional, but it's not
Anders> trivial.

It sounds like a lot of code could do with a bit of cleaning. :-) Ah,
how conveniently easy it is to make these observations from the
sideline, resting assured that I will not be the one doing said
cleaning.

Anders> I'm sorry, but I don't think you'll be able to do that in the
Anders> near future. Rawstudio really needs an X server.
>> Why is it necessarily so dependent on one for batch processing. Mind
>> you, I'm only talking about batch processing, nothing else.
Anders> It's not needed at all, but as of today it's not trivial.

Is it going to happen in the foreseeable future?


Martin


From klauspost at gmail.com  Sun Aug  9 16:08:09 2009
From: klauspost at gmail.com (Klaus Post)
Date: Sun, 9 Aug 2009 16:08:09 +0200
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <87bpmp9mam.fsf@gmail.com>
References: <h55bpc$6cc$1@ger.gmane.org> <h5611o$g1j$1@ger.gmane.org> 
	<cad77fcf0908030808s78a80932i6ee23ce272e39ddc@mail.gmail.com> 
	<87zlagsz26.fsf@gmail.com> <1249328145.13233.5.camel@travelgate2> 
	<877hxkftgq.fsf@gmail.com> <1249357088.9677.7.camel@video64> 
	<871vnsm4w1.fsf@gmail.com>
	<cad77fcf0908040353s6be90d87xdc521fd3f574c178@mail.gmail.com> 
	<87bpmp9mam.fsf@gmail.com>
Message-ID: <cad77fcf0908090708m3cfb93c2qc16ad463f6850552@mail.gmail.com>

> Klaus> Some things were very easy, if there are no spatial dependencies,
> Klaus> then you just split the image in vertical slices and have each
> Klaus> thread process each slice, very easy and scales very well.
>
> Obviously. Most photo manipulations can be written as transformation
> matrices and could in principle be split into a separate thread per
> pixel.

Only the final color transform is a simple matrix.
As I wrote, they are split vertically - thread synchronization is
expensive, so a per-pixel thread is

> Klaus> The sharpen/denoiser required a job/workqueue to be efficient.
>
> Why's that? Isn't that basically just the same thing as above except
> with a bit of (read-only) overlap?

No it isn't - it a very advanced algorithm, that denoises and sharpens
in FFT (frequency domain) space. It is not completely unlike the
wavelet denoiser in dcraw, but it is much better at preserving detalis
in the denoiser and preventing oversharpining.

The processing is done in blocks of 128x128 pixels, so it was obvious
to create a job queue for handling these blocks.

I have a writeup planned, where I will write how it differs from
ordinary sharpen/denoisers.

> Klaus> Basic render (color correct), demosaic, denoise/sharpen, lensfun
> Klaus> (the processing done outside of liblensfun), resample (image
> Klaus> resize), rotate.
>
> What other filters could we expect to be parallelised in future?
There are currently are no (slow) filters that are not multithreaded.


> Klaus> Furthermore the RawSpeed loader is multithreaded when possible
> Klaus> (DNG images).
>
> Why can't they all be multi-threaded?
As I wrote above, Lossless JPEG is impossible to multithread. I have
done some tests where I split the decoder up in two parallel stages,
but the memory overhead and synchronization made it quite a bit
slower.

> Thanks for the status update. It's quite interesting.

No problem. :)


> Martin

Regards, Klaus Post

http://www.klauspost.com


From atenrok at gmail.com  Mon Aug 10 08:12:09 2009
From: atenrok at gmail.com (oleksandr korneta)
Date: Mon, 10 Aug 2009 02:12:09 -0400
Subject: [Rawstudio-dev] image display quality
In-Reply-To: <1249328630.13233.13.camel@travelgate2>
References: <h55bpc$6cc$1@ger.gmane.org>
	<1249328630.13233.13.camel@travelgate2>
Message-ID: <h5odnq$6cp$1@ger.gmane.org>

my apologies for abandoning the thread, I was away from my machine.

on 08/03/2009 03:43 PM Anders Brander wrote:
> Hi,
> 
> On Sun, 2009-08-02 at 20:42 -0400, oleksandr korneta wrote:
>> RawStudio and Ufraw side by side http://bayimg.com/image/eadljaaca.jpg
>>
>> I would like to use the former, but on my machine pictures look much 
>> better in the latter. What am I missing?
> 
> UFRaw and Rawstudio are two very different applications with different
> rendering algorithms.

it is obvious but the render by ufraw right off hand looks better to me.
> 
> Did you enable color management in Rawstudio?
> Which color profile did you use in UFRaw? in Rawstudio?

built-in RGB for this particular case, since I expected the question

> Did you use the "color matrix" option in UFRaw?
  yes, it is was on, as most of the time since I don't have a good 
profile for my 10D.

> 
> Even if you use the same color profiles in both applications, you cannot
> be sure that the result will look the same. Using ICC profiles for
> developing raw images is a lucky guess at best :)

well, I tried my best and couldn't make the images in rawstudio to 
resemble those rendered by ufraw. But as several people pointed out 
above life is easier with saturation at ~1.3. Doesn't help for me 100% 
though. I feel like hue is also different comparing to the value one is 
ufraw, and perhaps something else.
-- 
regards,
Oleksandr Korneta

I'm running F9 x86_64 and F10 i386 on x86_64 hardware, should this matter.

/The nice thing about standards is that there are so many to choose from./




From sampo at vuoret.net  Wed Aug 12 14:56:04 2009
From: sampo at vuoret.net (Sampo Vuori)
Date: Wed, 12 Aug 2009 15:56:04 +0300
Subject: [Rawstudio-dev] RS plugins?
Message-ID: <c8b3c5280908120556g2e6beec5y9b2cad5d43943c4a@mail.gmail.com>

Hi all!

Thanks devs and other contributors for the great raw developer for
linux! I have been thinking of making my own raw developer but now
that I see rawstudio approaching very much usable state I guess I
should try help pushing it forward instead.

I'd like to try writing a plugin for rawstudio (B&W for starters). Is
there any documentation of the plugin interface? Shipping a sample
plugin with the sources could help a lot too I think (I love examples
:-) I guess I'd need info about 1) how the data moves between plugin
and the program? 2) how do I register a plugin so the program knows
it's there 3) how do I specify how the plugin shows up in the GUI? 4)
what interface should it implement? (which functions need to be
implemented)

BTW. The idea of being able to specify the processing flow (what image
processors affect the image and in which order) is *great*

TIA, Sampo


From anders at brander.dk  Wed Aug 12 15:32:18 2009
From: anders at brander.dk (Anders Brander)
Date: Wed, 12 Aug 2009 15:32:18 +0200
Subject: [Rawstudio-dev] RS plugins?
In-Reply-To: <c8b3c5280908120556g2e6beec5y9b2cad5d43943c4a@mail.gmail.com>
References: <c8b3c5280908120556g2e6beec5y9b2cad5d43943c4a@mail.gmail.com>
Message-ID: <1250083938.18612.23.camel@video64>

Hi,

On Wed, 2009-08-12 at 15:56 +0300, Sampo Vuori wrote:
> Thanks devs and other contributors for the great raw developer for
> linux! I have been thinking of making my own raw developer but now
> that I see rawstudio approaching very much usable state I guess I
> should try help pushing it forward instead.

You're very welcome! But if you would like to have your filter included
in mainline Rawstudio, be prepared for some discussion ;-)

Please make sure that you are using newest Rawstudio from subversion.
The filter code is currently being developed and is subject to change at
any time.

First of, an introduction to the various types involved:
RSPlugin: Basic plugin class, takes care of loading and unloading plugin
code.
RSFilter: Filter class, defines what a filter (not a plugin!) must
implement and do.
RSFilterParam: Gives _SOME_ parameters to filters.
RSFilterResponse: Filters use this for sending response data to the next
filter in the chain.

Some sources to study if you plan on developing an image filter:
librawstudio/rs-plugin-manager.c
librawstudio/rs-filter.c
librawstudio/rs-filter-param.c
librawstudio/rs-filter-response.c

If you have graphviz installed, you can try "Debug" -> "Filter Graph"
for an overview of the current filter chain.

If you look at the console when starting Rawstudio, you can currently
see some debug information about loaded plugins.

> I'd like to try writing a plugin for rawstudio (B&W for starters). Is
> there any documentation of the plugin interface? Shipping a sample
> plugin with the sources could help a lot too I think (I love examples
> :-) I guess I'd need info about

The documentation for writing plugins for Rawstudio is non-existent at
the moment. Currently there is an outdated template in contrib/.
Hopefully someone will get around to update it at some point :)
Try to get a look at some of the filters currently implemented, it's the
best documentation we have right now. plugins/rotate/rotate.c is quite
simple.

> 1) how the data moves between plugin and the program?

Well. For the most part it doesn't. It mostly moves from filter to
filter. The application can use rs_filter_get_image() (and a handful of
other functions) to extract data from the last filter.

g_object_set() is used for setting processing parameters for most
filters.

> 2) how do I register a plugin so the program knows it's there

It's quite simple. Just install it ;) Rawstudio will search the plugin
path for any plugins.
For an example of an plugin that build out-of-tree take a look at
RawSpeed.

If you develop your plugin in-tree, just add it to the relevant
Makefile.am's and configure.in.

"./contrib/new_filter.sh RS_FILTER_NAME RSFilterName rs_filter_name"
will create a (outdated) template for you to build on, and tell you
which files you need to modify.

> 3) how do I specify how the plugin shows up in the GUI?

Currently plugins have no way of altering the GUI.

> 4) what interface should it implement? (which functions need to be
> implemented)

You should try to take a look at some of the current filters.
plugins/rotate/rotate.c is quite simple.

> BTW. The idea of being able to specify the processing flow (what image
> processors affect the image and in which order) is *great*

Please note that this is only for the programmer - not for the end user.
And probably never will be.

/Anders Brander


From sampo at vuoret.net  Wed Aug 12 20:55:25 2009
From: sampo at vuoret.net (Sampo Vuori)
Date: Wed, 12 Aug 2009 21:55:25 +0300
Subject: [Rawstudio-dev] RS plugins?
In-Reply-To: <1250083938.18612.23.camel@video64>
References: <c8b3c5280908120556g2e6beec5y9b2cad5d43943c4a@mail.gmail.com>
	<1250083938.18612.23.camel@video64>
Message-ID: <c8b3c5280908121155l7d1cc6b1k3dc99fb055df61d1@mail.gmail.com>

> You're very welcome! But if you would like to have your filter included
> in mainline Rawstudio, be prepared for some discussion ;-)

Thanks, I'm prepared :-)

> Please make sure that you are using newest Rawstudio from subversion.
> The filter code is currently being developed and is subject to change at
> any time.

Yup, I've been using that for a while.. can't wait to have the latest features.

> If you have graphviz installed, you can try "Debug" -> "Filter Graph"
> for an overview of the current filter chain.

This seems to show only the default chain which is specified in
application.c .. is that right? At least my installed plugin does not
appear there unless I add it to the chain which I think I'm not
supposed to do.

>
> If you look at the console when starting Rawstudio, you can currently
> see some debug information about loaded plugins.

Yeah, I managed to get my plugin show up there.

>> 1) how the data moves between plugin and the program?
>
> Well. For the most part it doesn't. It mostly moves from filter to
> filter. The application can use rs_filter_get_image() (and a handful of
> other functions) to extract data from the last filter.

What specifies in which order the plugins are processed?

>
> g_object_set() is used for setting processing parameters for most
> filters.

If the plugin is not marked "dirty" via setting the properties does it
ever get computed (is get_image called for it)? My problem is that the
plugin does the loaded but it does not affect the images.. I tried
putting it in the filter chain in application.c and it seems to work
(wow :-) but I can't make it do anything if I don't hardwire it in the
filter chain.

>> 2) how do I register a plugin so the program knows it's there
>
> It's quite simple. Just install it ;) Rawstudio will search the plugin
> path for any plugins.
> For an example of an plugin that build out-of-tree take a look at
> RawSpeed.

I think I'll have a look at that too :-)

>> 3) how do I specify how the plugin shows up in the GUI?
>
> Currently plugins have no way of altering the GUI.

So the GUI has to be built in the application itself? I think I'd like
to have a color picker for the B&W filter to simulate color filters.

>> BTW. The idea of being able to specify the processing flow (what image
>> processors affect the image and in which order) is *great*
>
> Please note that this is only for the programmer - not for the end user.
> And probably never will be.

That's a shame.. I liked the idea in Lightzone.


- Sampo


From anders at brander.dk  Wed Aug 12 22:14:49 2009
From: anders at brander.dk (Anders Brander)
Date: Wed, 12 Aug 2009 22:14:49 +0200
Subject: [Rawstudio-dev] RS plugins?
In-Reply-To: <c8b3c5280908121155l7d1cc6b1k3dc99fb055df61d1@mail.gmail.com>
References: <c8b3c5280908120556g2e6beec5y9b2cad5d43943c4a@mail.gmail.com>
	<1250083938.18612.23.camel@video64>
	<c8b3c5280908121155l7d1cc6b1k3dc99fb055df61d1@mail.gmail.com>
Message-ID: <1250108089.18612.31.camel@video64>

Hi :-)

On Wed, 2009-08-12 at 21:55 +0300, Sampo Vuori wrote:
> > If you have graphviz installed, you can try "Debug" -> "Filter Graph"
> > for an overview of the current filter chain.
> This seems to show only the default chain which is specified in
> application.c .. is that right? At least my installed plugin does not
> appear there unless I add it to the chain which I think I'm not
> supposed to do.

That's exactly what you're supposed to do. I was referring to the filter
graph, because it can give you some ideas about where your filter would
best fit in the flow. Most of the chain is specified in application.c
and rs-preview-widget.c.

> > If you look at the console when starting Rawstudio, you can currently
> > see some debug information about loaded plugins.
> Yeah, I managed to get my plugin show up there.

You're halfway there! :)

> >> 1) how the data moves between plugin and the program?
> > Well. For the most part it doesn't. It mostly moves from filter to
> > filter. The application can use rs_filter_get_image() (and a handful of
> > other functions) to extract data from the last filter.
> What specifies in which order the plugins are processed?

The filter initialization only. And there is currently no way for the
user to alter this at runtime.

> > g_object_set() is used for setting processing parameters for most
> > filters.
> If the plugin is not marked "dirty" via setting the properties does it
> ever get computed (is get_image called for it)? My problem is that the
> plugin does the loaded but it does not affect the images.. I tried
> putting it in the filter chain in application.c and it seems to work
> (wow :-) but I can't make it do anything if I don't hardwire it in the
> filter chain.

The dirty flag is not exposed outside the filter itself. All logic
depending on dirty must be implemented by the filter itself.
- and you are correct, filters must be hardcoded in the application.

> >> 3) how do I specify how the plugin shows up in the GUI?
> > Currently plugins have no way of altering the GUI.
> So the GUI has to be built in the application itself? I think I'd like
> to have a color picker for the B&W filter to simulate color filters.

That's understandable - but currently plugins in Rawstudio mostly helps
the development of Rawstudio, not really the end user. You will also
note that plugins aren't exposed anywhere in the UI.

> >> BTW. The idea of being able to specify the processing flow (what image
> >> processors affect the image and in which order) is *great*
> > Please note that this is only for the programmer - not for the end user.
> > And probably never will be.
> That's a shame.. I liked the idea in Lightzone.

I think many did. But it's not a priority in Rawstudio. I'm not sure it
ever will be.

/Anders Brander


From giallu at gmail.com  Mon Aug 24 16:01:50 2009
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 24 Aug 2009 16:01:50 +0200
Subject: [Rawstudio-dev] Crash report: sounds familiar?
Message-ID: <d5ad21470908240701x198539a4t9eb86de85db8cf3@mail.gmail.com>

Hi all,
thanks to a new tool in Fedora which is catching and automatically
reporting program crashes, I received this shiny report complete with
a traceback:

 https://bugzilla.redhat.com/show_bug.cgi?id=518540

does it sound familiar to anyone (that is, could it be fixed already in SVN?)

TIA

Gianluca


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna