{"id":35605,"date":"2025-09-23T10:01:37","date_gmt":"2025-09-23T08:01:37","guid":{"rendered":"https:\/\/risc.web-email.at\/fachbeitraege\/anomaly-detection-in-industrial-image-data\/"},"modified":"2026-03-10T14:23:15","modified_gmt":"2026-03-10T13:23:15","slug":"anomaly-detection-in-industrial-image-data","status":"publish","type":"publication","link":"https:\/\/risc.web-email.at\/en\/technicalarticles\/anomaly-detection-in-industrial-image-data\/","title":{"rendered":"Anomaly detection in industrial image data"},"content":{"rendered":"\n

Why standard AI fails in production reality – and specialized approaches make the difference.<\/h2>\n\n

by Patrick Kraus-F\u00fcreder and Markus Steindl<\/h2>\n\n

AI enables new forms of automated quality assurance – with enormous potential, but also practical hurdles in terms of data availability, model architecture and system integration.<\/p>\n\n

<\/div>\n\n
\n

Contents<\/strong><\/p>\n\n\n\n

    \n
  • Between everyday life and industry: why generic AI fails<\/li>\n\n\n\n
  • Image anomalies: Visual conspicuousness vs. semantic error<\/li>\n\n\n\n
  • Supervised or unsupervised?<\/li>\n\n\n\n
  • Labeled data: The bottleneck of practice<\/li>\n\n\n\n
  • Variability as a reality – and a challenge<\/li>\n\n\n\n
  • Adaptivity as the key to the future<\/li>\n\n\n\n
  • Hardware requirements in live operation<\/li>\n\n\n\n
  • RISC as a solution partner: from model architecture to operational implementation<\/li>\n\n\n\n
  • Conclusion<\/li>\n\n\n\n
  • Six questions that companies should ask themselves before using anomaly detection<\/li>\n\n\n\n
  • Contact us<\/li>\n\n\n\n
  • Authors<\/li>\n\n\n\n
  • Read more<\/li>\n<\/ul>\n<\/div>
    \"\"<\/figure><\/div>\n
    \n
    \n

    Between everyday life and industry: why generic AI fails<\/h3>\n\n\n\n

    Most pre-trained computer vision models from the open source sector or from research institutions are based on image databases such as ImageNet, COCO or OpenImages. These contain millions of images, but almost exclusively from everyday contexts – such as cars, people, animals or pieces of furniture. Specific industrial scenarios, such as those that occur in manufacturing, are hardly represented in them, if at all, and can therefore only be depicted inadequately. This data is therefore only of limited use in industrial production. <\/p>\n\n\n\n

    As a result, a model that reliably distinguishes between cats and dogs often fails completely when it is supposed to assess the quality of a plug connection or detect fine cracks on a highly reflective metal surface. The visual features that define industrial anomalies are simply different – often more subtle, specific and context-dependent. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Figure 1: Examples of industrial anomalies on metallic fasteners (drive-in nuts). Left: Original images, right: marked damaged areas. Such subtle, context-dependent defects cannot be adequately captured by generically pre-trained AI models. <\/p>\n<\/div>\n<\/div>

    \n
    \n

    Image anomalies: Visual conspicuousness vs. semantic error<\/h3>\n\n\n\n

    Anomalies in industrial image data are not only rare – they also take many forms. They can be roughly divided into two classes: <\/p>\n\n\n\n

      \n
    • Structural anomalies<\/strong>: These are local, usually texture- or pixel-based deviations that are “new” in their characteristic patterns compared to the training data. Typical examples are scratches, dents, cracks or soiling on surfaces. Detection is carried out, for example, by comparing sections or feature memory networks that mark unknown textures or shapes as anomalous. <\/li>\n\n\n\n
    • Logical anomalies<\/strong>: These anomalies violate the semantic or spatial rules that were learned from correct images without individual objects being technically defective. Examples are missing or additional components, incorrect placement, incorrect arrangement or deviating number of expected components. Their detection requires an understanding of global object relationships and counters, for example through autoencoders or hybrid models that check both local and logical constraints. <\/li>\n<\/ul>\n\n\n\n

      A robust anomaly detection system must be able to deal with both types of error – and must not rely on rigid reference images or simple differences. It needs contextual knowledge and the ability to interpret “meaning”, not just “deviation”. <\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Figure 2: Example of different classes of industrial anomalies. (a) Structural anomaly: the wire is damaged or broken. (b) Logical anomaly: instead of a single wire, there are two faultlessly laid wires. While the former is visible locally, the latter violates the semantic expectation of the correct component configuration. <\/p>\n<\/div>\n<\/div>

      \n
      \n

      Supervised or unsupervised?<\/h3>\n\n\n\n

      A common assumption: in order to reliably detect anomalies, a model needs as many fault examples as possible. In industrial reality, however, the opposite is the case: errors should occur as rarely as possible – ideally not at all. And this is precisely why they are usually almost completely absent from the available data sets. <\/p>\n\n\n\n

      This is a significant problem for classic supervised procedures. Without sufficient fault examples, they cannot draw any meaningful dividing lines between good and bad. Instead, modern industrial applications rely on unsupervised or one-class learning methods<\/strong> in which only good images are used for training. The model learns the characteristics of “normality” – and recognizes anything that deviates significantly from this as potentially anomalous. <\/p>\n\n\n\n

      Although these procedures do not require explicit error data, they do have other requirements: The definition of what is considered “normal” must be clear and consistent. In addition, typical production-related deviations – such as slight changes in position, surface variations or different exposures – must be sufficiently represented<\/strong> in the training data set so that the system does not incorrectly interpret them as defects. <\/p>\n\n\n\n

      Only if the real variance of everyday production is represented in the “normal picture” can the system act robustly in the face of real fluctuations.<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Figure 3: A complete annotation of all potential production errors is hardly possible in practice. Instead, the “normal” can be learned unsupervised and deviations can then be recognized as potential anomalies. <\/p>\n<\/div>\n<\/div>

      \n
      \n

      Labeled data: The bottleneck of practice<\/h3>\n\n\n\n

      Even if error images were available, their annotation is expensive and time-consuming. Their targeted generation is often impractical: production lines have to be stopped, errors deliberately provoked and then rectified manually – a time-consuming and expensive process that is rarely justified. <\/p>\n\n\n\n

      In addition, even in very large production data sets, real errors have often simply not yet occurred.<\/strong> This is not a verification problem, but a desirable state – after all, industrial quality assurance aims to avoid errors at an early stage. For the training of a model, however, this means that there are no concrete examples of anomalies that must nevertheless be detected in the future.<\/strong> This means that the existing labeled defect data – if available – is often incomplete and not representative of the entire range of potential deviations. <\/p>\n\n\n\n

      Unsupervised methods<\/strong> offer a viable approach here: they do not require explicit fault images, but learn exclusively from fault-free examples. In many industrial scenarios, they are therefore the only realistic option<\/strong> – provided that the quality and consistency of the good images is high and the model architecture allows a distinction to be made between tolerable variance and genuine anomalies. <\/p>\n<\/div>\n<\/div>

      \n
      \n

      Variability as a reality – and a challenge<\/h3>\n\n\n\n

      Industrial image data is rarely homogeneous. Even with consistent processes, they are subject to natural variance – due to: <\/p>\n\n\n\n

        \n
      • Variable-position components<\/strong> such as connection cables, hydraulic lines or hoses<\/li>\n\n\n\n
      • Changing lighting conditions<\/strong> due to ambient light, machine shadows or seasonal influences<\/li>\n\n\n\n
      • Scattering on surfaces<\/strong> due to manufacturing tolerances, contamination or assembly marks<\/li>\n<\/ul>\n\n\n\n

        These factors mean that two “correct” images often differ significantly from each other – even though both are error-free. A system that is too sensitive constantly reports false alarms. A system that is too coarse overlooks real problems. The fine line between sensitivity and robustness is the central challenge of industrial anomaly detection. <\/p>\n\n\n\n

        It becomes particularly critical with high-resolution images<\/strong>: As potential anomalies can occur anywhere, many methods work on 256\u00d7256 pixel sections. To examine a detailed image of 2048\u00d72048 px, for example, hundreds of these sections are required.<\/p>\n\n\n\n

        The problem is that each section is a separate “test”. And the more tests are carried out, the higher the probability of false-positive results – even with good individual performance. This statistical accumulation problem<\/strong> is an often underestimated source of errors and frustration in practice. <\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        Figure 4: Patch-based anomaly detection requires extremely reliable detection of individual errors. With 500 patches per image, the misclassification rate per patch must not exceed 1 in 10,000 in order not to exceed a false positive rate of 5% per image. <\/p>\n<\/div>\n<\/div>

        \n
        \n

        Adaptivity as the key to the future<\/h3>\n\n\n\n

        Even a well-trained, finely tuned system loses its effectiveness when reality changes. New suppliers, modified components, updates to the product design – they all change the visual appearance of the normal state. <\/p>\n\n\n\n

        A system that cannot react to this will either report everything as an error – or nothing at all. Modern anomaly detection must therefore be adaptive and capable of learning<\/strong>. The aim is to integrate new “normal states” with a small amount of sample data without having to completely retrain the model. Methods from the field of few-shot learning<\/em> or continuous learning<\/em> are becoming increasingly relevant here. <\/p>\n<\/div>\n<\/div>

        \n
        \n

        Hardware requirements in live operation<\/h3>\n\n\n\n

        One aspect that is often underestimated is the technical requirements<\/strong> of an anomaly detection system in live operation.<\/p>\n\n\n\n

        Although many modern computer vision models are considered comparatively efficient in inference, in practice specialized hardware resources<\/strong> are required to work reliably and in real time.<\/p>\n\n\n\n

          \n
        • Powerful CPUs<\/strong> are necessary for image pre-processing: cropping, color space conversion, contrast adjustment and other processing steps must be carried out for each image – often under time pressure and parallel to the running line.<\/li>\n\n\n\n
        • Graphics cards (GPUs)<\/strong> offer the decisive speed advantage in the actual image evaluation (i.e. the AI inference step) – especially with high-resolution images or complex models.<\/li>\n<\/ul>\n\n\n\n

          Whether the hardware is installed directly on the line (e.g. in an edge device) or operated centrally (e.g. with a camera connection to a computer server) depends on the scenario in question. The important thing is that these requirements should already be taken into account in the planning phase.<\/strong> <\/p>\n\n\n\n

          This is the only way to prevent a working prototype from failing later due to excessive response times or system overload.<\/p>\n<\/div>\n<\/div>

          \n
          \n

          RISC Software as a solution partner: From model architecture to operational implementation<\/h3>\n\n\n\n

          The implementation of industrial anomaly detection requires more than simply applying ready-made models. Each application scenario has its own requirements: different image qualities, product variants, cycle times or integration environments. Standard models often reach their limits here – whether in terms of robustness, scalability or dealing with variable reality. <\/p>\n\n\n\n

          RISC Software GmbH sees itself as a solution partner<\/strong> that does not shy away from this complexity: we analyze the specific use case, adapt existing model architectures in a targeted manner – and integrate them into functioning systems. From image acquisition to production-related decisions, we help companies not only to test AI-based quality control, but also to make<\/strong> it sustainable and productive<\/strong>. <\/p>\n<\/div>\n<\/div>

          \n
          \n

          Conclusion<\/h3>\n\n\n\n

          Anomaly detection is not a finished product, but a continuous process. Anyone who takes the reality of industrial image data seriously – with its variance, imbalance and permanent change – can use AI-based quality control sensibly and effectively. This requires suitable models, realistic expectations and an agile concept for operation and further development. <\/p>\n<\/div>\n<\/div>

          \n
          \n

          Six questions that companies should ask themselves before using anomaly detection<\/h2>\n\n\n
          \n \n \"Zeitpunkt\"\n 1<\/span>\n \"Zeitlinie\"\n

          Werden Bilder in gleichbleibender Qualit\u00e4t erzeugt?<\/strong>
          \nAnomalieerkennung lebt von Konsistenz. Unterschiede bei Kameraposition, Beleuchtung oder Hintergrund f\u00fchren schnell zu Fehlalarmen. Nur wenn die Bildaufnahme technisch stabil und wiederholbar ist, kann KI sinnvoll eingesetzt werden.<\/p>\n<\/div>\n <\/span>\n \n \"Zeitpunkt\"\n 2<\/span>\n \"Zeitlinie\"\n

          Gibt es genug Beispielbilder f\u00fcr den Normalzustand?<\/strong>
          \nAuch wenn keine Fehlerdaten vorhanden sind: Ein gutes Anomalieerkennungsmodell braucht viele Bilder von fehlerfreien Produkten. Je gr\u00f6\u00dfer und vielf\u00e4ltiger dieses Set, desto robuster kann das System sp\u00e4ter reagieren.<\/p>\n<\/div>\n <\/span>\n \n \"Zeitpunkt\"\n 3<\/span>\n \"Zeitlinie\"\n

          Sind bekannte Fehlerarten dokumentiert \u2013 auch mit Bildbeispielen?<\/strong>
          \nFehlerbilder m\u00f6gen beim Training teilweise nicht n\u00f6tig sein, sind aber essentiell bei der Bewertung des fertigen Systems. Nur wenn klar ist, welche Anomalien erkannt werden sollen, l\u00e4sst sich die Leistungsf\u00e4higkeit objektiv beurteilen.<\/p>\n<\/div>\n <\/span>\n \n \"Zeitpunkt\"\n 4<\/span>\n \"Zeitlinie\"\n

          Wie oft \u00e4ndern sich Bauteile, Lieferanten oder Produktvarianten?<\/strong>
          \nEin KI-System erkennt, was es kennt. Wenn sich das Aussehen von Bauteilen regelm\u00e4\u00dfig \u00e4ndert, braucht das System die F\u00e4higkeit zur schnellen Anpassung \u2013 und das Projekt muss so konzipiert sein, dass solche Anpassungen eingeplant sind.<\/p>\n<\/div>\n <\/span>\n \n \"Zeitpunkt\"\n 5<\/span>\n \"Zeitlinie\"\n

          Wer kann im Unternehmen beurteilen, ob ein gemeldeter Fehler tats\u00e4chlich einer ist?<\/strong>
          \nKein System ist perfekt. Es wird Grenzf\u00e4lle geben. Wichtig ist, dass intern eine Ansprechperson (z.\u202fB. aus der Qualit\u00e4tssicherung) definiert ist, die R\u00fcckmeldungen geben kann \u2013 damit das System laufend besser wird.<\/p>\n<\/div>\n <\/span>\n \n \"Zeitpunkt\"\n 6<\/span>\n \"Zeitlinie\"\n

          Gibt es geeignete Hardware f\u00fcr den Live-Betrieb?<\/strong>
          \nF\u00fcr Tests reicht oft der Laptop \u2013 f\u00fcr den produktiven Einsatz braucht es zuverl\u00e4ssige Bildverarbeitung in Echtzeit. Das erfordert leistungsf\u00e4hige CPU-Ressourcen und meist auch eine GPU \u2013 direkt an der Linie oder im Netzwerk.<\/p>\n<\/div>\n <\/span>\n <\/div>\n<\/div>\n<\/div>\n

          \n
          \n

          Contact us<\/h2>\n\n\n\n
          \n
          \n

          <\/p>

            <\/ul><\/div>\n
            \n
            \n<\/fieldset>\n
            \n\t
            \n\t\t

            \n\t\t

            \n\t
            \n\t\t

            \n\t\t

            \n\t
            \n\t\t