4.1

[Beep6581]

Originally reported on Google Code with ID 2032

RT is fast and stable. So many new features since 4.0, or even since 4.0.11. Let's tag
4.1 stable soon.

Please add your realistically doable issues to "blocked on" below. They should take
not more than two weeks to complete, giving us a few days buffer before releasing near
the end of the month.

Reported by entertheyoni on 2013-11-07 00:35:13

[Beep6581]

ooops did blocking the other way around :-), fixing....

Reported by torger@ludd.ltu.se on 2013-11-07 07:43:42

• Blocked on: #783, #2002

[Beep6581]

Why 795: should be easy to fix, proper zoom logic has dragged for a loooong time you
see it all the time, and fixing it will make the app feel much more polished

Why 2018: started, easy to fix (once decided), currently confusing see often issue

Reported by torger@ludd.ltu.se on 2013-11-07 07:48:02

[Beep6581]

Why 2034: if we ever get around to build OS X release it would be nice if curves actually
works properly, as many tools use the curve widget

Reported by torger@ludd.ltu.se on 2013-11-07 12:07:17

• Blocked on: #2018

[Beep6581]

Added 4 Issues, which I should be able to complete during the next 10 days.

Ingo

Reported by heckflosse@i-weyrich.de on 2013-11-07 21:53:32

• Blocked on: #1819, #1905, #2005, #2021

[Beep6581]

I've been looking a little bit on OSX. Note that I'm 99% a Linux user so I'm doing this
only because I happen to have an OSX box here.

Due to some immediately noted bugs the OS X build looks to be in pretty bad shape.
However only by fixing issue 2018 (already a patch for that) and issue 1935 the OS
X version would look a lot better.

issue 1935 includes the task of adding a dependency to gtk-osx-integration lib, which
would require me to learn the cmake system, which is currently too big a task for me.
Someone who knows how its done can probably do it in 10 minutes while I would need
hours. If someone could fix with adding the dependency I could hopefully fix the rest.

Reported by torger@ludd.ltu.se on 2013-11-08 17:31:59

[Beep6581]

Have had very good progress on OSX. I think we can make a really nice 4.1 build.

Adding 1287 to the list, need to get a decision on if we can remap Ctrl-Q to Ctrl-B
(or something else) as suggested there, as we want to reserve Cmd-Q on the mac for
quitting as it's an expected standard shortcut. Having Ctrl-Q for batch queue would
be strange.

Reported by torger@ludd.ltu.se on 2013-11-10 13:41:35

• Blocked on: #1271

[Beep6581]

This issue has a duplicate, issue 1403

Reported by torger@ludd.ltu.se on 2013-11-10 13:47:07

[Beep6581]

Having first run strangeness (when .config does not exist) on OS X, and maybe Linux
(haven't tested there as I have valuable config on that system). Need clarification
on issue 841 for this. Maybe the bundle need to include something more, or there's
a bug in 853 patch.

Reported by torger@ludd.ltu.se on 2013-11-10 15:18:06

• Blocked on: #841

[Beep6581]

Reported by entertheyoni on 2013-11-10 21:34:07

• Blocked on: #1851

[Beep6581]

Removed Issue 2021 from blocking this Issue. Will concentrate on 1835.

Ingo

Reported by heckflosse@i-weyrich.de on 2013-11-11 00:26:42

• No longer blocked on: #2021

[Beep6581]

Reported by entertheyoni on 2013-11-11 01:55:52

• Blocked on: #2024, #2025

[Beep6581]

Torger maybe mattintosh4 can help you with OS X issues, you could try emailing him as
I don't know if he monitors general GC issues. As for Ctrl+Q, it would be good to remap
this for all platforms - e.g. can't quit RT when using Awesome window manager in Linux.

Reported by entertheyoni on 2013-11-11 02:34:57

[Beep6581]

Ok, I can do the remap. I'm just a bit worried I'll upset users that press Ctrl+Q to
put on batch queue and now it will close the program :-). The current pp3 will be saved
though so there will be no work lost until learning to press Ctrl+B.

I don't have much platform-specific issues on OS X left now I think, what's left seems
to be stuff that's shared with Linux, but we'll see.

Reported by torger@ludd.ltu.se on 2013-11-11 08:35:19

[Beep6581]

issue 2026 is somewhat related to 1867, concerns the batch queue output folder.

Reported by torger@ludd.ltu.se on 2013-11-11 12:34:23

• Blocked on: #2026

[Beep6581]

@comment 20: then we must add this info to the RELEASE_NOTES so there are no excuses
that "I didn't know".

Reported by entertheyoni on 2013-11-11 14:42:33

[Beep6581]

Reported by heckflosse@i-weyrich.de on 2013-11-11 23:15:13

• No longer blocked on: #1819

[Beep6581]

Reported by heckflosse@i-weyrich.de on 2013-11-12 00:10:57

• No longer blocked on: #1905, #2005

[Beep6581]

Reported by natureh.510 on 2013-11-12 16:47:01

• Blocked on: #2030

[Beep6581]

Reported by entertheyoni on 2013-11-13 01:01:34

• Blocked on: #2029

[Beep6581]

Issue 1971: I'm going to make an attempt for fixing DCP support so we can handle a wider
range of DCPs (can only handle old Adobe Standard DCPs and some tool-generated DCPs
now). If it's shown to be too much work I'll give up and postpone after 4.1.

Reported by torger@ludd.ltu.se on 2013-11-13 09:12:04

• Blocked on: #1971

[Beep6581]

Reported by natureh.510 on 2013-11-15 04:45:03

• Blocked on: #2031

[Beep6581]

DCP patch is ready, and want a decision on issue 2032, ie if the obsolete "DCP Preferred
Profile" setting can be removed or not. I want to remove it, discussion in issue 2032.

Reported by torger@ludd.ltu.se on 2013-11-15 11:24:58

• Blocked on: #2032

[Beep6581]

Reported by torger@ludd.ltu.se on 2013-11-15 11:38:45

• Blocked on: #2036

[Beep6581]

Added Amaze artifact issue.

Reported by entertheyoni on 2013-11-16 11:28:40

• Blocked on: #1819

[Beep6581]

Reported by natureh.510 on 2013-11-17 17:16:46

• No longer blocked on: #841

[Beep6581]

Reported by torger@ludd.ltu.se on 2013-11-18 15:09:11

• Blocked on: #1994

[Beep6581]

Once all blocked-on issues are fixed, I will tag 4.1-rc1 (release-candidate 1). It will
be released for all platforms the same as any other major release. The public must
test. If after about 10 days of having been made available to the public no showstoppers
are found, I will tag 4.1.

During that time I ask that no new features are committed, only bug-fixes.

Reported by entertheyoni on 2013-11-19 00:06:53

[Beep6581]

Should issue 2043 be added? A "full" fix may be much work, but a basic fix is probably
quite easy to do. I want to commit my DCP work first though (1987) as there's overlaps.

Reported by torger@ludd.ltu.se on 2013-11-19 07:32:20

[Beep6581]

I'm thinking about committing my name to AUTHORS.txt, is that okay? Don't know how significant
contributions one need to make before one can get into that list :-). I hope to be
able to continue contributing in the future too.

Reported by torger@ludd.ltu.se on 2013-11-19 09:53:52

[Beep6581]

I too hope to see more of your contributions:) IMHO, you have every right to be added
to the authors list!

Reported by michaelezra000 on 2013-11-19 10:21:54

[Beep6581]

ok thanks, now I'm in the list... and feel obliged to contribute more :-)

Reported by torger@ludd.ltu.se on 2013-11-19 11:38:38

[Beep6581]

Of course, I even asked you to add yourself a week or two ago! ;)

Reported by entertheyoni on 2013-11-19 18:22:39

[Beep6581]

Added issue 2059, as I have a ready solution for that issue which seems to work.

Reported by torger@ludd.ltu.se on 2013-11-20 07:45:29

• Blocked on: #2059

[Beep6581]

Continuing from https://code.google.com/p/rawtherapee/issues/detail?id=1738#c59
When ready, I want to tag 4.1-rc1 because that is the correct way to do it. I just
tested locally, I made the tag and then made some further commits, and RT compiled
correctly using buildRT. Could someone check locally whether RT compiles correctly
after you tag 4.1-rc1 in Windows and OS X?

Reported by entertheyoni on 2013-11-20 19:52:35

[Beep6581]

I don't see any problem in tagging that way, but what you have in AboutThisBuild, param
"AppVersion", will still be 4.0.11.156 (e.g.)

Reported by natureh.510 on 2013-11-20 20:14:01

[Beep6581]

Reported by michaelezra000 on 2013-11-21 01:38:15

• Blocked on: #2073

[Beep6581]

Adding issue 2069: I'd really really like to sort out this working space profile once
for all. It should be ProPhoto per default, not sRGB. All reasons for keeping sRGB
as default seems to go back to integer legacy, and people mix it up with output profile
*all the time*. The manual states wrong things about it too.

From the manual: "Wide gamut profiles such as ProPhoto and WideGamut are suitable only
for source files of a high bit depth (at least 16-bit), such as raw files or 16-bit
TIFF files, but not JPEG images. For JPEG files sRGB and AdobeRGB are the best profiles.
If you are unsure, use sRGB."

This is wrong. We convert to floating point before conversion to and after conversion
from working color space, ie it does no harm to have a large color space there even
if source or destination has small. I even made some test processing to be sure. However
working profile MAY do harm to have a too small color space for source files with larger
color space, ie all camera raws. So having sRGB as default is *broken*.

The reason for even keeping the setting and not make it hard-coded ProPhoto is very
weak as far as I can see, but we can start with making it ProPhoto as default.

Reported by torger@ludd.ltu.se on 2013-11-21 19:09:00

• Blocked on: #2069

[Beep6581]

Supporting 2069, I've added a sRGB -> Prophoto patch for some traces of sRGB hard-coded
stuff that was left.

Old: integer math and sRGB primaries
New: floating point math Prophoto primaries

RT has got floating point math, but is still semi-stuck in sRGB. It's about time we
fix that, and I think it's quite small work if we just dare to take the leap. Just
need to make sure nothing crazy happens with the tools, and if so fix that.

It may be the case that the patch in 2068 already fixes all that need to be done, except
for changing Working Profile in all bundled profiles to Prophoto.

Reported by torger@ludd.ltu.se on 2013-11-22 11:31:32

• Blocked on: #2068

[Beep6581]

I'd wait on Jacques' opinion (he's away for some days now) before committing anything,
since he did many tools that correct the image depending on the color gamut.

Reported by natureh.510 on 2013-11-22 13:06:29

[Beep6581]

Don't worry, I'll stay low :-).

Reported by torger@ludd.ltu.se on 2013-11-22 13:16:36

[Beep6581]

Output color space conversion fix issue 2081. Trivial fix and improved precision and
slightly improved performance.

Reported by torger@ludd.ltu.se on 2013-11-23 10:00:00

• Blocked on: #2081

[Beep6581]

removing issue 2081, results wasn't as I expected. Work postponed after release.

Reported by torger@ludd.ltu.se on 2013-11-25 15:56:33

• No longer blocked on: #2081

[Beep6581]

Reported by heckflosse@i-weyrich.de on 2013-12-04 21:33:44

• Blocked on: #2094

[Beep6581]

Issue 2084 rename HQ/LQ S/H.

Reported by entertheyoni on 2013-12-04 22:49:26

[Beep6581]

RELEASE_NOTES v1

Reported by entertheyoni on 2013-12-05 01:30:42

---

• _Attachment: RELEASE_NOTES.txt_

[Beep6581]

Need to add info for builders that GTK+ >=2.24.18 is recommended due to bugs in <2.24.18

Reported by entertheyoni on 2013-12-05 01:48:01

[Beep6581]

Added "Exif comments not saved to TIFF files", issue 2033.

Reported by entertheyoni on 2013-12-05 02:03:44

• Blocked on: #2033

[Beep6581]

Issue 1661: "Added support for Kodak DCS 760 and 760s"

Reported by entertheyoni on 2013-12-06 16:46:26

[Beep6581]

issue 1919: "Added shortcuts to File Browser to navigate between displayed thumbnails
(left, right, up and down), to jump to first or last thumbnail and to select a range
of thumbnails."

Reported by michaelezra000 on 2013-12-06 21:26:05

[Beep6581]

HISTOGRAM_TOOLTIP_FULL;Toggle full (on) or scaled (off) histogram
(if no objections)

Reported by entertheyoni on 2013-12-07 15:36:11