Imagium visual testing frequently asked questions.

Yes. Imagium can be incorporated into DevOps and CI/CD workflows through its REST APIs or command-line execution. This allows visual validations to run automatically as part of a build, deployment, or regression-test pipeline. Common examples include Jenkins and CircleCI, and the same approach can be used with other CI/CD platforms that can send HTTP requests or run scripts.

Imagium receives screenshot content as a Base64-encoded image in its API payload. A standard image format can therefore be used as long as your test code can convert it to Base64 before submission. For predictable results, use common lossless screenshot formats such as PNG whenever possible.

Imagium is language-agnostic. Any programming or scripting language that can send an HTTP POST request or invoke a shell or batch command can integrate with it. Common choices include Java, C#, Python, JavaScript, TypeScript, PowerShell, and VBScript.

Imagium can work with automation tools that can capture screenshots and send HTTP requests or invoke a command-line utility. Examples include Selenium, Appium, Playwright, Cypress, UFT, WebdriverIO, Katalon Studio, Coded UI, and other API-capable testing frameworks.

Imagium is an AI-powered visual testing and review platform used to detect meaningful visual changes in web applications, mobile applications, PDF documents, and standalone images. It compares a current screenshot with an approved baseline, highlights visual differences, supports dynamic-region exclusions, and integrates through REST APIs with tools such as Selenium, Appium, Playwright, Cypress, and Jenkins.

Default mode uses Imagium's proprietary visual-comparison algorithms to focus on meaningful visual changes rather than treating every raw pixel variation as a defect. It is designed to reduce noise and false positives while still detecting small, human-visible UI changes.

Strict mode performs a pixel-by-pixel comparison. It is useful when exact rendering is required, but it can also surface minor anti-aliasing, font-rendering, or environmental differences. For pages with frequent harmless pixel changes, Default mode is generally the more practical choice.

Hide the page overflow immediately before taking the screenshot. For a simple page, the browser-side JavaScript is:

In Selenium with C#, execute the same statement through IJavaScriptExecutor after the page has loaded and before the screenshot is captured:

The best method depends on the browser and Selenium version. You can use browser-native screenshot capabilities where available or a library such as AShot or Shutterbug to stitch the full page. Sticky headers, animations, lazy-loaded content, and changing viewport sizes should be stabilized before the image is captured.

Dynamic areas—such as dates, advertisements, rotating banners, cursors, timestamps, or personalized content—can be excluded from validation. Exclusion regions can be configured from the Imagium interface and, where supported by the workflow, supplied through the API at runtime.

You can export visual-validation results from the Imagium home page as a PDF and share the report with stakeholders who do not have an Imagium account. This provides a portable record of the failed steps, screenshots, and highlighted differences for review or defect triage.

Yes. Imagium can compare PDF content by rendering the pages as images and validating the visual output. This is useful for generated statements, invoices, reports, forms, and other documents where layout and presentation are important.

Only minimal coding is required for standard use. Most administration, baseline review, exclusion, reporting, and result-analysis activities are performed through the interface. Basic development or test-automation knowledge is useful when connecting a framework, capturing screenshots, and calling the Imagium APIs.

Images with different dimensions are treated as different visual outputs and will fail comparison. For reliable results, keep the browser viewport, device profile, display scale, zoom level, and screenshot method consistent between the baseline and current execution.

Yes, provided the images are converted to a supported Base64 representation before they are submitted through the API. For the most stable comparison, use the same source format and encoding settings for both the baseline and subsequent test runs.

Yes. Imagium offers a SaaS option as well as an on-premises deployment. SaaS provides a managed environment, while the on-premises option is suitable for organizations that need the application and test data to remain within their own infrastructure and firewall.

The published setup guidance calls for a Windows machine, IIS, the Imagium setup package, .NET Framework 4.7 or later, and approximately 16 GB of memory as a recommended minimum. Actual capacity should be sized according to the number of users, execution volume, image sizes, retention period, and concurrency requirements.

Yes. Your test automation can run from a Mac as long as it can capture the required screenshots and communicate with the Imagium endpoint through the REST API or supported command-line integration.

Storage depends on the deployment model. With an on-premises installation, Imagium data remains on infrastructure controlled by your organization. With the SaaS offering, data is handled within the managed Imagium environment according to the applicable service and security terms.

Yes. Tests can be executed from Windows workstations or servers using a compatible automation framework, REST API calls, or command-line integration. Keep the test environment and screenshot settings stable to produce repeatable visual results.

The published on-premises setup is designed for Windows and IIS, so the server component is not installed directly on macOS. A Mac can still access the Imagium web interface and run test automation against an Imagium SaaS or Windows-hosted on-premises environment.

Yes. The on-premises edition can be deployed on a supported Windows machine or Windows Server through IIS. Review the setup guide for prerequisites, application-pool settings, folder permissions, and deployment steps before installing it in a production environment.

The one-way key is tied to a specific Imagium installation and is used during license activation. It is represented using a SHA-256 one-way hash, which is designed to prevent the original source value from being reconstructed from the hash. Share it only through an approved business channel and only with the authorized Imagium licensing team.

For an on-premises deployment, Imagium is designed so that application data and images remain within infrastructure controlled by your organization. For the SaaS offering, data is processed and stored in the managed service environment. Organizations should review the relevant service terms, security controls, and data-residency requirements before selecting a deployment model.