This is a story from the perspective of an image processing expert. I considered the strengths of each. Human Eye: I believe the most significant feature is its "adaptive" nature. It can spot small differences by staring intently, and it can also gather overarching information from fleeting moments. When something is hard to see, we instinctively squint, right? We also unconsciously use or ignore color information. Camera Eye: Specialized cameras surpass human capabilities for specific purposes. For example, even when the human eye tries hard to be "adaptive," its vision is limited in very dark conditions. However, images obtained through optical amplification can reveal objects in darker spaces than what humans can see (they become invisible if the light source is completely blocked). Specialized cameras can detect wavelengths that the human eye cannot perceive. This is similar in the world of sound. Infrared and ultraviolet light use wavelengths that exceed the range of "visible light" that humans can see, which changes the discussion further. The job of an image processing expert is to "realize" the processing of information obtained from these "eyes" in the "brain" part. *News is distributed through our company newsletter.

We develop and provide solutions through software and hardware, but it is not uncommon for misunderstandings to arise from our guidance on "acceleration using FPGA." The misconception is that any processing implemented in software can be "accelerated" by developing a dedicated board. In reality, the types of processing that can be accelerated using FPGA are limited. It is suitable for processes that can execute the same calculations in large quantities simultaneously. An example of this is convolution filters. Even if you perform addition and multiplication operations simultaneously, by equipping the necessary number of multiplication and addition circuits, you can obtain results in one clock cycle, regardless of the range. Additionally, for processes that allow "pipelining," in software, you would perform process A, then process B, and then return to process A. However, in hardware, when transitioning from process A to process B, you can perform process A simultaneously, which reduces the processing time of the faster operation. Even with a 5-stage pipeline, results can be obtained in the time of just one stage. By the way, when accessing large volumes of image data, GPUs with very wide data bus widths are also effective. *News is distributed through our company newsletter.

As engineers, we should look forward without looking back. I have been sharing this message, but this time I have intentionally chosen this title. Let me introduce the path I have walked. In school, I happened to join a research lab of a professor who was working part-time in "image processing." My first job after graduating and entering the workforce was the development of an "inspection device using a camera." The main CPU was a Motorola 6809. I also designed hardware circuits for the image processing section using the 74 series. The binary template matching board was the size of two 6U units. It was a given that I would write the software for the circuits I created myself. Initially, the camera used a vidicon tube, which later changed to CCD and CMOS. In the next phase, I upgraded to a 68020 CPU with UNIX as the OS, and I also designed the CPU board myself. For the specialized image processing section, I used AMD's bit-slice 2901. Thanks to this device, I learned the workings of microcontrollers. Coincidentally, I have continued to be involved in "image processing" from my new graduate days to the present. I believe that my experience in both hardware and software design is beneficial to my current work in "system design." *News is distributed through our company's newsletter.

Depending on the application, there are image processing tasks that cannot be "used" unless the operation time guarantee is strictly adhered to. I will introduce two additional types of "operation time guarantees." Example 1: Inspection Equipment Application If the processing is not completed within the manufacturing tact time of the production line, the next inspection target cannot be inspected. However, the delay time from when the image data is input until the result is produced does not need to be within the tact time. Delays up to the mechanism for rejecting the result are acceptable. By skillfully utilizing this "acceptable delay" and adhering to the principle of "fixed delay time guarantee," implementation costs can be reduced compared to Example 2. Example 2: Collision Avoidance It may be easier to explain with something called automatic braking. Since it is a collision avoidance brake, the faster the time from detection to the judgment of "stop," the better. However, to drop this into catalog specifications, it needs to be paired with braking performance, so an operation speed guarantee is required as "maximum delay." In this case, even if it incurs higher costs than Example 1, speed is prioritized. Since different performance is required for the same terms, understanding the requirements is crucial, as discussed in this column. *News is distributed through our company newsletter.

There is a fear that no one has tried cutting-edge technology. With the evolution of software, automatic updates have become common, but hardware has yet to achieve the ability to swap out components later. Designers sometimes choose to "hide" certain features as a result of various considerations, so I would like to introduce this. Registers set in LSI and FPGA are provided for external "configuration." This "configuration" can easily lead to the misunderstanding that "the more settings available, the better," and if there are many settings, it is necessary to understand the meaning of those settings and consider the order in which they are applied. Ideally, it would be best if there were "no configuration required" and the device would "start operating as soon as power is supplied," making it user-friendly. However, there are unexpected usage methods and environments that differ from what the designers anticipated. Therefore, it becomes necessary to expose the "configuration" to accommodate those situations. Having many options is not always good, and having too few can lack versatility, which is a dilemma. I have often been helped by this, but there have also been times when I was troubled by the lack of publicly available information. We also face such dilemmas when determining the specifications for the FPGAs we provide. *News is distributed through our company newsletter.

There are two types of opportunities for us to explain our work. 1. During business negotiations, introducing the company to first-time clients. 2. During recruitment, introducing the job responsibilities to applicants. The first type is relatively smooth since it occurs during business negotiations, which typically have fewer variations. The second type, during recruitment, requires us to gauge how to explain based on the background of the applicants. For example, some may be completely new to the image processing industry, while others may be unfamiliar with the business style of contract development. One of the challenges we face is that our company requires different skills for algorithm development, software development, and hardware development, which necessitates a common internal language of "C++." Explaining this can be difficult, and if we don't overcome this hurdle and help applicants understand the work, it can lead to dissatisfaction on both sides, with applicants thinking, "This is not the kind of job I expected." Therefore, we continue to invest time in ensuring a shared understanding of this aspect. *News is distributed through our company newsletter.

"Since it was outsourced, only the source code and circuit diagrams remain, and there is no specification document." Looking at this theme, I think many people can relate, so I wanted to share it. First of all, we also want to avoid getting involved in the above situation. I want to convey that. While it is possible to create a "pseudo specification document" by diligently stepping through the source code and circuit diagrams, we cannot trace back to understand "why that method was implemented." When we design ourselves, we create a specification document first, so when we are unsure about the means of implementation, we can refer back to the specification to understand "which method should be used for implementation." Of course, since it is the initial specification document, there are times when we realize "this specification is better" or "this specification has contradictions" while designing, and it is quite common to revise the specification document after completing the design (it is rare not to revise it). I believe it is smoother to think of it as something that cannot be reversed, like finding a dam when going upstream. *News is distributed through our company's newsletter.

This is not just about image processing, but I would like to provide some insights on variables (know-how) that may be helpful for software engineers working closely with hardware. Are you familiar with SoCFPGA? It is an FPGA with an embedded microcontroller. Currently, the mainstream offerings from the top two companies both include ARM. This ARM is referred to as a "hard core." On the other hand, for a long time, there has been a demand to embed small microcontrollers within FPGAs. To meet this demand, various manufacturers have developed mechanisms to incorporate freely configurable logic circuits within FPGAs. XILINX, for example, offers a soft core called MicroBlaze(TM). Hard cores and soft cores are used differently based on their applications. Here is an important point that may not be widely known: the char type variable in MicroBlaze is signed, while in ARM it is unsigned. You might be surprised, but as you know, whether a variable is signed or unsigned can lead to different results even with the same calculation. I wanted to highlight this point because if you attempt to port code without being aware of it, you may encounter difficulties. *News is distributed through our company newsletter.

I believe engineers will understand, but it's a very difficult title. To explain it simply, as it's a column, it refers to the act of "finding mistakes" in what we humans design. However, the reason it becomes complicated is that not everything is designed by a single person. For example, in the case of software, the operating system or computer that runs it is designed by someone else. In hardware, even if a device is used independently, the electronic components used in it are often not designed by the device designer. Until the cause of a malfunction is found, the focus is primarily on identifying mistakes in one's own design, but there are often cases where the issue lies outside of one's own design. Defining the boundaries of responsibility and separating these issues can be challenging, but there are many engineers in Japan who consider even the gray areas. I am confident that the act of "debugging" will not disappear until our column is no longer published. *News is distributed through our company's newsletter.

Taking computers as an example, the things created by humans continue to evolve year by year. Whether it's memory storage capacity, processing speed, or operating clock frequency. There was a time when it was said that the exposure width of semiconductors had hit a limit at the nanometer scale due to the constraints of light, but through various innovations, it continues to evolve. Clock frequencies were also said to be reaching a point where anything higher would turn into radio waves, but we have overcome that and further advancements in multiplexing technology are ongoing. On the other hand, what about the capacity of the human brain? I am not a neuroscientist, nor do I have any expertise in human biology, so I do not know the answer. Looking at myself, I find that thanks to mobile phones and smartphones, I no longer memorize phone numbers, and thanks to navigation systems, I no longer memorize maps. Is it possible that as generations change, our capacity is also increasing? I don't really notice improvements in human performance, so I don't seek to be "broad and deep." People who are "broad" and those who are "deep" are both needed separately, and we work daily to produce a single outcome through "team play." Unfortunately, this column will end without a clear conclusion. *News is distributed through our company's newsletter.

Our company's strength lies in being a development company specialized in image processing. We pride ourselves on developing everything in-house, from algorithm development to applications, firmware, device drivers, and hardware. Sometimes we are asked, "Which is more important, hardware engineers or software engineers?" or "Which is more difficult?" While I can convey the benefits of having both within the same company, I have never compared or chosen one over the other. Additionally, while things change with the times, I will intentionally write about it in this column. It is not about superiority or inferiority, but rather a comparison. Comparison Items Software Engineers Hardware Engineers 1) Learning Period 1 year 5-10 years 2) Required Number Many Few 3) Knowledge of Other Field Not required Essential 4) Development Tools Many options Few options 5) Expression Languages Many options Few options While comparisons can be made, it is not about superiority or hierarchy. Furthermore, comments on each item were significantly different 20 years ago. I would like to revisit this topic in 10 years. *News is distributed through our company's newsletter.

Officially, it is said to be Agile Software Development. Although it is a development method that is unrelated to our company, I have been calmly taught the merits of this method by clients who embrace it as part of their culture. I learned that it can yield results beyond expectations and that development can sometimes be completed in a short period, among many other advantages. This is not a message intended for those who are implementing this method as a "corporate culture." It is dangerous if it is misunderstood as simply "developing without specifications, through trial and error." There is a dangerous aura when specifications are only in one's head. This is not limited to image processing, and since our company utilizes multiple development patterns, I hope this theme serves as a trigger for investigating "development methods." *News is distributed through our company newsletter.

As an engineer, there are times when you are faced with the choice of "depth" or "breadth" in mastering technology. As an organization, a company also needs members who have a "shallow and broad" skill set. When it comes to wanting to "master" something, I believe that, except for a few geniuses, one must choose one or the other to avoid overwhelming their brain capacity. I think our engineers are faced with this choice around five years after joining the company, even for those who are quick to adapt. Choosing "depth" doesn't mean focusing on just one field. It can also involve mastering a second field, and sometimes the first field may suddenly be replaced by a different theory. The choice of programming languages and other tools is similar. Some engineers are adept at using various languages, while others may only use one language, yet for some reason, the programs they write run at high speed. Even though we refer to ourselves as a group of engineers, "ten people, ten colors" applies here. Our company motto, "One person, one skill," is also a reflection of this idea. *News is distributed through our company newsletter.

In image processing, there are various different purposes for the "users" who will utilize it, so I would like to introduce some examples. For instance, in the case of a section developing certain materials, it involves inspections for those developing "flame-retardant materials" using various substances. This is a combustion test that measures how much the material burned and self-extinguished during combustion experiments. For this application, it is important for the user to measure the same object with a measuring tool and obtain the same values. As an example of a different application, I will introduce "mass production inspection." For instance, let's take the mass production inspection of display devices. In terms of inspection equipment, all defects are detected, but in the case of "mass production inspection," there are specifications for "mass production quality." For example, even if there are defective pixels, if they are within the smallest unit, up to five can be considered good products. If the size exceeds the specifications, even one defect is considered unacceptable. This is the kind of regulation in place. In this case, image processing detects even the smallest defects, but the judgment is made at a slightly higher level to determine pass or fail. I have introduced two extreme examples, but even under the umbrella of "image inspection," the content developed varies depending on the application. *News is distributed through our company newsletter.

Those who work in FPGA circuit design are likely troubled by the "logic synthesis time" of various tools from different companies. This theme has persisted since the era when the concept of FPGA first emerged. It was not an issue during the PAL and GAL era, but it was a consideration in contemporary ASIC design. While the performance of CPUs in personal computers has dramatically improved, the logic synthesis time for FPGAs still takes an excessive amount of time. In a simulation environment, we create a "test bench," but using features that allow us to view the internal signal states during debugging on the actual chip (such as chip scopes or signal taps) further extends the logic synthesis time. This topic is often difficult for software engineers to understand. Fortunately, our company operates with a small team, and since hardware, firmware, and device driver personnel work closely together, we understand the time it takes to respond to requests like "please check this signal" from the firmware team. This time, I introduced an example where the evolution of development environment performance has not kept pace. *News is distributed through our company newsletter.

Please check the differences in words in a dictionary. Since this is an engineer's column, I will consider the "dangers of speculation" and the "hypotheses" for making assumptions. This theme applies in various scenes, from specification decisions to debugging. To avoid divergence, I will focus on the "debugging scene." In image processing development, even if there is a lot of noise or the image is distorted, once you can obtain an "image (a collection of two-dimensional array data)," you can speculate about issues from a visual perspective. A common pitfall of speculation is the behavior of trying various things in trial and error, thinking, "Could this be the problem?" For whatever you try, if the result is A, consider that a "hypothesis," and if the result is B, treat that as another "hypothesis," also forming a hypothesis for the cause of each result obtained. You should not continue testing until you can organize these. If it becomes a habit to test without considering hypotheses, escaping that quagmire will rely on luck. As you gain experience, it becomes more common for trial and error to accidentally lead to fixing issues. This is the "danger." Since humans think and design, mistakes can occur, necessitating debugging. *News is distributed through our company's newsletter.

We develop cutting-edge technology at the request of our customers. However, if we can achieve our goals using combinations of established techniques, there are many advantages to that approach. Since these techniques are referred to as established, they have been widely used for a long time. Many of them are included in university textbooks, and if we consider "a long time ago" to be over 25 years, there are no patent restrictions. Additionally, while there are various calculation methods that can yield the same results, the techniques known as established have survived the competition with many other methods, often resulting in a streamlined process. Is it just combinations of established techniques? If it's merely a combination of publicly known technologies, it would be easily imitated, right? Unless we specifically advertise what combinations of processes we use, imitation is not so simple. I mentioned that an ideal situation would be a combination of established processes, but even if 80% or 90% can be handled with established techniques, when we hit the remaining 10% barrier, we need to develop unknown approaches. It is precisely this last 10% that leads to inquiries to our company, and we participate in exhibitions to convey this "new technology," so I may not be the most suitable person to discuss this topic. *News is distributed through our company newsletter.

The capacity of the human brain does not seem to be increasing like the evolution of semiconductors. While reminiscing about the past is a step towards decline, please allow me to do so for the sake of discussing the evolution of semiconductors. The evolution of semiconductors has often been said to have reached its limits in terms of gate scale due to various reasons, such as "the limits of (exposure) light wavelengths," yet we have overcome these challenges time and again. Human wisdom knows no bounds, and I reflect on this. When I first designed an ASIC, the maximum scale was around 3,000 gates. In the design rooms of semiconductor manufacturers, we couldn't proceed with the drawings until we achieved a circuit operation verification rate (the ratio of places that changed between Hi and Lo to those that never changed) of 95% using "test patterns." Now, even FPGAs are said to have "50 million ASIC gates," which is on a completely different scale. Even though the capacity of the human brain has increased, it is not possible for one person to design such large-scale systems alone. The increase in scale has benefited from the incorporation of dedicated circuits, embedded memory, hard-core CPUs, and so on. Using IP provided by device manufacturers becomes, in a sense, a black box. This has turned into a discussion of difficult challenges. *News is distributed through our company newsletter.

I used to believe that in order to develop something, it was ideal to firmly establish the "specifications" before the design phase. However, I learned from a client company that passionately advocates the policy of "not strictly defining specifications leads to better outcomes." Let me introduce the pros and cons of each approach. The advantage of "defining specifications" is that during the process of setting specifications, trade-offs are made, allowing for an optimal approach to the objectives. There may be moments of uncertainty during design or debugging, but if the initial specifications are clearly defined, there will be no deviations. The advantage of "not defining specifications" is that if new ideas emerge during development, the specifications can be flexibly adjusted, leading to the creation of "better products." Until I understood this, I thought, "Doesn't that lead to unnecessary costs?" I used to think, "If you try to define the specifications in detail, won't that delay the start?" However, after the completion of that project, a new product was developed that incorporated convenient features that were not recognized at the start. This became an episode that prompted me to always want to remain flexible. *News is distributed through our company newsletter.

I reflected on the initial demonstration of the "QR Code Multi-Focus Reading" and considered improvements for the next exhibition. One point of reflection is that we displayed three demos at the venue, but we received feedback that this particular demo was "not immediately recognizable as an image processing demo." We wanted to showcase that we developed technology to read QR codes placed on boxes at different distances using a webcam. However, no one who only saw the demo understood this without verbal explanation, which meant we couldn't convey our valuable technology. However, there were also reactions that made me think, "I don't want to stop this demo." After the explanation, there were discussions like, "We are an optical system manufacturer and have prototyped something that can change focus quickly, but we are considering what to use it for. How about collaborating for a display?" and suggestions like, "What if we place a toy forklift at the exhibition and attach a camera to it to move it?" Since it is an exhibition, if attendees don't take a glance and wonder, "What is that?" they won't stop by. We also learned that if the technology is communicated effectively, people might say, "I wanted that." *News is distributed through our company newsletter.

Having broad knowledge and deep knowledge is the ideal for engineers. Except for special geniuses, humans are given the same amount of time each day. Therefore, a choice between "broad knowledge" and "deep knowledge" is necessary. The solution to this choice, as well as the desire for both, is "organization" and teamwork. At KIT, the company acts as a single team, engaging in problem-solving through information exchange between those responsible for deep knowledge and those responsible for broad knowledge. Humans cannot "copy and hand over the contents of their brains," so "skillfully copying and handing over" becomes the communication ability. Within the information being conveyed, there are parts that one unconsciously assumes "the other person already knows," which can lead to incomplete information transmission. To prevent this, "observing the other person's reaction" is a communication technique. Before the regular weekly meetings, we create a time called "communication time" to practice. Like a cleaning duty in elementary school, each week, a "theme presenter" takes turns using that time to decide what kind of "communication time" it will be. This column has turned into a casual chat, so I will stop here. *News is distributed through our company newsletter.

It may sound self-serving, but I appreciate being called as the title suggests and receiving feedback that I have a lot of ideas. Although it's not synchronized swimming, I put in invisible efforts for that purpose. This is the "preparation of core technology." Continuing from the last time, to be honest, what becomes "core technology" comes from the results. Even if aimed for, some things may not become core technology and end up being discarded. When budgeting for preparation, I consider it as "customer attraction costs during exhibitions" and secure time for it. Since development is my main job, the change of periods is an opportunity for "preparation." The next preparation topic will be the "reflection meeting after the exhibition," where we will evaluate the demonstrations. Evaluations will be conducted based on categories such as "Did they notice it instantly?" "Visual novelty," and "Novelty in technical explanations." At the same time, I will also provide evaluations for the "next" aspects, such as "Would they be surprised if realized?" and "Would they be surprised by the technical explanation?" There have been instances where I worked hard on development, but it ended with just one exhibition. When I grow and receive feedback that something was "wonderful" when used in specific projects, it is a moment when I feel glad I chose the profession of an engineer. *News is distributed through our company newsletter.

Unlike what one might imagine, this is not a story to be proud of. I present this as "a raw column from the development field." When accelerating the processing speed of image processing, a little technique is to use continuous address access. This is coding that takes into account the fact that the access speed of DRAM differs depending on changes in Row Address and Column Address. In a certain image processing task (for the sake of simplicity), a less experienced team member was developing a process that involved performing horizontal integration followed immediately by vertical integration. Since the reported processing time was slow, I asked whether they were aware of the processing order mentioned above, and what would happen to the processing time if they deliberately reversed the order. The result was that the processing time was the same for both orders. However, when I asked them to report the individual processing times, it was reported that the processing done later was twice as fast. By this point, you may have seen the "punchline." It became clear that coding with an awareness of addresses was less important than the fact that, regardless of the order, the later processing hit the cache, resulting in faster execution. This is a real case. *News is distributed through our company newsletter.

The "online seminar?" that we informed you about in previous news has become a reality. Since this is our first time using an online format, we are currently practicing how to proceed, but there were some unexpected issues that we learned from the organizers. 1) Participants may not be able to install the software. 2) Some participants may not be able to turn on their cameras. These are the two points. In a seminar held in person, there are "practical exercises," but in an online format, we cannot allocate time for participants to think. We anticipated this and were preparing to implement the new items we added this time. In the first half, the "explanation of image processing principles" involves participants performing the explained operations on the venue's PC, but those who cannot install the software will only be able to watch the instructor's screen, raising concerns about how much they will actually learn. Furthermore, not being able to use cameras makes it difficult to gauge whether the participants are understanding the material. When we can see participants' faces in person, we can adjust our explanations if something seems unclear. We will share the results if there is an opportunity to do so in the future. *The news is distributed via our company newsletter.

This product implements standard image processing techniques, allowing you to "try" necessary processes without programming during development and debugging. It has been updated from Ver.2.1.1.0C to Ver.2.1.1.0D. This software is the same for both the commercial and trial versions. By entering a license key, you will be able to use all features as the commercial version. The "license keys" that were prepared have all been sold or used up in the "Image Processing Learning Set Campaign" and "Image Processing Seminar," necessitating a switch to a new protection method. At that time, the development environment used Borland products, which made it easy to create GUI elements like icons, but we had to port it to the Visual Studio environment for our convenience. There are no changes to the implemented image processing functions, but some operation buttons have been turned into menus and the appearance has changed. Existing users can continue to operate by entering their already obtained "license key." If you are moving to the new version, please uninstall the old one before installing the new version. *News is distributed through our company newsletter.

For over twenty years, I have been serving as a seminar instructor in the gaps of my main job in development, but for the past two years, events have been canceled due to the impact of COVID-19. The decision to hold this event was made during a period when the number of infections had significantly decreased. The differentiation of our seminars comes from the voices of those in the image processing development field, so we ask the attendees who are eager to learn something specific today to raise their hands, allowing us to focus on the most requested topics. During the practical sessions, I observe everyone's screens and provide individual hints when I notice someone is struggling. At the time of this column, the organizers are also focusing on "risk avoidance" and are planning for in-person attendance at the venue. Organizer: Japan Techno Center, February 24 (Thursday) https://www.j-techno.co.jp/seminar/seminar-47031/ There is a possibility that it may be changed to "the first online seminar." I am somewhat skeptical about whether "responding and improvising" can work online, but even if it switches to online, I aim for participants to feel that they gained something from attending. *News is distributed through our company newsletter.

There have long been many inquiries about image processing from departments with production management titles at various different companies. The common keyword in these inquiries has been "inspection." Most of them pertain to the inspection of defective products and the inspection of manufactured goods. The reason I chose "production management" as the theme this time is to introduce the various tasks beyond inspection that we receive requests for, specifically related to "images." Here are some themes other than inspection: 1) Human movement Tracing the movements of workers in the factory. 2) Tracing the position of transport vehicles In an unmanned factory, I assumed that the control system would naturally know the position of the transport vehicles. However, it was surprising to hear that they wanted to trace this completely separately from the device that operates it, as a form of third-party verification. 3) Inventory management Outbound management is easy to arrange since everything is produced in-house. However, inbound management involves a wide variety of companies, so the sizes of the packaged boxes vary, making it difficult to standardize the quantity checks of the contents. The scope of production management tasks is very broad, and there seem to be new opportunities for inquiries like "Can we do this using images?" *News is distributed through our company newsletter.

The "Image Processing Seminar," which was originally limited to a maximum of two times a year, has not been held for a long time due to the impact of infectious diseases and the realization that online seminars do not convey the same experience. During this time, there have been advancements in technology, and the "materials" used as textbooks in the seminar have been updated. We have added GPU programming to the means of realization that were previously "software and hardware," based on "industry information" such as application fields of image processing, image sizes, and pixel rates. Not only the materials but also the lectures will include ad-libbed topics based on "areas of interest to the participants," so we are looking forward to what new information will be discussed this time. The seminar is organized by the Japan Techno Center. It is scheduled to be held on February 24, 2022. https://www.j-techno.co.jp/seminar/seminar-47031/ We aim to convey firsthand information from the field that specializes in "image processing" every time. The instructor introduction discount is also valid for newsletter subscribers. Please bring any questions related to image processing, regardless of the seminar lecture content. *News is distributed through our company newsletter.

This is a discussion about business negotiations for developing "custom processing" tailored to our customers' requests, which is our main business. Even though we call it a negotiation, it mostly involves "specification determination." We listen to our customers' requests and make proposals to realize them. Since the industries and applications are different each time, it is difficult to fully understand the requests in one go. Therefore, the exchange of "specifications" corresponds to the negotiation. At times, the conversation may be perceived as "modest" or "conservative," not from the person we are exchanging ideas with, but from someone in between the two parties. In our case, the person conducting the negotiation often becomes the one responsible for development. If we proceed by saying "we can do it" without much thought, only to later say "it turns out we can't do it with the expected method," the time spent considering the matter becomes a disadvantage for both parties. However, simply stating "we can't do it" is a no-go for a development company. What approach can make it possible? What are the merits and demerits of that approach? Being able to discuss these directly with the users of the deliverables is the advantage of sales talk. *News is distributed through our company newsletter.

Recently, we completed the final year and final delivery of the "image processing" project, which was part of a five-year plan, and held the last "delivery presentation meeting." We developed an image recognition component for a theme focused on "automation" of a certain action performed by humans. "Automation" is a common theme, and many projects aim for labor-saving. From basic research over five years to the development of actual equipment, the theme was extensive in both cost and duration. Depending on the application, it likely holds significant value. I was responsible for the image processing component, and the equipment was successfully completed. During the final delivery presentation meeting, I was surprised to learn that the "purpose of the entire equipment" was that "automation" was not merely for labor-saving but an essential function. Since the target objects are pharmaceuticals, it was explained that "automation" was necessary to avoid human contact with "bacteria." I have been involved in image processing development for many years, but through this long period of collaboration, I realized my immaturity in not understanding the true purpose. At the same time, I felt the excitement of the future, knowing that there are still many people who need image processing that I have yet to meet. *News is distributed through our company newsletter.