docs: webp images are back

psy-ex · Oct 30, 2024 · 94b8b20 · 94b8b20
1 parent b8f8497
commit 94b8b20
Show file tree

Hide file tree

Showing 221 changed files with 63 additions and 63 deletions.
diff --git a/Docs/Appendix-Compound-Mode-Prediction.md b/Docs/Appendix-Compound-Mode-Prediction.md
@@ -77,7 +77,7 @@ of the block. The feature makes use of a wedge codebook where wedge
 orientations are either horizontal, vertical or oblique with slopes: 2,
 -2, 0.5 and -0.5 for square and rectangular blocks, as shown in Figure 2.
 
-![Wedge_Codebook_2020_01_11](./img/Wedge_Codebook_2020_01_11.png)
+![Wedge_Codebook_2020_01_11](./img/Wedge_Codebook_2020_01_11.webp)
 
 ##### Figure 2. Wedge Codebook.
 

diff --git a/Docs/Appendix-Dynamic-Mini-GoP.md b/Docs/Appendix-Dynamic-Mini-GoP.md
@@ -16,7 +16,7 @@ AV1 allows up to 8 pictures to be stored in a decoded picture buffer (DPB) to be
 
 ### Open Loop (Mostly in Picture Decision)
 
-<img src="./img/open_loop_fig1.png" width=100%>
+<img src="./img/open_loop_fig1.webp" width=100%>
 
 ##### **Figure 1:** Open-loop reference tracking.
 

diff --git a/Docs/Appendix-Intra-Block-Copy.md b/Docs/Appendix-Intra-Block-Copy.md
@@ -25,7 +25,7 @@ frame consists of already reconstructed blocks that are 256 pixels away
 (in a raster scan order) from the current block. Figure 1 below
 illustrates the allowed search area.
 
-![intra_block_copy_fig1](./img/intra_block_copy_fig1.png)
+![intra_block_copy_fig1](./img/intra_block_copy_fig1.webp)
 
 ##### Figure 1. Diagram showing blocks not allowed in the search area.
 
@@ -40,7 +40,7 @@ A diagram of the main function calls associated with the IBC algorithm
 is shown in Figure 2 below. The functions are shown according to the
 depth of the function call.
 
-![intra_block_copy_fig2](./img/intra_block_copy_fig2.png)
+![intra_block_copy_fig2](./img/intra_block_copy_fig2.webp)
 
 ##### Figure 2. Main function calls associated with the IBC algorithm.
 

diff --git a/Docs/Appendix-Local-Warped-Motion.md b/Docs/Appendix-Local-Warped-Motion.md
@@ -41,7 +41,7 @@ The remaining parameters $`h_{11}, h_{12}, h_{21}, h_{22}`$ are estimated using
 
 To illustrate the estimation of these parameters, consider example shown in Figure 1 below.
 
-![local_warped_motion_fig1](./img/local_warped_motion_fig1.png)
+![local_warped_motion_fig1](./img/local_warped_motion_fig1.webp)
 
 ##### Figure 1. Current block in yellow is a 32x32 block. Neighboring blocks that refer to the same reference picture as the current block are in blue. MVs (in orange) for the current block and the blue blocks are used to infer the local warp motion of the yellow block.
 
@@ -130,7 +130,7 @@ The final warped motion model is applied on an 8x8 basis in the reference
 frame. The predicted block is constructed by assembling the 8x8 predicted
 warped blocks from the reference picture.
 
-![local_warped_motion_fig2](./img/local_warped_motion_fig2.png)
+![local_warped_motion_fig2](./img/local_warped_motion_fig2.webp)
 
 ##### Figure 2. The horizontal, vertical, and combined shears respectively.
 
@@ -158,7 +158,7 @@ indicated in Table 1.
 
 Figure 3 below summarizes the data flow of the LW implementation.
 
-![local_warped_motion_fig_new1](./img/local_warped_motion_fig_new1.png)
+![local_warped_motion_fig_new1](./img/local_warped_motion_fig_new1.webp)
 
 ##### Figure 3. Data flow for the LW feature.
 
@@ -168,7 +168,7 @@ RD optimization. A high-level diagram of the function calls relevant to the two
 main LW functions, namely ```inject_inter_candidates``` and
 ```warped_motion_prediction``` is given in Figure 4 below.
 
-![local_warped_motion_fig_new2](./img/local_warped_motion_fig_new2.png)
+![local_warped_motion_fig_new2](./img/local_warped_motion_fig_new2.webp)
 
 ##### Figure 4. Function calls relevant to the two main LW functions highlighted in blue.
 
@@ -181,7 +181,7 @@ are outlined in the following.
 The injection is performed by the function ```inject_inter_candidates```.
 A diagram of the relevant function calls is given in Figure 5.
 
-![local_warped_motion_fig_new3](./img/local_warped_motion_fig_new3.png)
+![local_warped_motion_fig_new3](./img/local_warped_motion_fig_new3.webp)
 
 ##### Figure 5. Continuation of Figure 3 with the function calls related to the injection of LW candidates.
 
@@ -243,7 +243,7 @@ The generation of the LW predictions in MD is performed using the
 function ```warped\_motion\_prediction```. A diagram of the associated
 function call is shown in Figure 6 below.
 
-![local_warped_motion_fig_new4](./img/local_warped_motion_fig_new4.png)
+![local_warped_motion_fig_new4](./img/local_warped_motion_fig_new4.webp)
 
 ##### Figure 6. Continuation of Figure 4 with the function calls related to the evaluation of the LW predictions in MD.
 

diff --git a/Docs/Appendix-Mode-Decision.md b/Docs/Appendix-Mode-Decision.md
@@ -20,7 +20,7 @@ estimations from the Motion Estimation process and the picture-level QP from
 the Rate Control process. The Mode Decision process operates on an SB basis
 (i.e. each step in the Mode Decision process is performed for each SB).
 
-![md_figure1](./img/md_figure1.png)
+![md_figure1](./img/md_figure1.webp)
 
 ##### Figure 1. Partitioning, mode decision, encoding and filtering tasks.
 
@@ -46,7 +46,7 @@ is applied in subsequent steps until PD Stage n where $`N_N`$ partitions will be
 tested. The output of the final (nth) PD stage is the final partition and its
 corresponding coding modes that are selected.
 
-![md_figure2](./img/md_figure2.png)
+![md_figure2](./img/md_figure2.webp)
 
 ##### Figure 2. Partitioning decision stages.
 
@@ -62,7 +62,7 @@ applied in subsequent stages. In the last stage, only very few candidates as
 considered at the input and usually the full set of high-performance prediction
 tools are used to finalize the selected partitions and modes.
 
-![md_figure3](./img/md_figure3.png)
+![md_figure3](./img/md_figure3.webp)
 
 ##### Figure 3. Example of the processing details in each PD stage.
 
@@ -97,7 +97,7 @@ in the bitstream, which is the task performed by the Encode Pass discussed
 next. The exception is that final MD stage must be conformant when the Encode
 Pass is bypassed (controlled using the ```bypass_encdec``` signal).
 
-![md_figure4](./img/md_figure4.png)
+![md_figure4](./img/md_figure4.webp)
 
 ##### Figure 4. MD flow within a single PD stage.
 
@@ -198,7 +198,7 @@ block as illustrated in Figure 5. Also note that the neighbor array design can
 store either mode information directly or reference data indirectly (e.g.
 pointers).
 
-![md_figure5](./img/md_figure5.png)
+![md_figure5](./img/md_figure5.webp)
 
 ##### Figure 5. Neighbor array structure.
 
@@ -230,7 +230,7 @@ neighbor arrays contain a snapshot of the mode information currently stored in
 each block position at the time that the block labeled “Current Block” is being
 processed.
 
-![md_figure6](./img/md_figure6.png)
+![md_figure6](./img/md_figure6.webp)
 
 ##### Figure 6. Neighbor array data illustration.
 

diff --git a/Docs/Appendix-Open-Loop-Motion-Estimation.md b/Docs/Appendix-Open-Loop-Motion-Estimation.md
@@ -47,7 +47,7 @@ search centres (based on SAD), the worst HME-level-0 search centre is replaced
 by the best pre-HME result (to be considered in the next HME stages). As such,
 HME-level-1 must be enabled to use pre-HME.
 
-![me_fig1](./img/me_fig1.png)
+![me_fig1](./img/me_fig1.webp)
 
 ##### Figure 1. Example of a pre-HME search area around point X. The search region is long and narrow in the horizontal and vertical direction.
 
@@ -69,11 +69,11 @@ is divided into a 2x2 grid). All search and selection decisions are based on a
 pure SAD distortion metric. Figure 3 depicts an example HME full search and
 refinement data flow through Level-0, Level-1, and Level-2.
 
-![me_fig2](./img/me_fig2.png)
+![me_fig2](./img/me_fig2.webp)
 
 ##### Figure 2: Illustration of the different search levels in HME.
 
-![me_fig3](./img/me_fig3.png)
+![me_fig3](./img/me_fig3.webp)
 
 ##### Figure 3: Search center selection in HME.
 
@@ -84,7 +84,7 @@ based on a SAD distortion metric. Search center candidates may be generated
 from HME or other sources of candidate search centers. A diagram showing search
 center selection and the Motion Estimation is given in Figure 4.
 
-![me_fig4](./img/me_fig4.png)
+![me_fig4](./img/me_fig4.webp)
 
 ##### Figure 4: Search centre selection and motion estimation. Reference N search centre candidates come from HME (or other sources, if applicable).
 
@@ -101,7 +101,7 @@ on 8x8 blocks, and the MV/SAD information for larger block sizes are derived
 from the 8x8 results (by adding together all the 8x8 SADs that make up a given
 block).
 
-![me_fig5](./img/me_fig_new.png)
+![me_fig5](./img/me_fig_new.webp)
 
 ##### Figure 5: ME search for the case of a 64x64 SB. The SAD is computed for each 8x8 block. For larger square blocks, the 8x8 SADs are summed to produce the output SAD of the larger blocks.
 
@@ -116,7 +116,7 @@ values.
 The flow of data in open-loop ME is illustrated in Figure 6, along with the
 relevant functions that are associated with each part of the algorithm.
 
-![me_fig6](./img/me_fig5.png)
+![me_fig6](./img/me_fig5.webp)
 
 ##### Figure 6: Open-loop ME flow diagram for each SB.
 

diff --git a/Docs/Appendix-Overlapped-Block-Motion-Compensation.md b/Docs/Appendix-Overlapped-Block-Motion-Compensation.md
@@ -28,7 +28,7 @@ The prediction algorithm for a given block proceeds as follows:
 
 As an example, consider the yellow block shown in Figure 1 below. The 16x16 yellow block is the current block to be predicted. The 16x16 green and 8x8 blue blocks are inter coded neighboring blocks. The initial inter prediction for the yellow block is generated using regular inter prediction.
 
-![obmc_figure1](./img/obmc_figure1.png)
+![obmc_figure1](./img/obmc_figure1.webp)
 
 ##### Figure 1. The yellow block in the figure is the inter block of interest.
 
@@ -43,7 +43,7 @@ Step 1: Vertical blending (see Figure 2 below)
 
   where the index i corresponds to the y position of the pixel in the block.
 
-![obmc_figure2](./img/obmc_figure2.png)
+![obmc_figure2](./img/obmc_figure2.webp)
 
 ##### Figure 2. Vertical blending of the prediction based on the blue 8x8 inter block.
 
@@ -60,7 +60,7 @@ Step 2: Horizontal blending (See Figure 3 below)
 
   where the index i corresponds to the x position of the pixel in the block.
 
-![obmc_figure3](./img/obmc_figure3.png)
+![obmc_figure3](./img/obmc_figure3.webp)
 
 ##### Figure 3. Horizontal blending of the prediction based on the green inter block.
 
@@ -89,7 +89,7 @@ Flags associated with the OBMC feature are listed in Table 1.
 
 A diagram of the OBMC-related function calls in MD and in the Encode Pass is given in Figure 5.
 
-![obmc_figure4](./img/obmc_figure4.png)
+![obmc_figure4](./img/obmc_figure4.webp)
 
 ##### Figure 4. A diagram of the function calls leading to the generation and coding of OBMC candidates in MD and in the Encode Pass.
 

diff --git a/Docs/Appendix-Palette-Prediction.md b/Docs/Appendix-Palette-Prediction.md
@@ -29,7 +29,7 @@ colors with index 0, 1 and 2. Based on the selected palette, the index
 map of the block can be generated as shown below. The encoding of the
 indices then proceeds in a wavefront manner as indicated below.
 
-![palette_prediction_fig1](./img/palette_prediction_fig1.png)
+![palette_prediction_fig1](./img/palette_prediction_fig1.webp)
 
 ##### Figure 1. Example of a 4x4 source block, corresponding palette, index map and wavefront processing pattern. The 4x4 block is considered here only for illustration purposes, as the block size needs to be at least 8x8 for palette prediction to be allowed.</p>
 
@@ -79,7 +79,7 @@ The feature is currently active only when screen content encoding is active, eit
 
 The main function calls associated with palette mode prediction are indicated in Figure 2 below.
 
-![palette_prediction_fig2](./img/palette_prediction_fig2.png)
+![palette_prediction_fig2](./img/palette_prediction_fig2.webp)
 
 ##### Figure 2. Main function calls related to the injection of palette mode candidates.
 

diff --git a/Docs/Appendix-Rate-Control.md b/Docs/Appendix-Rate-Control.md
@@ -33,7 +33,7 @@ matching. After each frame is completely coded, the packetization kernel sends
 the corresponding actual number of bits for the encoded frame back to the rate
 control algorithm to update the internal model and decide on future QPs.
 
-![rc_figure1](./img/rc_figure1.PNG)
+![rc_figure1](./img/rc_figure1.webp)
 
 ###### Figure 1. High-level encoder process dataflow.
 
@@ -75,7 +75,7 @@ helps in matching the target rate considerably. The second pass uses the
 data from the previous pass to achieve the best performance. A block diagram
 of the encoder with three passes is shown in Figure 2.
 
-![rc_figure2](./img/rc_figure2.PNG)
+![rc_figure2](./img/rc_figure2.webp)
 
 ###### Figure 2. Block diagram of two-pass encoder.
 
@@ -121,7 +121,7 @@ The rate control algorithm in the second pass includes the following main steps:
 6) Decide to perform re-encode (if applicable) at the end of the Mode Decision process (*recode_loop_decision_maker*).
 7) Update post-encode VBR data after receiving the feedback (*av1_rc_postencode_update()*).
 
-![rc_figure3](./img/rc_figure3.PNG)
+![rc_figure3](./img/rc_figure3.webp)
 
 ###### Figure 3. Flowchart of rate control in the second pass.
 
@@ -369,7 +369,7 @@ encoder pipeline tasks such as motion estimation, entropy coding or in-loop
 filtering. The flowchart in Figure 4 shows the high-level design of the
 re-encode decision mechanism.
 
-![rc_figure4](./img/rc_figure4.PNG)
+![rc_figure4](./img/rc_figure4.webp)
 
 ###### Figure 4. Re-encode flowchart.
 
@@ -443,7 +443,7 @@ frame is to be processed. The output is the actual encoded frame size, and is
 removed from the buffer content at the same frequency the contents of the
 virtual buffer are updated by the target frame size.
 
-![rc_figure5](./img/rc_figure5.PNG)
+![rc_figure5](./img/rc_figure5.webp)
 ###### Figure 5. CBR virtual buffer diagram.
 
 The virtual buffer parameters are initialized once before invoking the CBR rate control for the first frame as follows:

diff --git a/Docs/Appendix-Recursive-Intra.md b/Docs/Appendix-Recursive-Intra.md
@@ -11,7 +11,7 @@ shown in Figure 1 below. The intra prediction for sample P in this case is the
 weighted sum of samples A, B and C. The latter could be reference samples for
 the current block and/or already predicted samples within the same block.
 
-![recursive_intra_fig0](./img/recursive_intra_fig0.png)
+![recursive_intra_fig0](./img/recursive_intra_fig0.webp)
 
 ##### Figure 1. Prediction of the sample P using the neighboring samples A, B and C.
 
@@ -20,7 +20,7 @@ The prediction procedure is outlined as follows:
   - The predicted block is divided into 4x2 sub-blocks.
     See the example of the 8x8 block in Figure 2 below where the 8x8 block is divided into eight 4x2 blocks.
 
-![recursive_intra_fig1](./img/recursive_intra_fig1.png)
+![recursive_intra_fig1](./img/recursive_intra_fig1.webp)
 
 ##### Figure 2. Splitting an 8x8 block (in yellow) into 4x2 blocks.
 
@@ -31,14 +31,14 @@ The prediction procedure is outlined as follows:
         For Block\_1, the seven reference samples consist of the above five neighboring samples for the 8x8 block
         and two left neighboring samples that are predicted samples from Block\_0.
 
-![recursive_intra_fig2](./img/recursive_intra_fig2.png)
+![recursive_intra_fig2](./img/recursive_intra_fig2.webp)
 
 ##### Figure 3. Example of reference samples for 4x2 blocks.
 
   - The predicted pixels in the 4x2 sub-block are obtained by filtering the array of seven reference samples.
     To illustrate the procedure, consider the 4x2 block shown in Figure 4 below:
 
-![recursive_intra_fig3](./img/recursive_intra_fig3.png)
+![recursive_intra_fig3](./img/recursive_intra_fig3.webp)
 
 ##### Figure 4. Reference sample around a 4x2 block.
 
@@ -67,7 +67,7 @@ prediction mode and predicted sample.
 
 ##### Table 2. Filter coefficients as a function of the intra prediction mode and the predicted sample.
 
-![recursive_intra_table-2](./img/recursive_intra_table-2.png)
+![recursive_intra_table-2](./img/recursive_intra_table-2.webp)
 
 The best filtering mode (i.e. set of weights) is selected through, for
 example, a rate distortion performance measure.
@@ -100,7 +100,7 @@ below.
 
 ##### Table 4. Interface to the recursive filter intra feature.
 
-![recursive_intra_fig4](./img/recursive_intra_fig4.png)
+![recursive_intra_fig4](./img/recursive_intra_fig4.webp)
 
 ### Candidate Injection
 

diff --git a/Docs/Appendix-Reference-Scaling.md b/Docs/Appendix-Reference-Scaling.md
@@ -25,15 +25,15 @@ can have different downscaling factors. The following sections outline how
 pictures with different sizes are processed in the different stages of the
 SVT-AV1 encoder pipeline and how the downscaling factor is determined.
 
-![reference_scaling_pipeline](./img/reference_scaling_pipeline.png)
+![reference_scaling_pipeline](./img/reference_scaling_pipeline.webp)
 ##### Figure 1. Processing pipeline when reference scaling is active.
 
 
 ## 2. Implementation of the algorithm
 ### 2.1. Downscaled and full-size versions of pictures
 Figure 2 illustrates how pictures with different sizes are processed in
 different coding processes/stages.
-![reference_scaling_picture_size](./img/reference_scaling_picture_size.png)
+![reference_scaling_picture_size](./img/reference_scaling_picture_size.webp)
 ##### Figure 2. Processing of the downscaled and full-size pictures in the encoder pipeline.
 
 In Figure 2, downscaled input refers to a downscaled version of the current
@@ -92,7 +92,7 @@ each of the above-mentioned modes works is included below.
 The following sections explain how these different modes are implemented in the
 SVT-AV1 encoder. The high-level dataflow of reference scaling is shown in Figure
 3.
-![ref_scale_modes_dataflow](./img/ref_scale_modes_dataflow.png)
+![ref_scale_modes_dataflow](./img/ref_scale_modes_dataflow.webp)
 ##### Figure 3. High-level encoder process dataflow with reference scaling feature.
 
 #### 2.2.1. Fixed and Random mode
@@ -135,7 +135,7 @@ of scaling decision starts after this reset.
 ### 2.4. Reference Scaling API
 Table 1 illustrates the usage of reference scaling functions. Only related
 processes are listed.
-![ref_scale_API](./img/ref_scale_API.png)
+![ref_scale_API](./img/ref_scale_API.webp)
 ##### Table 1. Reference Scaling API
 
 ## 3. Optimization
@@ -161,7 +161,7 @@ The duplicated downscaling of ref_pic_0->downscaled_reference_picture[4][1] perf
 Reference Scaling also has an impact on memory usage: Extra buffers are
 allocated to hold downscaled pictures, including current coding picture, PA
 references and reconstructed references as shown in Figure 4.
-![ref_scale_downscaled_buffers](./img/ref_scale_downscaled_buffers.png)
+![ref_scale_downscaled_buffers](./img/ref_scale_downscaled_buffers.webp)
 ##### Figure 4. Buffers for downscaled pictures
 
 ## 4. Usage recommendation