rom9 22eee9787e
Film negative stable multipliers (#5485)
* Added new feature to calculate channel multipliers from crop area. This also saves the crop area channel medians to the processing profiles, in order to get a more consistent color balance when batch-applying the same profile to multiple pictures from the same film roll.

* Fixed wrong initialization of array, and missing check for the result of `getFilmNegativeMedians()`.
Moved `ImProcCoordinator::translateCoord()` from private member to anonymous namespace.
Fixed some whitespace and formatting issues.

* Fixed some formatting issues

* Passed `ipf` parameter as const in `translateCoord`.
Narrowed `using namespace` to single class `Coord2D`.

* Added `scaleGain` entry to thumbnail metadata file, to make `scale_mul` multipliers available in thumbnail processing phase. This simplifies multiplier calculations, so that "faking" thumbnail multipliers in the main image processing is not necessary anymore. This way, output values are immune to slight variations of multipliers between successive shots taken with in-camera AWB turned on.
Shifted multipliers so that the output channel medians are balanced when "Camera WB" is selected. This way, just computing multipliers from crop and setting "Camera WB" (which is the default) gives a pretty well balanced image as a starting point.

* New channel scaling method, based on a film base color sample instead of crop area channel medians. Channels are scaled so that the converted film base values are equal to 1/512th of the output range (65k). This giver better black levels in the output, and more consistency when batch-processing multiple negatives.
The output is now compensated for a known fixed WB value, so that the film base will appear grey when WB is set to 3500K, Green=1.
Added PPVERSION 347 to preserve backwards compatibility: when a processing profile saved by RT 5.7 is loaded (PPVERSION=346), the new fields are initialized to the special value -1, which will instruct the main processing to follow the old channel scaling behaviour. The old channel scaling multipliers will then be converted to the new film base values so that the resulting image is the same, and the fields will be overwritten as soon as the PP is saved again. This will transparently upgrade the processing profile.
When the new behaviour is used, but the film base values are still unset, they are estimated based on channel medians, excluding a 20% border around the image. This should give a better result out-of-the-box for pictures containing a large film holder.

* Code cleanup from review

* Run astyle on film neg source files

* Fixed automated build failure caused by incompatible libraries on my dev PC.

* Simplified `Thumbnail::processFilmNegative` method signature. There is no need to pass in `rmi`,`gmi`,`bmi` multipliers from the caller, i can do the same with my own internal multipliers.

* Added `FilmNegListener` class to pass estimeted film base values to the GUI after first processing. Removed old `filmBaseValues` instance variable from RawImageSource.

* Code cleanup

* Forgot to set baseValues flag in `PartialPasteDlg::applyPaste`
Fixed `filmBaseValuesLabel` not updating when reading zero baseValues. Normally not needed (the label is updated later by the listener), but when the user is browsing through pictures the listener won't fire, so the label must be updated to show values are unset.

* Overwritten channel scaling multipliers by calling `get_colorsCoeff` with `forceAutoWB=false`.
Initially, in `RawImageSource::load`, channels are auto-balanced by averaging the whole picture when computing multipliers.
This can give different multipliers for multiple shots of the same camera, which will lead to inconsistent conversions when batch-processing multiple negatives.
This commit re-sets `scale_mul`, `ref_pre_mul`, etc., in order to "undo" the auto-WB and use the normal camera multipliers.

* Found an easier way to get stable overall multipliers, removed the (horrible) on-the-fly mutation of scaling instance variables.
2020-04-13 17:20:56 +02:00
..
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2019-09-10 12:34:57 +02:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00
2020-01-27 16:59:44 +01:00

This is the directory where all translations should go.

Translations are loaded for a given term at three levels:

  1) default
  2) <Language>
  3) <Language> <Locale/Variant>

Developers who are adding a new feature should add new strings *only* to 
default.  This file should be comprised of basic English text.  It will be used 
in the event that there are no more specific languages specified.  Once you 
have modified default, you should run ./tools/generateTranslationDiffs (Bash 
script) which will re-generate the localizations with commented out additions 
which you have just added.

Translators should in general implement the <Language> file.  This is the 
generic translation for a given language; for instance, 'French', 'German', 
'Norsk', etc.  If a string exists in this file (and the user has specified this 
language), then RawTherapee will override the value in default with the value 
in <Language>.  Please note that the filename for this file must not contain 
any spaces.

In some situations, translations may differ based on region, locale, etc.  A 
good example of this is the difference in spelling between 'color' (American 
English) and 'colour' (British English). In this case, the vast majority of 
strings are identical between English and English (UK); however, to keep the 
proper spelling in Britain, we have a locale file called 'English (UK)' which
contains the differences between the two.  RawTherapee uses locale files when:
  a) The user has selected a language which has a space in the file name
  b) There is another file which is identical to the locale file up until the 
     space (i.e., 'English' to the locale file 'English (UK)').

If a locale file is used, it is applied in the same manner as <Language> is to 
default.  The locale will override any keys present from the ones in the 
language file (and in turn, the default).

After the generateTranslationDiffs has been run, all untranslated terms for 
a given language/locale will exist at the end of the file, prefixed by a ! 
comment marker.  Translators should go through this section of the file and 
translate all terms which they can. After you have translated a line, just 
remove the ! comment marker.  Comments may be included using the #xx comment 
marker, where xx is a numeric prefix used to make sure automated sorting keeps 
comments in the right order, e.g.:
  #00 Comment line 1...
  #01 Line 2...
  #02 3, etc.

To create a file with only Latin characters from a non-Latin one, you can use 
sed with the "y" command. For example, to create a latin-only "Polish (Latin 
Characters)" file from the non-latin "Polish" one:
  sed 'y/ĄĆĘŁŃÓŚŹŻąćęłńóśźż/ACELNOSZZacelnoszz/' < Polish > "Polish (Latin Characters)"

You can use this Wikipedia "Character sets" category page to help you find all 
the characters in the language file you want to convert into Latin-only:
  http://en.wikipedia.org/wiki/Category:Character_sets

To convert all line terminators in all language files to CRLF (dos/mac/unix)
you can use vim:
  a) cd rtdata/languages
     vim
  b) In vim, type:
     :set ffs=dos
     :args *
     :argdo w
  c) vim will process all language files. Once done, you can close it:
     :q