ADPlug

adplug

This is a story of investing in skills and development with a twist: instead of your own skills, this is a story of investing in other people’s skills. Back in 2010, I was asked by my current freelance client if I wanted to join him in creating a company in the Philippines. I would be the first employee and due to some circumstances (and some goading from my future wife), I made a leap of faith and agreed. For a couple of months, there were only two of us in the company working on client projects. I was learning the ropes as well since I was focused on frontend before, but now I needed to ramp up my skills to also cover the backend. My boss had a vision, he expected to double our numbers every year. That meant 4 people in 2011, 8 in 2012 , sixteen in 2013 etc. When I heard of his vision, I admit, I was a bit doubtful — we were a Ruby shop and the amount of people in the monthly Ruby meetup never exceeded ten. And everyone had a job! To be able to reach those targets in the future, the only plan I could think of was to poach people from other companies or train non-Rubyists for the job. I was naive and this is why he was a CEO: he knew how to have that kind of vision and to actually pull it off. Fast forward to 2016, I celebrated my fifth year anniversary with the company — with twenty plus people. How was that possible? Simple, we helped grow the community. As a disclaimer, my previous company didn’t grow it single-handedly, but was part of the effort in doing so. The Ruby community in the Philippines is pretty tightly knit and I think this was one of the reasons we also got to that point in time. Here are some of the things we did to help make the community as it is today. Hosting meetups One of the things he did to put the company on the map was by hosting some of the monthly Ruby meetups. In doing so, people learned about the company and got to talk with us employees. As custom in our community, meetup hosts also got a free job ad / plug — which was pretty effective seeing we hired a few attendees in some occassions! I think this was one of the best and easiest things to do since meetups were usually composed of finding a person who will talk and buy pizza and beer enough for twenty people. EASY. Sponsoring events We researched and sponsored school events and job fairs. With meetups, the people who usually came were other developers who were curious about Ruby, people who wanted to improve their Ruby skills, and veterans who were there for the discussions with fellow enthusiasts. With school events and job fairs, the target market are the students and job hunters. Sometimes, sponsoring also meant having to do some talks, which some of my colleagues did. This gave off the impression that we knew our stuff and that we were a good company to apply to. Speaking in conferences In line with sponsoring events, we also did some talks and sponsorships in conferences. The two major ones that I know of (from recent memory) are and . DevconPH RubyConfPH By speaking and sponsoring these events, we also got to reach out to MORE professionals. The RubyConf PH event also involved some of the big names in Ruby like Y , and . ukihiro ‘Matz’ Matsumoto Aaron ‘tenderlove’ Patterson André Arko In doing so, people who didn’t usually attend the meetups surely went to the conferences — one, because their Ruby heroes were there, and two, who wouldn’t want a conference at the beach? (granted some of those were in the CBD, but still!). Planting the seeds There was a huge shortage of Rubyists in the Philippines. One, because it was still quite new, and two, it wasn’t taught in the universities. In universities, the foundation languages were usually C or Java. After that, it was mostly usually algorithms and solutions using any of those two languages (since you already had them as your foundation). Electives with different languages were few and mostly comprised of Lisp, ASP (Microsoft sponsored some of the major universities so this was part of the curriculum), and usually PHP since it was one of the easiest languages to learn. By spreading the word through trainings and ‘install fests’, we got to talk with novices and tried to entice them to try Ruby out — and then apply to us. We did succeed in this regard as well — we had a bunch of interns who came to us for their OJT (on the job training). It was a win for both parties: students got to peek into the professional world and learn during the process, and as a company, we had more people to train and eventually hire. Helping out in open source During my time in my previous company, we suggested that the interns contribute to an open source project and . As you can see, Karlo and his pair helped out by adding a new feature. In doing so, we knew that he was a good prospect in hiring and we eventually did hire him as soon as he graduated. Pretty cool! then blog about it Gitlab Not only did he get to learn stuff and be hired in the process (eventually!), he also got to help with an actual community project! Talk about hitting two birds with one stone! Training the newcomers Continuing from my point above, we trained some interns who eventually applied to us for hiring. Since my old company was a pair programming company, we paired almost 100% of the time so seniors can train and mentor their colleagues while working. Interns got to do some “shadowing” where they sit behind a pair and watch how they work. They can still ask questions and suggest things, but generally they were there to watch and learn. Sometimes they also got to “drive” where they were the ones who typed while the senior-junior pair discussed the solution or told them how to solve it, while sometimes they were asked to be the ‘tie-breaker’ in some disagreements for solutions. These steps took us years to accomplish. As an example, the interns we hired were juniors in college, so after they completed their OJT hours, it wasn’t until a year after that they graduated and applied to us. As for the community, the meetups were a regular thing and in doing so, the community got to know each other better and spread the knowledge, such that everyone was a little bit better every after a meetup. By investing time in helping out the community, everyone benefits since the community grows and now you have a larger pool of developers to choose from! It is now a thriving ecosystem of seniors and juniors helping each other level up their skills. I’ve known a LOT of people from the community and I’ve seen everyone just become better at what they do. Win-win indeed!

Investing in the developer community to grow your company

Running Eleventy Serverless On AWS Lambda@Edge Eleventy is great. It’s a static site generator written in JavaScript, for “ ” It’s 10 to 20 times faster than the alternatives, like Gatsby or Next.js. You get all of your content statically rendered and ready to be CDN-delivered. You needn’t worry about server-side rendering to get those pretty social share unfurls. And, if you have a large data set, that’s great — Eleventy can with no issues. Fast Builds and even Faster Web Sites. generate tens of thousands of pages What if you have a HUGE data set? When building Sandworm’s , we wanted to generate a catalog of beautiful report visualizations for every library in the npm registry. That is, for every version of every library in the registry. We soon found out — that’s more than . Good luck generating, uploading, and keeping that amount of HTML pages up to date in a decent amount of time, right? open-source security & license compliance audits for JavaScript packages 30 million package versions We looked at reducing our data set to just the most popular packages. We looked at implementing partial builds, where stale report pages would get continuously generated and uploaded. But the solution we ended up implementing was , a plugin that runs one or more template files to generate dynamic pages. So instead of going through the entire set of pages at build time, this plugin allows us to separate “regular” content pages rendered at build from “dynamic” pages rendered on demand. We can then simply generate and upload static content (like the homepage, about page, etc.) in the CI, and then deploy some code to a compute provider that will generate an npm package page when a user navigates to a specific URL. Great! Eleventy Serverless at request time Except: Eleventy Serverless is built to work out-of-the-box with Netlify Functions, and we’re running on AWS. The good news is that you get Eleventy Serverless to run in AWS Lambdas. Even better, you can get it to run in Lambda@Edge, which runs your code globally at AWS locations close to your users so that you can deliver full-featured, customized content with high performance and low latency. can Setting up Eleventy First things first: let’s get Eleventy running the local build. We start by installing it: npm i @11ty/eleventy --dev Then, let’s create the simplest template for our static Eleventy page. We’ll write it using , but since it’s so simple, it won’t take advantage of any useful templating tags for now. Liquid Let’s call it : index.liquid <h1>Hello</h1> That’s it, we’re ready to build and serve! Run: npx @11ty/eleventy --serve

[11ty] Writing _site/index.html from ./src/index.liquid
[11ty] Serverless: 3 files bundled to ./serverless/edge.
[11ty] Wrote 1 file in 0.12 seconds (v2.0.0)
[11ty] Watching…
[11ty] Server at http://localhost:8080/ Visit in your browser at this point, and you should see the “Hello” heading we’ve created above. Neat! http://localhost:8080/ Setting up the Eleventy Serverless plugin The Serverless plugin is bundled with Eleventy and doesn’t require you to npm install anything. We do need to configure it, though. To do that, we need to create an Eleventy config file: // .eleventy.js
const { EleventyServerlessBundlerPlugin } = require("@11ty/eleventy");

module.exports = function(eleventyConfig) {
  eleventyConfig.addPlugin(EleventyServerlessBundlerPlugin, {
    name: "edge",
    functionsDir: "./serverless/",
    redirects: false,
  });

  return {
    dir: {
      input: 'src',
    },
  };
}; Let’s break the plugin configuration down: Each plugin’s unique will determine the build output directory name and will be required when assigning permalinks. You can also instantiate multiple plugins to have different functions handle different pages. name The allows you to specify the path to the build output dir; in our case, the plugin will generate files in the directory relative to the app root. functionsDir ./serverless/edge configures how Netlify redirects should be handled — since we’re not running on Netlify, we set this to false to skip generating a file. redirects netlify.toml Lastly, in the configuration object we return to Eleventy, we specify an input dir for our content to keep things tidy. We’ll also go ahead and move the file we created earlier in the src directory. index.liquid Next, let's build again by running , and investigating what gets output under . npx @11ty/eleventy ./serverless/edge You should see the following: A number of js and json files starting with . Some are configuration files, and some are built to inform the Netlify bundler of function dependencies — we won’t need those for Lambda. eleventy- , a copy of the main configuration file in the app root. eleventy.config.js The directory with the template. src index.liquid An file with the actual serverless handler code that we’ll update and deploy to Lambda. index.js Let’s gitignore the build artifacts that we don’t want in our repo and only keep the file for now. index.js Add this to your file: .gitignore serverless/edge/**
!serverless/edge/index.js Good, we’re now ready to create our first dynamically generated page. Let’s make another simple Liquid file for it under : src/edge.liquid ---
permalink:
  edge: /hello/
---
<h1>Hello@Edge</h1> You’ll notice that for this file, we’ve added some to the liquid template. front matter data Specifically, we’ve defined a permalink for our page to respond to when running under the edge plugin. Eleventy won’t generate an page when building — this page will only be generated by invoking the serverless handler code. edge.html Making things Lambda-compatible Let’s now look at what’s going on with . This is only generated with the initial build, so we’re free to modify it — and we’ll definitely need to in order to support Lambda@Edge. serverless/edge/index.js First, we can remove the , as that’s only needed for the Netlify bundle process; require("./eleventy-bundler-modules.js") Next, we’ll need to get a reference to the current request path and query, as Eleventy needs that info to know what content to generate. With Netlify, you get these via , , and . With Lambda@Edge, we’ll be getting events generated by CloudFront on origin requests — see . We’ll also use querystring to handle parsing the query string. event.rawUrl event.multiValueQueryString event.queryStringParameters an example in the AWS docs Let’s update the code to this: const { request } = event.Records[0].cf; 
const path = ${request.uri}${request.uri.endsWith("/") ? "" : "/"}; 
const query = querystring.parse(request.querystring);
let elev = new EleventyServerless("edge", { path, query, functionsDir: "./", }); Finally, we need to update the handler’s returned objects to match the format expected by . Lambda@Edge Update the success & error responses status and headers to: { status: "200", headers: { "cache-control": [ { key: "Cache-Control", value: "max-age=0", }, ], "content-type": [ { key: "Content-Type", value: "text/html; charset=UTF-8", }, ], }, body: ... } We’ve also added a header to configure how CloudFront caches the returned results. We can get more thoughtful about this when moving to production, but for now, we’ll go with no caching. Cache-Control One last thing: we’ll want to separate build dependencies from edge handling dependencies, so let’s create a separate file in , and install as a prod dependency. package.json serverless/edge @11ty/edge As our edge function grows, we’ll add more things here, like database clients. Here’s our full handler code, for reference: Testing it out locally Good, let’s test this out locally before we deploy! It should be pretty easy to simulate sending an event to our handler function. Let’s create a simple file: test.js const { handler } = require('.');

(async () => {
  const response = await handler({Records: [{cf: {request: {uri: "/hello/", querystring: ""}}}]});

  console.log(response);
})(); Running in the console, you should see: node test.js {
  status: '200',
  headers: { 'cache-control': [ [Object] ], 'content-type': [ [Object] ] },
  body: '<h1>Hello</h1>'
} Take a moment to celebrate! You’ve just triggered your first Eleventy build in a serverless function. 🎊 Deploying to AWS Things look good — it’s now time to deploy this to AWS. To handle the deployment, we’ll be using Serverless. No, not the Eleventy Serverless plugin, but Serverless, the “ ” command-line tool. zero-friction development tooling for auto-scaling apps on AWS Lambda If you don’t have it installed, . run npm install -g serverless Then create a file to configure the deploy: serverless/edge/serverless.yml This will instantiate a CloudFront distribution connected to the bucket you specified under . Any calls to URLs matching the pathPattern will be forwarded to the serverless handler instead of being routed to the bucket. events>cloudfront>origin Fun fact: Lambda@Edge functions log console output to their regional CloudWatch. That is, if a user in Germany accesses your pages via the edge at , you’ll see logs for that specific run under the region and nowhere else. In the yml config, we make sure to give our function proper permissions to write log groups anywhere. eu-frankfurt-1 eu-frankfurt-1 We should also add an exception for the config file to — we want this in the repo. .gitignore If you already have a CloudFront distribution that you want to connect to your new serverless function, check out the plugin. serverless-lambda-edge-pre-existing-cloudfront We’re ready to deploy! Make sure you export AWS credentials for an IAM user with proper permissions for deploying the entire stack. When moving to production, for security purposes, you should create a dedicated user with the minimal set of permissions required — however, I haven’t been able to find a comprehensive list of such permissions, so this will likely be a tedious trial-and-error process of figuring them out by trying deploys and seeing what fails. While still in development, an admin user might be easier to use. Run to deploy. If all goes well, in a couple of minutes, you should see the URL to your new CloudFront distribution! sls deploy --stage prod Your settings will need to propagate globally though, so it might take a few more minutes for everything to be ready. You can check the current status of your distribution under the AWS console dashboard. Once it’s done deploying, navigating to in a browser should display our “ ” HTML header from the template. CF_URL/hello Hello@Edge edge.liquid We did it! 🙌 Bonus: making it dynamic Now let’s quickly make our serverless function actually do something async. Let’s have it accept a URL parameter that’s the name of a Pokémon, and respond with an image of said cute beast. We’ll use to get the image. https://pokeapi.co/ We could do the async work outside of eleventy, and then inject some global data like this: const eleventy = new EleventyServerless('serverless', {
  path,
  query,
  functionsDir: './',
  config: (config) => {
    config.addGlobalData('data', yourData);
  },
}); Or, better yet, starting with Eleventy 2.0.0, we can use . async filters Let’s first update our template to include the new HTML we want: edge.liquid ---
permalink:
  edge:
    - /hello/
    - /hello/:name/
---
<h1>Hello@Edge \{\{ eleventy.serverless.path.name }}</h1>
{% if eleventy.serverless.path.name %}
  <img src="\{\{ eleventy.serverless.path.name | escape | pokeimage }}" />
{% endif %} We’ve added a new that includes a name path parameter. That will become available in the data cascade as . permalink eleventy.serverless.path.name We’re transforming this param via two filters: and . Remember, user input should be treated as potentially malicious 😉. name escape pokeimage We need to define our filter. This is where the async magic happens. Add this to your file: pokeimage .eleventy.js eleventyConfig.addAsyncFilter("pokeimage", async function(name) { 
const results = await fetch(https://pokeapi.co/api/v2/pokemon/${name}); 
const json = await results.json();
return json.sprites.front_default;
}); We’re relying on the node’s built-in API here — it’s a good thing we’ve set in our file. fetch runtime: nodejs18.x serverless.yml Let’s update our file to query the URL, and run again. test.js /hello/ditto/ node test.js In the console output, you should now see: {
  status: '200',
  headers: { 'cache-control': [ [Object] ], 'content-type': [ [Object] ] },
  body: '<h1>Hello@Edge ditto</h1>\n' +
    '\n' +
    '  <img src="https://raw.githubusercontent.com/PokeAPI/sprites/master/sprites/pokemon/132.png" />\n'
} One last to get this deployed, and done! You’ve mastered setting up Eleventy Serverless on Lambda@Edge. sls deploy --stage prod All of Sandworm’s npm package report pages are generated using Eleventy Serverless and Lambda@Edge.

Running Eleventy Serverless On AWS Lambda@Edge

From the beginning I designed in the way that it could evolve into a system with a single core and multiple plugins and extensions. So that people could customise it in the most suitable way. And as a first step into that direction I would like to present you . Pury Plugins Custom Plugins In the previous version it was possible to change a to take advantage of libraries like Timber. allow much more flexible customisation. They provide access to raw results to process them in the most suitable way. For example, it could be interesting to compare performance between master and feature branch, I have a few ideas how to do that, but didn’t tried them yet. Or change formatting to a JSON, run application in a device farm, collect results and compare them with some script. I always wanted to measure application performance on live. So I played a bit with Analytics and got promising results. Instead of getting standard Pury output: Logger Plugins Google App Start --> 0msSplash Screen --> 5msSplash Load Data --> 37msSplash Load Data <-- 1042ms, execution = 1005msSplash Screen <-- 1042ms, execution = 1037msMain Activity Launch --> 1043msonCreate() --> 1077msonCreate() <-- 1100ms, execution = 23msonStart() --> 1101msonStart() <-- 1131ms, execution = 30msMain Activity Launch <-- 1182ms, execution = 139msApp Start <-- 1182ms I sent execution times to and got this: Google Analytics Timing API As you can see I got all execution times in a single table. Taking into account , it could be a very powerful to analyse application performance across different versions and devices. I’m planing to write an article about Google Analytics Timing API and Google Analytics Plugin once it is released, but in the meantime I would like to go back to Pury Plugins in general. GA Segments tool Plugin creation To create a custom plugin you need to implement interface: Plugin public interface Plugin {    void handleResult(ProfileResult result, ProfilerId profilerId);} In receives a result of profiling and an identifier of the profiler which produced the result. It worth to mention that is an interface with 4 different implementations. To simplify result processing I made a use of , each result has a method And this is interface: handleResult() Plugin ProfileResult Visitor Pattern accept(ResultVisitor). ResultVisitor public interface ResultVisitor {void visit(AverageProfileResult averageProfileResult); void visit(RootAverageProfileResult rootAverageProfileResult);  

void visit(RootSingleProfileResult rootSingleProfileResult);  

void visit(SingleProfileResult singleProfileResult); } There is a method for each of the result type, so no checks or casts are required. I hope you will find it useful. While I was writing support for I thought that filtering input by profiler name could be a very common use case. So if you think that an abstract class that implements and does filtering is useful, please raise an issue . Plugins, Plugin on GitHub How to use Plugins To add and remove plugins on the fly use the following methods: public final class Pury { .... 

public static void addPlugin(String key, Plugin plugin) {}  
public static void removePlugin(String key) {}

.... } There is a behind those two methods, so if two plugins with the same key are added, the first one is removed. Map Logging Plugin With introduction of , I decided to change the way logging works. So now logging is just an another nothing more. To take a look into the code, please, check class. Plugins Plugin, LoggerPlugin is added by default, so logging is working out of the box. To remove or replace it, use the key uses the same as was used for logging results before. To change it use method. LoggerPlugin Pury.LOGGER_PLUGIN. LoggerPlugin Logger, Pury.setLogger(Logger) Conclusion enable customisation and better control over reporting profiling results. They adds a certain degree of flexibility to Pury that, I hope, will be useful. You can find code with example . Plugins on GitHub As I’ve already mention, right now I’m working on integration Pury with Google Analytics. If you are interested in results then follow me on Twitter or here, on Medium. If you have ideas about what else can be done with profiling results, please write in comments or . in Gitter

Get access to raw profiling results with plugins for Pury

OFX, aka , is an open standard for creating 2D visual effects and video compositing. It operates in a plugin-like application development model. Essentially, it serves as both a Host - an application providing a set of methods, and a Plug-in - an application or module implementing this set. OFX Image Processing API This configuration offers the potential for unlimited expansion of the host application's functionality. DaVinci Resolve and Metal Applications such as Final Cut X and DaVinci Resolve Studio, starting from version 16, fully support Apple Metal pipelines. Similar to OpenCL and Cuda, in the case of OFX, you can obtain a descriptor or handler of a platform-specific command queue. The host system also takes responsibility for allocating a pool of such queues and balancing calculations on them. Moreover, it places the source and target image clip data in GPU memory, significantly simplifying the development of extensible functionality. OFX Version Support in Resolve With Resolve, things are slightly more complicated. DaVinci announces support for OFX v1.4, albeit with some limitations. Specifically, some methods for working with interface functions are not available for use. To determine which method is available, OFX allows you to examine the supported suite through key/value queries. Publishing methods in the plugin code are based on . But we will use the OpenFXS C++ shell adapted for C++17. For convenience, I've compiled everything into one repository: taken from the open-source . C calls dehancer-external Dehancer project OFXS Concept In this project, I will be using OpenFXS, a C++ extension to OpenFX that was originally written by and has become popular over time in commercial and open-source video processing projects. Bruno Nicoletti The original was not adapted to modern C++ dialects, so I updated it to make it compatible with . OpenFXS C++17 OFX, and consequently OFXS, is a standalone software module that is dynamically loaded by the host program. Essentially, it is a dynamic library that is loaded when the main application starts. OpenFXS, like OFX, must publish method signatures. Hence, we use one C method from the code. To start developing in OpenFXS, you need to agree to a few common sets of classes that are used to create new functionality in your application. Typically, in a new project, you need to inherit from these classes and implement or override some virtual methods. To create your own plugin on the host system, let's start by familiarizing ourselves with the following public classes and the same method: is a basic template for creating a plugin's data structure suite and control panel (although it can be left empty). The inherited class creates a singleton object that registers a set of parameters and presets in the host system, with which the developer registers his module; OFX::PluginFactoryHelper - base container class for creating and storing structure properties; OFX::ParamSetDescriptor - a container of properties used when manipulating graphic data when calling data processing procedures. Used by the host application to save the context of processing parameters in the internal database and work with plugin properties defined for each of its instances; OFX::ImageEffectDescriptor - a set of settings that allows you to manipulate the registered data structure; OFX::ParamSet - a set of settings for effects on graphical data, inherited from OFX::ParamSet; OFX::ImageEffect - in the child class, it is necessary to implement data stream processing: images or videos; OFX::MultiThread::Processor - method of registering a plugin (factory) in the host application; OFX::Plugin::getPluginIDs False Color One feature that distinguishes the process of shooting video from simply capturing an image in a photo is the dynamic change of scenes and lighting of both scenes as a whole and areas in the image. This determines the way exposure is controlled during the shooting process. In digital video, there is a control monitor mode for operators in which the exposure level of areas is mapped into a limited set of zones, each tinted with its own color. This mode is sometimes called "predator" or False Color mode. The scales are usually referenced to the IRE scale. Such a monitor allows you to see the exposure zones and avoid significant mistakes when setting camera shooting parameters. Something similar in meaning is used when exposing in photography - zoning according to Adams, for example. You can measure a specific target with an exposure meter and see in which zone it is located, and in real-time we see the zones, neatly tinted for ease of perception. The number of zones is determined by the objectives and capabilities of the control monitor. For instance, a monitor used with cameras can incorporate up to 6 zones. Arri Alexa Adding Extensions Before proceeding with the example, we need to add some simple proxy classes to implement OpenFXS as a platform for processing source data, such as Metal textures. These classes include: : A proxy class for OFX clip data. imetalling::Image : A functor for transferring data from the clip buffer into a Metal texture. From DaVinci, you can extract a buffer of any structure and packaging of image channel values into the plugin, and it should be returned in a similar form. imetalling::Image2Texture To make working with the stream format in OFX easier, you can request the host to prepare data of a specific type in advance. I will use floats packed in RGBA - red/green/blue/alpha. : A reverse functor for transforming a stream into a host system buffer. As you can see, there is potential for significant optimization of calculations if you teach the Metal computing cores to work not with the texture, but directly with the buffer. imetalling::ImageFromTexture We inherit the OFXS base classes and write our functionality without going into the details of how the Metal core works: : Here, we implement the stream transformation and initiate the processing. imetalling::falsecolor::Processor : This will be our specific part of the suite description for the plugin. We need to implement several mandatory calls related to setting up the structure and create an instance of the OFX::ImageEffect class with specific functionality, which we divide into two subclasses in the implementation: Interaction and Plugin. imetalling::falsecolor::Factory : Implementation of the interactive part of working with effects. Essentially, this is the implementation of only virtual methods from OFX::ImageEffect related to processing changes in plugin parameters. imetalling::falsecolor::Interaction : Implementation of thread rendering, that is, launching imetalling::Processor. imetalling::falsecolor::Plugin Additionally, we will need several utility classes built on top of Metal to logically separate the host code and the kernel code on MSL. These include: : A base class that obscures work with the Metal command queue. The main parameter will be the name of the kernel in the MSL code, and the executor of the kernel call. imetalling::Function : A general class for transforming a source texture into a target texture, extending Function to simply set the parameters for calling the MSL kernel. imetalling:Kernel : Bypass kernel. imetalling::PassKernel : Our main functional class, a "predator" emulator that posterizes (downsamples) to a specified number of colors. imetalling::FalseColorKernel The kernel code for the "predator" mode could look like this: static constant float3 kIMP_Y_YUV_factor = {0.2125, 0.7154, 0.0721};
constexpr sampler baseSampler(address::clamp_to_edge, filter::linear, coord::normalized);
 
inline float when_eq(float x, float y) {
  return 1.0 - abs(sign(x - y));
}
 
static inline float4 sampledColor(
        texture2d<float, access::sample> inTexture,
        texture2d<float, access::write> outTexture,
        uint2 gid
){
  float w = outTexture.get_width();
  return mix(inTexture.sample(baseSampler, float2(gid) * float2(1.0/(w-1.0), 1.0/float(outTexture.get_height()-1))),
             inTexture.read(gid),
             when_eq(inTexture.get_width(), w) // whe equal read exact texture color
  );
}
 
kernel void kernel_falseColor(
        texture2d<float, access::sample> inTexture [[texture(0)]],
        texture2d<float, access::write> outTexture [[texture(1)]],
        device float3* color_map [[ buffer(0) ]],
        constant uint& level [[ buffer(1) ]],
        uint2 gid [[thread_position_in_grid]])
{
  float4  inColor = sampledColor(inTexture,outTexture,gid);
  float luminance = dot(inColor.rgb, kIMP_Y_YUV_factor);
  uint      index = clamp(uint(luminance*(level-1)),uint(0),uint(level-1));
  float4    color = float4(1);
 
  if (index<level)
    color.rgb = color_map[index];
 
  outTexture.write(color,gid);
} Initialization of the OFX Plugin We will begin by defining the class In this class, we will set a single parameter - the status of the monitor (either on or off). This is necessary for our example. imetalling::falsecolor::Factory. We will inherit from and overload five methods: OFX::PluginFactoryHelper : This method is invoked to globally configure the instance when the plugin is first loaded. Overloading this method is optional. load() : This method is invoked when an instance is unloaded, for instance, to clear memory. Overloading this method is also optional. unload() : This is the second method that the OFX host calls when the plugin is loaded. It is virtual and must be defined in our class. In this method, we need to set all the properties of the plugin, regardless of its context type. For more details about the properties, refer to the code. describe(ImageEffectDescriptor&) ImageEffectDescriptor : Similar to the method, this method is also called when the plugin is loaded and must be defined in our class. It should define properties associated with the current context. describeInContext(ImageEffectDescriptor&,ContextEnum) describe The context determines the type of operations the application works with, such as filter, paint, transition effect, or frame retimer in a clip. : This is the most crucial method that we overload. We return a pointer to an object of type . In other words, our in which we have defined all the functionalities, both with regard to user events in the host program and rendering (transforming) the source frame into the target one: createInstance(OfxImageEffectHandle, ContextEnum) ImageEffect imetalling::falsecolor::Plugin OFX::ImageEffect *Factory::createInstance(OfxImageEffectHandle handle,OFX::ContextEnum) {
     return new Plugin(handle);
   } Handling Events At this stage, if you compile a bundle with the OFX module, the plugin will already be available in the host application, and in DaVinci, it can be loaded onto the correction node. However, to work fully with a plugin instance, you need to define at least the interactive part and the part associated with processing the incoming video stream. To do this, we inherit from the class and overload virtual methods: OFX::ImageEffect - This method allows us to define the logic for handling the event. The event type is determined by the value of OFX::InstanceChangedArgs::reason and can be: eChangeUserEdit, eChangePluginEdit, eChangeTime - the event occurred as a result of a property being edited by the user, changed in a plugin or host application, or as a result of a change in the timeline. changedParam(const OFX::InstanceChangedArgs&, const std::string&) The second parameter specifies the string name that we defined at the plugin initialization stage, in our case, it is one parameter: . false_color_enabled_check_box - This method allows us to define the logic for reacting to an event, and return a state that determines whether something has changed and whether rendering makes sense. The method must return false or true. This is a way to optimize and reduce the number of unnecessary calculations. isIdentity(...) You can read the implementation of interactive interaction with OFX in the code. As you can see, we receive pointers to the clips: the source one and the memory area in which we will put the target transformation. Interaction.cpp Implementation of Rendering Launch We will add another logical layer on which we will define all the logic for launching the transformation. In our case, this is the only method for overriding so far: - Here, you can find out the properties of the clips and decide how to render them. Also, at this stage, the Metal command queue and some useful attributes associated with the current timeline properties become available to us. render(const OFX::RenderArguments& args) Processing At the launch stage, an object with useful properties became available to us: we have at least a pointer to the video stream (more precisely, a memory area with frame image data), and, most importantly, a queue of Metal commands. Now, we can construct a generic class that will bring us closer to a simple form of reusing kernel code. The OpenFXS extension already has such a class: OFX::ImageProcessor; we just need to overload it. In the constructor, it has the OFX::ImageEffect parameter, i.e., in it, we will receive not only the current state of the plugin parameters but everything necessary for working with the GPU. At this stage, we just need to overload the method and initiate the processing of kernels already implemented on Metal. processImagesMetal() Processor::Processor(
            OFX::ImageEffect *instance,
            OFX::Clip *source,
            OFX::Clip *destination,
            const OFX::RenderArguments &args,
            bool enabled
    ) :
            OFX::ImageProcessor(*instance),
            enabled_(enabled),
            interaction_(instance),
            wait_command_queue_(false),
            /// grab the current frame of a clip from OFX host memory
            source_(source->fetchImage(args.time)),
            /// create a target frame of a clip with the memory area already specified in OFX
            destination_(destination->fetchImage(args.time)),
            source_container_(nullptr),
            destination_container_(nullptr)
    {
 
      /// Set OFX rendering arguments to GPU
      setGPURenderArgs(args);
 
      /// Set render window
      setRenderWindow(args.renderWindow);
 
      /// Place source frame data in Metal texture
      source_container_ = std::make_unique<imetalling::Image2Texture>(_pMetalCmdQ, source_);
 
      /// Create empty target frame texture in Metal
      destination_container_ = std::make_unique<imetalling::Image2Texture>(_pMetalCmdQ, destination_);
 
      /// Get parameters for packing data in the memory area of the target frame
      OFX::BitDepthEnum dstBitDepth = destination->getPixelDepth();
      OFX::PixelComponentEnum dstComponents = destination->getPixelComponents();
 
      /// and original
      OFX::BitDepthEnum srcBitDepth = source->getPixelDepth();
      OFX::PixelComponentEnum srcComponents = source->getPixelComponents();
 
      /// show a message to the host system that something went wrong
      /// and cancel rendering of the current frame
      if ((srcBitDepth != dstBitDepth) || (srcComponents != dstComponents)) {
        OFX::throwSuiteStatusException(kOfxStatErrValue);
      }
 
      /// set in the current processor context a pointer to the memory area of the target frame
      setDstImg(destination_.get_ofx_image());
    }
 
    void Processor::processImagesMetal() {
 
      try {
 
        if (enabled_)
          FalseColorKernel(_pMetalCmdQ,
                           source_container_->get_texture(),
                           destination_container_->get_texture()).process();
        else
          PassKernel(_pMetalCmdQ,
                           source_container_->get_texture(),
                           destination_container_->get_texture()).process();

        ImageFromTexture(_pMetalCmdQ,
                         destination_,
                         destination_container_->get_texture(),
                         wait_command_queue_);
 
      }
      catch (std::exception &e) {
        interaction_->sendMessage(OFX::Message::eMessageError, "#message0", e.what());
      }
    } Building the Project To build the project, you will need CMake, and it must be at least version 3.15. Additionally, you will require Qt5.13, which aids in the easy and convenient assembly of the bundle with the plugin installer in the system directory. To initiate cmake, you must first create a build directory. After creating the build directory, you can execute the following command: cmake -DPRINT_DEBUG=ON -DQT_INSTALLER_PREFIX=/Users/<user>/Develop/QtInstaller -DCMAKE_PREFIX_PATH=/Users/<user>/Develop/Qt/5.13.0/clang_64/lib/cmake -DPLUGIN_INSTALLER_DIR=/Users/<user>/Desktop -DCMAKE_INSTALL_PREFIX=/Library/OFX/Plugins .. && make install Afterward, the installer, called , will appear in the directory that you specified in the parameter. Let's go ahead and launch it! Once the installation is successful, you can start DaVinci Resolve and begin using our new plugin. IMFalseColorOfxInstaller.app PLUGIN_INSTALLER_DIR You can find and select it in the OpenFX panel on the color correction page, and add it as a node. External links False Color OFX Plugin Code The Open Effects Association - OFX header file version and OFXS library code under Resolve + examples Download DaVinci Resolve

An Easy Way to Develop Your Own Apple Metal Plugin and Integrate It Into DaVinci Resolve

আপনার নিজস্ব অ্যাপল মেটাল প্লাগইন বিকাশ করার এবং এটিকে DaVinci সমাধানে সংহত করার একটি সহজ উপায়

Eine einfache Möglichkeit, Ihr eigenes Apple Metal Plugin zu entwickeln und es in DaVinci Resolve zu integrieren

Una forma sencilla de desarrollar su propio complemento Apple Metal e integrarlo en DaVinci Resolve

Un moyen simple de développer votre propre plugin Apple Metal et de l'intégrer dans DaVinci Resolve

अपना स्वयं का Apple मेटल प्लगइन विकसित करने और इसे DaVinci रिज़ॉल्यूशन में एकीकृत करने का एक आसान तरीका

独自の Apple Metal プラグインを開発して DaVinci Resolve に統合する簡単な方法

나만의 Apple Metal 플러그인을 개발하고 DaVinci Resolve에 통합하는 쉬운 방법

Uma maneira fácil de desenvolver seu próprio plug-in Apple Metal e integrá-lo ao DaVinci Resolve

Простой способ разработать собственный плагин Apple Metal и интегрировать его в DaVinci Resolve

Kendi Apple Metal Eklentinizi Geliştirmenin ve DaVinci Resolve'ye Entegre Etmenin Kolay Yolu

Một cách dễ dàng để phát triển Plugin Apple Metal của riêng bạn và tích hợp nó vào DaVinci Resolve

开发您自己的 Apple Metal 插件并将其集成到 DaVinci Resolve 中的简单方法

Getting Started With Maven - A Beginner's Guide to Efficient Java Build Management

Stories, News & Mentions about ADPLUG

Adplug’s Stories on HackerNoon