Skip to content

feat(LAB-4612): support polygon annotations in PDF projects - #2065

Open
RuellePaul wants to merge 1 commit into
mainfrom
feature/lab-4612-pdf-projects-support-polygon-annotation-type
Open

feat(LAB-4612): support polygon annotations in PDF projects#2065
RuellePaul wants to merge 1 commit into
mainfrom
feature/lab-4612-pdf-projects-support-polygon-annotation-type

Conversation

@RuellePaul

Copy link
Copy Markdown
Contributor

Make a PDF polygon label round-trip through the SDK: parse without raising, expose the same attributes as a PDF bounding box, and export to pixel coordinates, without changing what today's PDF bbox exports produce.

Two defects already live in the field are fixed on the way, since polygon would inherit both:

  • PDF object detection labels raised AttributeNotCompatibleWithJobError on .annotations, .polys and .page_number_array, because the page-level geometry only existed on EntityInPdfAnnotation, whose compatible mlTask is NAMED_ENTITIES_RECOGNITION. The property bodies move to a _BasePdfAnnotation mixin, and a new PdfObjectDetectionAnnotation registers them for object detection jobs. They are guarded on inputType so an image polygon keeps rejecting .polys.
  • A "type" key on the inner page-level annotation crashed BoundingPoly.normalized_vertices, which used the presence of type_of_tool as its proxy for "vertices are flat" even though PDF nests them. The nesting is now inferred from the data, and the vertex count is checked per ring.

PDF labels only carry a "type" key when the tool is not the rectangle, so the type property reads its absence as "rectangle" rather than raising. The inference never reaches an export: serialization reads the raw json data, which the property does not write to.

Reading the nested layer no longer corrupts the label either. It cast the inner boundingPoly in place on every access while as_dict() returned the raw list, so to_dict() broke once .annotations had been read. The list is now cast once and un-cast on serialization, the same way job_response.py already does it.

Claude-Session: https://claude.ai/code/session_016dcoQidK7T4JZd7MyCuoNQ

Make a PDF polygon label round-trip through the SDK: parse without raising,
expose the same attributes as a PDF bounding box, and export to pixel
coordinates, without changing what today's PDF bbox exports produce.

Two defects already live in the field are fixed on the way, since polygon
would inherit both:

- PDF object detection labels raised AttributeNotCompatibleWithJobError on
  .annotations, .polys and .page_number_array, because the page-level
  geometry only existed on EntityInPdfAnnotation, whose compatible mlTask is
  NAMED_ENTITIES_RECOGNITION. The property bodies move to a _BasePdfAnnotation
  mixin, and a new PdfObjectDetectionAnnotation registers them for object
  detection jobs. They are guarded on inputType so an image polygon keeps
  rejecting .polys.
- A "type" key on the inner page-level annotation crashed
  BoundingPoly.normalized_vertices, which used the presence of type_of_tool as
  its proxy for "vertices are flat" even though PDF nests them. The nesting is
  now inferred from the data, and the vertex count is checked per ring.

PDF labels only carry a "type" key when the tool is not the rectangle, so the
type property reads its absence as "rectangle" rather than raising. The
inference never reaches an export: serialization reads the raw json data, which
the property does not write to.

Reading the nested layer no longer corrupts the label either. It cast the inner
boundingPoly in place on every access while as_dict() returned the raw list, so
to_dict() broke once .annotations had been read. The list is now cast once and
un-cast on serialization, the same way job_response.py already does it.

Claude-Session: https://claude.ai/code/session_016dcoQidK7T4JZd7MyCuoNQ
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants