{"id":16582,"date":"2019-11-13T23:30:00","date_gmt":"2019-11-13T20:30:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2019\/11\/13\/core-ml-and-combine\/"},"modified":"2019-11-13T23:30:00","modified_gmt":"2019-11-13T20:30:00","slug":"core-ml-and-combine","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2019\/11\/13\/core-ml-and-combine\/","title":{"rendered":"Core ML and Combine"},"content":{"rendered":"

Over the weekend I was reading Combine: Asynchronous Programming with Swift<\/a> from my friends at raywenderlich.com when it occured on me that Combine and Core ML might make a nice couple.<\/p>\n

Combine lets you build reactive event processing chains<\/strong>. Doing inference with a Core ML model can be one of the stages in such a chain, as this is nothing more than another data transformation operation.<\/p>\n

In this blog post I\u2019ll show a simple way to put Core ML inside a Combine event processing chain. You can find the code in this gist<\/a>.<\/p>\n

Keep in mind that I have a grand total of about 2 days experience writing Combine code, so there might be better ways to do this. \ud83d\ude05<\/p>\n

Publishers, subscribers, operators<\/h2>\n

A typical processing chain for an image classifier looks something like this:<\/p>\n

\n \"The<\/a>
\n<\/figure>\n

The first stage in this chain is a publisher<\/strong>, in Combine terminology, of images.<\/p>\n

The last stage of the chain is a subscriber<\/strong> that takes the classification results and displays them in the app.<\/p>\n

The in-between stages in the chain are operators<\/strong>. These subscribe to the previous publisher in the chain, transform the input they receive, and publish the results to the next subscriber in the chain.<\/p>\n

For an image classifier, you want an operator that performs inference on the input image using Core ML. This is followed by an operator that filters the results you\u2019re interested in from the model\u2019s prediction, for example the top-5 classes with the highest confidence scores.<\/p>\n

In this blog post you\u2019ll see how to create a custom Combine operator that lets you run any kind of Core ML model. There are actually several additional stages in the processing chain, but this is the general idea.<\/p>\n

\n

Tip:<\/strong> Want to know more about how Combine works? Read the book!<\/a> \ud83d\ude01 Combine isn\u2019t very well documented right now \u2014 and can be mind-boggling if you haven\u2019t done reactive programming before \u2014 but the team at raywenderlich.com did a great job at making the topic accessible.<\/p>\n<\/div>\n

Get yourself a model<\/h2>\n

For this blog post I\u2019m assuming we\u2019re working with an image classifier \u2014 but the same technique works for any kind of model, even ones that don\u2019t use images.<\/p>\n

The model I\u2019m using in the sample code is SqueezeNet, the 16-bit version. You can download it<\/a> from developer.apple.com\/machine-learning\/models\/<\/a>. Feel free to use any other image classifier model instead.<\/p>\n

Create an instance of the model using the Xcode-generated helper class:<\/p>\n

let squeezeNet = SqueezeNetFP16()\n<\/code><\/pre>\n
It starts with an image\u2026<\/h2>\n
Because SqueezeNet is an image classifier, it makes sense to start the processing chain with an image object. Core ML likes to work with CVPixelBuffer<\/code> objects, but let\u2019s say you have a UIImage<\/code> instead.<\/p>\n
You can create a publisher for images as follows:<\/p>\n
let imagePublisher = PassthroughSubject<UIImage, Never>()\n<\/code><\/pre>\n
Now you can write imagePublisher.send(someImage)<\/code> to send the UIImage<\/code> object down the processing chain. Pretty easy.<\/p>\n
You could also use a different publisher here. For example, the UIImage<\/code> could come from an event chain involving the UIImagePickerController<\/code>, or from an event chain that downloaded the image using NSURLSession<\/code>, or from any other publisher that outputs image objects.<\/p>\n
Or you could publish a CGImage<\/code> or a CVPixelBuffer<\/code> object instead of UIImage<\/code>. And if your model expects a multi-array input, you\u2019d use a publisher that produces MLMultiArray<\/code> objects.<\/p>\n
The whole point of Combine is that you can put all these different building blocks together in whatever specific way makes sense for your app.<\/p>\n
The goal in this blog post is to run the Core ML model on the UIImage<\/code> coming from the imagePublisher<\/code>. As you may know, Core ML does not directly accept UIImage<\/code> objects as input so we\u2019ll have to convert it to a CVPixelBuffer<\/code> somehow. That will be one of the stages in the processing chain.<\/p>\n
Before we get into that, let\u2019s look at how we\u2019re going to run Core ML using Combine in the first place.<\/p>\n
The prediction operator<\/h2>\n
We need to create a Combine operator that lets us perform inference using a Core ML model and capture the output.<\/p>\n
We want to be able to write something like the following:<\/p>\n
imagePublisher\n  .prediction(model: squeezeNet)\n  .sink { value in print(value) }\n<\/code><\/pre>\n
The prediction<\/code> operator is what runs the given Core ML model. This operator is connected to the imagePublisher<\/code>, which is where it gets the input image from. In turn, it sends the prediction results to the sink<\/code> subscriber, which displays them to the user \u2014 in this case, by printing the value to debug output.<\/p>\n
Every time you call imagePublisher.send(someImage)<\/code>, this processing chain is automatically executed.<\/p>\n
We\u2019ll actually need to make the processing chain a bit more complicated than the above, but first let\u2019s look at how to implement this new prediction<\/code> operator.<\/p>\n
Here is the code:<\/p>\n
extension Publisher where Self.Output: MLFeatureProvider {\n  public func prediction(model: MLModel) \n              -> Publishers.Map<Self, Result<MLFeatureProvider, Error>> {\n    map { input in\n      do {\n        return .success(try model.prediction(from: input))\n      } catch {\n        return .failure(error)\n      }\n    }\n  }\n}\n\n<\/code><\/pre>\n
There are several ways to create a new Combine operator, but this is the easiest. You simply add a new function to the Publisher<\/code> namespace. (An operator is both a publisher and a subscriber.)<\/p>\n
Combine really loves generics, and getting the type signature correct is half the battle of writing a new operator. Let\u2019s examine what all these types mean\u2026<\/p>\n
To make this a general-purpose operator that works with any<\/em> Core ML model, we\u2019re using the MLModel<\/code> API, not the helper class that Xcode automatically generates for you. (The generated helper code is specific to a particular model and won\u2019t work with a different model.)<\/p>\n
The key thing to know about the MLModel<\/code> API is that the input data must be given by an MLFeatureProvider<\/code> object, and the output data also gets placed inside an MLFeatureProvider<\/code>.<\/p>\n
If you look at the automatically generated class for SqueezeNetFP16, you can see the input and output helper classes indeed do conform to MLFeatureProvider<\/code>:<\/p>\n
class SqueezeNetFP16Input: MLFeatureProvider {\n  ...\n}\n\nclass SqueezeNetFP16Output: MLFeatureProvider {\n  ...\n}\n<\/code><\/pre>\n
Because the input data for the MLModel<\/code> must be contained in some type that conforms to MLFeatureProvider<\/code>, we\u2019ve defined the new prediction<\/code> operator so that it only can be used with publishers whose output is an MLFeatureProvider<\/code>:<\/p>\n
extension Publisher where Self.Output: MLFeatureProvider {\n<\/code><\/pre>\n
That\u2019s what the where Self.Output: MLFeatureProvider<\/code> thing does. It tells Swift you can only call prediction()<\/code> in a processing chain if the previous element in the chain outputs an MLFeatureProvider<\/code>.<\/p>\n
The next line in the code was:<\/p>\n
  public func prediction(model: MLModel) \n              -> Publishers.Map<Self, Result<MLFeatureProvider, Error>> {\n<\/code><\/pre>\n
A Combine operator is a function on a publisher that returns a new publisher object. It\u2019s important to get the return type correct.<\/p>\n
We\u2019re simply reusing an existing publisher type, Publishers.Map<\/code>, that is the result of performing a map<\/code> operation on the processing chain. After all, doing inference with a Core ML model is really nothing more than a transformation on some data \u2014 and that\u2019s exactly what map<\/code> does too.<\/p>\n
The Publishers.Map<\/code> object takes two generic types:<\/p>\n
    \n
  1. \n
    First, the type of the upstream publisher, which is Self<\/code>. The upstream publisher is the one whose output you\u2019re running prediction()<\/code> on.<\/p>\n<\/li>\n
  2. \n
    The second type is Result<MLFeatureProvider, Error><\/code>. This describes the output from the Core ML model.<\/p>\n<\/li>\n<\/ol>\n
    If all goes well, the Core ML output is a new MLFeatureProvider<\/code> object that contains whatever the model computed. However, things don\u2019t always go well. In that case, Core ML throws an error.<\/p>\n
    There are different ways in which you can handle errors with Combine. Normally, if an error is thrown in a Combine processing chain, the subscription is \u201ccompleted\u201d in a failure mode and the subscriber no longer receives any events. I don\u2019t really like that for Core ML errors, so another way to handle potential error situations is to return a Result<\/code> object.<\/p>\n
    Actually running the Core ML model is done by this code:<\/p>\n
        map { input in\n      do {\n        return .success(try model.prediction(from: input))\n      } catch {\n        return .failure(error)\n      }\n    }\n<\/code><\/pre>\n
    Here, map<\/code> is the Combine operator that converts the input<\/code>, which is the MLFeatureProvider<\/code> object provided by the upstream publisher, into a Result<\/code> object that will be sent downstream.<\/p>\n
    We simply run the usual MLModel<\/code> prediction()<\/code> method and either return a Result.success<\/code> with the output MLFeatureProvider<\/code> or a Result.failure<\/code> with the thrown Error<\/code> object.<\/p>\n
    It\u2019s now up to any other stages in the processing chain to figure out how to handle the Result<\/code> object, and to deal with the error in case it\u2019s a .failure<\/code>.<\/p>\n
    If you always want to silently ignore errors, you can write the prediction<\/code> operator using compactMap<\/code> instead of map<\/code>, like so:<\/p>\n
    public func prediction(model: MLModel) \n            -> Publishers.CompactMap<Self, MLFeatureProvider> {\n  compactMap { input in try? model.prediction(from: input) }\n}\n<\/code><\/pre>\n
    Now if Core ML gives an error, try?<\/code> returns nil<\/code> and compactMap<\/code> will ignore such results \u2014 they don\u2019t get pushed any further down the processing chain. Note that the return type is different now too. We\u2019re returning a Publishers.CompactMap<\/code> object; and Result<\/code> isn\u2019t needed because things can never go wrong.<\/p>\n
    It\u2019s also possible to use tryMap<\/code> to complete the subscription upon the first error:<\/p>\n
    public func prediction(model: MLModel) \n            -> Publishers.TryMap<Self, MLFeatureProvider?> {\n  tryMap { input in try model.prediction(from: input) }\n}\n<\/code><\/pre>\n
    In fact, you can have all three of these versions of prediction()<\/code> in the code base. Swift can tell them apart based on the type of the input used in the next stage of the chain. For example, if the next stage expects an MLFeatureProvider?<\/code> object, it\u2019s obvious it should use the tryMap<\/code> version of prediction()<\/code>.<\/p>\n
    \n
    Note:<\/strong> If you get an error message, \u201cAmbiguous use of \u2018prediction(model:)\u2018\u201c, it means Swift has trouble figuring out which version of the operator to use. You may need to provide explicit type annotations to disambiguate.<\/p>\n<\/div>\n
    Building the chain<\/h2>\n
    At this point, we\u2019ve got two parts of the processing chain:<\/p>\n
      \n
    1. the publisher that provides UIImage<\/code> objects<\/li>\n
    2. the operator that can run inference using a Core ML model<\/li>\n<\/ol>\n
      But we can\u2019t connect these two things together just yet. This won\u2019t work:<\/p>\n
      imagePublisher\n  .prediction(model: squeezeNet.model)\n  .sink(receiveValue: { value in\n    print(value)\n  })\n<\/code><\/pre>\n
      The problem is that imagePublisher<\/code> produces UIImage<\/code> objects but, as you\u2019ve seen in the previous section, prediction()<\/code> expects to receive an MLFeatureValue<\/code> (because of the generics constraint we put on Self.Output<\/code>).<\/p>\n
      If you tried to type in the above code, Xcode\u2019s autocomplete does not suggest prediction<\/code> as a valid thing after imagePublisher.<\/code>, which is a good hint that the two cannot be directly connected.<\/p>\n
      What we need is some way to convert the UIImage<\/code> into an MLFeatureProvider<\/code> object.<\/p>\n
      This is not limited to image classifiers, by the way. Since we\u2019re using the MLModel<\/code> API to run Core ML, all input data must be put into MLFeatureProvider<\/code>, also if it\u2019s an MLMultiArray<\/code> or integers or strings or anything else.<\/p>\n
      Each piece of input data must first be converted to MLFeatureValue<\/code>, and all the MLFeatureValue<\/code>s for a given prediction request need to be placed into the same MLFeatureProvider<\/code> object.<\/p>\n
      Also, recall that Core ML wants a CVPixelBuffer<\/code> object, not a UIImage<\/code>. There are ways<\/a> to convert from UIImage<\/code> to CVPixelBuffer<\/code>, but as of iOS 13, you can directly use a handy API on MLFeatureValue<\/code>.<\/p>\n
      Here\u2019s how to do it:<\/p>\n
      let inputName = \"image\"\nlet imageConstraint = squeezeNet.model.modelDescription\n                                .inputDescriptionsByName[inputName]!\n                                .imageConstraint!\n\nlet imageOptions: [MLFeatureValue.ImageOption: Any] = [\n  .cropAndScale: VNImageCropAndScaleOption.scaleFill.rawValue\n]\n\nimagePublisher\n  .compactMap { image in                            \/\/ 1\n    try? MLFeatureValue(cgImage: image.cgImage!,\n                        orientation: .up,\n                        constraint: imageConstraint,\n                        options: imageOptions)\n  }\n  .compactMap { featureValue in                     \/\/ 2\n    try? MLDictionaryFeatureProvider(dictionary: [inputName: featureValue])\n  }\n  .prediction(model: squeezeNet.model)\n<\/code><\/pre>\n
      The conversion from UIImage<\/code> to MLFeatureProvider<\/code> is split up into two steps:<\/p>\n
        \n
      1. \n
        First we load the image into an MLFeatureValue<\/code>. This API takes the UIImage<\/code> \u2014 or actually its CGImage<\/code> \u2014 and scales it to the image dimensions the model expects. It can also rotate the image if it\u2019s not upright. The scaled and rotated image is stored in an MLFeatureValue<\/code> object. For each input in your model, you need to provide such an MLFeatureValue<\/code>.<\/p>\n<\/li>\n
      2. \n
        All the feature value objects for your model\u2019s inputs are placed into a single MLFeatureProvider<\/code>. This is done in the second step. We use a concrete implementation, MLDictionaryFeatureProvider<\/code>, that takes a dictionary that maps the MLFeatureValue<\/code> objects to the model\u2019s named inputs. There\u2019s only one input in SqueezeNet, named \"image\"<\/code>, but if your model has multiple inputs you\u2019d specify them all in this dictionary.<\/p>\n<\/li>\n<\/ol>\n
        For both of these steps we\u2019re using the compactMap<\/code> operator, so that if the try?<\/code> fails and returns nil<\/code>, the rest of the chain silently ignores the error. You can use tryMap<\/code> instead in case you want such errors to propagate down the chain.<\/p>\n
        Now that the UIImage<\/code> is wrapped in an MLFeatureProvider<\/code>, you can finally call prediction()<\/code> to perform inference.<\/p>\n
        Note that you can also replace the second compactMap<\/code> with the following:<\/p>\n
          .map { featureValue in\n    SqueezeNetFP16Input(image: featureValue.imageBufferValue!)\n  }\n<\/code><\/pre>\n
        This uses the Xcode-generated helper class, SqueezeNetFP16Input<\/code>, which as you\u2019ll recall implements MLFeatureProvider<\/code>. This can\u2019t go wrong, so you can use map<\/code> here instead of compactMap<\/code>. (The helper class actually expects the image as a CVPixelBuffer<\/code>, which you can get from the MLFeatureValue<\/code> object using the imageBufferValue<\/code> property.)<\/p>\n
        If your model uses an MLMultiArray<\/code> as input, or if your images aren\u2019t UIImage<\/code>, you\u2019ll naturally need to change how the input data gets mapped. You can use any Combine operators here, just make sure that the input to prediction()<\/code> is an MLFeatureProvider<\/code> of some kind.<\/p>\n
        \n
        Note:<\/strong> When you call prediction()<\/code>, you need to pass in an MLModel<\/code> instance. You can\u2019t use the squeezeNet<\/code> variable, which is an instance of the auto-generated helper class SqueezeNetFP16<\/code>. Instead, you need to write squeezeNet.model<\/code> to get the MLModel<\/code> object.<\/p>\n<\/div>\n
        Processing the results<\/h2>\n
        Depending on which version of prediction()<\/code> you use, its return value is either an MLFeatureProvider<\/code>, the optional version of that, or a Result<\/code> object.<\/p>\n
        Actually, at this point in time it could still be any one of these\u2026 Swift doesn\u2019t have enough information yet to decide which one to use. The next stage in the chain will determine this.<\/p>\n
        For example, if you write the following,<\/p>\n
        imagePublisher\n  \/* conversion from UIImage to MLFeatureProvider omitted *\/\n  .prediction(model: squeezeNet.model)\n  .map { result -> String in\n    switch result {\n      case .success(let featureProvider):\n        return featureProvider.featureValue(for: \"classLabel\")?\n                              .stringValue ?? \"error\"\n      case .failure(let error):\n        return error.localizedDescription\n    }\n  }\n  .sink(receiveValue: { value in print(value) })\n<\/code><\/pre>\n
        Swift will use the prediction()<\/code> that returns a Result<\/code> object, because the switch statement obviously expects a Result<\/code> here. Inside this map<\/code> operation, we convert the prediction result into a string. The sink<\/code> subscriber at the very end of the chain simply prints this string to the debug output.<\/p>\n
        The above works fine but it\u2019s still a bit messy, especially the code needed to read the results from the MLFeatureProvider<\/code> object:<\/p>\n
        featureProvider.featureValue(for: \"classLabel\")?.stringValue ?? \"error\"\n<\/code><\/pre>\n
        Yuck. The whole reason Xcode generates the helper classes is to hide this nastiness from you, so let\u2019s use those helpers as much as possible:<\/p>\n
        imagePublisher\n  \/* conversion from UIImage to MLFeatureProvider omitted *\/\n  .prediction(model: squeezeNet.model)\n  .compactMap { try? $0.get() }                  \/\/ 1\n  .map { SqueezeNetFP16Output(features: $0) }    \/\/ 2\n  .map { $0.classLabel }                         \/\/ 3\n  .sink(receiveValue: { value in print(value) })\n<\/code><\/pre>\n
        Here\u2019s how this works:<\/p>\n
          \n
        1. \n
          The .compactMap<\/code> step calls get()<\/code> on the Result<\/code> object. If the result was successful, this returns the MLFeatureProvider<\/code> object. This does the same as the first case in the switch statement above.<\/p>\n
          If the Result<\/code> was not successful, the try?<\/code> returns nil and compactMap<\/code> silently ignores the error. As before, you can use tryMap<\/code> here too.<\/p>\n<\/li>\n
        2. \n
          The first map<\/code> puts the MLFeatureProvider<\/code> inside the generated helper class, SqueezeNetFP16Output<\/code>. This makes the next step more convenient.<\/p>\n<\/li>\n
        3. \n
          Here you grab the classLabel<\/code> property from the helper class. This property contains the label of the class with the highest predicted probability. (If you\u2019re not using SqueezeNet, this property may have a different name in your model.)<\/p>\n<\/li>\n<\/ol>\n
          And finally, we use the sink subscriber to print the string to the debug output.<\/p>\n
          \n
          Note:<\/strong> You can of course combine the two map<\/code> operations into one:<\/p>\n
          .map { SqueezeNetFP16Output(features: $0).classLabel }<\/code><\/p>\n
          The reason I used two different steps is that some models have more than one output, and you may only want to do the conversion to the helper class just once.<\/p>\n<\/div>\n
          It\u2019s easy enough to change the result processing: just replace the map<\/code> operation with something else.<\/p>\n
          For example, if you wanted to get the dictionary of predicted probabilities for all classes instead of just the highest probability class label, you\u2019d simply grab the $0.classLabelProbs<\/code> property. Now the sink receives a dictionary of [String: Double]<\/code> values instead of a string.<\/p>\n
          You may also want to do some additional post-processing on the prediction results. For example, here\u2019s how you\u2019d get the top-5 classes from the dictionary:<\/p>\n
          .map {\n  $0.classLabelProbs.sorted { $0.value > $1.value }.prefix(5)\n}\n<\/code><\/pre>\n
          For a model such as SSD<\/a> that predicts offsets to anchor boxes, you could do the bounding box decoding here, and so on\u2026<\/p>\n
          The complete chain<\/h2>\n
          Here\u2019s what the full source code looks like:<\/p>\n
          class MyClass {\n  let squeezeNet = SqueezeNetFP16()\n  let imagePublisher = PassthroughSubject<UIImage, Never>()\n  var subscriptions = Set<AnyCancellable>()\n\n  func setUpProcessingChain() {\n    let imageConstraint = squeezeNet.model.modelDescription\n                                    .inputDescriptionsByName[\"image\"]!\n                                    .imageConstraint!\n\n    let imageOptions: [MLFeatureValue.ImageOption: Any] = [\n      .cropAndScale: VNImageCropAndScaleOption.scaleFill.rawValue\n    ]\n\n    imagePublisher\n      .compactMap { image in\n        try? MLFeatureValue(cgImage: image.cgImage!,\n                            orientation: .up,\n                            constraint: imageConstraint,\n                            options: imageOptions)\n      }\n      .map { featureValue in\n        SqueezeNetFP16Input(image: featureValue.imageBufferValue!)\n      }\n      .prediction(model: squeezeNet.model)\n      .compactMap { try? $0.get() }\n      .map { SqueezeNetFP16Output(features: $0) }\n      .map { $0.classLabelProbs.sorted { $0.value > $1.value }.prefix(5) } \n      .sink(receiveCompletion: { completion in\n        print(\"Received completion event\")\n      }, receiveValue: { value in\n        print(\"Received value:\", value)\n        \/* do something with the predicted value here *\/\n      })\n      .store(in: &subscriptions)\n  }\n\n  func performInference(image: UIImage) {\n    imagePublisher.send(image)\n  }\n}\n<\/code><\/pre>\n
          setUpProcessingChain()<\/code> should be called just once to set everything up. And now you have a Combine processing chain that, every time you send it a UIImage<\/code> object with imagePublisher.send(image)<\/code>, will automatically run a Core ML model on that image and process the results. Pretty cool!<\/p>\n
          Conclusion<\/h2>\n
          Should you use this technique? It certainly makes sense if you\u2019re using Combine elsewhere in your app.<\/p>\n
          Since the prediction()<\/code> operator works like any Combine operator \u2014 it\u2019s just a convenient wrapper around map<\/code> \u2014 you can put it into any of your Combine processing chains.<\/p>\n
          For even more convenience, you could even implement conversion from UIImage<\/code> (or whatever) to MLFeatureProvider<\/code> as another operator:<\/p>\n
          imagePublisher\n  .toFeatureProvider(image: someImage)\n  .prediction(model: ...)\n  .postprocessPredictionResults()\n  .sink { ... }\n<\/code><\/pre>\n
          As I write this, I haven\u2019t used Combine much yet, and definitely not in a real app, but it looks like an interesting way to do reactive programming on iOS devices. And now it works with Core ML too!<\/p>\n
          \n
          Note:<\/strong> This blog post showed only a very simple implementation of prediction()<\/code> that blocks the current thread. To perform the Core ML request asynchronously, it\u2019s probably a good idea to write a custom Publisher<\/code> class. But that\u2019s a topic for another day.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"
          Over the weekend I was reading Combine: Asynchronous Programming with Swift from my friends at raywenderlich.com when it occured on me that Combine and Core ML might make a nice couple. Combine lets you build reactive event processing chains. Doing inference with a Core ML model can be one of the stages in such a […]<\/p>\n","protected":false},"author":1,"featured_media":16583,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":[],"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[1],"tags":[],"class_list":["post-16582","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-explore"],"_links":{"self":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/16582","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/comments?post=16582"}],"version-history":[{"count":0,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/16582\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media\/16583"}],"wp:attachment":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media?parent=16582"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/categories?post=16582"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/tags?post=16582"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}