Large memory leak when using RL Deconv sharpening

[Beep6581]

Originally reported on Google Code with ID 1564

Quite nasty, actually fills up RAM pretty fast in certain situations, may crash your
machine.
Here is the fix (one of my last ones ;-)

Reported by oduis@hotmail.com on 2012-09-18 21:55:41

---

• Attachment: sharpenLeak.patch

[Beep6581]

PS: The reason why some people report problems while others (espc. with fast hardware)
don't is that the memleak only gets wild if OpenMP decides to parallize a certain sections.
The decision depends on your hardware.

Reported by oduis@hotmail.com on 2012-09-18 22:41:53

[Beep6581]

Olli, what do you mean one of your last ones?!!!!

Reported by michaelezra000 on 2012-09-19 00:00:38

[Beep6581]

Morning Michael,
I downloaded a 30 days demo of Lightroom 4.1, initially to make same quality comparisons
with RT.
However I found that the new 4 version of LR has gained significantly in quality in
all areas. Yes, RL Deconv sharpening is a bit better than LRs sharpening, and Emils
Color Propagation is better than LR on some images. But say 95% of the test images
there is no quality difference, even when pixel peeping.
I created a special DCP profile on basis of RTs camera profile so the color handling
of LR is better and feels like RT (the big weakness why I left for RT), so this is
also solved.
LR is moving in the opposite direction of RT: instead of adding yet-another-slider,
it even reduced the controls to make it all-automatic, for instance they removed the
highlight recovery controls and integrated them in the exposure controls (which works
nice in most cases).
The pros for LR are that it is a LOT faster, and has a LOT useful features espc. for
mass editings, RTs UI is really no comparison. After a few hours and one of my friends
showing me some stuff, I really found it a joy to use, speeding up my photo edits where
I use to spend many hours a lot. You can do roughly the same with fewer sliders and
shorter time per image.
So I decided that I’ll buy LR (it’s got cheap) and use it together with RT like some
other folks in the forums. So for mass edits I use LR, while for the few extreme shots
where LR fails or when I prepare e.g. a must-have-the-last-1%-quality-image-for-print
I’ll continue to use RT.
Hence I will reduce my efforts in RT a bit. I will still provide some patches like
these and official dot builds, but not in that intensity any more.

Reported by oduis@hotmail.com on 2012-09-19 05:44:45

[Beep6581]

PS: If you also want to try the demo, it's freely downloadable, here is the modified
D700 profile with neutral, "RTish" color rendering for LR:

Reported by oduis@hotmail.com on 2012-09-19 06:07:12

---

• Attachment: [Nikon D700 Olli Neutral.dcp](https://storage.googleapis.com/google-code-attachments/rawtherapee/issue-1564/comment-4/Nikon D700 Olli Neutral.dcp)

[Beep6581]

Hi Olli, I do have ACR 7.1 as I upgraded to Photoshop CS6, so essentially the same engine
as LR4.1.  You are right, ACR clearly has improved. I am surprised why dcp needs to
be different? (I have various dcp-s created with Adobe's DNG profile editor and as
I previously was using them in ACR, continued to use them in RT).

For UI simplification, we could migrate more specialized tools to a new Advanced tab
or allow tools to be hidden via preferences. Eventually, more automation probably can
be migrated and embedded into newer tools once RT evolves in even more comprehensive
understanding of capabilities of exiting ones. I suppose internally in Adobe ACR has
million more sliders for R&D and they are used to design smart behavior of those sliders
which are left to the user. Eventually RT will go through this lifecycle, but only
if we have people like you:)...

Reported by michaelezra000 on 2012-09-19 11:54:07

[Beep6581]

Small, yet elegant and important fix, thank you.

I turn sometimes to Capture NX2 or LR4 when it comes to color balance, skin tones or
consistency so I get your point, Olli. That's what I say all the time: if someone focuses
on the photographic part (and less on the technical), the workflow becomes a crucial
element.
Yet the openness and evolvability of RT keeps calling me back. I hope that you will
find the time and motivation to work on this project, as it indeed does need you!

Maybe the core rewriting (a.k.a. "rtengine2") should be prioritized again... would
that motivate you more?

Reported by gyurko.david@e-arc.hu on 2012-09-19 13:31:46

[Beep6581]

Glad to see that I’m not the only one using other raw developers in parallel as well
:-)  I already felt a bit like a traitor even opening other software ;-)

Maybe it’s good that RT gets more complicated constantly to allow more detailed control.
So it better complements LR which gets easier and auto-smarter (but maybe less fine-controllable).
I’m not sure if it would be a good strategy to try to copy LR in that way. We’ll never
reach it and would just play catch-up all the time, it’s really comprehensive and good
in its area.

So instead of rewriting RT and copy LR, maybe better focus on high-tech feature that
LR does not offer, to aim to complement it in the niche. 
So push features like e.g. Emils high tech algorithms like Contrast-by-Detail, Color
Propagation, that are slow and complicated, but really give a visible edge over LR
sometimes. On the other hand it would be wasted effort to copy things like local editing
etc. It would be enormous work, and end up as cheap, suboptimal copies of the more
powerful and elegant tools found in commercial converters like LR.

@Michael: Most of our RT DCPs don’t contain a tone curve, but LR adds auto-adds a default
curve then (like when generated with Adobe DNG Profile editor). So I modified the RT
profile that it contains a defined straight curve. Otherwise LR has a contrast curve
that may look nice on most images, but as you say in the other issue, on a few images
the color get a bit dirty. With that profile it renders mostly like RT, neutral and
with full control on your side.

Reported by oduis@hotmail.com on 2012-09-19 14:15:10

[Beep6581]

Oh, I see. I always used only a linear curve in my custom dcp-s, that's why there was
no difference.

I think you are right, significant specialized improvements would be in auto CA quality
(I mentioned this to Emil, he suggested that fitting to LCP lens model might provide
better results), speed of NR (GPU?).

Reported by michaelezra000 on 2012-09-19 14:29:43

[Beep6581]

I guess performance should not be the focus. LR is so ultrafast that we'll never match
it anyway. And we don't have the manpower, it's complicated work to fine tune assembly
statements and GPU stuff.
But if we define RT as the complement for difficult cases, it needened be so fast anyway.

But as you say, things like Auto-CA might persuade people that it's more precise and
fine-fitting than one of the lower quality (Tamron, Sigma...) LCP profiles in LR. No
problem if it is slow for the 5 image you print in large.

Reported by oduis@hotmail.com on 2012-09-19 14:45:03

[Beep6581]

ok, then from complementarity perspective XMP branch should get the high priority. Actually,
now that denoise is merged, this is the only outstanding big elefant.

Reported by michaelezra000 on 2012-09-19 15:18:39

[Beep6581]

Hehe, I felt like a traitor too when I first opened Capture NX2... :]

However, I don't think we compete directly with LR: just think about the Linux users
at first, then about those amateurs who can't or won't pay for LR.
There is always a huge niche for an open source, quality raw development tool.

Reported by gyurko.david@e-arc.hu on 2012-09-19 18:10:04

[Beep6581]

Oh, you like NX2? Haven't played with it, better then LR4?

LRs prices have come down a lot. Street price is around 115 EUR here, which is not
a big deal in comparison to the cost for good DSLRs and lenses.

XMP branch is not really needed for integration with LR I guess. Say you use LR for
all your tagging, sorting, organizing. Then for the few which don't develop well in
LR, you configure RT as external editor in RT. It will open in the reduced mode (no
queue, file browser etc.), you edit the image. Then with already available XMP passtrough
all the tagging etc. from LR is transfered to the result file. All good.

Committed to default by the way, thanks for testing, David.

Reported by oduis@hotmail.com on 2012-09-19 19:05:34

• Status changed: Fixed

[Beep6581]

"we could migrate more specialized tools to a new Advanced tab"
I'm strongly against such a thing. The proper way of going about it is to make better
use of what GTK offers, e.g. floating panels. Don't like a tool? Move it away, detach
it, or hide it.

"I guess performance should not be the focus. LR is so ultrafast that we'll never match
it anyway. And we don't have the manpower, it's complicated work to fine tune assembly
statements and GPU stuff."
I don't agree with this either. The point isn't to catch up to LR, the point is to
make use of what most people have, primarily the GPU. If way smaller graphical projects
than RT can do it, RT can do it.

Reported by entertheyoni on 2012-09-19 19:43:52

[Beep6581]

> If way smaller graphical projects than RT can do it, RT can do it.
I didn't say it can't be done. My point is that using the GPU is more complex than
using OpenMP. And say some dev spends many work hours to get RT, say, 2x faster. Then
it's still far from e.g. LRs speed, so no LR guy will switch sides.
And RTs greatest "selling point" for using it in conjunction with LR (or other professional
tools), the superior fine tuning quality, hasn't gotten better either.
So the many dev hours would better be spent on advanced tools that offer significantly
better quality than LR. If you just use RT as specialized tool for a few pics, it not
a big deal if it is slower.

Reported by oduis@hotmail.com on 2012-09-19 20:40:35

[Beep6581]

Capture NX2 feels primitive compared to RT, but it is the de facto converter of Nikon
(precisely Nik Software, which is acquired recently by Google), so it provides the
exact same color balance and response as the camera bodies do. Besides that, U points
are basically the only advantage.

115 EUR may be a lot for some people. In Hungary the average income of a starting medical
doctor is 400 EUR...

Anyways, the point is: RT is in an important niche. :)

Reported by gyurko.david@e-arc.hu on 2012-09-19 23:33:38

[Beep6581]

I use RT not because I can't afford better, and I don't think RT's task is to convert
LR users :]

I don't mind the queue speed as it is - 4 seconds per photo using the Default profile
is great, when using EPD and NR its over tenfold that but still acceptable since you
can move on to do other work in the meanwhile. It's the preview responsiveness that
matters most to me - I would both like to be able to see the effect of all tools irrelevant
of zoom, and to have it fluid, and that would require the GPU. IIRC JanRinze's rtviewer
handles denoise (the old algo) preview at any zoom level in real time even when panning,
and it doesn't even use the GPU yet.

Reported by entertheyoni on 2012-09-19 23:51:13

[Beep6581]

> handles denoise (the old algo) preview at any zoom level 
Low hanging fruits. I'd like to see that for the current algo, and e.g. color propagation
;-)

> It's the preview responsiveness that matters most to me 
Just try LR4, it's really a joy to use in that respect. Working a few hours with it,
I really found myself focussing more on what should be done instead of how I do it
most effeciently. It's all just there. And the two monitor mode with laptop screen
is a real hit, much better than the one I added some month ago to RT.

Reported by oduis@hotmail.com on 2012-09-20 05:55:24

[Beep6581]

Anyway, to sum up:
Either RT takes the path as class-B raw converter for guy who can't afford a good one
or have no alternative (Linux). Or it could take the path to be a complementary product
for the professional converters from my point of view.

Reported by oduis@hotmail.com on 2012-09-20 05:57:58

[Beep6581]

But I wouldn't rate a program/application that doesn't run solely on windows or MAC
as class-B just because of this,even if I wanted I can't run many editing programs
(including DPP for my Canon camera) because they don't have a Linux version,so I'm
glad that an high(er) quality alternative as RT exists.
Taking the path of the "complementary product" to commercial raw converters is too
much of a restrictive point of view IMHO,RT despite of its limited resources has come
a long way since the beginning,thanks to the work of many developers including you,so
why can't we think of it as a specialized,high quality raw converter that has a place
of its own,and doesn't have to compare/compete with commercial products inevery aspect
at all costs..

Reported by msth67 on 2012-09-20 06:41:50

[Beep6581]

I agree with msth67.

I, for one, could afford LR too, but for linux it is not a solution. It also won't
be open source.
There is plenty of room for development in RawTherapee before it becomes the direct
competitor of Lightroom... see profiles (multiple profiles, profile history, snapshots,
etc. in XMP), color balance and handling (mimic camera color response, brightening
and darkening with a single curve, good default profiles for portrait, etc.), noise
reduction, DAM features, full-time preview of most/all tools... and the list is just
started. :)

Reported by gyurko.david@e-arc.hu on 2012-09-20 07:13:49

[Beep6581]

I don't think RT should define itself by where it lies relative to LR or any other program.

Reported by entertheyoni on 2012-09-20 08:17:50

[Beep6581]

Considering the market or comparing softwares is not the same IMO as defining the project
relatively to others.

The end of the story: (1) I think we agree that RawTherapee has its own niche, (2)
it is pointless to directly compete with Lightroom, but (3) we can learn from anyone
/ any software. Especially if a lot of manpower is put into it.

Reported by gyurko.david@e-arc.hu on 2012-09-20 09:26:35

[Beep6581]

Ok, we've heared the Linux party now ;-)
Like I said, I see this all as a matter of priorities in the face of scarce developer
resources.
Anyway, I'm still happy to help in development for the complementary part, as discussed
above.

Reported by oduis@hotmail.com on 2012-09-20 11:54:07