Skip to content

Rendering algorithms

Jump to bottom
Jan Hubička edited this page Jul 13, 2024 · 83 revisions

Rendering algorithms

Rendering pipeline for processes with regular screens

Scan of original negative

⇓ 		Infrared scan of original transparency

⇓ 		RGB scan of original transparency

⇓
Linearization and inverting negative to positive
⇘ 		Linearization
⇓ 		Linearization and channel mixing
⇙
Linear grayscale transparency

⇓
Viewing screen registration

⇓
linear RGB image with viewing screen
(see viewing screen superposition)

⇓
Determining luminosity of each color patch (optional)
⇓
Blocky linear RGB image (similar to RAW from digital camera)

⇓
Demosaicing using bicubic interpolation (optional)
⇓
Smooth but unsharp linear RGB image

⇓
Combining predicted and original data (optional)
⇓
linear RGB image

⇓
Simulation dyes of viewing screen and conversion to output color profile
⇓
Digital color rendering
## Inverting negative to positive If the original image is a negative, then we first need to simulate process of contact-copying negative to a transparency. Basic invertion to negative may be done by setting `gray_range` in a way minimal value is greater than maximal.

Future plans

Realistic simulation of what happens when negative is copied to a transparency in laboratory involves simulating sensitivity curve of the black and white emulsion used. At the moment this step is not implemented in a satisfactory way and we rely on other tools (such as vuescan) to do this job for us. We yet need to understand how typical sensitivity curves were and what kind of user-interface we want to implement here. Ideally we should do this based on scans of existing negative-transparency pairs.

Channel mixing

When only RGB scan of a color transparency is available, it is possible to estimate the original black and white transparency by mixing RGB channels to grayscale with a certain weights.

In theory it is possible to recover the infrared channel of the scan using the RGB data.
During digitization light passes from the light source through the filters and the emulsion (which is assumed to be close to neutral density filter) and color filters used on the top of the scanner CCD. Knowing RGB values of the scanner's response to the red, green and blue filters of the color screen it is possible possible to produce 3 equations which makes it possible to compute from scanned RGB value the density of the emulsion. mix_weights.red, mix_weights.green and mix_weights.blue are solution to the equations. Value is further compensated by mix_dark, which should ideally be (0,0,0) but it is practical to offset it in some situation (such as when the value is computed using the actual infrared channel).

The simulated infrared channel is computed as:

ir=(r-mix_dark.red)mix_weights.red+(g-mix_dark.green)mix_weights.green+(b-mix_dark.blue)mix_weights.blue.

Here r, g and b are linearized RGB values of the pixel inspected.

Meaningful of mix_dark are values are in range (-1,1). mix_red, mix_green and mix_blue can be both positive and negative.

Viewing screen registration


Screen-coordinates of Paget or Finlay screen.

In this step the screen-coordinates is mapped to the scan-coordinates. This is done by several parameters:

  • Affine transformation
    • screen_shift x y specifies that screen-coordinate (0,0) is (x,y) scan-coordinate.
    • coordinate_x xx xy is the x coordinate vector of the basis of linear transformation. Screen-coordinate (1,0) maps to (x+xx,y+xy) scan-coordinate.
    • coordinate_y yx yy is the y coordinate vector of the basis of linear transformation. Screen-coordinate (0,1) maps to the coordinate (x+yx,y+yy) scan-coordinate.
  • Perspective correction
    • tilt_x txx txy specifies tilt of the scanned image in the horizontal scan-axis. The rotation is in degrees if the image was scanned screen-distance 1 of the surface of image (thus not very meaningul)
    • tilt_y tyx tyy specifies tild of the scanned image in the vertical scan-axis. For scanners with fixed lens this should always be same as tilt_x. However for scanners with moving lens only one of tilt_x and tilt_y should be non-zero and it should correspond to the axis in which the sensor is fixed.
  • Lens distortion correction
    • k1 p specifies the lens correction parameter for the Brown-Conrady lens distortion model. Other parameters are not implemented (yet?) since it seems that quality macro lenses suitable for digitization of additive color screen processes typically have relatively mild (but sometimes still important) geometric distortions.

Future plans

Parameters are specified by hand using the GUI application. This gets laborious since they needs to be specified very precisely. For this reasons we plan to implement image analysis which will detect the dot pattern in the scanned image and help to (partly) automate this process.

Legacy scanners with moving sensor suffers from additional errors caused by inprecisions of the stepping motors. This is visible in final rendering and thus we need to implement compensation for this problem. Main question is how to set an user-interface which makes it possible to specify such corrections. We hope that after implementing image analysis we will be able to make this more automatic, too.

Viewing screen superposition

Once mapping of viewing screen and scan coordinates is made, it is possible to simulate the superposition of viewing screen and transparency. This means that for every pixel of the input image the color of viewing screen is determined in RGB values that represents intensities of each color dye and these RGB values are multiplied by the luminosity of the pixel.

Since scans nor viewing screens are perfectly sharp, parameter screen_blur_radius determine how much the simulated ideal screen should be blurred for this process.

Future plans

For later algorithms it is very desirable to make screen blurring to match the blur caused by the combination of photographic emulsion and scanner, so it precisely match the blur of original viewing screen. Instead of simple screen_blur_radius we may implement bluring based on fourier transformation that takes an MTF curve of the system as parameter.

Determining luminosity of each color patch

Precise data collection

This step is done by considering every pixel of the given color patch and computing weighted average where weights are given by screen blurring. Only pixels where given channel exceeds collection_threshold parameter are considered to be part of the patch. The algorithm uses screen_blur to estimate loss of saturation caused by the reduction of contrast of individual tiles and compensates for it. With correct screen_blur setting the value 0 of collection_threshold should give same results as slightly higher values (until the threshold is so large that no data is collected when the algorithm turns to fast mode). However since with lower values bigger increase of saturation is necessary, it yields to very visible artifacts around edges. Too large values of collection_threshold on the other hand may make image noisy.

Fast data collection

Center of every color patch is identified and the luminosity is given using the bicubic interpolation. This is useful especially for very low resolution scans where there are too few pixels corresponding to a given patch.

Clone this wiki locally