"We can not access the URL currently."

Viewed 5121

I call google api when the return of "We can not access the URL currently." But the resources must exist and can be accessed.

https://vision.googleapis.com/v1/images:annotate

request content:

{
  "requests": [
    {
      "image": {
        "source": {
          "imageUri": "http://yun.jybdfx.com/static/img/homebg.jpg"
        }
      },
      "features": [
        {
          "type": "TEXT_DETECTION"
        }
      ],
      "imageContext": {
        "languageHints": [
          "zh"
        ]
      }
    }
  ]
}

response content:

{
  "responses": [
    {
      "error": {
        "code": 4,
        "message": "We can not access the URL currently. Please download the content and pass it in."
      }
    }
  ]
}
10 Answers

I have faced the same issue when I was trying to call the api using the firebase storage download url (although it worked initially)

After looking around I found the below example in the api docs for NodeJs.

NodeJs example

// Imports the Google Cloud client libraries
const vision = require('@google-cloud/vision');

// Creates a client
const client = new vision.ImageAnnotatorClient();

/**
 * TODO(developer): Uncomment the following lines before running the sample.
 */
// const bucketName = 'Bucket where the file resides, e.g. my-bucket';
// const fileName = 'Path to file within bucket, e.g. path/to/image.png';

// Performs text detection on the gcs file
const [result] = await client.textDetection(`gs://${bucketName}/${fileName}`);
const detections = result.textAnnotations;
console.log('Text:');
detections.forEach(text => console.log(text));

In my case, I tried retrieving an image used by Cloudinary our main image hosting provider.

When I accessed the same image but hosted on our secondary Rackspace powered CDN, Google OCR was able to access the image.

Not sure why Cloudinary didn't work when I was able to access the image via my web browser, but just my little workaround situation.

I believe the error is caused by the Cloud Vision API refusing to download images on a domain whose robots.txt file blocks Googlebot or Googlebot-Image.

The workaround that others mentioned is in fact the proper solution: download the images yourself and either pass them in the image.content field or upload them to Google Cloud Storage and use the image.source.gcsImageUri field.

For me, I resolved this issue by requesting URI (e.g.: gs://bucketname/filename.jpg) instead of Public URL or Authenticated URL.

   const vision = require('@google-cloud/vision'); 
   function uploadToGoogleCloudlist (req, res, next) {
       const originalfilename = req.file.originalname;
       const bucketname = "yourbucketname";
       const imageURI = "gs://"+bucketname+"/"+originalfilename;
       
       const client = new vision.ImageAnnotatorClient(
            {
            projectId: 'yourprojectid',
            keyFilename: './router/fb/yourprojectid-firebase.json'
            }
        );

    var visionjson;

    async function getimageannotation() {
        const [result] = await client.imageProperties(imageURI);
        visionjson = result;
        console.log ("vision result: "+JSON.stringify(visionjson));
        return visionjson;
        }

    getimageannotation().then( function (result){
        var datatoup =  {
                    url: imageURI || ' ',
                    filename: originalfilename   || ' ',
                    available: true,
                    vision: result,
                                };
    
    })
    .catch(err => {
        console.error('ERROR CODE:', err);
        });

    next();

    }

I faced with the same issue several days ago.

In my case the problem happened due to using queues and call api requests in one time from the same ip. After changing the number of parallel processes from 8 to 1, the amount of such kind of errors was reduced from ~30% to less than 1%.

May be it will help somebody. I think there is some internal limits on google side for loading remote images (because as people reported, using google storage also solves the problem).

My hypothesis is that an overall (short) timeout exists on Google API side which limit the number of files that can actually be retrieved.

Sending 16 images for batch-labeling is possible but only 5 o 6 will labelled because the origin webserver hosting the images was unable to return all 16 files within <Google-Timeout> milliseconds.

In my case, the image uri that I was specifying in the request pointed at a large image ~ 4000px x 6000px. When I changed it to a smaller version of the image. The request succeeded

Related