{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/design-camera-coverage-from-dori-operational-task/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
        "slug": "design-camera-coverage-from-dori-operational-task",
        "url": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/design-camera-coverage-from-dori-operational-task/"
        },
        "title": "Design camera coverage from the task—not the megapixel count",
        "summary": "Detection, observation, recognition, and identification require different image detail. Define the task and target distance first, use pixel density as a planning aid, then prove the recorded result in the real scene.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "physical-security",
            "label": "Physical security",
            "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "video-surveillance",
                "name": "Video Surveillance",
                "url": "https://update.dsesecurity.com/topic/video-surveillance/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-11T09:45:00+00:00",
        "modified_at": "2026-08-11T14:12:11+00:00",
        "reviewed_on": "2026-08-11",
        "reading_minutes": 3,
        "word_count": 646,
        "potentially_affected": "Fixed, panoramic, multisensor, and PTZ surveillance cameras; lenses; VMS recording profiles; operator displays; sites planning new coverage or changing layouts.",
        "dse_recommendation": "Assign an operational requirement and test point to every important view, validate pixel density at the target plane, and accept the camera only after recorded images work under representative lighting, motion, compression, and display conditions.",
        "primary_source": {
            "name": "Axis Communications: Pixel density and DORI—Meeting operational requirements in network video",
            "url": "https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf",
            "published_on": "2023-05-01",
            "authority": "Axis Communications"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<h2>Source facts: DORI is a planning model, not a result</h2>\n<p>Axis Communications’ <a href=\"https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Pixel density and DORI</a> white paper describes four common operational requirements for video interpreted by people: detection, observation, recognition, and identification. In the paper, detection means determining whether a person is present; observation adds characteristic detail; recognition supports deciding whether someone is the same person seen before; and identification requires enough information to identify the person.</p>\n<p>The paper relates those tasks to a pixel-density model derived from IEC 62676-4. Its planning values are 25 pixels per meter for detection, 63 px/m for observation, 125 px/m for recognition, and 250 px/m for identification. The same paper warns that this is a simplified model. Lighting direction, optics, compression, distance, pose, scene geometry, and the resolution of the display used by an operator can change the practical result. The values apply to visual images interpreted by people; analytics and thermal imaging need their own performance definitions.</p>\n<p>Pixel density also changes across a scene. A person farther from the lens occupies fewer pixels than one near it, while a wide overview spreads the sensor’s pixels across more space. A high sensor resolution therefore does not automatically create identification coverage everywhere in the image. The source describes planning and validation tools, including site design, lens calculation, and an on-camera pixel counter, but none replaces a real-scene acceptance test.</p>\n\n<h2>DSE recommendation: turn each view into a testable requirement</h2>\n<p>Start with the decision the video must support, not a camera model. Mark the exact line, doorway, counter, lane, or area where the task matters and assign one intended result: detect, observe, recognize, or identify. Record the expected target direction, distance band, lighting, movement, and viewing method. A parking-lot overview and an identification view at an employee entrance are different requirements even when one camera can see both.</p>\n<ol>\n<li><strong>Map the target plane.</strong> Put the required coverage line on a drawing or reference image. Measure the near and far distances and identify obstructions, seasonal foliage, door swing, merchandise, parked vehicles, and future layout changes.</li>\n<li><strong>Calculate before installation.</strong> Use the intended camera, lens, aspect ratio, and stream resolution to estimate pixel density at the target. Preserve the calculation or design export with the project record. Treat it as a design assumption, not acceptance evidence.</li>\n<li><strong>Protect the recording path.</strong> Confirm that the VMS records the resolution, crop, frame rate, and compression profile used in the calculation. A high-quality live view does not prove that recorded playback or export preserves the same detail.</li>\n<li><strong>Test people and objects at the marked points.</strong> Use authorized test participants and representative clothing, movement, direction, and speed. Test the center and edges of the image, not only the easiest position.</li>\n<li><strong>Exercise difficult conditions.</strong> Repeat at daylight, darkness, backlight, artificial-light transitions, and other conditions material to the site. Review motion blur, noise, focus, reflections, headwear, and the effect of compression during scene activity.</li>\n<li><strong>Review on the real workstation.</strong> Have the intended operator retrieve and display recorded footage through the normal client, monitor, network path, and export workflow. Document whether the assigned task was achieved without relying on digital zoom to manufacture missing detail.</li>\n</ol>\n<p>When one view must provide both overview and identification, make both requirements explicit. The answer may be a narrower lens, a second camera, a multidirectional device, or a dedicated identification view. Do not silently downgrade the requirement because a broad field of view looks impressive on a wall monitor.</p>\n<p>Keep an acceptance image for every critical test point, along with camera model, lens position, stream settings, date, lighting condition, result, exception, and approver. Revalidate after a camera is moved, refocused, replaced, re-encoded, or obstructed, and after a material change to the scene. The durable outcome is not “eight megapixels installed”; it is a recorded image that performs the defined job at the defined place.</p>\n\n<h2>Official reference</h2>\n<ul><li>Axis Communications, <a href=\"https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf\" target=\"_blank\" rel=\"noopener noreferrer\"><em>Pixel density and DORI: Meeting operational requirements in network video</em></a>, May 2023.</li></ul>",
        "content_text": "Source facts: DORI is a planning model, not a result\nAxis Communications’ Pixel density and DORI white paper describes four common operational requirements for video interpreted by people: detection, observation, recognition, and identification. In the paper, detection means determining whether a person is present; observation adds characteristic detail; recognition supports deciding whether someone is the same person seen before; and identification requires enough information to identify the person.\nThe paper relates those tasks to a pixel-density model derived from IEC 62676-4. Its planning values are 25 pixels per meter for detection, 63 px/m for observation, 125 px/m for recognition, and 250 px/m for identification. The same paper warns that this is a simplified model. Lighting direction, optics, compression, distance, pose, scene geometry, and the resolution of the display used by an operator can change the practical result. The values apply to visual images interpreted by people; analytics and thermal imaging need their own performance definitions.\nPixel density also changes across a scene. A person farther from the lens occupies fewer pixels than one near it, while a wide overview spreads the sensor’s pixels across more space. A high sensor resolution therefore does not automatically create identification coverage everywhere in the image. The source describes planning and validation tools, including site design, lens calculation, and an on-camera pixel counter, but none replaces a real-scene acceptance test.\n\nDSE recommendation: turn each view into a testable requirement\nStart with the decision the video must support, not a camera model. Mark the exact line, doorway, counter, lane, or area where the task matters and assign one intended result: detect, observe, recognize, or identify. Record the expected target direction, distance band, lighting, movement, and viewing method. A parking-lot overview and an identification view at an employee entrance are different requirements even when one camera can see both.\n\nMap the target plane. Put the required coverage line on a drawing or reference image. Measure the near and far distances and identify obstructions, seasonal foliage, door swing, merchandise, parked vehicles, and future layout changes.\nCalculate before installation. Use the intended camera, lens, aspect ratio, and stream resolution to estimate pixel density at the target. Preserve the calculation or design export with the project record. Treat it as a design assumption, not acceptance evidence.\nProtect the recording path. Confirm that the VMS records the resolution, crop, frame rate, and compression profile used in the calculation. A high-quality live view does not prove that recorded playback or export preserves the same detail.\nTest people and objects at the marked points. Use authorized test participants and representative clothing, movement, direction, and speed. Test the center and edges of the image, not only the easiest position.\nExercise difficult conditions. Repeat at daylight, darkness, backlight, artificial-light transitions, and other conditions material to the site. Review motion blur, noise, focus, reflections, headwear, and the effect of compression during scene activity.\nReview on the real workstation. Have the intended operator retrieve and display recorded footage through the normal client, monitor, network path, and export workflow. Document whether the assigned task was achieved without relying on digital zoom to manufacture missing detail.\n\nWhen one view must provide both overview and identification, make both requirements explicit. The answer may be a narrower lens, a second camera, a multidirectional device, or a dedicated identification view. Do not silently downgrade the requirement because a broad field of view looks impressive on a wall monitor.\nKeep an acceptance image for every critical test point, along with camera model, lens position, stream settings, date, lighting condition, result, exception, and approver. Revalidate after a camera is moved, refocused, replaced, re-encoded, or obstructed, and after a material change to the scene. The durable outcome is not “eight megapixels installed”; it is a recorded image that performs the defined job at the defined place.\n\nOfficial reference\nAxis Communications, Pixel density and DORI: Meeting operational requirements in network video, May 2023.",
        "content_markdown": "## Source facts: DORI is a planning model, not a result\n\nAxis Communications’ [Pixel density and DORI](https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf) white paper describes four common operational requirements for video interpreted by people: detection, observation, recognition, and identification. In the paper, detection means determining whether a person is present; observation adds characteristic detail; recognition supports deciding whether someone is the same person seen before; and identification requires enough information to identify the person.\n\nThe paper relates those tasks to a pixel-density model derived from IEC 62676-4. Its planning values are 25 pixels per meter for detection, 63 px/m for observation, 125 px/m for recognition, and 250 px/m for identification. The same paper warns that this is a simplified model. Lighting direction, optics, compression, distance, pose, scene geometry, and the resolution of the display used by an operator can change the practical result. The values apply to visual images interpreted by people; analytics and thermal imaging need their own performance definitions.\n\nPixel density also changes across a scene. A person farther from the lens occupies fewer pixels than one near it, while a wide overview spreads the sensor’s pixels across more space. A high sensor resolution therefore does not automatically create identification coverage everywhere in the image. The source describes planning and validation tools, including site design, lens calculation, and an on-camera pixel counter, but none replaces a real-scene acceptance test.\n\n## DSE recommendation: turn each view into a testable requirement\n\nStart with the decision the video must support, not a camera model. Mark the exact line, doorway, counter, lane, or area where the task matters and assign one intended result: detect, observe, recognize, or identify. Record the expected target direction, distance band, lighting, movement, and viewing method. A parking-lot overview and an identification view at an employee entrance are different requirements even when one camera can see both.\n\n- Map the target plane. Put the required coverage line on a drawing or reference image. Measure the near and far distances and identify obstructions, seasonal foliage, door swing, merchandise, parked vehicles, and future layout changes.\n\n- Calculate before installation. Use the intended camera, lens, aspect ratio, and stream resolution to estimate pixel density at the target. Preserve the calculation or design export with the project record. Treat it as a design assumption, not acceptance evidence.\n\n- Protect the recording path. Confirm that the VMS records the resolution, crop, frame rate, and compression profile used in the calculation. A high-quality live view does not prove that recorded playback or export preserves the same detail.\n\n- Test people and objects at the marked points. Use authorized test participants and representative clothing, movement, direction, and speed. Test the center and edges of the image, not only the easiest position.\n\n- Exercise difficult conditions. Repeat at daylight, darkness, backlight, artificial-light transitions, and other conditions material to the site. Review motion blur, noise, focus, reflections, headwear, and the effect of compression during scene activity.\n\n- Review on the real workstation. Have the intended operator retrieve and display recorded footage through the normal client, monitor, network path, and export workflow. Document whether the assigned task was achieved without relying on digital zoom to manufacture missing detail.\n\nWhen one view must provide both overview and identification, make both requirements explicit. The answer may be a narrower lens, a second camera, a multidirectional device, or a dedicated identification view. Do not silently downgrade the requirement because a broad field of view looks impressive on a wall monitor.\n\nKeep an acceptance image for every critical test point, along with camera model, lens position, stream settings, date, lighting condition, result, exception, and approver. Revalidate after a camera is moved, refocused, replaced, re-encoded, or obstructed, and after a material change to the scene. The durable outcome is not “eight megapixels installed”; it is a recorded image that performs the defined job at the defined place.\n\n## Official reference\n\n- Axis Communications, [Pixel density and DORI: Meeting operational requirements in network video](https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf), May 2023."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
                "url": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-11"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Design camera coverage from the task—not the megapixel count",
                        "item": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/#article",
                "identifier": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
                "url": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/",
                "headline": "Design camera coverage from the task—not the megapixel count",
                "description": "Detection, observation, recognition, and identification require different image detail. Define the task and target distance first, use pixel density as…",
                "abstract": "Detection, observation, recognition, and identification require different image detail. Define the task and target distance first, use pixel density as a planning aid, then prove the recorded result in the real scene.",
                "articleBody": "Source facts: DORI is a planning model, not a result\nAxis Communications’ Pixel density and DORI white paper describes four common operational requirements for video interpreted by people: detection, observation, recognition, and identification. In the paper, detection means determining whether a person is present; observation adds characteristic detail; recognition supports deciding whether someone is the same person seen before; and identification requires enough information to identify the person.\nThe paper relates those tasks to a pixel-density model derived from IEC 62676-4. Its planning values are 25 pixels per meter for detection, 63 px/m for observation, 125 px/m for recognition, and 250 px/m for identification. The same paper warns that this is a simplified model. Lighting direction, optics, compression, distance, pose, scene geometry, and the resolution of the display used by an operator can change the practical result. The values apply to visual images interpreted by people; analytics and thermal imaging need their own performance definitions.\nPixel density also changes across a scene. A person farther from the lens occupies fewer pixels than one near it, while a wide overview spreads the sensor’s pixels across more space. A high sensor resolution therefore does not automatically create identification coverage everywhere in the image. The source describes planning and validation tools, including site design, lens calculation, and an on-camera pixel counter, but none replaces a real-scene acceptance test.\n\nDSE recommendation: turn each view into a testable requirement\nStart with the decision the video must support, not a camera model. Mark the exact line, doorway, counter, lane, or area where the task matters and assign one intended result: detect, observe, recognize, or identify. Record the expected target direction, distance band, lighting, movement, and viewing method. A parking-lot overview and an identification view at an employee entrance are different requirements even when one camera can see both.\n\nMap the target plane. Put the required coverage line on a drawing or reference image. Measure the near and far distances and identify obstructions, seasonal foliage, door swing, merchandise, parked vehicles, and future layout changes.\nCalculate before installation. Use the intended camera, lens, aspect ratio, and stream resolution to estimate pixel density at the target. Preserve the calculation or design export with the project record. Treat it as a design assumption, not acceptance evidence.\nProtect the recording path. Confirm that the VMS records the resolution, crop, frame rate, and compression profile used in the calculation. A high-quality live view does not prove that recorded playback or export preserves the same detail.\nTest people and objects at the marked points. Use authorized test participants and representative clothing, movement, direction, and speed. Test the center and edges of the image, not only the easiest position.\nExercise difficult conditions. Repeat at daylight, darkness, backlight, artificial-light transitions, and other conditions material to the site. Review motion blur, noise, focus, reflections, headwear, and the effect of compression during scene activity.\nReview on the real workstation. Have the intended operator retrieve and display recorded footage through the normal client, monitor, network path, and export workflow. Document whether the assigned task was achieved without relying on digital zoom to manufacture missing detail.\n\nWhen one view must provide both overview and identification, make both requirements explicit. The answer may be a narrower lens, a second camera, a multidirectional device, or a dedicated identification view. Do not silently downgrade the requirement because a broad field of view looks impressive on a wall monitor.\nKeep an acceptance image for every critical test point, along with camera model, lens position, stream settings, date, lighting condition, result, exception, and approver. Revalidate after a camera is moved, refocused, replaced, re-encoded, or obstructed, and after a material change to the scene. The durable outcome is not “eight megapixels installed”; it is a recorded image that performs the defined job at the defined place.\n\nOfficial reference\nAxis Communications, Pixel density and DORI: Meeting operational requirements in network video, May 2023.",
                "datePublished": "2026-08-11T09:45:00+00:00",
                "dateModified": "2026-08-11T14:12:11+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Design camera coverage from the task—not the megapixel count"
                },
                "articleSection": [
                    "Video Surveillance"
                ],
                "keywords": [
                    "Video Surveillance",
                    "Guide",
                    "Advisory priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Video Surveillance",
                        "url": "https://update.dsesecurity.com/topic/video-surveillance/"
                    }
                ],
                "wordCount": 646,
                "timeRequired": "PT3M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "Axis Communications: Pixel density and DORI—Meeting operational requirements in network video",
                    "url": "https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf",
                    "datePublished": "2023-05-01"
                }
            }
        ]
    }
}