ソースを参照

docs: update image links and enhance documentation clarity in multiple files

myhloli 4 ヶ月 前
コミット
b83f8fa9a8

+ 1 - 1
docs/en/index.md

@@ -1,7 +1,7 @@
 <div align="center" xmlns="http://www.w3.org/1999/html">
 <!-- logo -->
 <p align="center">
-  <img src="../images/MinerU-logo.png" width="300px" style="vertical-align:middle;">
+  <img src="https://opendatalab.github.io/MinerU/images/MinerU-logo.png" width="300px" style="vertical-align:middle;">
 </p>
 </div>
 

+ 214 - 163
docs/en/usage/output_files.md → docs/en/output_files.md

@@ -1,69 +1,118 @@
-# Overview
+# MinerU Output Files Documentation
 
-After executing the `mineru` command, in addition to outputting files related to markdown, several other files unrelated to markdown will also be generated. These files will be introduced one by one.
+## Overview
 
-## some_pdf_layout.pdf
+After executing the `mineru` command, in addition to the main markdown file output, multiple auxiliary files are generated for debugging, quality inspection, and further processing. These files include:
 
-Each page's layout consists of one or more bounding boxes. The number in the top-right corner of each box indicates the reading order. Additionally, different content blocks are highlighted with distinct background colors within the layout.pdf.
-![layout example](../images/layout_example.png)
+- **Visual debugging files**: Help users intuitively understand the document parsing process and results
+- **Structured data files**: Contain detailed parsing data for secondary development
 
-## some_pdf_spans.pdf(Applicable only to the pipeline backend)
+The following sections provide detailed descriptions of each file's purpose and format.
 
-All spans on the page are drawn with different colored line frames according to the span type. This file can be used for quality control, allowing for quick identification of issues such as missing text or unrecognized inline formulas.
+## Visual Debugging Files
 
-![spans example](../images/spans_example.png)
+### Layout Analysis File (layout.pdf)
 
-## some_pdf_model.json(Applicable only to the pipeline backend)
+**File naming format**: `{original_filename}_layout.pdf`
 
-### Structure Definition
+**Functionality**:
+
+- Visualizes layout analysis results for each page
+- Numbers in the top-right corner of each detection box indicate reading order
+- Different background colors distinguish different types of content blocks
+
+**Use cases**:
+
+- Check if layout analysis is correct
+- Verify if reading order is reasonable
+- Debug layout-related issues
+
+![layout page example](../images/layout_example.png)
+
+### Text Spans File (spans.pdf)
+
+> [!NOTE]
+> Only applicable to pipeline backend
+
+**File naming format**: `{original_filename}_spans.pdf`
+
+**Functionality**:
+
+- Uses different colored line boxes to annotate page content based on span type
+- Used for quality inspection and issue troubleshooting
+
+**Use cases**:
+
+- Quickly troubleshoot text loss issues
+- Check inline formula recognition
+- Verify text segmentation accuracy
+
+![span page example](../images/spans_example.png)
+
+## Structured Data Files
+
+### Model Inference Results (model.json)
+
+> [!NOTE]
+> Only applicable to pipeline backend
+
+**File naming format**: `{original_filename}_model.json`
+
+#### Data Structure Definition
 
 ```python
 from pydantic import BaseModel, Field
 from enum import IntEnum
 
 class CategoryType(IntEnum):
-     title = 0               # Title
-     plain_text = 1          # Text
-     abandon = 2             # Includes headers, footers, page numbers, and page annotations
-     figure = 3              # Image
-     figure_caption = 4      # Image description
-     table = 5               # Table
-     table_caption = 6       # Table description
-     table_footnote = 7      # Table footnote
-     isolate_formula = 8     # Block formula
-     formula_caption = 9     # Formula label
-
-     embedding = 13          # Inline formula
-     isolated = 14           # Block formula
-     text = 15               # OCR recognition result
-
+    """Content category enumeration"""
+    title = 0               # Title
+    plain_text = 1          # Text
+    abandon = 2             # Including headers, footers, page numbers, and page annotations
+    figure = 3              # Image
+    figure_caption = 4      # Image caption
+    table = 5               # Table
+    table_caption = 6       # Table caption
+    table_footnote = 7      # Table footnote
+    isolate_formula = 8     # Interline formula
+    formula_caption = 9     # Interline formula number
+    embedding = 13          # Inline formula
+    isolated = 14           # Interline formula
+    text = 15               # OCR recognition result
 
 class PageInfo(BaseModel):
-    page_no: int = Field(description="Page number, the first page is 0", ge=0)
+    """Page information"""
+    page_no: int = Field(description="Page number, first page is 0", ge=0)
     height: int = Field(description="Page height", gt=0)
     width: int = Field(description="Page width", ge=0)
 
 class ObjectInferenceResult(BaseModel):
+    """Object recognition result"""
     category_id: CategoryType = Field(description="Category", ge=0)
-    poly: list[float] = Field(description="Quadrilateral coordinates, representing the coordinates of the top-left, top-right, bottom-right, and bottom-left points respectively")
-    score: float = Field(description="Confidence of the inference result")
+    poly: list[float] = Field(description="Quadrilateral coordinates, format: [x0,y0,x1,y1,x2,y2,x3,y3]")
+    score: float = Field(description="Confidence score of inference result")
     latex: str | None = Field(description="LaTeX parsing result", default=None)
     html: str | None = Field(description="HTML parsing result", default=None)
 
 class PageInferenceResults(BaseModel):
-     layout_dets: list[ObjectInferenceResult] = Field(description="Page recognition results", ge=0)
-     page_info: PageInfo = Field(description="Page metadata")
+    """Page inference results"""
+    layout_dets: list[ObjectInferenceResult] = Field(description="Page recognition results")
+    page_info: PageInfo = Field(description="Page metadata")
 
-
-# The inference results of all pages, ordered by page number, are stored in a list as the inference results of MinerU
+# Complete inference results
 inference_result: list[PageInferenceResults] = []
-
 ```
 
-The format of the poly coordinates is \[x0, y0, x1, y1, x2, y2, x3, y3\], representing the coordinates of the top-left, top-right, bottom-right, and bottom-left points respectively.
-![Poly Coordinate Diagram](../images/poly.png)
+#### Coordinate System Description
 
-### example
+`poly` coordinate format: `[x0, y0, x1, y1, x2, y2, x3, y3]`
+
+- Represents coordinates of top-left, top-right, bottom-right, bottom-left points respectively
+- Coordinate origin is at the top-left corner of the page
+
+![poly coordinate diagram](../images/poly.png)
+
+#### Sample Data
 
 ```json
 [
@@ -116,142 +165,127 @@ The format of the poly coordinates is \[x0, y0, x1, y1, x2, y2, x3, y3\], repres
 ]
 ```
 
-## some_pdf_model_output.txt (Applicable only to the VLM backend)
-
-This file contains the output of the VLM model, with each page's output separated by `----`.  
-Each page's output consists of text blocks starting with `<|box_start|>` and ending with `<|md_end|>`.  
-The meaning of each field is as follows:  
-- `<|box_start|>x0 y0 x1 y1<|box_end|>`  
-  x0 y0 x1 y1 represent the coordinates of a quadrilateral, indicating the top-left and bottom-right points. The values are based on a normalized page size of 1000x1000.
-- `<|ref_start|>type<|ref_end|>`  
-  `type` indicates the block type. Possible values are:
-  ```json
-  {
-      "text": "Text",
-      "title": "Title",
-      "image": "Image",
-      "image_caption": "Image Caption",
-      "image_footnote": "Image Footnote",
-      "table": "Table",
-      "table_caption": "Table Caption",
-      "table_footnote": "Table Footnote",
-      "equation": "Interline Equation"
-  }
-  ```
-- `<|md_start|>Markdown content<|md_end|>`  
-  This field contains the Markdown content of the block. If `type` is `text`, the end of the text may contain the `<|txt_contd|>` tag, indicating that this block can be connected with the following `text` block(s).
-  If `type` is `table`, the content is in `otsl` format and needs to be converted into HTML for rendering in Markdown.
-
-## some_pdf_middle.json
-
-| Field Name     | Description                                                                                                    |
-|:---------------| :------------------------------------------------------------------------------------------------------------- |
-| pdf_info       | list, each element is a dict representing the parsing result of each PDF page, see the table below for details |
-| \_backend      | pipeline \| vlm, used to indicate the mode used in this intermediate parsing state                                  |
-| \_version_name | string, indicates the version of mineru used in this parsing                                                |
-
-<br>
-
-**pdf_info**
+### VLM Output Results (model_output.txt)
 
-Field structure description
+> [!NOTE]
+> Only applicable to VLM backend
 
-| Field Name          | Description                                                                                                        |
-| :------------------ | :----------------------------------------------------------------------------------------------------------------- |
-| preproc_blocks      | Intermediate result after PDF preprocessing, not yet segmented                                                     |
-| layout_bboxes       | Layout segmentation results, containing layout direction (vertical, horizontal), and bbox, sorted by reading order |
-| page_idx            | Page number, starting from 0                                                                                       |
-| page_size           | Page width and height                                                                                              |
-| \_layout_tree       | Layout tree structure                                                                                              |
-| images              | list, each element is a dict representing an img_block                                                             |
-| tables              | list, each element is a dict representing a table_block                                                            |
-| interline_equations | list, each element is a dict representing an interline_equation_block                                              |
-| discarded_blocks    | List, block information returned by the model that needs to be dropped                                             |
-| para_blocks         | Result after segmenting preproc_blocks                                                                             |
+**File naming format**: `{original_filename}_model_output.txt`
 
-In the above table, `para_blocks` is an array of dicts, each dict representing a block structure. A block can support up to one level of nesting.
+#### File Format Description
 
-<br>
+- Uses `----` to separate output results for each page
+- Each page contains multiple text blocks starting with `<|box_start|>` and ending with `<|md_end|>`
 
-**block**
+#### Field Meanings
 
-The outer block is referred to as a first-level block, and the fields in the first-level block include:
+| Tag | Format | Description |
+|-----|--------|-------------|
+| Bounding box | `<\|box_start\|>x0 y0 x1 y1<\|box_end\|>` | Quadrilateral coordinates (top-left, bottom-right points), coordinate values after scaling page to 1000×1000 |
+| Type tag | `<\|ref_start\|>type<\|ref_end\|>` | Content block type identifier |
+| Content | `<\|md_start\|>markdown content<\|md_end\|>` | Markdown content of the block |
 
-| Field Name | Description                                                    |
-| :--------- | :------------------------------------------------------------- |
-| type       | Block type (table\|image)                                      |
-| bbox       | Block bounding box coordinates                                 |
-| blocks     | list, each element is a dict representing a second-level block |
+#### Supported Content Types
+
+```json
+{
+    "text": "Text",
+    "title": "Title", 
+    "image": "Image",
+    "image_caption": "Image caption",
+    "image_footnote": "Image footnote",
+    "table": "Table",
+    "table_caption": "Table caption", 
+    "table_footnote": "Table footnote",
+    "equation": "Interline formula"
+}
+```
 
-<br>
-There are only two types of first-level blocks: "table" and "image". All other blocks are second-level blocks.
+#### Special Tags
 
-The fields in a second-level block include:
+- `<|txt_contd|>`: Appears at the end of text, indicating that this text block can be connected with subsequent text blocks
+- Table content uses `otsl` format and needs to be converted to HTML for rendering in Markdown
 
-| Field Name | Description                                                                                                 |
-| :--------- | :---------------------------------------------------------------------------------------------------------- |
-| type       | Block type                                                                                                  |
-| bbox       | Block bounding box coordinates                                                                              |
-| lines      | list, each element is a dict representing a line, used to describe the composition of a line of information |
+### Intermediate Processing Results (middle.json)
 
-Detailed explanation of second-level block types
+**File naming format**: `{original_filename}_middle.json`
 
-| type               | Description            |
-| :----------------- | :--------------------- |
-| image_body         | Main body of the image |
-| image_caption      | Image description text |
-| image_footnote     | Image footnote         |
-| table_body         | Main body of the table |
-| table_caption      | Table description text |
-| table_footnote     | Table footnote         |
-| text               | Text block             |
-| title              | Title block            |
-| index              | Index block            |
-| list               | List block             |
-| interline_equation | Block formula          |
+#### Top-level Structure
 
-<br>
+| Field Name | Type | Description |
+|------------|------|-------------|
+| `pdf_info` | `list[dict]` | Array of parsing results for each page |
+| `_backend` | `string` | Parsing mode: `pipeline` or `vlm` |
+| `_version_name` | `string` | MinerU version number |
 
-**line**
+#### Page Information Structure (pdf_info)
 
-The field format of a line is as follows:
+| Field Name | Description |
+|------------|-------------|
+| `preproc_blocks` | Unsegmented intermediate results after PDF preprocessing |
+| `layout_bboxes` | Layout segmentation results, including layout direction and bounding boxes, sorted by reading order |
+| `page_idx` | Page number, starting from 0 |
+| `page_size` | Page width and height `[width, height]` |
+| `_layout_tree` | Layout tree structure |
+| `images` | Image block information list |
+| `tables` | Table block information list |
+| `interline_equations` | Interline formula block information list |
+| `discarded_blocks` | Block information to be discarded |
+| `para_blocks` | Content block results after segmentation |
 
-| Field Name | Description                                                                                             |
-| :--------- | :------------------------------------------------------------------------------------------------------ |
-| bbox       | Bounding box coordinates of the line                                                                    |
-| spans      | list, each element is a dict representing a span, used to describe the composition of the smallest unit |
-
-<br>
+#### Block Structure Hierarchy
 
-**span**
+```
+Level 1 blocks (table | image)
+└── Level 2 blocks
+    └── Lines
+        └── Spans
+```
 
-| Field Name          | Description                                                                                              |
-| :------------------ | :------------------------------------------------------------------------------------------------------- |
-| bbox                | Bounding box coordinates of the span                                                                     |
-| type                | Type of the span                                                                                         |
-| content \| img_path | Text spans use content, chart spans use img_path to store the actual text or screenshot path information |
+#### Level 1 Block Fields
 
-The types of spans are as follows:
+| Field Name | Description |
+|------------|-------------|
+| `type` | Block type: `table` or `image` |
+| `bbox` | Rectangular box coordinates of the block `[x0, y0, x1, y1]` |
+| `blocks` | List of contained level 2 blocks |
 
-| type               | Description    |
-| :----------------- | :------------- |
-| image              | Image          |
-| table              | Table          |
-| text               | Text           |
-| inline_equation    | Inline formula |
-| interline_equation | Block formula  |
+#### Level 2 Block Fields
 
-**Summary**
+| Field Name | Description |
+|------------|-------------|
+| `type` | Block type (see table below) |
+| `bbox` | Rectangular box coordinates of the block |
+| `lines` | List of contained line information |
 
-A span is the smallest storage unit for all elements.
+#### Level 2 Block Types
 
-The elements stored within para_blocks are block information.
+| Type | Description |
+|------|-------------|
+| `image_body` | Image body |
+| `image_caption` | Image caption text |
+| `image_footnote` | Image footnote |
+| `table_body` | Table body |
+| `table_caption` | Table caption text |
+| `table_footnote` | Table footnote |
+| `text` | Text block |
+| `title` | Title block |
+| `index` | Index block |
+| `list` | List block |
+| `interline_equation` | Interline formula block |
 
-The block structure is as follows:
+#### Line and Span Structure
 
-First-level block (if any) -> Second-level block -> Line -> Span
+**Line fields**:
+- `bbox`: Rectangular box coordinates of the line
+- `spans`: List of contained spans
 
-### example
+**Span fields**:
+- `bbox`: Rectangular box coordinates of the span
+- `type`: Span type (`image`, `table`, `text`, `inline_equation`, `interline_equation`)
+- `content` | `img_path`: Text content or image path
+
+#### Sample Data
 
 ```json
 {
@@ -354,29 +388,37 @@ First-level block (if any) -> Second-level block -> Line -> Span
 }
 ```
 
+### Content List (content_list.json)
+
+**File naming format**: `{original_filename}_content_list.json`
+
+#### Functionality
+
+This is a simplified version of `middle.json` that stores all readable content blocks in reading order as a flat structure, removing complex layout information for easier subsequent processing.
+
+#### Content Types
 
-## some_pdf_content_list.json
+| Type | Description |
+|------|-------------|
+| `image` | Image |
+| `table` | Table |
+| `text` | Text/Title |
+| `equation` | Interline formula |
 
-This file is a JSON array where each element is a dict storing all readable content blocks in the document in reading order.  
-`content_list` can be viewed as a simplified version of `middle.json`. The content block types are mostly consistent with those in `middle.json`, but layout information is not included.  
+#### Text Level Identification
 
-The content has the following types:
+Text levels are distinguished through the `text_level` field:
 
-| type     | desc          |
-|:---------|:--------------|
-| image    | Image         |
-| table    | Table         |
-| text     | Text / Title  |
-| equation | Block formula |
+- No `text_level` or `text_level: 0`: Body text
+- `text_level: 1`: Level 1 heading
+- `text_level: 2`: Level 2 heading
+- And so on...
 
-Please note that both `title` and text blocks in `content_list` are uniformly represented using the text type. The `text_level` field is used to distinguish the hierarchy of text blocks:
-- A block without the `text_level` field or with `text_level=0` represents body text.
-- A block with `text_level=1` represents a level-1 heading.
-- A block with `text_level=2` represents a level-2 heading, and so on.
+#### Common Fields
 
-Each content contains the `page_idx` field, indicating the page number (starting from 0) where the content block resides.
+All content blocks include a `page_idx` field indicating the page number (starting from 0).
 
-### example
+#### Sample Data
 
 ```json
 [
@@ -437,4 +479,13 @@ Each content contains the `page_idx` field, indicating the page number (starting
         "page_idx": 5
     }
 ]
-```
+```
+
+## Summary
+
+The above files constitute MinerU's complete output results. Users can choose appropriate files for subsequent processing based on their needs:
+
+- **Model outputs**: Use raw outputs (model.json, model_output.txt)
+- **Debugging and verification**: Use visualization files (layout.pdf, spans.pdf) 
+- **Content extraction**: Use simplified files (*.md, content_list.json)
+- **Secondary development**: Use structured files (middle.json)

+ 12 - 3
docs/en/quick_start/docker_deployment.md

@@ -5,7 +5,7 @@ MinerU provides a convenient Docker deployment method, which helps quickly set u
 ## Build Docker Image using Dockerfile:
 
 ```bash
-wget https://gcore.jsdelivr.net/gh/opendatalab/MinerU@master/docker/china/Dockerfile
+wget https://gcore.jsdelivr.net/gh/opendatalab/MinerU@master/docker/global/Dockerfile
 docker build -t mineru-sglang:latest -f Dockerfile .
 ```
 
@@ -49,12 +49,21 @@ We provide a `compose.yml` file that you can use to quickly start MinerU service
 wget https://gcore.jsdelivr.net/gh/opendatalab/MinerU@master/docker/compose.yaml
 ```
 
+>[!NOTE]
+>
+>- The `compose.yaml` file contains configurations for multiple services of MinerU, you can choose to start specific services as needed.
+>- Different services might have additional parameter configurations, which you can view and edit in the `compose.yaml` file.
+>- Due to the pre-allocation of GPU memory by the `sglang` inference acceleration framework, you may not be able to run multiple `sglang` services simultaneously on the same machine. Therefore, ensure that other services that might use GPU memory have been stopped before starting the `vlm-sglang-server` service or using the `vlm-sglang-engine` backend.
+
 - Start `sglang-server` service and connect to `sglang-server` via `vlm-sglang-client` backend:
   ```bash
   docker compose -f compose.yaml --profile mineru-sglang-server up -d
-  # In another terminal, connect to sglang server via sglang client (only requires CPU and network, no sglang environment needed)
-  mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://<server_ip>:30000
   ```
+  >[!TIP]
+  >In another terminal, connect to sglang server via sglang client (only requires CPU and network, no sglang environment needed)
+  > ```bash
+  > mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://<server_ip>:30000
+  > ```
 
 - Start API service:
   ```bash

ファイルの差分が大きいため隠しています
+ 0 - 1
docs/en/quick_start/index.md


+ 11 - 6
docs/en/usage/advanced_cli_parameters.md

@@ -35,11 +35,11 @@
 > [!TIP]
 > Here are some common `CUDA_VISIBLE_DEVICES` setting examples:
 >   ```bash
->   CUDA_VISIBLE_DEVICES=1 Only device 1 will be seen
->   CUDA_VISIBLE_DEVICES=0,1 Devices 0 and 1 will be visible
->   CUDA_VISIBLE_DEVICES="0,1" Same as above, quotation marks are optional
->   CUDA_VISIBLE_DEVICES=0,2,3 Devices 0, 2, 3 will be visible; device 1 is masked
->   CUDA_VISIBLE_DEVICES="" No GPU will be visible
+>   CUDA_VISIBLE_DEVICES=1  # Only device 1 will be seen
+>   CUDA_VISIBLE_DEVICES=0,1  # Devices 0 and 1 will be visible
+>   CUDA_VISIBLE_DEVICES="0,1"  # Same as above, quotation marks are optional
+>   CUDA_VISIBLE_DEVICES=0,2,3  # Devices 0, 2, 3 will be visible; device 1 is masked
+>   CUDA_VISIBLE_DEVICES=""  # No GPU will be visible
 >   ```
 
 ### Practical Application Scenarios
@@ -50,7 +50,12 @@
 >   ```bash
 >   CUDA_VISIBLE_DEVICES=0,1 mineru-sglang-server --port 30000 --dp-size 2
 >   ```
->   
+> 
+> - If you have multiple GPUs and need to specify GPU 0–3, and start the 'sglang-server' using multi-GPU data parallelism and tensor parallelism, you can use the following command:
+>   ```bash
+>   CUDA_VISIBLE_DEVICES=0,1,2,3 mineru-sglang-server --port 30000 --dp-size 2 --tp-size 2
+>   ```
+>       
 > - If you have multiple graphics cards and need to start two `fastapi` services on cards 0 and 1, listening on different ports respectively, you can use the following commands:
 >   ```bash
 >   # In terminal 1

+ 12 - 4
docs/en/usage/index.md

@@ -44,7 +44,8 @@ If you need to adjust parsing options through custom parameters, you can also ch
   ```bash
   mineru-api --host 127.0.0.1 --port 8000
   ```
-  Access http://127.0.0.1:8000/docs in your browser to view the API documentation.
+  >[!TIP]
+  >Access `http://127.0.0.1:8000/docs` in your browser to view the API documentation.
 - Start Gradio WebUI visual frontend:
   ```bash
   # Using pipeline/vlm-transformers/vlm-sglang-client backends
@@ -52,14 +53,20 @@ If you need to adjust parsing options through custom parameters, you can also ch
   # Or using vlm-sglang-engine/pipeline backends (requires sglang environment)
   mineru-gradio --server-name 127.0.0.1 --server-port 7860 --enable-sglang-engine true
   ```
-  Access http://127.0.0.1:7860 in your browser to use Gradio WebUI or access http://127.0.0.1:7860/?view=api to use the Gradio API.
+  >[!TIP]
+  >
+  >- Access `http://127.0.0.1:7860` in your browser to use the Gradio WebUI.
+  >- Access `http://127.0.0.1:7860/?view=api` to use the Gradio API.
 - Using `sglang-client/server` method:
   ```bash
   # Start sglang server (requires sglang environment)
   mineru-sglang-server --port 30000
-  # In another terminal, connect to sglang server via sglang client (only requires CPU and network, no sglang environment needed)
-  mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://127.0.0.1:30000
   ``` 
+  >[!TIP]
+  >In another terminal, connect to sglang server via sglang client (only requires CPU and network, no sglang environment needed)
+  > ```bash
+  > mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://127.0.0.1:30000
+  > ```
 > [!TIP]
 > All officially supported sglang parameters can be passed to MinerU through command line arguments, including the following commands: `mineru`, `mineru-sglang-server`, `mineru-gradio`, `mineru-api`.
 > We have compiled some commonly used parameters and usage methods for `sglang`, which can be found in the documentation [Advanced Command Line Parameters](./advanced_cli_parameters.md).
@@ -69,6 +76,7 @@ If you need to adjust parsing options through custom parameters, you can also ch
 - MinerU is now ready to use out of the box, but also supports extending functionality through configuration files. You can create a `mineru.json` file in your user directory to add custom configurations.
 - The `mineru.json` file will be automatically generated when you use the built-in model download command `mineru-models-download`, or you can create it by copying the [configuration template file](https://github.com/opendatalab/MinerU/blob/master/mineru.template.json) to your user directory and renaming it to `mineru.json`.
 - Here are some available configuration options:
+
   - `latex-delimiter-config`: Used to configure LaTeX formula delimiters, defaults to `$` symbol, can be modified to other symbols or strings as needed.
   - `llm-aided-config`: Used to configure parameters for LLM-assisted title hierarchy, compatible with all LLM models supporting `openai protocol`, defaults to using Alibaba Cloud Bailian's `qwen2.5-32b-instruct` model. You need to configure your own API key and set `enable` to `true` to enable this feature.
   - `models-dir`: Used to specify local model storage directory, please specify model directories for `pipeline` and `vlm` backends separately. After specifying the directory, you can use local models by configuring the environment variable `export MINERU_MODEL_SOURCE=local`.

+ 1 - 0
docs/en/usage/model_source.md

@@ -38,6 +38,7 @@ mineru-models-download
 ```
 >[!TIP]
 >- After download completion, the model path will be output in the current terminal window and automatically written to `mineru.json` in the user directory.
+>- You can also create it by copying the [configuration template file](https://github.com/opendatalab/MinerU/blob/master/mineru.template.json) to your user directory and renaming it to `mineru.json`.
 >- After downloading models locally, you can freely move the model folder to other locations while updating the model path in `mineru.json`.
 >- If you deploy the model folder to another server, please ensure you move the `mineru.json` file to the user directory of the new device and configure the model path correctly.
 >- If you need to update model files, you can run the `mineru-models-download` command again. Model updates do not support custom paths currently - if you haven't moved the local model folder, model files will be incrementally updated; if you have moved the model folder, model files will be re-downloaded to the default location and `mineru.json` will be updated.

+ 1 - 1
docs/zh/index.md

@@ -1,7 +1,7 @@
 <div align="center" xmlns="http://www.w3.org/1999/html">
 <!-- logo -->
 <p align="center">
-  <img src="../images/MinerU-logo.png" width="300px" style="vertical-align:middle;">
+  <img src="https://opendatalab.github.io/MinerU/images/MinerU-logo.png" width="300px" style="vertical-align:middle;">
 </p>
 </div>
 

ファイルの差分が大きいため隠しています
+ 109 - 15
docs/zh/output_files.md


+ 13 - 3
docs/zh/quick_start/docker_deployment.md

@@ -37,7 +37,7 @@ docker run --gpus all \
 ```
 
 执行该命令后,您将进入到Docker容器的交互式终端,并映射了一些端口用于可能会使用的服务,您可以直接在容器内运行MinerU相关命令来使用MinerU的功能。
-您也可以直接通过替换`/bin/bash`为服务启动命令来启动MinerU服务,详细说明请参考[MinerU使用文档](../usage/index_back.md)。
+您也可以直接通过替换`/bin/bash`为服务启动命令来启动MinerU服务,详细说明请参考[MinerU使用文档](../usage/index.md)。
 
 
 ## 通过 Docker Compose 直接启动服务
@@ -48,19 +48,29 @@ docker run --gpus all \
 # 下载 compose.yaml 文件
 wget https://gcore.jsdelivr.net/gh/opendatalab/MinerU@master/docker/compose.yaml
 ```
+>[!NOTE]
+>  
+>- `compose.yaml`文件中包含了MinerU的多个服务配置,您可以根据需要选择启动特定的服务。
+>- 不同的服务可能会有额外的参数配置,您可以在`compose.yaml`文件中查看并编辑。
+>- 由于`sglang`推理加速框架预分配显存的特性,您可能无法在同一台机器上同时运行多个`sglang`服务,因此请确保在启动`vlm-sglang-server`服务或使用`vlm-sglang-engine`后端时,其他可能使用显存的服务已停止。
 
 - 启动`sglang-server`服务,并通过`vlm-sglang-client`后端连接`sglang-server`:
   ```bash
   docker compose -f compose.yaml --profile mineru-sglang-server up -d
-  # 在另一个终端中通过sglang client连接sglang server(只需cpu与网络,不需要sglang环境)
-  mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://<server_ip>:30000
   ```
+  >[!TIP]
+  >在另一个终端中通过sglang client连接sglang server(只需cpu与网络,不需要sglang环境)
+  > ```bash
+  > mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://<server_ip>:30000
+  > ```
+
 - 启动 API 服务:
   ```bash
   docker compose -f compose.yaml --profile mineru-api up -d
   ```
   >[!TIP]
   >在浏览器中访问 `http://<server_ip>:8000/docs` 查看API文档。
+
 - 启动 Gradio WebUI 服务:
   ```bash
   docker compose -f compose.yaml --profile mineru-gradio up -d

ファイルの差分が大きいため隠しています
+ 0 - 1
docs/zh/quick_start/index.md


+ 10 - 5
docs/zh/usage/advanced_cli_parameters.md

@@ -35,11 +35,11 @@
 > [!TIP]
 > 以下是一些常见的 `CUDA_VISIBLE_DEVICES` 设置示例:
 >   ```bash
->   CUDA_VISIBLE_DEVICES=1 Only device 1 will be seen
->   CUDA_VISIBLE_DEVICES=0,1 Devices 0 and 1 will be visible
->   CUDA_VISIBLE_DEVICES="0,1" Same as above, quotation marks are optional
->   CUDA_VISIBLE_DEVICES=0,2,3 Devices 0, 2, 3 will be visible; device 1 is masked
->   CUDA_VISIBLE_DEVICES="" No GPU will be visible
+>   CUDA_VISIBLE_DEVICES=1  # Only device 1 will be seen
+>   CUDA_VISIBLE_DEVICES=0,1  # Devices 0 and 1 will be visible
+>   CUDA_VISIBLE_DEVICES="0,1"  # Same as above, quotation marks are optional
+>   CUDA_VISIBLE_DEVICES=0,2,3  # Devices 0, 2, 3 will be visible; device 1 is masked
+>   CUDA_VISIBLE_DEVICES=""  # No GPU will be visible
 >   ```
 
 ### 实际应用场景
@@ -52,6 +52,11 @@
 >   CUDA_VISIBLE_DEVICES=0,1 mineru-sglang-server --port 30000 --dp-size 2
 >   ```
 >   
+> - 如果您有多张显卡,需要指定卡0-3,并使用多卡数据并行和张量并行来启动'sglang-server',可以使用以下命令: 
+>   ```bash
+>   CUDA_VISIBLE_DEVICES=0,1,2,3 mineru-sglang-server --port 30000 --dp-size 2 --tp-size 2
+>   ```
+>   
 > - 如果您有多张显卡,需要在卡0和卡1上启动两个`fastapi`服务,并分别监听不同的端口,可以使用以下命令: 
 >   ```bash
 >   # 在终端1中

+ 13 - 4
docs/zh/usage/index.md

@@ -44,7 +44,8 @@ mineru -p <input_path> -o <output_path> -b vlm-transformers
   ```bash
   mineru-api --host 127.0.0.1 --port 8000
   ```
-  在浏览器中访问 http://127.0.0.1:8000/docs 查看API文档。
+  >[!TIP]
+  >在浏览器中访问 `http://127.0.0.1:8000/docs` 查看API文档。
 - 启动gradio webui 可视化前端:
   ```bash
   # 使用 pipeline/vlm-transformers/vlm-sglang-client 后端
@@ -52,14 +53,21 @@ mineru -p <input_path> -o <output_path> -b vlm-transformers
   # 或使用 vlm-sglang-engine/pipeline 后端(需安装sglang环境)
   mineru-gradio --server-name 127.0.0.1 --server-port 7860 --enable-sglang-engine true
   ```
-  在浏览器中访问 http://127.0.0.1:7860 使用 Gradio WebUI 或访问 http://127.0.0.1:7860/?view=api 使用 Gradio API。
+  >[!TIP]
+  > 
+  >- 在浏览器中访问 `http://127.0.0.1:7860` 使用 Gradio WebUI。
+  >- 访问 `http://127.0.0.1:7860/?view=api` 使用 Gradio API。
 - 使用`sglang-client/server`方式调用:
   ```bash
   # 启动sglang server(需要安装sglang环境)
   mineru-sglang-server --port 30000
-  # 在另一个终端中通过sglang client连接sglang server(只需cpu与网络,不需要sglang环境)
-  mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://127.0.0.1:30000
   ``` 
+  >[!TIP]
+  >在另一个终端中通过sglang client连接sglang server(只需cpu与网络,不需要sglang环境)
+  > ```bash
+  > mineru -p <input_path> -o <output_path> -b vlm-sglang-client -u http://127.0.0.1:30000
+  > ```
+
 > [!TIP]
 > 所有sglang官方支持的参数都可用通过命令行参数传递给 MinerU,包括以下命令:`mineru`、`mineru-sglang-server`、`mineru-gradio`、`mineru-api`,
 > 我们整理了一些`sglang`使用中的常用参数和使用方法,可以在文档[命令行参数进阶技巧](./advanced_cli_parameters.md)中获取。
@@ -70,6 +78,7 @@ mineru -p <input_path> -o <output_path> -b vlm-transformers
 - MinerU 现已实现开箱即用,但也支持通过配置文件扩展功能。您可以在用户目录下创建 `mineru.json` 文件,添加自定义配置。
 - `mineru.json` 文件会在您使用内置模型下载命令 `mineru-models-download` 时自动生成,也可以通过将[配置模板文件](https://github.com/opendatalab/MinerU/blob/master/mineru.template.json)复制到用户目录下并重命名为 `mineru.json` 来创建。
 - 以下是一些可用的配置选项:
+
   - `latex-delimiter-config`:用于配置 LaTeX 公式的分隔符,默认为`$`符号,可根据需要修改为其他符号或字符串。
   - `llm-aided-config`:用于配置 LLM 辅助标题分级的相关参数,兼容所有支持`openai协议`的 LLM 模型,默认使用`阿里云百炼`的`qwen2.5-32b-instruct`模型,您需要自行配置 API 密钥并将`enable`设置为`true`来启用此功能。
   - `models-dir`:用于指定本地模型存储目录,请为`pipeline`和`vlm`后端分别指定模型目录,指定目录后您可通过配置环境变量`export MINERU_MODEL_SOURCE=local`来使用本地模型。

+ 1 - 0
docs/zh/usage/model_source.md

@@ -39,6 +39,7 @@ mineru-models-download
 ```
 >[!TIP]
 >- 下载完成后,模型路径会在当前终端窗口输出,并自动写入用户目录下的 `mineru.json`。
+>- 您也可以通过将[配置模板文件](https://github.com/opendatalab/MinerU/blob/master/mineru.template.json)复制到用户目录下并重命名为 `mineru.json` 来创建配置文件。
 >- 模型下载到本地后,您可以自由移动模型文件夹到其他位置,同时需要在 `mineru.json` 中更新模型路径。
 >- 如您将模型文件夹部署到其他服务器上,请确保将 `mineru.json`文件一同移动到新设备的用户目录中并正确配置模型路径。
 >- 如您需要更新模型文件,可以再次运行 `mineru-models-download` 命令,模型更新暂不支持自定义路径,如您没有移动本地模型文件夹,模型文件会增量更新;如您移动了模型文件夹,模型文件会重新下载到默认位置并更新`mineru.json`。

+ 1 - 1
mkdocs.yml

@@ -56,7 +56,7 @@ nav:
       - CLI Tools: usage/cli_tools.md
       - Model Source: usage/model_source.md
       - Advanced CLI Parameters: usage/advanced_cli_parameters.md
-      - Output File Format: usage/output_files.md
+  - Output File Format: output_files.md
   - FAQ:
       - FAQ: FAQ/index.md
 

この差分においてかなりの量のファイルが変更されているため、一部のファイルを表示していません