Beep6581 / RawTherapee

A powerful cross-platform raw photo processing program
https://rawtherapee.com
GNU General Public License v3.0
2.81k stars 318 forks source link

converting RT image pipeline to float #427

Closed Beep6581 closed 9 years ago

Beep6581 commented 9 years ago

Originally reported on Google Code with ID 437

I started a new branch to convert the RT image processing pipeline to floating point
throughout.  So far I have ported most of the Lab image processing to floating point.
 I am not sure all the image processing tools are working as desired, but basic exposure
adjustments seem to be OK.

The next step will likely be to star converting the RGB processing to floating point,
in particular raw conversion.

For the moment, I would like to ask that I be the only one allowed to check in changes
to this branch; of course, anyone is free to post patches for me to vet for check-in.

Reported by ejm.60657 on 2010-12-26 17:15:30

Beep6581 commented 9 years ago
A patch to convert to lcms2.  Seems to work on my machine; didn't look for color management
issues yet.  You will need to rerun cmake.

Reported by ejm.60657 on 2011-01-08 18:10:18


Beep6581 commented 9 years ago
Can lcms2 be run in parallel? I saw in current code there is always a mutex to prevent
parallel execution of color transformation.

Reported by ffsup2@yahoo.it on 2011-01-08 18:48:11

Beep6581 commented 9 years ago
I believe it is somewhat set up for multithreading, we'd have to look at the info at
http://www.littlecms.com/ (perhaps including some of the discussion on the mailing
list archive) to see what they say.

Right now I'm struggling with Gabor's idiosyncratic matrix transforms between standard
color spaces and XYZ.  I think Jan had issues with this too, which is why we split
off the exposure patch. 

Reported by ejm.60657 on 2011-01-08 19:04:25

Beep6581 commented 9 years ago
I would also need help.  I have no clue what a mutex is or does.

Reported by ejm.60657 on 2011-01-08 19:05:07

Beep6581 commented 9 years ago
changeset cf2394b60c compiles, on windows, but RT crashes with Glig::KeyFileError
I deleted the options file, still the same error.

Reported by michaelezra000 on 2011-01-10 01:32:54

Beep6581 commented 9 years ago
Could you supply an error log from gdb?

Reported by ejm.60657 on 2011-01-10 03:41:15

Beep6581 commented 9 years ago
hmm well, this may not be very helpful, I am afraid:)

Starting program: S:\Projects\Eclipse\RT\rawtherapee_default_437float\release/rt.exe
[New Thread 6500.0x1af8]
[New Thread 6500.0x1494]
[New Thread 6500.0x14ec]
[New Thread 6500.0x1428]
[New Thread 6500.0x15ec]

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(rt.exe:6500): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",
[New Thread 6500.0x16b8]
[New Thread 6500.0x14d8]
[New Thread 6500.0x14e8]
[New Thread 6500.0xee4]
[New Thread 6500.0x113c]
terminate called after throwing an instance of 'Glib::KeyFileError'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Program exited with code 03.
(gdb) bt
No stack.
(gdb)

Reported by michaelezra000 on 2011-01-10 04:24:12

Beep6581 commented 9 years ago
I have converted more of the pipeline to float, it seems to have resolved a number of
additional clipping issues; along the way I uncovered a bug that was generating some
of the color differences with default.  As an example of improvements, here is a long
exposure from DrSlony with hot/dead pixel filtering applied, to both default and to
float (this is float before the last changeset)

http://theory.uchicago.edu/~ejm/pix/20d/posts/ojo/hotdead_float-vs-default.jpg

and after the last changeset, the colors agree better, and the 'dead' pixels, which
were a clipping artifact, are gone completely:

http://theory.uchicago.edu/~ejm/pix/20d/posts/ojo/hotdead_float2.jpg

There are a few remaining hot pixels -- a shortcoming of the filter algorithm, which
has trouble eliminating two adjacent pixels that are both hot.  An application of impulse
noise reduction with a lowish setting cleaned the stragglers away nicely.

Reported by ejm.60657 on 2011-02-03 16:28:40

Beep6581 commented 9 years ago
I see some difference in sharpness in all illustrations, were all sharpening settings
disabled for each illustration?

Reported by michaelezra000 on 2011-02-03 16:51:01

Beep6581 commented 9 years ago
It looks as though sharpening was turned on in the first comparison image; it was definitely
off in the last image.  I suspect I turned it on in the first set to accentuate the
artifacts, which in any event are not there any more (I checked by doing some sharpening
on the last one).  Conversion to float is not expected to have a dramatic effect on
image sharpness; rather it will get rid of these sorts of artifacts, and should in
the end improve color accuracy.

Reported by ejm.60657 on 2011-02-03 17:20:35

Beep6581 commented 9 years ago
attached a patch that will avoid crashes during sharpening with the float branch. will
also fix some compilation errors about memcpy().

Reported by janrinze on 2011-02-06 16:40:12


Beep6581 commented 9 years ago
Thanks janrinze, i will try it this afternoon!

Reported by michaelezra000 on 2011-02-06 16:53:09

Beep6581 commented 9 years ago
Jan, I pushed your patch to float.  Also corrected a botched update to dcraw 9.06

Reported by ejm.60657 on 2011-02-06 18:10:48

Beep6581 commented 9 years ago
I just tested the patch on 9d29122341df+ (float).
1- There are black blobs over clipped areas of the image. When a camera ICM profile
is used, the highlight recovery amount (HLA) slider does weird things - notice that
the weird effect becomes more and less intense every few HLA value changes; its intensity
grows and shrinks in cycles.
2- Hot/dead pixel reduction doesn't work well. Fiddling with the threshold value just
changes the individual hot pixels that disappear, no setting of the slider seems to
be better then any other.

Video of the problem [9.4MB] http://www.rawtherapee.com/bugs/437/rt_float_clipping_and_hotpixels.mp4

Raw file used [11.3MB] http://www.rawtherapee.com/test_images/hot_pixels_long_exposure_381s.pef

Reported by entertheyoni on 2011-02-06 18:55:58

Beep6581 commented 9 years ago
1 -- I can reproduce the issues with exposure slider; HLA is probably related since
they are applied at the same time.  I suspect it's something that hasn't been converted
to float yet, or clipping that is applied at the wrong time (or not applied at the
right time).  I'll have a look.

2 -- Seems as though hot/dead pixel filtering is not working at all for you, which
is quite the opposite of what I find (see the posted images above in comment 60). 
I cannot reproduce this issue at the moment.

Reported by ejm.60657 on 2011-02-06 19:43:32

Beep6581 commented 9 years ago
Which revision did you use for comment 60? I'll try it.

Reported by entertheyoni on 2011-02-06 20:07:29

Beep6581 commented 9 years ago
Most likely it was 890 : 9de5b6b9e1d0

Reported by ejm.60657 on 2011-02-06 20:38:59

Beep6581 commented 9 years ago
9de5b6b9e1d0 is changeset 828, latesttagdistance 601
Applying the patch to this revision works, but compilation fails: http://pastebin.com/e4N6FV77

Oh well, nevermind, the latest revision compiles, that's important... it's just that
it doesn't work well :]

Reported by entertheyoni on 2011-02-07 00:12:18

Beep6581 commented 9 years ago
I know what the problem is.  Patch coming soon.

Reported by ejm.60657 on 2011-02-07 04:52:14

Beep6581 commented 9 years ago
I think this issue can be closed. ?

Reported by ffsup2@yahoo.it on 2011-09-02 09:32:22

Beep6581 commented 9 years ago
You think so?  ;-)

Reported by ejm.60657 on 2011-09-02 11:59:42

Beep6581 commented 9 years ago

Reported by rinni@gmx.net on 2013-01-28 14:40:00