OCRTEXT fails with relative image paths

[Bahbus]

I have images saved in a separate folder and tied to my data using relative paths:

Trying to use OCRTEXT() in a VC on this image field returns nothing. These same pictures work fine in the OCR Demo when being directly added to a form. Is this a known issue, or unintended?

These images otherwise display normally within AppSheet and there are no other issues.

[Koichi_Tsuji]

hi @Bahbus

I assume your app settings should be different from one I quickly created to test this.
I made two table. One to store simply save image file. Second table to pick image from 1st table through suggested values and then OCR text filed capture the text out of it.

The image file is firstly save to image table where the relative path is captured to DB. Then the same relative path is refered and used on table 2.

Based on this, OCR Text worked out.

To assist your investigation.

[Bahbus]

Hmm. Perhaps there is some sort of difference from how I manually built the string originally vs how AppSheet would if I were to have created the entry through it. I played with the various secure image access blah blah blah settings. No changes. This is why I don’t understand where exactly the failure point is. It’s the same picture either way. AppSheet sees it either way. And there isn’t much documentation to go on.

[Fabian_Weller]

Hi @Bahbus how do you use OCRTEXT()? In a form or via an Action? Because OCRTEXT() is not yet working with Actions.

[Bahbus]

My first attempt was to throw it in a VC (guess I should have mentioned that part), just to pull the text of some pictures waaaaay after the fact. I saw the part where it doesn’t yet work with actions/workflows and such. I haven’t gotten back to playing with it yet. So I figure its either the VC, the relative path being weird for the function, or something else buggy.

[Fabian_Weller]

Got it. You could contact Support. Last time I had an Issue with OCRTEXT @tony was able to fix it fast. Perhaps it’s just a use case they didn’t thought about.

[Bahbus]

Yeah, I’m just trying to gather as much info before I get him involved.

[Bahbus]

I’m pretty sure at this point that OCRTEXT() straight up doesn’t work outside of a Form environment at the moment. Changing it to a real column. Putting OCRTEXT() in the initial value, and setting to reset on edit didn’t help either UNLESS I edited and “reupload” the picture manually.

This means I also cannot have this picture change dynamically and OCR it.

[Fabian_Weller]

Yes this is also what I observed.
OCRTEXT is only working in a form with user interaction.

[tony1 · Accepted solution]

This is correct, OCRTEXT will only work when evaluated inside a form. Virtual Columns with an OCRTEXT app formula do not currently work. This is on our todo list.

[Bahbus]

Well then at least its on the todo list. I would have been mad if there was no documentation on it and it wasn’t on the todo.

[tony1]

Good point. I’ll make sure the docs are updated today.

Just a little bit of background: Almost all of AppSheet’s functions perform simple operations that quickly finish. For example, ABS(-3.14) or CONCATENATE("Foo", "Bar"). However, the OCR functionality is significantly slower since it involves making a round-trip call to AppSheet’s server. This means there’s a period of time when your app is sitting and waiting for the results to come back. None of the other functions in AppSheet behave in this way, which means that OCR doesn’t “fit in” with a lot of the expression language.

We’re looking to fix this problem in a way that would allow for these long-running functions (OCR and beyond) to be composed with the rest of the system.

[Bahbus]

Hmm, well, I believe you guys already have the ability on the backend to know when certain things are updated (since there are sync options related to it). So, would it be possible setup the OCRTEXT function to work in VCs, but to keep the potential sync time down, automatically “delta sync” that column?

I feel like the backend logic would be a much more complicated form of:
IF(OR(ISBLANK([_THIS]), [_THISROW_BEFORE].[Image]<>[_THISROW_AFTER].[Image]),
OCRTEXT([Image]),
Do Nothing)

If it runs in this kind of manner by default, I feel like the performance hit would be manageable. There should only be huge spikes if a large number of pictures need to be OCR’d, but if its only when new images are added or existing ones change, then the performance at all other times should be back to normal. Theoretically.

Now that I’m thinking about it, this sounds similar to the problem with geocoding and why there is no direct way to access that either.