Delete memory-bank

memory-bank/activeContext.md

@@ -1,36 +0,0 @@
-# Active Context: HOCR Processing Tool - Initial Setup
-
-## 1. Current Focus
-
-*   **Initial Project Setup:** Establishing the core Memory Bank documentation structure for the HOCR project as per Cline's requirements.
-*   Creating the foundational markdown files (`projectbrief.md`, `productContext.md`, `activeContext.md`, `systemPatterns.md`, `techContext.md`, `progress.md`).
-
-## 2. Recent Changes
-
-*   Created `memory-bank` directory within the `hocr` project folder.
-*   Created `projectbrief.md` with initial project goals and scope.
-*   Created `productContext.md` outlining the problem space, vision, and user goals.
-*   Created this `activeContext.md` file.
-
-## 3. Next Steps
-
-*   Create `systemPatterns.md` to document the high-level architecture and design patterns (based on initial analysis of existing code).
-*   Create `techContext.md` to detail the technologies, libraries, and setup requirements.
-*   Create `progress.md` to establish the baseline for tracking project status.
-*   Once the initial Memory Bank is set up, await further instructions or tasks from the user regarding the HOCR project itself.
-
-## 4. Active Decisions & Considerations
-
-*   Following Cline's standard Memory Bank structure.
-*   Populating initial files with baseline information derived from the project's file structure and general OCR principles. These will need refinement as the project is explored further.
-
-## 5. Important Patterns & Preferences
-
-*   *(To be filled in as patterns are identified in the codebase or specified by the user)*
-
-## 6. Learnings & Insights
-
-*   The HOCR project appears to be a substantial Python application with distinct modules for different OCR stages (preprocessing, segmentation, OCR processing, etc.) and includes a UI component.
-*   Initial setup requires creating the standard Memory Bank files.
-
-*(This file tracks the immediate state and short-term plans. It should be updated frequently.)*

memory-bank/productContext.md

@@ -1,44 +0,0 @@
-# Product Context: HOCR Processing Tool
-
-## 1. Problem Space
-
-*   Extracting text from images and scanned documents (PDFs) is a common but often challenging task.
-*   Documents vary widely in quality, layout, language, and format.
-*   Manual transcription is time-consuming, error-prone, and not scalable.
-*   Existing OCR tools may lack flexibility, specific preprocessing capabilities, or produce output that isn't easily usable for downstream tasks.
-
-## 2. Solution Vision
-
-*   Provide a reliable, configurable, and extensible OCR processing pipeline.
-*   Empower users to convert document images and PDFs into usable, structured text data.
-*   Offer fine-grained control over the OCR process, from preprocessing to output formatting.
-*   Serve as a foundational tool that can be integrated into larger document processing workflows.
-
-## 3. Target Audience & Needs
-
-*   **Researchers/Academics:** Need to extract text from historical documents, scanned books, or research papers for analysis. Require high accuracy and potentially language-specific handling.
-*   **Archivists/Librarians:** Need to digitize large collections of documents, making them searchable and accessible. Require batch processing capabilities and robust handling of varied document types.
-*   **Developers:** Need an OCR component to integrate into applications (e.g., document management systems, data extraction tools). Require a clear API or command-line interface and structured output (like JSON or hOCR).
-*   **General Users:** May need to occasionally extract text from a scanned form, receipt, or image. Require a simple interface (if applicable) and reasonable default settings.
-
-## 4. User Experience Goals
-
-*   **Accuracy:** The primary goal is to maximize the accuracy of the extracted text.
-*   **Configurability:** Users should be able to tailor the processing steps and parameters to their specific document types and needs.
-*   **Transparency:** The tool should provide feedback on the processing steps and allow for debugging (e.g., viewing intermediate images, logs).
-*   **Performance:** Processing should be reasonably efficient, especially for batch operations.
-*   **Ease of Use:** While powerful, the tool should be approachable, whether through a command-line interface or a potential GUI. Configuration should be clear and well-documented.
-
-## 5. How it Should Work (High-Level Flow)
-
-1.  User provides input file(s) (image or PDF).
-2.  User specifies configuration options (or uses defaults).
-3.  The tool executes the configured pipeline:
-    *   Preprocessing (optional steps like deskew, binarize).
-    *   Segmentation (detecting text regions).
-    *   OCR (applying Tesseract or another engine).
-    *   Post-processing (e.g., text correction, structuring output).
-4.  The tool outputs the extracted text in the desired format (plain text, hOCR, JSON).
-5.  Logs and potentially intermediate results are generated for review.
-
-*(This context provides the 'why' and 'how' from a user perspective. Technical details are in systemPatterns.md and techContext.md.)*

memory-bank/progress.md

@@ -1,30 +0,0 @@
-# Project Progress: HOCR Processing Tool
-
-## 1. What Works
-
-*   **Initial Memory Bank Setup:** The core documentation structure (projectbrief, productContext, activeContext, systemPatterns, techContext, progress) has been established in the `memory-bank/` directory.
-
-## 2. What's Left to Build / Verify
-
-*   **Verify Core Functionality:** Need to run the application and test its basic OCR capabilities on sample images and PDFs.
-*   **Confirm Technical Assumptions:** Validate the libraries and dependencies outlined in `techContext.md` by checking `requirements.txt` and relevant code sections.
-*   **Understand Configuration:** Investigate `config.py` to determine how users configure the pipeline.
-*   **Test UI Layer:** If `app.py` provides a UI (Streamlit/Flask), test its usability and connection to the backend pipeline.
-*   **Review Existing Code:** Deeper dive into the modules (`preprocessing.py`, `ocr_processing.py`, etc.) to understand implementation details.
-*   **Assess Test Coverage:** Examine the tests in `testing/` to understand what is currently covered.
-*   **Address Specific User Goals:** Once the baseline is understood, tackle any specific feature requests, bug fixes, or improvements requested by the user.
-
-## 3. Current Status
-
-*   **Baseline Established (Memory Bank):** As of 2025-05-05, the initial Memory Bank structure is in place.
-*   **Code Functionality:** The operational status of the HOCR tool itself is yet to be verified.
-
-## 4. Known Issues / Bugs
-
-*   *(None identified yet. To be populated as testing and development proceed.)*
-
-## 5. Evolution of Project Decisions (Decision Log)
-
-*   **2025-05-05:** Decided to create the standard Cline Memory Bank structure for the `hocr` project upon user request to check configuration. Found no existing `memory-bank` directory and proceeded with creation of core files.
-
-*(This document tracks the overall progress and state of the project.)*

memory-bank/projectbrief.md

@@ -1,39 +0,0 @@
-# Project Brief: HOCR Processing Tool
-
-## 1. Project Goal
-
-*   **Primary Objective:** To develop and maintain a robust tool for performing Optical Character Recognition (OCR) on various document types (images, PDFs), extracting structured text, and handling potential complexities like diverse layouts, languages, and image quality issues.
-*   **Target Users:** Researchers, archivists, developers, or anyone needing to extract text from scanned documents or images.
-
-## 2. Core Requirements
-
-*   **Input:** Accept image files (PNG, JPG, TIFF, etc.) and PDF documents.
-*   **Processing Pipeline:**
-    *   Image Preprocessing (deskewing, noise reduction, binarization, etc.)
-    *   Layout Analysis / Image Segmentation (identifying text blocks, columns, images)
-    *   OCR Engine Integration (e.g., Tesseract)
-    *   Language Detection
-    *   Structured Output Generation (e.g., hOCR format, JSON, plain text)
-    *   Error Handling and Logging
-*   **Configuration:** Allow users to configure processing parameters (e.g., language, preprocessing steps, output format).
-*   **Extensibility:** Design for potential future enhancements (e.g., handwriting recognition, specific template handling).
-
-## 3. Scope
-
-*   **In Scope:** Core OCR pipeline, configuration management, basic UI (if applicable), testing framework, documentation.
-*   **Out of Scope (Initially):** Advanced AI-driven layout analysis beyond standard segmentation, real-time processing for video streams, integration with specific external databases or workflows unless specified.
-
-## 4. Key Technologies (Initial Assessment - *To be refined in techContext.md*)
-
-*   **Language:** Python
-*   **Core Libraries:** OpenCV, Tesseract (pytesseract), Pillow, pdf2image, potentially others for specific tasks.
-*   **Framework (if UI exists):** Flask/Streamlit (based on existing files like `app.py`, `ui/`)
-
-## 5. Success Metrics
-
-*   Accuracy of text extraction (measured against ground truth data).
-*   Robustness across different document types and qualities.
-*   Ease of configuration and use.
-*   Maintainability and extensibility of the codebase.
-
-*(This is a foundational brief. Details will be expanded in other Memory Bank documents.)*

memory-bank/systemPatterns.md

@@ -1,79 +0,0 @@
-# System Patterns: HOCR Processing Tool
-
-## 1. High-Level Architecture
-
-*   **Modular Pipeline:** The system appears structured as a pipeline with distinct modules for different stages of OCR processing. Key modules suggested by filenames include:
-    *   `preprocessing.py`: Handles initial image adjustments.
-    *   `image_segmentation.py`: Identifies regions of interest (text blocks).
-    *   `ocr_processing.py`: Manages the core OCR engine interaction.
-    *   `language_detection.py`: Determines the language of the text.
-    *   `pdf_ocr.py`: Specific handling for PDF inputs.
-    *   `structured_ocr.py`: Likely involved in formatting the output.
-*   **Configuration Driven:** `config.py` suggests a centralized configuration management approach, allowing pipeline behavior to be customized.
-*   **Entry Point / Orchestration:** `app.py` likely serves as the main entry point or orchestrator, possibly for a web UI or API, coordinating the pipeline execution based on user input and configuration. `process_file.py` might be an alternative entry point or a core processing function called by `app.py`.
-*   **UI Layer:** The `ui/` directory (`ui/layout.py`, `ui/ui_components.py`) indicates a dedicated user interface layer, possibly built with Streamlit or Flask (as suggested in `projectbrief.md`).
-*   **Utility Functions:** The `utils/` directory (`utils/image_utils.py`, `utils/text_utils.py`, etc.) points to a pattern of encapsulating reusable helper functions.
-*   **Error Handling:** `error_handler.py` suggests a dedicated mechanism for managing and reporting errors during processing.
-
-## 2. Key Design Patterns (Inferred)
-
-*   **Pipeline Pattern:** The core processing flow seems to follow a pipeline pattern, where data (image/document) passes through sequential processing stages.
-*   **Configuration Management:** Centralized configuration (`config.py`) allows for decoupling settings from code.
-*   **Separation of Concerns:** Different functionalities (UI, core processing, utilities, configuration) appear to be separated into distinct modules/files.
-*   **Utility/Helper Modules:** Common, reusable functions are grouped into utility modules.
-
-## 3. Component Relationships (Initial Diagram - Mermaid)
-
-```mermaid
-graph TD
-    subgraph User Interface / Entry Point
-        A[app.py / UI Layer] --> B(process_file.py);
-    end
-
-    subgraph Configuration
-        C[config.py];
-    end
-
-    subgraph Core OCR Pipeline
-        B --> D(preprocessing.py);
-        D --> E(image_segmentation.py);
-        E --> F(ocr_processing.py);
-        F --> G(language_detection.py);
-        G --> H(structured_ocr.py);
-    end
-
-    subgraph Input Handling
-        I[pdf_ocr.py] --> B;
-        J[Image Input] --> B;
-    end
-
-    subgraph Utilities
-        K[utils/];
-        L[error_handler.py];
-    end
-
-    A --> C;
-    B --> C;
-    D --> K;
-    E --> K;
-    F --> K;
-    G --> K;
-    H --> K;
-    I --> K;
-    B --> L;
-
-    style User Interface / Entry Point fill:#f9f,stroke:#333,stroke-width:2px
-    style Configuration fill:#ccf,stroke:#333,stroke-width:2px
-    style Core OCR Pipeline fill:#cfc,stroke:#333,stroke-width:2px
-    style Input Handling fill:#ffc,stroke:#333,stroke-width:2px
-    style Utilities fill:#eee,stroke:#333,stroke-width:2px
-
-```
-
-## 4. Critical Implementation Paths
-
-*   **Image Input -> Preprocessing -> Segmentation -> OCR -> Structured Output:** The main flow for image files.
-*   **PDF Input -> PDF Extraction -> Image Conversion (per page) -> [Main Flow] -> Aggregated Output:** The likely path for PDF documents.
-*   **Configuration Loading -> Pipeline Execution:** How settings influence the process.
-
-*(This document outlines the observed structure. It will be refined as the codebase is analyzed in more detail.)*

memory-bank/techContext.md

@@ -1,37 +0,0 @@
-# Technical Context: HOCR Processing Tool
-
-## 1. Core Language
-
-*   **Python:** The project is primarily written in Python, as indicated by the `.py` files. The specific version should be confirmed (e.g., via `requirements.txt` or environment setup).
-
-## 2. Key Libraries & Frameworks
-
-*   **OCR Engine:** Likely **Tesseract OCR**, potentially accessed via the `pytesseract` wrapper (common practice). This needs confirmation by inspecting `ocr_processing.py` or dependencies.
-*   **Image Processing:** **OpenCV (`cv2`)** and/or **Pillow (PIL)** are highly probable for tasks in `preprocessing.py` and `image_segmentation.py`.
-*   **PDF Handling:** **`pdf2image`** (which often relies on Poppler) is a common choice for converting PDF pages to images, relevant for `pdf_ocr.py`. Other PDF libraries like PyMuPDF or PyPDF2 might also be used.
-*   **Web Framework/UI:** Based on `app.py` and the `ui/` directory, **Flask** or **Streamlit** are potential candidates for the user interface or API layer.
-*   **Configuration:** Standard Python mechanisms (e.g., `.ini` files with `configparser`, `.json` files, or custom Python modules like `config.py`).
-*   **Dependency Management:** Likely uses `pip` with a `requirements.txt` file (observed in the file listing). Virtual environments (like `venv` or `conda`) are standard practice.
-
-## 3. External Dependencies & Setup
-
-*   **Tesseract OCR Engine:** Requires separate installation on the host system. The path to the Tesseract executable might need configuration.
-*   **Poppler:** Often required by `pdf2image` for PDF processing; needs separate installation.
-*   **Python Environment:** A specific Python version and installed packages via `requirements.txt`.
-*   **Environment Variables:** Potential use of environment variables for configuration (e.g., API keys, paths), possibly managed via a `.env` file (observed in the file listing).
-
-## 4. Development Environment
-
-*   **Standard Python Setup:** Requires a Python interpreter, `pip`, and likely `virtualenv`.
-*   **Code Editor/IDE:** VS Code is being used (based on environment details). Settings might be stored in `.vscode/`.
-*   **Version Control:** Git is likely used (indicated by `.gitignore`, `.gitattributes`). The `.git_disabled` directory suggests Git might have been temporarily disabled or renamed.
-*   **Testing:** The `testing/` directory and `pytest_cache` suggest **pytest** is used for running tests.
-
-## 5. Technical Constraints & Considerations
-
-*   **Performance:** OCR, especially on large documents or batches, can be computationally intensive. Image processing steps add overhead.
-*   **Tesseract Limitations:** Tesseract's accuracy depends heavily on image quality, preprocessing, and language model availability.
-*   **Dependency Hell:** Managing Python dependencies and external binaries (Tesseract, Poppler) across different operating systems can be challenging.
-*   **Layout Complexity:** Handling complex layouts (multi-column, tables, embedded images) requires sophisticated segmentation logic.
-
-*(This document provides an initial technical overview based on file structure and common practices. It requires verification by examining code and configuration files like requirements.txt.)*