pondělí 23. června 2025

Python: Rozdíl mezi přidáním a rozšířením pole - append vs extend'!

 

Výborná otázka – pojďme si vysvětlit rozdíl mezi append() a extend() a proč je v tomto konkrétním případě správné použít extend().


🔍 append() vs extend():

Funkce Co dělá Příklad
append(x) Přidá celý objekt x jako jeden prvek [1, 2].append([3, 4]) → [1, 2, [3, 4]]
extend(x) Přidá všechny prvky ze sekvence x jednotlivě [1, 2].extend([3, 4]) → [1, 2, 3, 4]

📘 Co přesně děláš ve funkci?

Ve funkci získáváš children ze node:

children = node.get("children", [])

Hodnota children je seznam ID potomků daného uzlu (např. ["abc123", "def456"]). Tím pádem:

❌ Pokud bys použil:

root_chat.append(children)

Výsledek bude:

root_chat = [["abc123", "def456"]]  # špatně – seznam v seznamu

✅ Ale pokud použiješ:

root_chat.extend(children)

Výsledek bude:

root_chat = ["abc123", "def456"]  # správně – seznam ID

🔧 Shrnutí:

Použij extend() pokud chceš slít obsah seznamu do jiného seznamu, nikoli vnořit seznam jako prvek. Ve tvém případě pracuješ s ID uzlů a očekáváš plochý seznam všech potomků určitého typu (root_chat, user_chat, assistant_chat).


Můj příklad pro json:

        for idx, session in enumerate(data, 1):
            title = session.get("title", "<bez názvu>")
            ct = session.get("create_time")
            if isinstance(ct, (int, float)):
                dt = datetime.fromtimestamp(ct)
                ct_str = dt.strftime("%Y-%m-%d %H:%M:%S")
            else:
                ct_str = str(ct)

            #  root
            #   └── node A (system message)
            #         └── node B (user message)  <--- tu chceš najít
            #               └── node C (assistant)

            mapping = session.get("mapping", {})
            root = next((nid for nid,node in mapping.items() if node.get("parent") is None), None)
            children = mapping.get(root, {}).get("children", [])
            root_first_id = None
            user = None
            root_chat = []
            user_chat = []
            assistant_chat = []
            for nid, node in mapping.items():
                if root is None and node.get("parent") is None:
                    root_first_id = nid
                role = node.get("author").get("role")
                children = node.get("children", [])  # children obsahuje seznamy ideček
                if role == "system":
                    root_chat.extend(children) else:
                if role == "user":
                    user_chat.extend(children) else:
                if role == "assistant":
                    assistant_chat.extend(children)


Struktura jsonData chatGPT - kdy parent neexistuje?

 

V kontextu souboru mapping ve struktuře exportu z ChatGPT (nebo podobných chatových systémů) node nemá parent (tj. parent == None) typicky za těchto okolností:


1. Kořen (root) celého sezení

To je výchozí bod celé konverzace. Může jít o:

  • systémový uzel (system prompt),

  • nebo prázdný root, který slouží jen jako výchozí místo, ke kterému jsou připojené první zprávy.

V takovém uzlu bývá:

{
  "id": "abc123",
  "parent": null,
  "children": ["xyz456"]
}

Tedy parent == None → je to začátek celého stromu zpráv v tomto sezení.


⚠️ 2. Starší exporty nebo upravené exporty

U některých exportů může být kořenový uzel označen jako "id": "client-created-root" a neobsahuje žádné zprávy, jen children. To je umělý (vygenerovaný) uzel pro zachování jednotné struktury stromu.

Příklad:

"client-created-root": {
  "id": "client-created-root",
  "parent": null,
  "children": ["12345-abc"]
}

⚠️ 3. Chybná nebo neúplná data

Výjimečně může být parent chybějící i kvůli:

  • neúplnému exportu,

  • ruční úpravě,

  • poškozenému JSONu.

V takovém případě je potřeba být opatrný a vyhledávat také alternativní kořeny (např. více uzlů s parent: null nebo žádný).


🧠 Shrnutí:

Uzly bez parent jsou:

Kontext Význam
parent == null Kořen (root) stromu zpráv
"id": "client-created-root" Umělý kořen přidaný klientem nebo systémem
parent chybí nebo není None Možná chyba v datech nebo nestandardní formát

Chceš-li přesněji zjistit, co je v konkrétním exportu root, doporučuji vypsat všechny uzly s parent == None a zkontrolovat, kolik jich je a co obsahují. Mohu ti dát k tomu jednoduchou funkci, pokud chceš.

Jak parsovat jsonData ChatGPT - díl3. - jednoduchý průchod přes session.mapping

V JSON datech ChatGPT (nebo i jiných chatových exportech) je klíč mapping zásadní strukturou, která popisuje stromovou strukturu celého rozhovoru. Není to prostý seznam zpráv v pořadí, ale spíš strom navazujících zpráv, kde každá má unikátní id a odkazy na parent a children.


🌳 Co je mapping?

mapping je slovník (dict), kde:

  • klíčem je id uzlu (např. "13f65eae-...")

  • hodnotou je datová struktura s:

    • id (znovu)

    • message (obsah zprávy, může být null)

    • parent – ID rodičovského uzlu

    • children – seznam ID potomků


🔍 Co to znamená?

Tohle umožňuje:

  • Získat libovolný uzel zprávy podle jeho ID.

  • Rekonstruovat celý tok konverzace z uzlů (např. najít hlavní větev, alternativní větve atd.).

  • Rychle zjistit, kdo co řekl (message.author.role).

  • Navigovat zprávy např. od client-created-root až po poslední odpověď.


🧠 Příklad ze tvých dat:

"mapping": {
  "client-created-root": {
    "id": "client-created-root",
    "message": null,
    "parent": null,
    "children": ["13f65eae-..."]
  },
  "13f65eae-...": {
    "id": "13f65eae-...",
    "message": {
      "author": {"role": "system"},
      ...
    },
    "parent": "client-created-root",
    "children": ["61b6910f-..."]
  },
  "61b6910f-...": {
    "id": "61b6910f-...",
    "message": {
      "author": {"role": "user"},
      ...
    },
    "parent": "13f65eae-...",
    "children": [...]
  }
}

Z toho vyplývá:

  • Konverzace začíná „virtuálním“ kořenem client-created-root

  • První reálná zpráva je 13f65eae-... (např. systémové uvítání)

  • Uživatel odpovídá ve zprávě 61b6910f-...


🔄 Proč se to tak dělá?

  • Flexibilita: umožňuje větvení konverzace (např. pokud si vybereš jinou cestu nebo prompt).

  • Snadné spojení zpráv přes ID.

  • Zachování stromové hierarchie, ne jen lineárního seznamu.


🧰 Kódově:

Chceš-li iterovat všechny zprávy:

for node_id, node in mapping.items():
    msg = node.get("message")
    if msg and msg.get("author"):
        print(f"{node_id}: {msg['author']['role']} – {msg['content']}")

Aby ses dostal k reálným zprávám (user/assistant), musíš filtrovat:

  • message != null

  • message.content.parts != [""]


Chceš-li, můžu ti upravit funkci, která to celé přehledně vytáhne a uloží každou zprávu podle pořadí (nebo podle větví).

 

* * *

V JSON poli jsonData jsou na nejvyšší úrovni “sezení” – každé položce v tom seznamu odpovídá jedno celé chat-session. Tyto položky mají nejčastěji klíče:

  • title – lidsky čitelný název sezení (např. „Analýza TJV…“)

  • create_time / update_time – UNIX čas nebo ISO-string, kdy bylo sezení založeno a naposledy aktualizováno

  • mapping – slovník, který obsahuje všechny uzly (root, systémové zprávy, uživatelské vstupy, odpovědi), každý uzel se odkazuje na svůj parent a na pole children

Podle tebe tedy:

  1. Položky v jsonData → to jsou jednotlivá sezení/chaty.

  2. Uvnitř každé položky (sezení) najdeš právě ten klíč mapping, který ukrývá všechny zprávy a jejich vztahy.


Struktura jedné položky v jsonData

{
  "title": "Název sezení…",
  "create_time": 1748653404.439806,
  "update_time": 1750666511.338081,
  "mapping": {
    "client-created-root": {
      "id": "client-created-root",
      "message": null,
      "parent": null,
      "children": ["13f65eae-…"]
    },
    "13f65eae-…": {
      "id": "13f65eae-…",
      "message": { … },
      "parent": "client-created-root",
      "children": ["61b6910f-…"]
    },
    "61b6910f-…": {
      "id": "61b6910f-…",
      "message": { … },
      "parent": "13f65eae-…",
      "children": [ … ]
    },
    // …
  }
}
  • mapping je slovník všech uzlů.

  • Uzel s id: "client-created-root" je virtuální počátek (nemá message, ale má children).

  • Každý další uzel obsahuje message, které má:

    • author.role (system / user / assistant)

    • create_time (timestamp)

    • content: objekt { content_type, parts }

      • parts je pole řetězců nebo dalších objektů – tady jsou skutečné texty zpráv.


Co si z toho odnést:

  • Sezení (session) ↔ jedna položka v poli jsonData

  • Zprávy ↔ jednotlivé uzly ve mapping (kde message != null)

  • parts uvnitř message.content jsou vlastní texty promptů/odpovědí


Jak na to prakticky:

  1. Projdi pole jsonData – to jsou všechna sezení.

  2. Pro každé sezení si vytáhni title, create_time atd.

  3. Vnořený slovník mapping projdi dvojicí (id, node):

    • pokud node["message"] není null, je to skutečná zpráva, vyzvedneš message.author.role a message.content.parts.

Např. v Pythonu:

for session in jsonData:
    title = session["title"]
    for node_id, node in session["mapping"].items():
        msg = node.get("message")
        if msg and msg.get("content"):
            author = msg["author"]["role"]
            text = msg["content"]["parts"][0]  # první část
            print(f"Sezení: {title} | Uzlu {node_id} | Autor: {author} | Text začíná: {text[:30]!r}")

Takhle dostaneš řádek po řádku všechny skutečné zprávy (user/assistant/system) uvnitř každého chat-sezení.

 

Jak parsovat jsonData chatGPT - díl 2. části a citace

 

* * *

Ve vašem výpisu už nevidím skutečný text zprávy rozdělený do několika jazykově smíšených fragmentů, ale hromadný seznam objektů citací, který je součástí metadat. Podívejme se, jak to celé sedí:

  1. Obsah zprávy (text uživatele nebo asistenta) je vždy v poli

    message.content.parts
    

    a to je pouze seznam řetězců (stringů), například

    "parts": [
      "Toto je celý text jedné odpovědi..."
    ]
    

    nebo u multimédií seznam „asset“ objektů.

  2. Separátně od parts bývají v message.metadata různé další pole, například

    "citations": [ {...}, {...}, … ]
    

    a v nich najdete objekty tvaru

    {
      "start_ix": 423,
      "end_ix": 435,
      "citation_format_type": "tether_v4",
      "metadata": {
        "type": "webpage",
        "title": "Mapování psychologických tendencí…",
        "url": "https://…",
        "text": "Uživatel TJV ve svých příspěvcích...",
        …
      }
    }
    

    Tyto objekty nejsou částí pole parts, ale (message.metadata.citations) – takže nejsou přímo součástí pořadí textu, jen k němu dodatečně odkazují (pomocí start_ix/end_ix) na úseky textu.

  3. Všechny zprávy i citace jsou zabaleny ve stromu mapping. Ten vám říká, která message (uzel) je rodič, které uzly jsou děti atd.


Shrnutí struktury jedné zprávy

"node_id": {
  "id": "…",
  "message": {
    "id": "…",
    "author": { "role": "user" },
    "create_time": 1748…,
    "content": {
      "content_type": "text",
      "parts": [
        "Toto je normální text zprávy; tady je celý řetězec."
      ]
    },
    "status": "finished_successfully",
    "metadata": {
      // další meta, včetně:
      "citations": [
        {
          "start_ix": 423,
          "end_ix": 435,
          "citation_format_type": "tether_v4",
          "metadata": { "type": "webpage", "title": "…", "url": "…", "text": "…" }
        },
        …
      ]
    }
  },
  "parent": "…",
  "children": [ … ]
}
  • parts obsahuje čistě text (nebo assety).

  • metadata.citations obsahuje objekty, které popisují, jaké citace nebo odkazy se v tom textu vyskytují (ale nejsou to přímé fragmenty parts).

  • Když chcete vypsat reálné vzkazy, projděte vždy mapping → node["message"]["content"]["parts"] a ignorujte metadata.citations, pokud se vám nechce ty citace detailně zpracovávat.


Takže ten kus, který jste ukázal:

{"start_ix": 423, "end_ix": 435, "citation_format_type": "tether_v4", "metadata": { … }},
{"start_ix": 5026, …}

je právě první a druhý objekt ve seznamu citací message.metadata.citations, nikoli pokračování řetězce zprávy. Každý takový objekt má:

  • start_ix/end_ix – pozice v původním textu, kam se citace vztahuje

  • citation_format_type – formát (např. tether_v4)

  • metadata – podrobné údaje o dané citaci (URL, titul článku, výňatek textu…)


Doporučení pro parsování

  • Pro čistý text concatenujte všechny položky parts.

  • Pokud vás citace zajímají, přečtěte si message.metadata.citations jako samostatné pole.

  • Nemíchejte objekty z citations s parts — jsou to dvě různé vrstvy informací.

* * *

V exportovaném JSONu je každá položka v poli jsonData celé jedno „sezení“ (chat). Uvnitř každé položky najdeš:

  1. Metainformace sezení

    • title – název/chunk celé session

    • create_time / update_time – kdy bylo sezení vytvořeno a naposledy změněno

  2. mapping – slovník všech uzlů (node), kde klíčem je id uzlu a hodnotou objekt:

    "mapping": {
      "<node-id>": {
        "id": "<node-id>",
        "message": { … }  // nebo null pro kořen
        "parent": "<parent-node-id>"  // nebo null
        "children": ["<child-id-1>", …]
      },
      …
    }
    
    • Uzel s message: null (většinou "client-created-root") je virtuální kořen.

    • Ostatní uzly mají v message skutečnou zprávu.

  3. Struktura jedné zprávy (message)

    "message": {
      "id": "...",
      "author": { "role": "user" | "assistant" | "system", … },
      "create_time": <float nebo null>,
      "content": {
        "content_type": "text" | "...",
        "parts": [
          "<celý text té jedné zprávy jako jeden řetězec>"
        ]
        // u jiných typů obsahu tu mohou být asset ukazatele místo běžného textu
      },
      "status": "...",
      "metadata": {
        "citations": [ { "start_ix":…, "end_ix":…, "metadata": { "url":…, "text":… } }, … ],
        // další meta jako request_id, parent_id atd.
      },
      "recipient": "...",
      "channel": "..."
    }
    
    • content.parts: ZÁKLADNÍ TEXT zprávy – list řetězců, typicky jednprvkový (parts[0] je celý text).

    • metadata.citations: Samostatné bloky s informacemi o citacích v textu (např. zdroj URL, vypíchnutý text), ale nejsou částí parts.


Jak na to:

  • Sezení (chat) = jedna položka v jsonData.

  • Uzel = jeden záznam ve mapping.

    • Pokud message ≠ null → je to opravdová zpráva.

    • message.content.parts → ZPRÁVA.

    • message.metadata.citations → DODATEČNÉ INFO o tom, co v textu citujete (nejsou to další části textu).


Příklad průchodu:

for session in jsonData:
    title = session["title"]
    print("=== Sezení:", title)
    for node_id, node in session["mapping"].items():
        msg = node["message"]
        if msg:
            author = msg["author"]["role"]
            text   = msg["content"]["parts"][0]
            print(f"- {author}: {text[:30]!r}…")
            # pokud chcete i citace:
            for c in msg["metadata"].get("citations", []):
                print("    * citace:", c["metadata"]["text"][:30], "…")

Takhle jasně oddělíte:

  1. Normální text (parts)

  2. Citace (metadata.citations)

a získáte kompletní obraz struktury i obsahu.

 

Jak parsovat jsonData chatGPT (exported data) - přehled 1.

"mapping": {
  "<node-id>": {
    "id": "<node-id>",
    "message": { … }  // nebo null pro kořen
    "parent": "<parent-node-id>"  // nebo null
    "children": ["<child-id-1>", …]
  },
  …
}
 

Zcela klíčové pro orientaci ve stromu mapping jsou tyto identifikátory:

  1. id (uzlu / node-id)

    • Unikátní řetězec (většinou UUID), který označuje právě tento uzel ve slovníku mapping.

    • Používá se jako klíč i v node["id"].

  2. parent (ve slovníku mapping)

    • Hodnota je id nadřazeného uzlu.

    • Každý uzel (kromě „root“) má jednoho parent, tedy uzel, ze kterého tato zpráva/podstrom logicky vychází.

    • Uzel s parent: null (většinou "client-created-root") je počáteční „kořen“ sezení.

  3. children

    • Pole ["id1", "id2", …] – seznam id všech potomků (uzly, které navazují na daný uzel).

    • V jednoduchém lineárním chatu bude každé pole children obsahovat právě jeden další uzel, u vícevětvených scénářů jich může být víc.

  4. message.id

    • Stejné jako uzlové id, ale uvnitř objektu message.

    • Slouží k unitárnímu mapování mezi uzlem a jeho message.

  5. metadata.parent_id (uvnitř message.metadata)

    • Duplicitně ukládá parent i přímo v metadatech té zprávy.

    • Může se hodit pro rychlé filtrování přímo na úrovni message, aniž bys musel prolézat mapping.

  6. metadata.request_id

    • Identifikátor konkrétního API požadavku / uživatelského promptu, ze kterého tah vznikl.

    • Pokud jde o uživatelský vstup, request_id jej spojuje s interním zpracováním.

  7. async_task_id / async_task_title

    • Pokud is_async_task_result_message: true, máte tu ještě async_task_id (interní značka dlouhé operace) a human-readable async_task_title.

  8. mapping vs. jsonData

    • jsonData je pole sezení (chat sessions). Každý prvek pole je jedno celé sezení/chat (má svůj title, create_time apod.).

    • Uvnitř každé session se zcela odděleně nachází mapping, tedy strukturální strom všech uzlů ve vlastním rozhovoru.


Jak je to navázané:

  • Top-level:

    [
      {  // session #1
        "title": "...",
        "mapping": { ... }
      },
      {  // session #2
        ...
      }
    ]
    
  • V každé session:

    • mapping["node-id"] → uzel, který má:

      • id (shodné s klíčem),

      • parent (id nadřazeného),

      • children (pole id potomků),

      • message (objekt).

  • V objektu message najdeš:

    • message.id (jaký uzel to je),

    • message.metadata.parent_id (pro rychlé rozpoznání rodiče),

    • message.metadata.request_id (který uživatelský dotaz to vyvolal),

    • někdy i async_task_id a další příznaky režie.


Zjednodušené schéma

jsonData: [
  session₁ {
    mapping: {
      node₁ {
        id: node₁
        parent: null
        children: [node₂]
        message: null  ← virtuální root
      }
      node₂ {
        id: node₂
        parent: node₁
        children: [node₃]
        message: {
          id: node₂
          author: { role: user }
          metadata: {
            parent_id: node₁
            request_id: abc-123
            is_async_task_result_message: false
          }
        }
      }
      node₃ {
        id: node₃
        parent: node₂
        children: []
        message: {
          …
          metadata: {
            parent_id: node₂
            request_id: abc-123
            async_task_id: long-job-456
            async_task_title: "…"
          }
        }
      }
    }
  },
  session₂ { … }
]
  • parent/parent_id udávají, „ze kterého kroku/vstupu“ daná zpráva vzešla.

  • children: na co navazuje dál.

  • request_id: váže to k tomu, co jsi skutečně poslal „ven“ jako svůj prompt.

  • async_task_*: značí, že odpověď vznikla vícefázově (nejen bezprostředně po promptu).

* * *

 

* * *

Ta pole start_ix a end_ix udávají přesné pozice (offsety) v textovém řetězci, kde v dané zprávě citace začíná a končí. V praxi to znamená:

  1. Odkazují na znaky v té samé proměnné msg["content"]["parts"][0] nebo v msg["content"]["parts"] po sloučení.

  2. Jsou to 0-based indexy znaků (v JavaScriptu se to obvykle měří jako UTF-16 code units, v Pythonu jako Unicode code points).


Co to znamená pro převod \uXXXX → skutečné diakritické znaky

  • Pokud JSON načteš a necháš Python či JavaScript automaticky dekódovat ty unicode escape sekvence (\u00fdý apod.), pak parts[0] uloží v paměti skutečné znaky.

  • Potom start_ix a end_ix odpovídají právě těmto dekódovaným znakům.

    text = msg["content"]["parts"][0]
    # text už obsahuje např. 'TJV má velmi nízkou...'
    citace = text[start_ix:end_ix]
    
  • Nezmění se ti tedy offsety, pokud je dekóduješ před použitím těch indexů.


Kdy nastává problém?

  • Pokud bys nejprve počítal znaky nad původním JSON řetězcem se \uXXXX (tj. escape syntaxí), a pak nahradil \u00fd znakem ý, pak by se ti indexy posouvaly (protože \u00fd je 6 znaků, ale ý je jen 1 znak).

  • Správný postup je:

    1. Načíst JSON a nechat ho plně dekódovat (json.loads v Pythonu, nebo JSON.parse v JS).

    2. Teprve na dekódovaném text = parts[0] pak aplikovat start_ix:end_ix.

To zajistí, že offsety sedí na finální podobu řetězce s diakritikou a emoji. Pokud bys ale nejprve dekódovaný text znovu kódoval zpátky do \uXXXX, nebo manipuloval s řetězcem jiným způsobem (vkládal/odstraňoval znaky), tak bys ty indexy samozřejmě rozházel.


Závěr:

  • start_ix/end_ix jsou offsety v již dekódovaném textu zprávy.

  • Dekódování \uXXXX→UTF-8 (= skutečné diakritické znaky) proto nezmění jejich význam, pokud proběhne před jejich aplikací.

  • Pokud ale unicode escapes převádíš početně nevhodným krokem (např. ve zdrojovém JSONu), pak ano, indexy by neseděly. Proto:

    1. zavolej data = json.loads(raw)

    2. text = data[…]["content"]["parts"][0]

    3. substring = text[start_ix:end_ix]
      a budeš mít přesně tu část zprávy, kterou citace popisuje.

 

* * * 

V metadata zpráv se kromě textových částí (content.parts) nachází ještě pole citations (případně citations + další typy poznámek) s těmito nejčastějšími formáty:


1. "type": "webpage"

Objekt popisuje základní citaci zdroje – má:

  • start_ix / end_ix
    Pozice v dekódovaném textu (parts[0]) od – do (UTF-8 znaky), kde se citace nachází.

  • metadata podklíč s těmito poli:

    • type: "webpage"

    • title – titul stránky

    • url – odkaz

    • text – vypíchnutý úsek původního textu (short snippet)

    • cited_message_id / cited_message_idx – na kterou předchozí zprávu se citace odkazuje

    • evidence_text – další poznámka (často prázdné)

Struktura:

{
  "start_ix": 423,
  "end_ix": 435,
  "citation_format_type": "tether_v4",
  "metadata": {
    "type": "webpage",
    "title": "Mapování psychologických tendencí…",
    "url": "https://…",
    "text": "Uživatel TJV ve svých příspěvcích…",
    "cited_message_id": "cc5d078c-…",
    "evidence_text": ""
  }
}

2. "type": "webpage_extended"

Rozšířená citace, přidává další kontext a ověřené údaje:

  • matched_text
    Přesná sekvence z originálního textu, kterou citace popisuje (např. “[28]L49-L52”).

  • snippet
    Kratší úryvek z cílové webové stránky (nemusí být totožné s metadata.text).

  • attribution
    Zdroj domény (např. zpovednica.blogspot.com).

  • icon_type
    Ikonka zdroje (většinou null).

  • pub_date
    Datum publikace zdroje (často null).

  • alt
    Alternativní popisek (většinou null).

Struktura:

{
  "matched_text": "“[28]L49-L52”",
  "start_idx": 3505,
  "end_idx": 3517,
  "type": "webpage_extended",
  "title": "Mapování psychologických tendencí…",
  "url": "https://…",
  "pub_date": null,
  "snippet": "sarkasticky, její tón je převážně kritický…",
  "attribution": "zpovednica.blogspot.com",
  "icon_type": null
}

3. is_async_task_result_message

Když vidíš v message.metadata klíč

"is_async_task_result_message": true,
"async_task_id": "...",
"async_task_title": "Psychologická a behaviorální analýza…"

znamená to, že tato zpráva je výsledkem asynchronní úlohy (např. delšího API volání / batchového procesu).

  • async_task_id – interní ID úlohy

  • async_task_title – popisek, co se zpracovávalo


Jak to celé použít

  1. Rozdělení obsahu

    • Vypíšeš text z message.content.parts[0].

    • Citace vkládáš pomocí metadata.citations (pro základní linky) a/nebo metadata.citations obsahujících type: "webpage_extended".

  2. Správné offsety

    • Vždy pracuj na dekódovaném textu (json.loads), pak start_ix:end_ix ukazují přímo na české znaky.

  3. Asynchronní zprávy

    • Pokud is_async_task_result_message je true, můžeš je vyfiltrovat nebo označit jako odpovědi generované dávkovou úlohou – mají k sobě vlastní async_task_title.

Tím máš kompletní přehled, jak v datech najít samotný text, veškeré citace a jak rozpoznat, že zpráva vznikla v rámci asynchronní operace.

* * *

V tomhle úseku jsi narazil na několik nových polí a formátů, které obohacují chování a metadata jednotlivých uzlů – pojďme si je rychle projít:

… "content": {
     "content_type": "text",
     "parts": ["… ;\n</html>"]
   },
   "status": "finished_successfully",
   "end_turn": true,
   "weight": 1.0,
   "metadata": {
     "citations": [],              
     "content_references": [],     ← nově vidíš tohle pole
     "message_type": null,
     "model_slug": "o4-mini",
     "default_model_slug": "auto",
     "parent_id": "7d32f62e-…",
     "request_id": "94829d82bd8f8033-MXP",
     "timestamp_": "absolute",
     "is_async_task_result_message": true,  ← a i tohle
     "b1de6e2_rm": true,
     "async_task_id": "deepresch_683a…",
     "async_task_title": "Psychologická a behaviorální analýza…"
   },
   "recipient": "all",
   "channel": "final"
…

1. content_references

Prázdné pole tady, ale obecně by mohlo obsahovat odkazy na externí entity, obrázky, nebo další assety, které se v textu objevují. Pokud bys měl např. vestavěné grafy, videa apod., sem by se zapsal jejich popis/odkaz.

2. status, end_turn, weight

status: stav vykonání (např. "finished_successfully" znamená, že celý backend proces doběhl ok).
end_turn: zda tah končí (pokud true, uživatel má možnost vložit nový vstup).
weight: interní váha nebo priorita v stromu — obvykle všechny outputy mají 1.0.

3. model_slug / default_model_slug

– Označují, který model odpověď generoval ("o4-mini"). Pokud se měnil model, default_model_slug to může zaznamenat.

4. timestamp_

– Zde "absolute" znamená, že create_time v tomto message je absolutní Unix timestamp (nikoli relativní).

5. Asynchronní tasky:

  • is_async_task_result_message: true říká, že tah vznikl jako výsledek dlouhé asynchronní operace (např. batchové zpracování, složitější analýza).

  • async_task_id / async_task_title ukládají interní ID a popisek té úlohy („Psychologická a behaviorální analýza TJV…“).

  • A b1de6e2_rm je jen interní flag, že se jedná o rebase_developer_message nebo podobné značení uvnitř systému.

6. channel

– Hodnota "final" značí, že tohle je konečné zpracování odpovědi asistenta.
– Kromě něj můžou být i jiné kanály (např. "analysis", "thoughts", apod.), ale konečný výstup vždy jde na "final".


Celkově to znamená, že:

  • Nejsou to už jen tvoje požadavky a odpovědi, ale v datech vidíš úplnou historii celého procesu generování:

    1. request (uživatel)

    2. system mezikroky (thoughts, reasoning_recap)

    3. asynchronní výpočty (dlouhé úlohy)

    4. finální output (channel: "final")

  • Metadata ti tím dávají detailní auditní stopu:

    • Který model to vypočítal,

    • zda to byla asynchronní taska,

    • jestli to ukončilo turn,

    • jaké externí assety by se mohly objevit (content_references).

To ti umožňuje přesně rekonstruovat, jak a odkud každá část odpovědi vznikla.

 

 

 

sobota 14. června 2025

Test5 - Volání ve skriptu + popis volání a resize po implementaci simulace draw

process_images()
 └─ for each image:
     ├─ create_thumbnail_with_regions()
     │   ├─ binarize_shadow() → bl_bw, tr_bw
     │   ├─ locate_region_and_source()
     │   │   └─ project_and_find_shadow_ranges()
     │   │       ├─ normalize_projection_manual(row_proj)
     │   │       ├─ find_intervals(vals, ShadowType)
     │   │       ├─ normalize_projection_manual(col_proj)
     │   │       └─ find_intervals(vals, ShadowType)
     │   └─ return bl_small, bl_crop, tr_small, tr_crop, thumbnail, bl_box, tr_box
     ├─ locate_region_and_source(bl_bw, tr_bw, bl_crop, tr_crop, …)
     └─ detect_angle_from_crops(bl_small, bl_crop, tr_small, tr_crop, thumbnail, full_img, bl_box, tr_box)

 

Pipeline volání

  1. create_thumbnail_with_regions(img, output_path, regions, estimated_dpi, debug_simulate_shadow)
    └─ best_divisor(width, height, estimated_dpi)
    └─ resize → thumbnail
    └─ get_dimensions_for_cropped_areas(regions, thumbnail_size, divisor)bl_box, tr_box
    └─ crop → bl_crop, tr_crop
    └─ compute_small_image_and_divisor(bl_crop, est_shadow_thumb_px)bl_small, bl_div
    └─ compute_small_image_and_divisor(tr_crop, est_shadow_thumb_px)tr_small, tr_div
    └─ binarize_shadow(bl_small)bl_bw
    └─ binarize_shadow(tr_small)tr_bw
    └─ if debug_simulate_shadow: simulate_and_measure_thresholds(region_size, debug_folder, label, best_divisor, div_factor, orientations)

  2. locate_region_and_source(bl_bw, tr_bw, bl_crop, tr_crop, thumbnail, full_img, bl_box, tr_box, bl_div, tr_div, small_capacity_bl, small_capacity_tr, est_shadow_thumb_px, output_path)
    └─ project_and_find_shadow_ranges(bl_bw, tr_bw, …, output_path)
    │ └─ for ("small_bl", bl_bw) and ("small_tr", tr_bw):
    │ └─ resize → row_proj, col_proj
    │ └─ normalize_projection_manual(row_proj, w)img_norm, scale, offset
    │ └─ find_intervals(vals, ShadowType.DARK|GRAY)*_dark_row, *_gray_row
    │ └─ normalize_projection_manual(col_proj, h)img_norm, scale, offset
    │ └─ find_intervals(vals, ShadowType.DARK|GRAY)*_dark_col, *_gray_col
    │ └─ intersect_intervals(row_intervals, col_intervals, ShadowType.DARK|GRAY)*_regions_dark, *_regions_gray
    │ └─ save regions in debugging_bl / debugging_tr
    │ └─ return results
    └─ compute kapacita_small_bl, kapacita_small_tr, kapacita_thumbnail
    └─ append candidates in order small_bl, small_tr, crop_bl, crop_tr, thumbnail, full
    └─ return {"candidates": …}, resolution_info

  3. detect_angle_from_crops(bl_small, bl_crop, tr_small, tr_crop, thumbnail, full_img, bl_box, tr_box)
    └─ compute capacities
    └─ in order small_bl → small_tr → crop_bl → crop_tr → thumbnail → full:
    │ └─ measure_angle_and_length(crop_img, threshold_px)angle, length
    │ └─ if angle found → compute regionreturn result dict
    └─ return last result or fallback with angle=None

 TABULKA S VYSVĚTLENÍM

 

Proměnná Vypočítává/definuje se v Používá se v Vysvětlení použití Vazba a konzistence
divisor create_thumbnail_with_regions tamtéž Dělí originální rozměry (width, height) pro zmenšení na thumbnail. Volí se tak, aby výsledný DPI thumbnailu byl blízko cílových 300 dpi → ovlivňuje všechny další úrovně.
scale_factor create_thumbnail_with_regions tamtéž Poměr new_width/width = 1/divisor; škáluje souřadnice regionů z originálu do thumbnailu. Je přesně obrácenou hodnotou divisor (v reálných pixelech) → zajišťuje korektní překlad oblastí.
bl_div / tr_div create_thumbnail_with_regions tamtéž + simulate_and_measure_thresholds Dělí bl_crop a tr_crop pro vytvoření „small“ obrázků (bl_small, tr_small). bl_div, tr_div by měly být stejné řády jako divisor (např. ∼10) pro konzistentní zmenšování věrné DPI.
scale (normalizace) normalize_projection_manual project_and_find_shadow_ranges, simulate_and_measure_thresholds Kompenzuje jak intenzitu (255/(mx–mn)), tak zředění (original_length/L_proj) po projekci. Závisí na poměru původní délky řady/sloupce k délce po resize → zajišťuje konzistentní prahování stínu.
offset (normalizace) normalize_projection_manual project_and_find_shadow_ranges, simulate_and_measure_thresholds Posun původního minima, které bylo „odečteno“ při normalizaci. Společně se scale vytváří konzistentní mapování původních intenzit na [0–255] i napříč různými velikostmi.

POZNÁMKY:

"Zředění" - zředění je zjednodušující výraz pro vedlejší efekt projekce, kdy se intenzity šedi při zmenšení na jednorozměrné pole zprůměrují, a šedá nebo černá vybledne.

Normalizace (po projekci do 1D obrazu): Míra zesílení intenzit v obrazu je závislá na tom jak moc se původní strana zmenšila a taky na tom jaká je minimální a maximální hodnota intenzity v tom obrazu.

Normalizace pak dvoufázově kompenzuje:
1. intenzitu – škála = 255/(max–min), aby nejtmavší byl → 0 a nejsvětlejší byl → 255,
2. zředění – násobek = (původní délka)/(délka projekce), čímž se vyrovná efekt průměrování přes různý počet pixelů.

Společně scale = (255/(mx–mn)) × (original_length/L_proj) a offset = mn zajistí, že 1D obraz vrátí správné relativní rozložení stínu nezávisle na tom, jak moc byl zmenšený.

Úskalí po normalizaci

Poté co byla provedena normalizace 1D obrazu, už neplatí, že by barvy stínu, které byly vizuálně přečteny z původního small náhledu (např. v grafickém editoru), byly totožné s nově vygenerovaným stínem normalizovaného souboru. K tomu by bylo nutné provést přepočet nebo test. Takže pro nalezení hranic šedi jak definuje třída:

class ShadowRanges(Enum):
    DARK_MAX = 188
    GRAY_MIN = 189
    GRAY_MAX = 232
    BLACK = 0
    WHITE = 255

by bylo nutné použít přepočet. Pro ověření funkce pro přepočet a doladění nastavení scriptu vzniká funkce pro simulaci.


 



čtvrtek 12. června 2025

simulační funkce pro kreslení a průniky

 

Tady je kompletní „end-to-end“ funkce, která pro obě oblasti (bottom‐left i top‐right):

  1. Vygeneruje v barvách BLACK, DARK_MAX, GRAY_MIN, WHITE

    • vodorovné čáry (0°)

    • šikmé čáry (+15°)

    • a jednu vertikální šedou čáru (90° / GRAY)

  2. Uloží je ve velikosti původního regionu

  3. Zmenší je do „small“ pomocí vašeho bl_div / tr_div (NEAREST, bez binarizace)

  4. Pro každý výsledný small obraz:

    • vytvoří row/col projekce

    • normalizuje je normalize_projection_manual (vrací (img_norm, scale, offset))

    • spočte find_intervals(…, ShadowType.DARK) a find_intervals(…, ShadowType.GRAY)

    • uloží všechny mezivýsledky (2D, raw small, row, col, nrow, ncol)

    • vytiskne intervaly i skutečné prahové hodnoty, na kterých byly založeny

import os
from enum import Enum
from dataclasses import dataclass
from PIL import Image, ImageDraw
import numpy as np

class ShadowType(Enum):
    DARK = "dark"
    GRAY = "gray"

class ShadowRanges(Enum):
    BLACK    =   0
    DARK_MAX = 188
    GRAY_MIN = 189
    GRAY_MAX = 232
    WHITE    = 255

@dataclass
class PageRegions:
    top_right: tuple[int,int,int,int]
    bottom:    tuple[int,int,int,int]

def normalize_projection_manual(img_proj: Image.Image, original_length: int):
    pixels = list(img_proj.getdata())
    mn, mx = min(pixels), max(pixels)
    if mx == mn:
        img_proj.scale = 1.0
        img_proj.offset = mn
        return img_proj, 1.0, mn
    inten_scale = 255.0 / (mx - mn)
    length_scale = original_length / (img_proj.width if img_proj.height == 1 else img_proj.height)
    scale = inten_scale * length_scale
    offset = mn
    lut = [min(255, max(0, int((i - offset) * scale))) for i in range(256)]
    img_norm = img_proj.point(lut)
    img_norm.scale = scale
    img_norm.offset = offset
    return img_norm, scale, offset

def find_intervals(vals: list[int], shadow: ShadowType):
    if shadow is ShadowType.DARK:
        lo, hi = ShadowRanges.BLACK.value, ShadowRanges.DARK_MAX.value
    else:
        lo, hi = ShadowRanges.GRAY_MIN.value, ShadowRanges.GRAY_MAX.value
    intervals = []
    start = None
    for i, v in enumerate(vals):
        if lo <= v <= hi:
            if start is None: start = i
        elif start is not None:
            intervals.append((start, i-1))
            start = None
    if start is not None:
        intervals.append((start, len(vals)-1))
    return intervals

def simulate_and_measure_thresholds(
    region_px: tuple[int,int],
    debug_folder: str,
    label: str,
    div_factor: int,
    orientations: list[float] = (0.0, 15.0)
):
    """
    1) Vytvoří v debug_folder obraz velikosti region_px + horizontální, šikmé i vertikální čáry
    2) Zmenší (NEAREST) o div_factor na small
    3) Pro small:
       - vytvoří row/col projekce
       - normalizuje je
       - spočte intervaly pro DARK i GRAY
       - uloží všechny mezivýsledky
    4) Vytiskne skutečná lo/hi použitá pro detekci a nalezené intervaly.
    """
    os.makedirs(debug_folder, exist_ok=True)
    w0, h0 = region_px

    # barvy + tvary
    shades = {
        "black":    ShadowRanges.BLACK.value,
        "dark":     ShadowRanges.DARK_MAX.value,
        "gray":     ShadowRanges.GRAY_MIN.value,
        "white":    ShadowRanges.WHITE.value
    }

    for orientation in orientations + [90.0]:  # +90° jednou vertikálně
        for name, intensity in shades.items():
            base = Image.new("L", (w0, h0), 255)
            draw = ImageDraw.Draw(base)

            # horizontální / šikmá / vertikální
            if orientation == 90.0:
                # vertikální čára uprostřed šedě
                x0 = w0//2 - 16
                draw.rectangle([x0, 0, x0+31, h0], fill=ShadowRanges.GRAY_MIN.value)
            else:
                length_px = 368
                thick_px  = 32
                gap = 4
                img = base.copy()
                d = ImageDraw.Draw(img)
                d.rectangle([gap, gap, gap+length_px, gap+thick_px], fill=intensity)
                img = img.rotate(orientation, expand=False, center=(w0//2,h0//2))
                base = img

            # 2D uložíme
            fname2d = f"{label}_{name}_{int(orientation)}.png"
            p2d = os.path.join(debug_folder, fname2d)
            base.save(p2d)

            # zmenšení small
            small = base.resize((w0//div_factor, h0//div_factor), Image.Resampling.NEAREST)
            p_small = os.path.join(debug_folder, f"{label}_{name}_{int(orientation)}_small.png")
            small.save(p_small)

            # 1D projekce
            w, h = small.size
            row = small.resize((w,1), resample=Image.Resampling.BILINEAR)
            col = small.resize((1,h), resample=Image.Resampling.BILINEAR)
            p_row = os.path.join(debug_folder, f"{label}_{name}_{int(orientation)}_small_row.png")
            p_col = os.path.join(debug_folder, f"{label}_{name}_{int(orientation)}_small_col.png")
            row.save(p_row)
            col.save(p_col)

            # normalizace
            nrow, scale_r, off_r = normalize_projection_manual(row, original_length=w)
            ncol, scale_c, off_c = normalize_projection_manual(col, original_length=h)
            p_nrow = p_row.replace(".png", "_n.png")
            p_ncol = p_col.replace(".png", "_n.png")
            nrow.save(p_nrow)
            ncol.save(p_ncol)

            # detekce intervalů
            vals_row = list(nrow.getdata())
            vals_col = list(ncol.getdata())
            int_row_dark = find_intervals(vals_row, ShadowType.DARK)
            int_row_gray = find_intervals(vals_row, ShadowType.GRAY)
            int_col_dark = find_intervals(vals_col, ShadowType.DARK)
            int_col_gray = find_intervals(vals_col, ShadowType.GRAY)

            print(f"[{label} {name} {orientation}°] "
                  f"scale_r={scale_r:.3f}, off_r={off_r}, "
                  f"scale_c={scale_c:.3f}, off_c={off_c}")
            print("  → row_dark:", int_row_dark, " row_gray:", int_row_gray)
            print("  → col_dark:", int_col_dark, " col_gray:", int_col_gray)
            print("  --------------------------------------")

Jak to použít:

regions = PageRegions(
    top_right=(1875, 30, 2400, 300),
    bottom=(25, 3050, 2455, 3310),
)

# po výpočtu scale_factor, bl_div, tr_div v `create_thumbnail_with_regions`:
simulate_and_measure_thresholds(
    region_px=(regions.bottom[2]-regions.bottom[0],
               regions.bottom[3]-regions.bottom[1]),
    debug_folder="/path/to/output/debug_sim_bl",
    label="bl",
    div_factor=bl_div,
    orientations=[0.0, 15.0]
)

simulate_and_measure_thresholds(
    region_px=(regions.top_right[2]-regions.top_right[0],
               regions.top_right[3]-regions.top_right[1]),
    debug_folder="/path/to/output/debug_sim_tr",
    label="tr",
    div_factor=tr_div,
    orientations=[0.0, 15.0]
)

Tím dostaneš pro každou barvu a orientaci:

  • originál 2D (čára na bílé ploše)

  • small verzi

  • row/col projekce (raw i normalizované)

  • vypsané skutečné scale, offset a nalezené intervaly pro DARK a GRAY

Na základě toho si přesně doladíš ShadowRanges.DARK_MAX, GRAY_MIN a GRAY_MAX.

středa 11. června 2025

Příprava na získání intersekcí - průniků Image

 

Průnik v tomto kontextu znamená vzít každý “řádkový” interval a každý “sloupcový” interval a pro každý pár (row_int, col_int) vytvořit obdélník:

def intersect_intervals(row_ints, col_ints):
    regions = []
    for r_start, r_end in row_ints:
        if r_start is None: continue
        for c_start, c_end in col_ints:
            if c_start is None: continue
            regions.append((c_start, r_start, c_end + 1, r_end + 1))
    return regions

# příklad použití:
dark_row_ints = shadow_ranges["small_bl_row"]  # může být list of tuples
dark_col_ints = shadow_ranges["small_bl_col"]

# zajistíš, že shadow_ranges vrací list intervalů, ne jen jeden:
#   results["small_bl_row"] = [(r1,r2), (r3,r4), …]
# teprve pak
bl_dark_regions = intersect_intervals(dark_row_ints, dark_col_ints)

Každý tuple (x1, y1, x2, y2) pak použiješ k oříznutí:

for idx, (x1, y1, x2, y2) in enumerate(bl_dark_regions, start=1):
    crop = bl_bw.crop((x1, y1, x2, y2))
    crop.save(dbg_bl / f"region_bl_dark_{idx}.png")

A obdobně pro světlé intervaly (small_bl_gray), i pro small_tr.

Příprava kontejneru pro detekci oblastí stínů k analýze

 

Zde je funkce, která na předem vygenerovaných binárních projekcích n_small_bl_row.png, n_small_bl_col.png, n_small_tr_row.png, n_small_tr_col.png:

  1. otevře odpovídající Image objekty

  2. pro každý z nich prozkoumá hodnoty pixelů

  3. rozdělí je na dva kontejnery dark (0–188) a gray (189–232)

  4. vrátí čtyři seznamy intervalů (start_index, end_index) v rámci těchto projekcí

from PIL import Image

def collect_shadow_ranges(
    bl_row_path: str,
    bl_col_path: str,
    tr_row_path: str,
    tr_col_path: str,
    dark_max: int = 188,
    gray_min: int = 189,
    gray_max: int = 232
) -> dict:
    """
    Pro každou 1D projekci (row i col, small_bl i small_tr) vrátí intervaly,
    kde pixelová hodnota spadá do dark (<=dark_max) nebo gray (>=gray_min a <=gray_max).
    """
    def find_intervals(vals, lo, hi):
        intervals = []
        start = None
        for i, v in enumerate(vals):
            if lo <= v <= hi:
                if start is None:
                    start = i
            else:
                if start is not None:
                    intervals.append((start, i-1))
                    start = None
        if start is not None:
            intervals.append((start, len(vals)-1))
        return intervals

    # načteme projekce
    bl_row = Image.open(bl_row_path).convert("L").getdata()
    bl_col = Image.open(bl_col_path).convert("L").getdata()
    tr_row = Image.open(tr_row_path).convert("L").getdata()
    tr_col = Image.open(tr_col_path).convert("L").getdata()

    bl_row = list(bl_row)
    bl_col = list(bl_col)
    tr_row = list(tr_row)
    tr_col = list(tr_col)

    return {
        "bl_dark_row":  find_intervals(bl_row, 0, dark_max),
        "bl_gray_row":  find_intervals(bl_row, gray_min, gray_max),
        "bl_dark_col":  find_intervals(bl_col, 0, dark_max),
        "bl_gray_col":  find_intervals(bl_col, gray_min, gray_max),
        "tr_dark_row":  find_intervals(tr_row, 0, dark_max),
        "tr_gray_row":  find_intervals(tr_row, gray_min, gray_max),
        "tr_dark_col":  find_intervals(tr_col, 0, dark_max),
        "tr_gray_col":  find_intervals(tr_col, gray_min, gray_max),
    }

Tato funkce neukládá nic na disk, ale očekává cesty ke čtyřem jednorozměrným obrázkům a vrací slovník s osmi položkami, kde každá je seznamem intervalů (start, end) odpovídajících tmavým (dark) nebo světlým (gray) úsekům.

Teď prosím pošli aktuální verzi svého skriptu, kam tuto funkci zařadíme.

Vysvětlení jednovětvého zápisu a vrácení iterovatelného proudu z obrazu

 

  1. Ternární operátor v Pythonu

    L_proj = img_proj.width if img_proj.height == 1 else img_proj.height
    

    To je jednovětvý zápis pro:

    if img_proj.height == 1:
        L_proj = img_proj.width
    else:
        L_proj = img_proj.height
    

    Znamená to „pokud je výsledný obrázek řádková projekce (výška == 1), vezmi jeho šířku, jinak (sloupcová projekce) vezmi jeho výšku“.

  2. getdata()

    pixels = list(img_proj.getdata())
    
    • img_proj.getdata() vrací iterovatelný proud všech pixelů obrázku img_proj, hodnoty 0–255 (pro režim 'L').

    • Zápisem list(…) to naházíme do Python-listu, takže máme pevné pole [p0, p1, …, pN].

  3. Korekce zředění podle změny délky
    Když redukujete řadu o délce L_orig na projekci délky L_proj, každý pixel nové projekce "shrne" ≈ L_orig/L_proj původních bodů. Abychom tam kompenzovali tu ztrátu kontrastu, násobíme standardní normalizační faktor

    255 DĚLENO (max−min)

    ještě faktorem délky

    Lorig DĚLENO Lproj

    dohromady:

    length_scale   = original_length / L_proj
    inten_scale    = 255.0 / (mx - mn)
    scale          = inten_scale * length_scale
    

    Tím obnovíme šedé odstíny zhruba na úroveň původního detailu.

def normalize_projection_manual(img_proj: Image.Image, original_length: int) -> tuple[Image.Image, float, int]:
    """
    Lineárně přepočte 1D projekci (L režim, size=(w,1) nebo (1,h)) tak,
    že původní min → 0 a původní max → 255, kompenzuje zředění dle změny velikosti.

    Parametry:
      img_proj         – PIL.Image v režimu 'L', délky L_proj (1D).
      original_length  – délka před resize (např. šířka nebo výška cropu).

    Návrat:
      img_norm   – nový Image ‚L‘
      scale      – škálovací faktor zohledňující both intensity a length: (255/(mx–mn)) * (original_length/L_proj)
      offset     – původní min, který byl „odečten“
    """
    # 1) Jednorozměrná délka projekce
    L_proj = img_proj.width if img_proj.height == 1 else img_proj.height

    # 2) Data a min/max
    pixels = list(img_proj.getdata())
    mn, mx = min(pixels), max(pixels)
    if mx == mn:
        return img_proj.copy(), 1.0, mn

    # 3) Intenzitní faktor
    inten_scale = 255.0 / (mx - mn)
    # 4) Korekce zředění podle délky
    length_scale = original_length / L_proj
    scale = inten_scale * length_scale
    offset = mn

    # 5) LUT pro rychlou aplikaci
    lut = [min(255, max(0, int((i - offset) * scale))) for i in range(256)]

    # 6) Aplikace
    img_norm = img_proj.point(lut)
    img_norm.scale = scale
    img_norm.offset = offset
    return img_norm, scale, offset

Shrnutí problému normalizace (GPT, ne deepthink)

PLÁN: Normalizace šedi v Image, po resize.

 


Rozumím, chyba byla v tom, že se nejprve dělala projekce (sloupcová/řádková) z už zmenšeného obrázku, aniž by se ta projekce odpovídajícím způsobem kompenzovala ztráta intenzit (nebo naopak ztráta stínu). Tím vznikne slabší (rozředěný) stín, protože každé zmenšení rozměru (např. šířky z 1000 px na 64 px) zároveň zprůměruje nebo zprůměruje hodnoty pixelů.


🧩 Co se má dělat správně

Předpoklady spuštění:

  1. získal jsem binární masku 2D obrazu pomocí bl_bw = binarize_shadow(bl_small) a tr_bw = binarize_shadow(tr_small)

  2. spouštím funkci     candidates, resolution_info = locate_region_and_source(
            bl_bw=bl_bw,
            bl_crop=bl_crop,
            tr_bw=tr_bw,
            tr_crop=tr_crop,
            thumbnail=thumbnail,
            full_img=img,  # originál v plném rozlišení
            bl_box_in_thumb=bl_box,
            tr_box_in_thumb=tr_box,
            crop_resize_bl_factor=bl_div,
            crop_resize_tr_factor=tr_div,
            small_capacity_bl=small_capacity_bl,  # např. 4
            small_capacity_tr=small_capacity_tr,
            est_shadow_thumb_px=est_shadow_thumb_px,   # odhad tloušťky stínu ve thumbnailu
            output_path = output_path
        )


  3. uvnitř funkce locate_region_and_source se spouští     shadow_ranges = project_and_find_shadow_ranges(
            bl_bw=bl_bw,
            tr_bw=tr_bw,
            min_shadow_thickness_px=MIN_SHADOW_PX_SMALL,
            min_shadow_length_px=20,
            intensity_thresh=0.5,
            output_path=output_path
        )

    která přijímá dvě binární masky 2D

  4. Náhled kodu kde bude probíhat editace: def project_and_find_shadow_ranges(
            bl_bw: Image.Image,
            tr_bw: Image.Image,
            min_shadow_thickness_px: int = MIN_SHADOW_PX_SMALL,
            min_shadow_length_px: int = 20,
            intensity_thresh: float = 0.5,
            output_path: str = ""
        ) -> dict:
            def find_longest_true_interval(bool_list: list[bool]) -> tuple[int, int, int]:
                best_len = 0
                best_start = None
                curr_start = None
                curr_len = 0
                for i, val in enumerate(bool_list):
                    if val:
                        if curr_start is None:
                            curr_start = i
                            curr_len = 1
                        else:
                            curr_len += 1
                    else:
                        if curr_start is not None and curr_len > best_len:
                            best_len = curr_len
                            best_start = curr_start
                        curr_start = None
                        curr_len = 0
                if curr_start is not None and curr_len > best_len:
                    best_len = curr_len
                    best_start = curr_start
                if best_start is None:
                    return (None, None, 0)
                return (best_start, best_start + best_len - 1, best_len)
                # END find_longest_true_interval(bool_list: list[bool])
            # POKRAČOVÁNÍ project_and_find_shadow_ranges
            """
            Pro každý z obrázků bl_bw a tr_bw vytvoří:
              - horizontální projekci (w × 1) a ukládá ji jako
                output_path.replace("thumbnail_", "{label}_row_")
              - vertikální projekci (1 × h) a ukládá ji jako
                output_path.replace("thumbnail_", "{label}_col_")
            Poté v každé projekci najde nejdelší souvislý True-interval
            a vrátí slovník:
              {
                "small_bl_row": (start, end, length),
                "small_bl_col": (start, end, length),
                "small_tr_row": (…),
                "small_tr_col": (…)
              }
            """
            results = {}
            threshold_255 = int(round(intensity_thresh * 255))

            # label je řetězec "small_bl" nebo "small_tr".
            # Vytvoření klíčů "small_bl_row", "small_bl_col", "small_tr_row" a "small_tr_col"
            for label, img_bw in (("small_bl", bl_bw), ("small_tr", tr_bw)):
                w, h = img_bw.size

                # @TODO: Zavést normalizaci barev po zmenšení, vycházeje asi z poměru zmenšení
                # horizontální projekce
                row_proj = img_bw.resize((w, 1), resample=Image.Resampling.BILINEAR)
                row_path = output_path.replace("thumbnail_", f"{label}_row_")
                row_proj.save(row_path)
                # @TODO: Provést normalizaci barev přepočet podle původní výšky

                # vertikální projekce
                col_proj = img_bw.resize((1, h), resample=Image.Resampling.BILINEAR)
                col_path = output_path.replace("thumbnail_", f"{label}_col_")
                col_proj.save(col_path)
                # @TODO: Provést normalizaci barev přepočet podle původní šířky

Správné pořadí kroků:

  1. Ve funkci project_and_find_shadow_ranges row_proj: img_bw.resize((w, 1), resample=Image.Resampling.BILINEAR) a col_proj = img_bw.resize((1, h), resample=Image.Resampling.BILINEAR)

  2. Proveď normalizaci šedi/intenzit podle původní výšky nebo šířky, protože aktuální velikost strany je 1, čímž došlo ke "zředění" intenzit stínů.

  3. Po provedení normalizace ulož to jako nové soubory:

                row_path = output_path.replace("thumbnail_", f"n_{label}_row")
    a

                col_path = output_path.replace("thumbnail_", f"n_{label}_col")
     


✳️ Proč je potřeba škálovat podle míry zmenšení?

Při projekci (např. img_bw.resize((w, 1)... nebo img_bw.resize((1, h),) se intenzita stínu sníží, protože se rozmaže do menšího počtu bodů. Např.:

  • Pokud zmenšíš obrázek 100×100 na 100×1, pak každý pixel nové projekce odpovídá asi ???? původním bodům → tím se intenzita zprůměruje → výsledek bude méně kontrastní.

  • Bez korekce škálováním dostaneš slabý stín, který je těžko detekovatelný a pokaždé jiný.


🧮 Řešení: korekce podle škálovacího faktoru

Spočítat kolikrát se po resize na 1, stíny "zředily" oproti původní velikosti zmenšené strany.

Následně provést opravu pomocí kontrastu - levels podobně jako jsem to dělal výše:

    bl_crop = thumbnail.crop(bl_box)
    enhancer = ImageEnhance.Brightness(bl_crop)
    bl_crop = enhancer.enhance(1.2)
    enhancer = ImageEnhance.Contrast(bl_crop)
    bl_crop = enhancer.enhance(2.0)
    enhancer = ImageEnhance.Brightness(bl_crop)
    bl_crop = enhancer.enhance(1.4)


neděle 8. června 2025

Implementace kandidádátů po oříznutí small po hledání v jednorozměrném obrazu

User:

Jasně že to nestačí, protože kurva nebudu spouštět algoritmus na hledání nějaké pojebané čáry na celý obraz nascanovaný v 300dpi A4! "Proč region=(0, 0, *image.size) je špatně? To je jen fallback, nouzový začátek – říká: “Celý obrázek je kandidátní oblast”" To určitě. RE: "Chceš, abych ti upravil tu funkci tak, aby dělala přesně tohle – tedy omezila každý kandidát jen na jeho reálný detekovaný rozsah podle shadow_ranges?"

AI:

Upravil jsem locate_region_and_source, aby nejprve zavolala project_and_find_shadow_ranges, získala pro bl_small/tr_small konkrétní intervaly a pak podle nich sestavila kandidáty s přesnými regiony (přepočtenými na příslušné měřítko). Zde je nová verze funkce:

def locate_region_and_source(
    bl_small: Image.Image,
    tr_small: Image.Image,
    bl_crop:  Image.Image,
    tr_crop:  Image.Image,
    thumbnail: Image.Image,
    full_img:  Image.Image,
    bl_box_in_thumb:   tuple,
    tr_box_in_thumb:   tuple,
    crop_resize_bl_factor: int,
    crop_resize_tr_factor: int,
    small_capacity_bl: int,
    small_capacity_tr: int,
    est_shadow_thumb_px: int
) -> tuple[dict, dict]:
    """
    Vrátí:
      - {'candidates': [...]}, kde každý kandidát má přesně vypočtený region
      - resolution_info s kapacitami
    """

    # 1) Normy
    MIN_SHADOW_PX_SMALL = 4
    SHADOW_PX_THUMB    = 8

    # 2) Kapacity
    kap_small_bl  = bl_small.height // MIN_SHADOW_PX_SMALL
    kap_small_tr  = tr_small.height // MIN_SHADOW_PX_SMALL
    kap_thumb     = thumbnail.height  // SHADOW_PX_THUMB

    resolution_info = {
        "kapacita_small_bl":  kap_small_bl,
        "kapacita_small_tr":  kap_small_tr,
        "kapacita_thumbnail": kap_thumb,
    }

    # 3) Zúžení regionu pomocí 1D projekcí
    shadow_ranges = project_and_find_shadow_ranges(
        bl_bw=bl_small,
        tr_bw=tr_small,
        min_shadow_thickness_px=MIN_SHADOW_PX_SMALL,
        min_shadow_length_px=20,
        intensity_thresh=0.5,
        prefix=""  # nebo použij output_path, pokud chceš názvy souborů
    )
    # shadow_ranges obsahuje např.:
    #   'bl_row': (x1, x2, length), 'bl_col': (y1, y2, length), atd.

    candidates = []

    # 4) small_bl
    r1, r2, _ = shadow_ranges["bl_row"]
    c1, c2, _ = shadow_ranges["bl_col"]
    if r1 is not None and c1 is not None and kap_small_bl >= kap_thumb:
        candidates.append({
            "source": "small_bl",
            "image": bl_small,
            "region": (r1, c1, r2 + 1, c2 + 1)  # +1, protože end je včetně
        })

    # 5) small_tr
    r1, r2, _ = shadow_ranges["tr_row"]
    c1, c2, _ = shadow_ranges["tr_col"]
    if r1 is not None and c1 is not None and kap_small_tr >= kap_thumb:
        candidates.append({
            "source": "small_tr",
            "image": tr_small,
            "region": (r1, c1, r2 + 1, c2 + 1)
        })

    # 6) crop_bl — přepočtené z small na crop
    if bl_crop.height >= SHADOW_PX_THUMB:
        # region v bl_small byl (r1,c1,r2,c2), nyní násobíme bl_box v thumb a faktor
        x1 = bl_box_in_thumb[0] + r1 * crop_resize_bl_factor
        y1 = bl_box_in_thumb[1] + c1 * crop_resize_bl_factor
        x2 = bl_box_in_thumb[0] + (r2 + 1) * crop_resize_bl_factor
        y2 = bl_box_in_thumb[1] + (c2 + 1) * crop_resize_bl_factor
        candidates.append({
            "source": "crop_bl",
            "image": bl_crop,
            "region": (x1, y1, x2, y2)
        })

    # 7) crop_tr
    if tr_crop.height >= SHADOW_PX_THUMB:
        x1 = tr_box_in_thumb[0] + r1 * crop_resize_tr_factor
        y1 = tr_box_in_thumb[1] + c1 * crop_resize_tr_factor
        x2 = tr_box_in_thumb[0] + (r2 + 1) * crop_resize_tr_factor
        y2 = tr_box_in_thumb[1] + (c2 + 1) * crop_resize_tr_factor
        candidates.append({
            "source": "crop_tr",
            "image": tr_crop,
            "region": (x1, y1, x2, y2)
        })

if not candidates:
return None, resolution_info
 
Tímto způsobem každý kandidát obsahuje přesný ořez, nikoli celý obraz. Konkrétní souřadnice se přepočítají zpět na příslušné rozlišení (crop_resize_*_factor) a dají se rovnou použít pro Houghovu transformaci.

čtvrtek 5. června 2025

Hrubý odhad vhodnosti detekce hrany stínu v obrazu vzhledem k jeho rozlišení (kvalitě)

Tento manuál popisuje jak postupovat v případě, že provádíte detekci hrany stínu nascanovaného documentu.

Fakta pro orientaci

Pipeline: Original Image (300 dpi at least A4) --> Thumbnail (resize na 4th of dims) --> small (resize na estimated 4th of dims)

Přitom crop není nic jiného než ořez oblasti thumbnailu (top-right nebo bottom-left)

Dims and divisor

original 2480 x 3508 px

optimal divisor for thumbnail: 4

thumbnail 620 x 877 px

                  border size

thumbnail 8-9 px thick 

original 8*4 divisor

small 8/4 = 2px thick

Jak počítám zda je rozlišení náhledu nebo cropu dostačující?

Pro thumbnail vychází při této konfiguraci (rozměrech, dpi) tlouštka stínu 4, což stačí, ale při small vychází 2 a to nestačí. Takže si musíš říct kolikrát se 4 vleze do 877 (výška thumbnail) aby si získal nějakou normu. Pokud by byl stín tlustější řekněme 8 tak to bude 877/8, takže menší číslo. Ale menší číslo mi nevadí. Ale co by to ukazovalo kdyby vyšel výsledek menší? Když bude 2x menší než 877/4, tak mi to říká, že mohu použít small a ne thumbnail. 

Podobně small: obrázek 32x32, 4 je px je ok. Kolikrát se vleze 4 do 32px výšky? To mi vychází 8px. To je pro hrubý odhad. A když by u small vyšlo např 128x128 rozměr obrázku small, tak při tloušťce 8px mi zase vyjde 128/8 což je 16. Když bude 32x32 ale 8px tlustý stín pak mám 32/8= 4 a 4 je 2x menší než 8 takže si mohu říct: no jo on ten stín je zbytečně tlustý, možná bych to mohl zmenšit trochu víc.

Začněme

Níže je stručné vysvětlení, jak z orientačně odhadnout, zda je detekce stínu s rozlišením v bl_small (či tr_small) ještě dostatečně přesná, nebo jestli musíme přejít na „vyšší“ úroveň (bl_crop/tr_crop což je úroveň thumbnail). Zavedeme přitom následující dvě čísla:

  1. est_shadow_thumb_px – odhad tloušťky (výšky) stínu už v celém thumbnailu (v mém případě 8 až 9 px takže 8px beru jako normu),

  2. min_shadow_px_small – minimální počet pixelů (např. 4 px), pod kterým už bl_small/tr_small nelze považovat za dostatečně ostrý stín.

Poté si spočteme dvě kapacity (jakoby „kolikrát se stín vejde do výšky“):

  • „kapacita thumbnailu“ = thumbnail.height / est_shadow_thumb_px (čím větší, tím detailnější je thumbnail vůči tloušťce stínu takže vyjde 2x menší číslo když je "kvalita stínu" dvounásobná),

  • „kapacita small“ = bl_small.height / min_shadow_px_small (čím větší, tím small stále dokáže ukázat tloušťku ≥ min_shadow_px_small).

Pokud „kapacita small“ ≥ „kapacita thumbnailu“, znamená to, že i v bl_small je dostatečné množství pixelů, aby stín byl detekovatelný s porovnatelnou přesností, a proto můžeme spustit detekci přímo v bl_small. V opačném případě (tj. když small ztrácí příliš mnoho detailu) přejdeme raději na bl_crop/tr_crop či rovnou na thumbnail, kde je stín stále dostatečně „tlustý“.


1) Konkrétní úprava locate_region_and_source

locate_region_and_source je funkce, která detekuje a měří souřadnice, pro ořez, zmenšení vyššího regionu vrátíme-li se do vyššího rozlišení např. ze small do crop. Např. crop 200x200 můžeme oříznout na 40x350 a teprve v tomto oříznutém regionu budeme hledat línii stínu a detekovat úhel natočení stránky.

Upravíme vnitřek locate_region_and_source tak, že:

  1. Nejprve dynamicky spočítáme

    thumb_capacity = thumbnail.height / est_shadow_thumb_px
    small_capacity = bl_small.height / min_stin_px_small
    
  2. Pokud small_capacity >= thumb_capacity, zkusíme detekci „hrany“ ve bl_small¹.
    Jinak přejdeme rovnou k bl_crop (nebo tr_crop), protože small už je příliš nízké rozlišení.

Takhle bude část kódu uvnitř locate_region_and_source vypadat:

def locate_region_and_source(
    bl_small: Image.Image,  # crop po resize
    bl_crop:   Image.Image, # úroveň tumbnailu (no resize)
    tr_small:  Image.Image, # crop po resize
    tr_crop:   Image.Image, # úroveň tumbnailu (no resize)
    thumbnail: Image.Image, # original image resized to 4th of dims
    full_img:  Image.Image, # original image
    bottom_box_in_thumb: tuple, # asi souřadnice bboxu pro bl?
    top_box_in_thumb:    tuple, # asi souřadnice bboxu pro tr?
    divisor_for_small:   int = 4, # optimální dělitel pro zmenšení cropu
    min_stin_px_small:   int = 4, # obvykle 4 px stačí pro detekci línie
    est_shadow_thumb_px: int = 8  # asi nutno spočítat
) -> dict:
    """
    ... (vaše docstring) ...
    """

    def find_edge_bbox(img_gray, threshold_px):
        gray = np.array(img_gray)
        edges = cv2.Canny(gray, 50, 150)
        lines = cv2.HoughLinesP(
            edges,
            rho=1,
            theta=np.pi/180,
            threshold=threshold_px,
            minLineLength=threshold_px,
            maxLineGap=5
        )
        if lines is None or len(lines) == 0:
            return None
        xs, ys = [], []
        for l in lines:
            x1, y1, x2, y2 = l[0]
            xs += [x1, x2]
            ys += [y1, y2]
        return (min(xs), min(ys), max(xs), max(ys))

    # --- A) nejprve vypočtu kapacity: ---
    #   thumb_capacity  = (kolikrát se tloušťka stínu vejde do výšky thumbnailu)
    #   small_capacity  = (kolikrát se min. tloušťka vejde do výšky bl_small)
    thumb_capacity = thumbnail.height / est_shadow_thumb_px
    small_capacity = bl_small.height / min_stin_px_small

    # --- 1) Zkusíme bottom-left v bl_small, **pouze pokud** small_capacity >= thumb_capacity ---
    if small_capacity >= thumb_capacity:
        # 1.a) Převod bl_small na grayscale a Hough
        gray_bl_small = cv2.cvtColor(np.array(bl_small), cv2.COLOR_RGB2GRAY)
        bbox = find_edge_bbox(gray_bl_small, threshold_px=min_stin_px_small)
        if bbox is not None:
            off_x, off_y = bottom_box_in_thumb[0] * divisor_for_small, bottom_box_in_thumb[1] * divisor_for_small
            bx1, by1, bx2, by2 = bbox
            return {
                "source": "small_bl",
                "region": (bx1 + off_x, by1 + off_y, bx2 + off_x, by2 + off_y)
            }
        # jinak – když v bl_small nic nenajde – přejdeme na crop_bl dále

    # --- 2) Pokud bl_small padne (small_capacity < thumb_capacity) **nebo** Hough v bl_small vrátil None,
    #         zkusíme bl_crop (to je bottom‐left crop na úrovni thumbnail) ---
    if est_shadow_thumb_px >= (min_stin_px_small * divisor_for_small):
        gray_bl_crop = cv2.cvtColor(np.array(bl_crop), cv2.COLOR_RGB2GRAY)
        bbox = find_edge_bbox(gray_bl_crop, threshold_px=min_stin_px_small * 2)
        if bbox is not None:
            off_x, off_y = bottom_box_in_thumb[0], bottom_box_in_thumb[1]
            bx1, by1, bx2, by2 = bbox
            return {
                "source": "crop_bl",
                "region": (bx1 + off_x, by1 + off_y, bx2 + off_x, by2 + off_y)
            }
    # jinak – přeskočíme bl_crop

    # --- 3) Teď analogicky pro top‐right small (tr_small) ---
    if small_capacity >= thumb_capacity:
        gray_tr_small = cv2.cvtColor(np.array(tr_small), cv2.COLOR_RGB2GRAY)
        bbox = find_edge_bbox(gray_tr_small, threshold_px=min_stin_px_small)
        if bbox is not None:
            off_x, off_y = top_box_in_thumb[0] * divisor_for_small, top_box_in_thumb[1] * divisor_for_small
            tx1, ty1, tx2, ty2 = bbox
            return {
                "source": "small_tr",
                "region": (tx1 + off_x, ty1 + off_y, tx2 + off_x, ty2 + off_y)
            }

    # --- 4) A pro tr_crop (tzv. top‐right crop v thumbnail) ---
    if est_shadow_thumb_px >= (min_stin_px_small * divisor_for_small):
        gray_tr_crop = cv2.cvtColor(np.array(tr_crop), cv2.COLOR_RGB2GRAY)
        bbox = find_edge_bbox(gray_tr_crop, threshold_px=min_stin_px_small * 2)
        if bbox is not None:
            off_x, off_y = top_box_in_thumb[0], top_box_in_thumb[1]
            tx1, ty1, tx2, ty2 = bbox
            return {
                "source": "crop_tr",
                "region": (tx1 + off_x, ty1 + off_y, tx2 + off_x, ty2 + off_y)
            }

    # --- 5) Pokud jsme se nedostali k žádnému bottom‐left ani top‐right řezu, zkusíme celý thumbnail ---
    gray_thumb = cv2.cvtColor(np.array(thumbnail), cv2.COLOR_RGB2GRAY)
    bbox = find_edge_bbox(gray_thumb, threshold_px=min_stin_px_small * 3)
    if bbox is not None:
        return {
            "source": "thumbnail",
            "region": bbox
        }

    # --- 6) A nakonec fallback: celý originál (full_img) ---
    gray_full = cv2.cvtColor(np.array(full_img), cv2.COLOR_RGB2GRAY)
    bbox = find_edge_bbox(gray_full, threshold_px=min_stin_px_small * 5)
    if bbox is not None:
        return {
            "source": "full",
            "region": bbox
        }

    # fallback --- 7) Když ani originál nic nenajde, prostě vrať celý full_img jako region ---
    W, H = full_img.size
    return {
        "source": "full",
        "region": (0, 0, W, H)
    }

Vysvětlení klíčové úpravy:

  • Na řádku thumb_capacity = thumbnail.height / est_shadow_thumb_px vezmeme odhadnutou tloušťku stínu v celém thumbnailu (řekněme 8 px) a řekneme si:

    • „Kolikrát se do těch 877 px (výšky) vejde ten 8 px stín?“ → 877/8 ≈ 109.6.
      Čím menší je ta kapacita, tím hruběji hrubě se nám může detekovat úhel ve thumbnailu; naopak čím větší kapacita, tím je thumbnail relativně detailnější vůči tloušťce stínu.

  • Na řádku small_capacity = bl_small.height / min_stin_px_small spočítáme, kolikrát se do výšky bl_small vejde minimální tloušťka stínu, kterou ještě chceme detekovat (např. 4 px). Příklad:
    bl_small.height je třeba 32 px → 32/4 = 8.
    – Pokud je 8 (small_capacity) menší než 109.6 (thumb_capacity), znamená to, že v bl_small je relativně příliš málo „pixelek“ na to, aby stín o tloušťce 8 px (v thumbnailu) pořád měl v small tloušťku minimálně 4 px. Jinými slovy, small už ztratí příliš detailu.

  • Podmínka if small_capacity >= thumb_capacity: říká, že pokud dokážu v bl_small alespoň stejný poměr „tloušťka stínu vs. výška obrazu“ (tj. kapacita detekce) jako mám v celém thumbnailu, pak stojí za to hned zkusit Hough v bl_small. Pokud to z bl_small vypadne None (nebo pokud small_capacity < thumb_capacity), i tak se dostanu do kroku č. 2, tj. zkusím bl_crop.

  • Ty další úrovně (bl_crop, tr_small, tr_crop, thumbnail, full) už zůstanou stejně, jen thresholdy (resp. threshold_px=min_stin_px_small * 2 apod.) se násobí podle logiky, kterou jste si definoval dřív.


2) Jak to zapojíte do create_thumbnail_with_regions

V „upravené“ verzi create_thumbnail_with_regions (viz výše) po vygenerování bl_small, tr_small (a jejich „bw“‐variant) větříme locate_region_and_source(...). Nově tedy create_thumbnail_with_regions vrací:

return bl_small, bl_crop, tr_small, tr_crop, thumbnail, bl_box, tr_box, region_info

kde region_info obsahuje vždy:

{
    "source":  <"small_bl"|"crop_bl"|"small_tr"|"crop_tr"|"thumbnail"|"full">,
    "region":  (x1, y1, x2, y2)   # v souřadnicích toho zvoleného source‐obrazu
}

3) Použití v process_images

Ve vaší funkci process_images pak nahradíte původní:

bl_small, bl_crop, tr_small, tr_crop, thumbnail, bl_box, tr_box = create_thumbnail_with_regions(
    img_pil, thumbnail_path, ocr_area, toc_area, theme_numbers_area, theme_area, top_right_area, bottom_area
)

tímto:

bl_small, bl_crop, tr_small, tr_crop, thumbnail, bl_box, tr_box, region_info = create_thumbnail_with_regions(
    img_pil, thumbnail_path, ocr_area, toc_area, theme_numbers_area, theme_area, top_right_area, bottom_area
)

a hned po tom zpracujete region_info takto:

# 1) Zjistíme, jestli locate_region_and_source už spočítal úhel (angle) – případně mu region dtočil:
angle = None
angle_source = None

# Pokud locate_region_and_source přiřadil rovnou úhel, mohli bychom do region_info přidat key "angle".
# Příklad: region_info = {"source": "small_bl", "region": (...), "angle":  -2.34 }
# Pokud tam je, hned to použijeme.
if "angle" in region_info:
    angle = region_info["angle"]
    angle_source = region_info["source"]

# 2) Jinak (žádný úhel jsme dosud neměli) musíme spustit Hough podle toho, co region_info řekne:

if angle is None:
    src = region_info["source"]
    x1, y1, x2, y2 = region_info["region"]

    if src == "small_bl":
        crop_img = bl_small.crop((x1, y1, x2, y2))
    elif src == "crop_bl":
        # Protože bl_crop začíná v bl_box[0..1], pak
        crop_img = bl_crop.crop((
            x1 - bl_box[0], y1 - bl_box[1],
            x2 - bl_box[0], y2 - bl_box[1]
        ))
    elif src == "small_tr":
        crop_img = tr_small.crop((x1, y1, x2, y2))
    elif src == "crop_tr":
        crop_img = tr_crop.crop((
            x1 - tr_box[0], y1 - tr_box[1],
            x2 - tr_box[0], y2 - tr_box[1]
        ))
    elif src == "thumbnail":
        crop_img = thumbnail.crop((x1, y1, x2, y2))
    else:  # src == "full"
        crop_img = img_pil.crop((x1, y1, x2, y2))

    # Teď Hough na vybraném crop_img:
    sub_np = np.array(crop_img.convert("L"))
    edges = cv2.Canny(sub_np, 50, 150)
    lines = cv2.HoughLinesP(
        edges,
        rho=1, theta=np.pi/180,
        threshold=min_stin_px_small * 3,   # např. 12
        minLineLength=20 * 3,             # např. délka 60 px
        maxLineGap=5
    )
    if lines is not None and len(lines) > 0:
        longest = max(lines, key=lambda L: np.hypot(L[0][2]-L[0][0], L[0][3]-L[0][1]))[0]
        x1s, y1s, x2s, y2s = longest
        angle = float(np.degrees(np.arctan2((y2s - y1s), (x2s - x1s))))
        angle_source = src
    else:
        # žádná linie nenalezena – můžete dál zkusit „thumbnail“ nebo „full“… podle potřeby
        pass

# 3) Pokud máme nějaký angle, otočíme obrázek:
if angle is not None and angle != 0:
    rotate_angle = angle - 90
    img_pil = rotate_image(img_pil, -rotate_angle)

Výsledek

Díky tomu, že:

  • create_thumbnail_with_regions (bod 1 všeho) už vrací i region_info = locate_region_and_source(...),

  • a locate_region_and_source (bod 2) počítá thumb_capacity a small_capacity a na jejich základě rozhoduje, kde spustit Hough (a vrátí buď rovnou box s úhlem, nebo jen box bez úhlu),

  • tak v process_images (bod 3) už přesně víte, ve kterém „source“ (small_bl, crop_bl, small_tr, crop_tr, thumbnail, full) a v jakém „regionu“ spustíte finální Hough, nebo rovnou odchytíte úhel z locate_region_and_source.

Celý mechanismus teď:

  1. create_thumbnail_with_regions vytvoří bl_small, tr_small, thumb atd., hned zavolá locate_region_and_source(...).

  2. locate_region_and_source spočítá kapacity (porovnání small vs. thumb) a vrátí "source" + "region", případně i "angle" – podle toho, kde našel nejdelší linii stínu.

  3. process_images prostě rozbalí návrat z create_thumbnail_with_regions, podívá se do region_info a podle source a region buď:

    • vezme úhel přímo z region_info["angle"],

    • nebo si „vyřízne“ tu oblast z příslušného obrázku (bl_small, bl_crop, thumbnail či full_img) a spustí Hough znovu jen v tom krabičkovém výřezu.

Tím je zaručeno, že:

  • nikdy nespustíte Canny+Hough na zbytečně velkém obrázku (protože nejprve vyberete nejmenší možnou úroveň, na které je ještě stín dostatečně tlustý),

  • a současně dynamicky zohledníte, jestli je bl_small/tr_small ještě dostatečně ostré (porovnáním small_capacity vs thumb_capacity).


Poznámka k hodnotám

  • est_shadow_thumb_px nastavte z předchozí zkušenosti (u vás ~ 8 px).
    Pokud nevíte přesně, můžete ho třeba měnit podle toho, jaký je původní rozměr a dpi, ale v praxi stačí říct „vzhledem k 625×875 px thumbnailu mám stín tloušťky ~ 8 px“.

  • min_stin_px_small zvolte tak, aby v bl_small mívá ten stín nejméně 4 pixely na výšku.

V ukázce jsme dali min_stin_px_small = 4. Jakmile bl_small.height / 4 bude menší než thumbnail.height / 8, tak rovnou přeskočíme bl_small a zkusíme bl_crop či thumbnail.

Takto získáte objektivní (číslem řízenou) logiku, kdy „small“ ještě stačí a kdy už musíte vzít větší obraz.


Shrnutí jednou větou

Rozhodovací vzorec:
– Spočti thumb_capacity = thumbnail.height / est_shadow_thumb_px a small_capacity = bl_small.height / min_stin_px_small.
– Pokud small_capacity >= thumb_capacity, nejprve Hough ve bl_small; jinak přeskoč přímo na bl_crop (a dál).

A tím pádem už nikdy neběží Hough na zbytečně velké oblasti.

Python: Rozdíl mezi přidáním a rozšířením pole - append vs extend'!

  Výborná otázka – pojďme si vysvětlit rozdíl mezi append() a extend() a proč je v tomto konkrétním případě správné použít extend() . ...

Štítky

.profile adm administrace Adobe AI akcelerace alfa transparence analýza AND any aplikace apt ar archiv asociativní pole atomicity audio autentifikace awk balíčkovací systém bash beacon beacon_hint benchmark Bézierovy křivky bezpečnost biblehub BJT blogger boolean buffer buffering Cache-Conrol Cloudflare code Collector Cut-off ColorManager colorpicker common compare config cookies CPU CPU pipe css CSS3 curl current code cut čas data loss data lost data transfer reliability datasheet datetime.strptime deb deb-systemd-helper debian debián depricated development dioda diody dpkg dpkg -S dpkg-deb drivers EBO Emitter Cut-off Current eps ETag exclude exec Expires extrakce jediného extrakce názvu balíčku souboru extrakce obrázků extrakce souboru .deb fflock fflush ffmpeg FIFO file read file write file_get_contents file_get_contents/file_put_contents file_put_contents filter find first_install.sh flock Fly-back dioda font-face fóra fotorezistor fread functions funkce fwrite gate gate drive GDVfs gedit gedit-common geolokace getdata Ghostscript GIO glib gnome gnome settings GNU Privacy Guard gnupg gpg gradient-background grafika grep grep -v groupadd grub grub update gs gsettings gtk gtk.css gtk+ hebrejština history hlavičky HS html html 5 https hudba charakterizace chatGPT chroot chyba ICES IGBT Image img sizes img srcset impedance implementace imshow inference inkscape inrush current install jalový výkon javascript javescript jednocení seznamů js jsonData kapacita součástek koeficient zesílení komponenty xFce komunikace se serverem koncept konfigurace kontejner korekce barev Krita KSF Last-Modified lazy caching led LEFT JOIN librosa ligatury light-locker lightdm linux list log maják manuál maskování maskování služby masky matplotlib Max-Age measure memory měření MFCC MFCC koeficienty mint Mint 21.3 Mint xFce míry modules moralizace morphologie MOSFET mount moviepy mysql náběhový proud napěťová ochrana nastavení šablony návod nel Network Error Logging NLP normalizace šedi po resize not Notifications NTFS nth-child oblasti oblékání ochrana okruhy přátel OpenVINO IR formát oprava oprava balíčku optočlen org.gnome.desktop.screensaver org.gnome.nm-applet ořezové masky OSHB otázky otázky_jazyky otázky_moralismu_řešení ovladače panely parsování path pdf personifikace photorec php php 4 php 5 php 6 php 7 php 8 phpbb phpBB3 PipeWire pitch PN přechody pnp pole Policykit postscript práva profilování program prune průraz přeinstalování přepěťová ochrana přepolování příkazy připojení k síti připojení k wifi pseudokódd pstoedit PulseAudio PWM regulátory pydub python python3 pytorch ramdisk RBE RDSon read reaktance rectifier regulace vstupního napětí reinstall relyability remount replace restore reverzní geolokace RIGHT JOIN rm role rozvržení disků pro OS linux a data databází řešení samba scan scroll sdílení sdílení souborů Sec-Fetch-Dest Sec-Fetch-Mode Sec-Fetch-Site Sec-Fetch-User Secure Shell sed Set Cookie show-manual-login show-remote-login shunt schemas schémata schottka skript skupiny sloupce služby small song sort soubory soundfile spínané zdroje spínání splines split správa diskových zařízení SQL ssh stabilizace napětí stahování stíny stream string strojové učení stropové učení supplicant svg syntax systemctl systemd-logind T5 tabulka tabulky Tangentové úsečky tar témata tepelná ztráta terminologie test text-shadow themes thermal runaway time timestamp tkinter tr transistor transition tranzistor tranzistory tuple tvorba otázek TVS ubuntu účiník udiskd udisks unconfined underrun unity-greeter update usermod uživatelé va charakteristika vala vektorová grafika Vgs video Vth vynechání adresářů vývoj while wpa wpa_supplicant wrapovací funkce x xandr xapp-watt xargs -I xed xed-common xfdesktop xml XOR Xorg Xorg Thumbnails xrandr závislosti zdánlivý výkon zdroj zenerka zenerovo napětí zip zip archiv zkratky zpomalení zpracování textu zrychlení Žalmy