Rawtherapee: Allow resizing to physical dimensions

[Beep6581]

Every once in a while someone asks how to resize an image in RawTherapee to a physical dimension in centimeters or inches based on pixels per inch (PPI). I tried to solve that problem.

[Beep6581]

Duplicates:

• #834
• #630
• #2426
• #2419
• https://discuss.pixls.us/t/save-jpg-file-for-printing/7675
• https://discuss.pixls.us/t/output-file-dpi-changeable/1046
  etc.

[Beep6581]

Branch hihowdoisaveaphotoat300dpi implements a working solution.

The scaling is based on pixels, so dimensions in centimeters and inches are not stored, just calculated when needed. Only the PPI value is stored.

I know very little about C++ and would appreciate help with several things:

• What to do in the if (pedited) { sections is a mystery to me.
• The XResolution and YResolution Exif tags should be written to the saved image (all output formats) containing the PPI value:
  http://www.exiv2.org/tags.html
  I will create a PR once this is done.

Heads up @TooWaBoo and other theme designers:
RawTherapee still hard-codes most widget spacing values instead of leaving that up to the CSS the GTK3 way. The Resize tool now uses two grids without hard-coded spacing, and instead leaves the spacing up to CSS. All grids which require spacing to be set by CSS are assigned a class grid-spacing, see here:
https://github.com/Beep6581/RawTherapee/blob/hihowdoisaveaphotoat300dpi/rtdata/themes/RawTherapee-GTK3-20_.css#L1040

[Beep6581]

Notes to self, review language keys when merging: TP_RESIZE_ALLOW_UPSCALING (capitalization), delete all TP_RESIZE_W and TP_RESIZE_H

[Thanatomanic]

Just to say, love your branch name.
What I would prefer from a GUI point of view is to try and reduce the crowding. What I think I have seen elsewhere is a toggle (or tabs) that shows you either the pixel values, or the DPI + physical sizes, not both at the same time.

[Hombre57]

@Beep6581 I'll have a look at the pedited problem tomorrow. Great that you added this feature :+1:

[Hombre57]

@Beep6581 Before looking at the pedited problem, the Crop tool already has a PPI spin button for information purpose only, with informational label. I think those should be moved to the Resize tool and updated when the Crop tool is changed.

Instead of adding 2 supplementary spin button not handled in the ProcParams, the unit combobox should simply tell the unit of the actual width and height values, with px / mm / in entries (px as default, for compatibility).

If unit is set to px, the PPI is the consequence of the new size in pixel, in which case the PPI spin button should be made unsensitive (if not in batchmode).

If the unit is set to mm or in, the PPI should be made sensitive (if not in batchmode) and the hint label updated (if not in batchmode).

[Beep6581]

@Hombre57 I see no need for the PPI stuff being in the crop tool, but that's one of several separate issues with the crop tool, let's not mix those here.

I will consider the other suggestions.

[Beep6581]

@Hombre57 I like your idea and haven't thought of drawbacks - I'll implement it.

[Hombre57]

@Beep6581 My comment was i bite incorrect. PPI should always be sensitive and put as is in the output file, but :

• if unit is set to px, PPI will be used to update a label displaying the resulting mm/inch size
• if unit is set to mm or in, PPI will be used to define the image size in pixel of either the width, height or bounding box depending on the mode combobox, and update a label showing this size

In batch mode, you should just hide the informative label. Whatever the unit is set to in each of the selected files, the user is responsible for the coherency of the values set in width and height.

[Thanatomanic]

For reference: https://discuss.pixls.us/t/note-to-the-dev-guys-about-72-ppi-output/18570
There is still a wish for this to work.