User Guide-Debugging Profiling and Tuning
š§ Documentation under development
The PVA ISP for NVIDIA Jetson guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
The PVA ISP sample applications provide a set of debugging and tuning features that can be configured through the ISP parameter file. These capabilities are intended to help developers:
- Inspect intermediate ISP behavior
- Export scalar metrics and histograms
- Visualize CSV outputs with external tools such as PVA ISP View
- Tune ISP parameters based on measurable pipeline behavior
PVA ISP exposes debug and profiling outputs through the example applications, primarily isp_app.
The main mechanisms are:
- Execution-time reporting printed to the console
- CSV export of scalar metrics
- CSV export of histograms at key ISP stages
- Optional scene-key export for tone-mapping analysis
These outputs are controlled from params.yaml, you can find an example below:
params.yaml example
# Copyright (C) 2026 RidgeRun, LLC (http://www.ridgerun.com) # All Rights Reserved. # # The contents of this software are proprietary and confidential to RidgeRun, # LLC. No part of this program may be photocopied, reproduced or translated # into another programming language without prior written consent of # RidgeRun, LLC. The user is free to modify the source code after obtaining # a software license from RidgeRun. All source code changes must be provided # back to RidgeRun without any encumbrance. # Decompanding parameters decompand: input_shift: 4 x_pts: [0, 1107, 3325, 7766, 16652, 34430, 52207, 56648, 65535] y_pts: [0, 1098, 1885, 2501, 3062, 3602, 3914, 3975, 4095] # 3x3 Convolution filter coefficients in row-major order convolution: kernel: [1, 2, 1, 2, 4, 2, 1, 2, 1] shift: 4 # Optical black levels to use in the Black Level Correction algorithm black_level: channel00: 16 channel01: 16 channel10: 16 channel11: 16 # Digital gain value to apply digital_gain: 1.5 # Calibration points for the following light temperatures: [2800K, 3200K, # 4000K, 5000K, 6500K] white_balance_calibration: u_ref: [0.982, 0.789, 0.668, 0.558, 0.426] v_ref: [0.308, 0.382, 0.445, 0.428, 0.678] use_calibration: false # Option to use the manual white balance manual_wb: false # Manual White Balance gains wb_gains: [1.0, 1.0, 1.0] # Input Bayer pattern. 0 for BGGR, 1 for RGGB, 2 for GBRG, 3 for GRBG bayer_pattern: 0 # Histogram bit depth after and mask usage Histogram: bit_depth: 16 use_mask: false # Gamma value for the Gamma Tone Mapping algorithm gamma: 2.2 # Global Tone Mapping parameters brightness: 0.18 gtm_scale_min: 0.0001 gtm_scale_max: 0.01 gtm_temporal_alpha: 1.0 saturation: 1.0 # Debug options export_scene_key: false # Enable CSV export for histogram/debug metrics generation. # CSV files are generated for the selected frame after key ISP stages # (decompand, black leveling, white balance, demosaic, gamma, etc.). export_debug_csv: false # Frame index used for CSV/debug data export. debug_export_frame_index: 0
ISP Calibration
This section shows how to configure the PVA ISP in order to get the desired output based on the selected camera specification. The calibration guide goes over all configurable parameters in the YAML configuration guide and shows how to select the value to use.
Bayer Pattern
Used to indicate the Bayer pattern use by the camera sensor. Supported formats map as follows:
- 0 = BGGR
- 1 = RGGB
- 2 = GBRG
- 3 = GRBG
Select the value that matches the format provided by the camera sensor.
Decompanding
The decompanding stage is meant to be used when an HDR image must be converted to a linear representation. As shown in the example parameters file, this stage includes two configurable parameters:
Input Shift
Input image data is stored in 16 bit containers even though the bit depth provided by the camera sensor is smaller than this. In cases like this, the remaining bits in the container might be filled with undesired data. In order to solve this and make the ISP use only the data captured by the sensor, the input shift must be configured so that the data in the container matches the bit depth provided by the camera. As an example, if the selected camera captures 12 bit data, the shift must be configured to 4 bits so that the 16 bit container matches the data captured by the sensor.
Decompand Table
The Decompand table is used by the ISP to apply the Piece-Wise-Linear Decompanding as desired by the user. It consists of 9 x and 9 y points which must be strictly increasing starting at 0 and ending at the maximum possible value in each case. As an example, if the sensor bit depth is 12 bits, the y points must go from 0 to 4095 and the x points from 0 to 65 535.
It is also possible to configure the decompand table in a "pass through" mode when an HDR sensor is not used. In case this the y points must be configured to be the same as the x points.
Convolution
If the convolution stage is used, there are two configurable parameters:
Kernel
The kernel corresponds to the 3x3 convolution kernel to be applied. It must be written in row-major order. As an example, the kernel included in the example configuration file corresponds to a Gaussian filter in the following form:
1 2 1 2 4 2 1 2 1
Shift
The shift parameter corresponds to a shift-right operation performed after applying the convolution kernel. The value is in bits, so a value of 4 corresponds to a shift-right of 4 bits.
Black Level
These values configure the black offset to be applied in each channel to get accurate representation of dark regions. Offsets are configurable per channel using the Bayer pattern indices. For example, if the input image is BGGR the indices are as follows:
- 00 for blue pixels
- 01 for green pixels in blue rows
- 10 for green pixels in red rows
- 11 for red pixels
The values can go from 0 to 65 535 and the actual values to use are depending on each camera sensor. If the optical black values are not indicated in the sensor datasheet, they can be computed by capturing a fully dark frame and computing the average value for each channel.
Digital Gain
Digital Gain can be seen as applying a scale to the image. Values greater than 1.0 can be used to increase the overall intensity of the image, while values smaller than 1.0 can be used to lower the intensity. The value to use for the digital gain depends on the input desired by the user.
White Balance
Several parameters are configurable for the White Balance algorithm as there are several supported modes. First, it is possible to select if the Auto White Balance algorithm is used or if a manual mode is used. This is control with the manual_wb option, and the manual mode is enabled when the option is set to true.
When using the manual mode, the gains to apply are configurable using the wb_gains parameter in the following way:
# Manual White Balance gains wb_gains: [1.0, 1.1, 1.2]
Gains are in order R, G, B, so with the previous example a gain of 1.0 is applied to the red channel, a gain of 1.1 applied to the green channel and a gain of 1.2 to the blue channel. A simple method to select manual gains is to capture a gray or white frame and compute the average value for each channel, then compute the gains based on the channel with the highest average value.
When the the manual_wb option is false, and use_calibration is false, a Grayworld auto white balance algorithm is applied. In this case, the ISP will compute per-channel averages for each processed frame and compute the gains to apply in that case.
It is also possible to use a calibrated version of the Grayworld algorithm which is applied when manual_wb is false and use_calibration is true. In this case, the algorithm considers five u,v calibration points which are set in the u_ref and v_ref parameters. Calibration points depend on each sensor and can be obtained by following a similar process to the one used to obtain the manual gains. In this case, capture gray frames at different desired light temperatures, for example 2800K, 3200K, 4000K, 5000K, and 6500K. Then, for each frame compute the per-channel averages and use the averages to obtain a u,v point for each frame.
Gamma
The gamma values controls the power-law OETF used to convert the linear RGB8 output from Global Tone Mapping into a display-ready non-linear representation. A value of 2.2 is commonly used for standard sRGB displays. In general, a higher gamma value results in a slightly brighter image.
Global Tone Mapping
For the Global Tone Mapping, it is possible to configure the following parameters:
Brightness
It controls the overall brightness of the image. The value can be selected depending on the desired look for the output, and higher values result in brighter looking images.
Scale
Parameters gtm_scale_min and gtm_scale_max work as safeguards to avoid extreme changes to the image in corner cases. In general, using the values provided in the example avoid the image getting blown out.
Temporal Alpha
This parameter controls temporal smoothing. A value close to 1.0 reacts quickly to changes. Lower values can make transitions smoother but slower.
Enabling Debug Exports
The following parameters control debug output:
- export_scene_key: When is enabled, additional Global Tone Mapping scalar metrics are exported.
This is useful for analyzing scene-key evolution and tone-mapping behavior. - export_debug_csv: When is set to true, the application generates CSV files under the debug/ directory.
This enables:- Per-stage histogram CSV export
- Scalar metric CSV export
- Per-pixel and per-point CSV exports for selected stages
- debug_export_frame_index: This parameter selects which frame is used for frame-specific debug exports.
For example:export_debug_csv: true debug_export_frame_index: 25
With this configuration, detailed frame-specific outputs are generated for frame 25.
This is especially useful when processing multiple frames and only one frame should be inspected in detail.
Generated Outputs
When debug export is enabled, the application may generate files such as:
- debug/histogram.csv
- debug/histogram_pre_decompand.csv
- debug/histogram_post_decompand.csv
- debug/histogram_post_black_leveling.csv
- debug/histogram_post_white_balance.csv
- debug/histogram_post_demosaic.csv
- debug/histogram_pre_gamma.csv
- debug/histogram_post_gamma.csv
- debug/decompand_pwl.csv
- debug/decompand_points.csv
- debug/decompand_shift.csv
- debug/black_leveling_factors.csv
- debug/digital_gain_metrics.csv
- debug/white_balance_gains.csv
- debug/global_tone_mapping.csv
- debug/gtm_luminances.csv
- debug/gamma_metrics.csv
Not all files represent the same kind of data. Some are scalar metrics per frame, some are per-bin histograms, and some are per-pixel or per-point debug exports.
Using the CSV Files with PVA ISP View
Histogram and debug CSV files generated by PVA ISP can be visualized with PVA ISP Viewer.
cd pva-isp-viewer xdg-open index.html
In general:
- Load the exported CSV file into the viewer
- Select the corresponding plot or histogram mode
- Compare results before and after parameter changes
- Inspect how the signal distribution changes across ISP stages
Possible uses include:
- Comparing pre- and post-black-level distributions
- Verifying white-balance channel alignment
- Inspecting clipping before and after gamma
- Checking scene brightness distribution for tone mapping
This section describes which CSV outputs are useful for each ISP algorithm, how the plots are typically interpreted, what indicators to look for, and which parameters in `params.yaml` can be tuned in response.
Decompanding
To debug and tune decompanding we have different useful csv files:
decompand_pwl.csv:
segment,input_code_start_12bit,input_code_end_12bit,output_code_start_16bit,output_code_end_16bit,slope,intercept 0,0,1098,0,1107,1.0082,0 1,1098,1885,1107,3325,2.8183,-1987.49 2,1885,2501,3325,7766,7.20942,-10264.7 3,2501,3062,7766,16652,15.8396,-31848.8 4,3062,3602,16652,34430,32.9222,-84155.8 5,3602,3914,34430,52207,56.9776,-170803 6,3914,3975,52207,56648,72.8033,-232745 7,3975,4095,56648,65535,74.0583,-237734
This CSV file defines the piecewise linear (PWL) decompanding curve used to convert the sensor's compressed 12-bit input values into 16-bit linear output values. Each row represents one segment of the PWL function and includes:
- segment: Sequential identifier of the PWL segment.
- input_code_start_12bit: First 12-bit input code covered by the segment.
- input_code_end_12bit: Last 12-bit input code covered by the segment.
- output_code_start_16bit: Corresponding 16-bit output value at the beginning of the segment.
- output_code_end_16bit: Corresponding 16-bit output value at the end of the segment.
- slope: Linear gain applied within the segment.
- intercept: Linear offset used together with the slope to compute the output value.
During decompanding, each input pixel is mapped to the appropriate segment according to its 12-bit code, and the output value is computed using the segment's linear equation:
output=slopeĆinput+intercept
This plot visualizes the Piecewise Linear (PWL) decompanding curve loaded from decompand_pwl.csv. The horizontal axis represents the 12-bit compressed sensor input code, while the vertical axis represents the corresponding 16-bit linear output code produced after decompanding.
The orange markers correspond to the control points defined in the CSV file, and the blue line represents the complete PWL transfer function obtained by linearly interpolating between consecutive control points.
If the curve is configured correctly, the output should appear as a smooth increasing function with no discontinuities, negative slopes, or unexpected flat regions. Any abrupt jumps, missing segments, or decreasing portions of the curve may indicate an incorrect PWL configuration or an error in the decompanding parameters.
decompand_points.csv
frame,x,y,color,input_code_12bit,output_code_16bit 25,0,0,R,220,222 25,1,0,G,236,238 25,2,0,R,216,218 25,3,0,G,236,238 25,4,0,R,220,222 25,5,0,G,236,238 25,6,0,R,216,218 25,7,0,G,236,238 25,8,0,R,220,222 25,9,0,G,236,238 25,10,0,R,220,222 25,11,0,G,236,238
This CSV contains per-pixel decompanding results for a selected frame. Each row corresponds to a single Bayer pixel and records both its original compressed sensor value and the resulting linear value after applying the decompanding operation. The file includes the following information:
- frame: Frame number from which the pixel was extracted.
- x, y: Pixel coordinates within the image.
- color: Bayer color component (R, G, or B).
- input_code_12bit: Original 12-bit compressed sensor value.
- output_code_16bit: Corresponding 16-bit linear value produced by the decompanding stage.
This plot compares the measured decompanding results obtained from every processed pixel against the theoretical Piecewise Linear (PWL) decompanding curve.
The horizontal axis represents the 12-bit compressed input code, while the vertical axis represents the corresponding 16-bit linear output code produced by the decompanding stage.
The dashed blue lines correspond to the individual PWL segments defined in decompand_pwl.csv. The red points represent the actual pixel values measured during execution.
The purpose of this visualization is to verify that the implementation applies the configured PWL curve correctly to every pixel in the image. When the decompanding implementation is correct, the theoretical curve and the measured points become nearly indistinguishable
histogram_pre_decompand.csv:
bin,r_count,g_count,b_count 12,49296,32605,39673 13,132662,181250,161737 14,146439,122739,100858 15,79245,185693,67191 16,27292,127507,42045 17,17695,73752,21826 18,14751,52946,17111 19,10348,45337,13137 20,7490,26512,9515 21,5376,23046,7096 22,4198,16587,4951 23,4148,18571,3716 24,3871,14449,3441
This CSV contains the Bayer image histogram before the decompanding stage. It records the distribution of pixel values independently for the red, green, and blue color components, allowing developers to evaluate how the sensor data is distributed before any dynamic range expansion is applied. Each row represents one histogram bin and includes:
- bin: Histogram bin index corresponding to a range of input code values.
- r_count: Number of red pixels that fall within the bin.
- g_count: Number of green pixels that fall within the bin.
- b_count: Number of blue pixels that fall within the bin.
A correctly generated histogram should exhibit the following characteristics:
- The sum of all histogram counts should equal the total number of Bayer pixels for each color channel.
- The distribution should reflect the scene content. Dark scenes produce histograms concentrated in lower bins, while bright scenes shift the distribution toward higher bins.
- The green channel typically contains approximately twice as many samples as the red or blue channels, since most Bayer patterns contain two green pixels for every red and blue pixel (e.g., RGGB, BGGR, GBRG, or GRBG).
bin,r_count,g_count,b_count 16,117,165,112 17,131,152,146 18,141,154,123 19,112,175,99 20,102,160,118 21,122,186,117 22,114,171,108 23,113,168,128 24,124,155,104 25,134,191,86 26,106,173,100 27,123,193,113 28,86,205,101 29,127,186,108 30,81,137,76 31,31,75,35 32,47,57,51 33,40,78,46 34,47,82,55 35,44,93,46
This CSV contains the Bayer image histogram after the decompanding stage. It records the distribution of pixel values after the compressed sensor data has been expanded into a linear representation. Each row represents one histogram bin and includes:
- bin: Histogram bin index corresponding to a range of output code values.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
Compared to the pre-decompanding histogram, the post-decompanding histogram is expected to exhibit a different distribution because the pixel values have been remapped by the PWL function. The exact histogram distribution depends on the configured PWL curve and the input scene.
Tune in params.yaml:
- decompand.input_shift
- decompand.x_pts
- decompand.y_pts
Black Level Correction
To debug and tune Black Level Correction algorithm we have different useful csv files:
histogram_post_black_leveling.csv:
bin,r_count,g_count,b_count 0,434934,649794,411504 1,73804,331425,95973 2,1337,34566,2147 3,774,2479,521 4,707,1066,259 5,516,495,248 6,475,153,290 7,484,135,346 8,452,125,350 9,421,174,425 10,412,217,351 11,343,262,359 12,353,340,323 13,138,114,148 14,130,124,127 15,129,135,133
This CSV contains the Bayer image histogram after the Black Level Correction (BLC) stage. Since the input to this stage is the output of the decompanding stage, the histogram reflects how the pixel value distribution changes after the sensor's optical black offset has been removed and the configured digital gain has been applied.
Each row represents one histogram bin and includes:
- bin: Histogram bin index corresponding to a range of pixel values after Black Level Correction.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
The viewer displays the post-Black-Level-Correction histograms for the red, green, and blue Bayer channels independently.
When compared to the post-decompanding histogram, the histogram should exhibit only modest changes corresponding to the configured optical black subtraction and digital gain. Large shifts, discontinuities, or unexpected changes in the histogram shape may indicate incorrect black level calibration or an improperly configured digital gain.
A successful Black Level Correction stage produces a histogram that preserves the scene distribution while removing the sensor's black offset, ensuring that subsequent ISP stages operate on properly calibrated linear image data.
other useful CSV files:
- black_leveling_factors.csv
- digital_gain_metrics.csv
This files allow us to check the black leveling factors and the digital gain applied to the image and what changes when you edit this values in the yaml.
Tune in params.yaml:
- black_level red
- black_level green_r
- black_level green_b
- black_level blue
- digital_gain
White Balance
To debug and tune Auto White Balance algorithm we have different useful csv files: Useful CSV files: white_balance_gains.csv
frame,gain_r,gain_g,gain_b 25,1,0.963491,0.995026
This CSV records the white balance gains used for each processed frame. Depending on the pipeline configuration, these gains can originate from one of two sources:
- Manual white balance, where the gains are specified by the user in the ISP configuration (YAML) file.
- Automatic white balance (AWB), where the gains are estimated by the white balance algorithm during pipeline execution.
Each row contains:
- frame: Processed frame number.
- gain_r: Gain applied to the red channel.
- gain_g: Gain applied to the green channel.
- gain_b: Gain applied to the blue channel.
histogram_post_white_balance.csv
bin,r_count,g_count,b_count 24,75,117,68 25,90,97,80 26,84,100,91 27,87,121,83 28,82,128,78 29,71,111,71 30,74,112,82 31,77,150,80 32,92,109,77 33,65,102,74 34,76,113,81 35,78,108,76 36,81,110,67 37,84,155,58 38,86,122,56 39,75,131,65 40,83,139,73 41,66,141,75
This CSV contains the Bayer image histogram after the White Balance stage. The input to this stage is the output of the Black Level Correction (BLC) stage. White Balance applies independent gain factors to the red, green, and blue Bayer channels in order to compensate for the scene illumination and produce a more neutral color response.
Each row represents one histogram bin and includes:
- bin: Histogram bin index corresponding to a range of pixel values after White Balance.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
The viewer displays the post-White-Balance histograms for the red, green, and blue Bayer channels independently.
When compared to the post-Black-Level-Correction histogram, the channel distributions are expected to shift according to the applied white balance gains. The amount of shift depends on whether the gains were manually configured or estimated by the Automatic White Balance (AWB) algorithm.
A successful White Balance stage produces channel histograms that are more closely aligned while preserving the overall image information.
Tune in params.yaml:
- manual_wb
- wb_gains
- white_balance_calibration.u_ref
- white_balance_calibration.v_ref
Histogram Stage
This stage provides a usefulhistogram.csv
This histogram is generated by the dedicated PVA Histogram stage during pipeline execution. The other histogram CSV files are debugging artifacts generated to visualize the pixel distribution after individual ISP stages. Although both describe pixel distributions, they serve different purposes: the hardware histogram is intended for real-time ISP processing, while the exported histograms are intended for analysis and debugging.
bin,count 0,0 1,457090 2,42250 3,8689 4,929 5,515 6,334 7,107 8,92 9,63 10,70 11,84 12,107 13,132 14,85
The input to this stage is the output of the Black Level Correction (BLC) stage. Each row contains:
- bin: Histogram bin index.
- count: Number of pixels falling within the corresponding intensity range.
Demosaicing
To debug and tune Demosaicing algorithm we have an useful Histogram_post_demosaic.csv file:
bin,r_count,g_count,b_count 39,199,271,271 40,200,268,283 41,230,287,259 42,279,252,269 43,343,197,281 44,302,142,247 45,205,136,178 46,166,100,145 47,163,100,122 48,156,117,138 49,171,118,132 50,127,137,98 51,155,108,127
This CSV contains the RGB image histogram after the Demosaicing stage. The input to this stage is the output of the White Balance stage.
Unlike the previous Bayer histograms, which represent the individual sensor color samples, this histogram is computed from the fully reconstructed RGB image produced by the demosaicing algorithm. Each row contains:
- bin: Histogram bin index.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
The viewer displays the histograms of the reconstructed red, green, and blue channels after demosaicing.
Compared to the Bayer histograms, the distributions are expected to appear smoother because the missing color components have been interpolated. While the exact histogram depends on the interpolation algorithm and the scene content, the overall intensity distribution should remain consistent with the output of the White Balance stage.
A successful demosaicing stage reconstructs a complete RGB image while preserving luminance and color relationships, without introducing visible artifacts or unexpected changes in the histogram distribution.
Global Tone Mapping
To debug and tune Global Tone Mapping algorithm we have different useful csv files: gtm_luminances.csv
x,y,luminance,display_luminance 0,0,237,28 1,0,312,36 2,0,263,31 3,0,314,36 4,0,268,32 5,0,315,37 6,0,260,31 7,0,314,36 8,0,266,31 9,0,312,36 10,0,268,31
This CSV contains the luminance values processed by the Global Tone Mapping (GTM) stage. The input to this stage is the luminance computed from the demosaiced RGB image, and the output is the corresponding display luminance after applying the global tone mapping curve. Each row contains:
- x: Horizontal pixel coordinate.
- y: Vertical pixel coordinate.
- luminance: Input scene luminance computed from the RGB image.
- display_luminance: Output luminance after applying the GTM transfer function.
The CSV records the mapping applied to every processed pixel, allowing developers to verify how the tone mapping algorithm compresses the scene dynamic range into the displayable output range.
The viewer reconstructs the Global Tone Mapping transfer curve using the luminance samples contained in the CSV.
The blue curve represents the reconstructed tone mapping function. The orange points correspond to the measured luminance samples extracted from the processed image.
The horizontal axis represents the input scene luminance, while the vertical axis represents the display luminance produced by the GTM stage. Both axes are displayed using a logarithmic scale to improve the visualization of the wide luminance range.
A correctly configured GTM stage should produce measured points that closely follow the reconstructed transfer curve. Small variations are expected because multiple pixels may share similar luminance values, but the overall distribution should remain smooth and monotonic.
histogram_pre_gamma.csv
bin,r_count,g_count,b_count 0,716,108,1347 1,14,0,14 2,7,2,16 3,13,2,21 4,17,1,20 5,10,1,10 6,11,1,19 7,14,2,22 8,15,0,11 9,13,2,15 10,12,1,19 11,19,0,27 12,11,2,33
This CSV contains the RGB histogram produced by the output of the Global Tone Mapping (GTM) stage. Since the next stage in the ISP pipeline is Gamma Tone Mapping, the file is named histogram_pre_gamma.csv.
The histogram therefore represents the image immediately after Global Tone Mapping and immediately before Gamma Tone Mapping. Each row contains:
- bin: Histogram bin index.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
This histogram allows developers to inspect the pixel intensity distribution produced by the Global Tone Mapping stage before any gamma correction is applied.
The viewer displays the RGB histogram generated from the output of the Global Tone Mapping stage.
This histogram serves as the input distribution for the Gamma Tone Mapping stage. It provides a reference for understanding how GTM redistributes the image intensities before the nonlinear gamma correction is applied.
When the GTM stage is functioning correctly, the histogram should exhibit a smooth redistribution of pixel intensities without introducing abrupt discontinuities or excessive clipping.
Tune in params.yaml:
- brightness
- gtm_scale_min
- gtm_scale_max
- gtm_temporal_alpha
- saturation
Gamma Tone Mapping
To debug and tune Global Tone Mapping algorithm we have different useful csv files: gamma_metrics.csv
frame,gamma 25,2.2
This CSV reports the gamma value used during processing.
histogram_pre_gamma.csv
This CSV shows the tonal distribution before gamma correction. You can see a detailed information about this CSV in the previous section.
histogram_post_gamma.csv
bin,r_count,g_count,b_count 34,13,2,21 35,0,0,0 36,0,0,0 37,0,0,0 38,0,0,0 39,17,1,20 40,0,0,0 41,0,0,0 42,0,0,0 43,10,1,10 44,0,0,0 45,0,0,0 46,11,1,19 47,0,0,0 48,0,0,0 49,0,0,0 50,14,2,22
This CSV contains the RGB histogram after the Gamma Tone Mapping stage. The input to this stage is the output of the Global Tone Mapping (GTM) stage, represented by histogram_pre_gamma.csv.
Gamma Tone Mapping applies a nonlinear transfer function to the tone-mapped image, producing pixel values that are better suited for display devices and human visual perception.
Each row contains:
bin: Histogram bin index.
- r_count: Number of red pixels within the bin.
- g_count: Number of green pixels within the bin.
- b_count: Number of blue pixels within the bin.
Comparing this histogram with histogram_pre_gamma.csv allows developers to evaluate the effect of the gamma transfer function on the image intensity distribution.
The viewer displays the RGB histograms after Gamma Tone Mapping.
Compared to histogram_pre_gamma.csv, the histogram is expected to shift according to the nonlinear gamma transfer function. The redistribution of pixel intensities generally makes better use of the available display range while preserving the tone relationships established by the Global Tone Mapping stage.
A correctly functioning Gamma Tone Mapping stage should produce a smooth histogram redistribution without introducing artifacts or altering the color balance of the image.
Tune in params.yaml:
- gamma
