Import digital documents ; the case of images

[edsz14]

I tested importing a .jpg file, which is indeed also processed by Tika.
The result is fine, with a link to the image immediately being available.
My only concern is the fact that the resulting html-file has still real contents but only in the '' tags, meaning the text-preview doesn't show anything. The presentation of that text-preview should be made conditional on the 'size of v95' being >0, as was the case in the previous version of DubCore (with the previous docbatchimport.php script) but even with that in place here an empty preview box will be present. So the tags should be avoided in the output-html file ?
Example of such meta-tags output from a jpg-image :
'









'... etc.

[rogercgui]

About this, I thought of an idea, which I don't know if it is possible, but I will share it for you to evaluate.

Some systems embed images inside the database with base64 encoding. I evaluated a software some time ago that all the system's photo storage was embedded in the database itself as text with base64 encoding.

I did a conversion test here with an 87kb photo and a text file was generated with 130,841 characters with 128kb, I don't know if this is a limiting factor but it worked.

To convert an image to test I used this external tool: https://elmah.io/tools/base64-image-encoder/

To display in PFT I put:

'<img src="data:image/jpeg;base64,'v99'">'
or

'<img src="data:image/png;base64,'v99'">'
 

I also found these links to help:

• https://stackoverflow.com/questions/8499633/how-to-display-base64-images-in-html
• https://base64.guru/developers/php/examples/decode-image
• https://stackoverflow.com/questions/3967515/how-to-convert-an-image-to-base64-encoding

[edsz14]

Embedding the image in an ISIS-database, using base64 encoding, is possible, for sure, but I am afraid many images, esp. of higher quality (as required in e.g. Cultural Heritage applications), will exceed the max. size allowed. Taking a ratio of 1 to 1,3 for base64 images (about 30% overhead), images should nog exceed 650Kb. Most 'normal' pictures fit within this size I think, but not the ones of high resolution, let alone 'raw'. The question is why would one want to embed the pictures ? Fred asked the same about the text-documents : in the 'old' application there is an option to store the text inside the record, with the same issue of limited size. My opinion was, when I decided to have that option, that it could lead to a more 'portable' database which could be moved around without - if not that important - dragging the original files which are mostly much larger. Same reasoning could be done for pictures, so I don't mind having such an option but then indeed using base64. I was using base64 already for manipulating UTF8 document-names and being able to have them embedded in URLs for linking. On Monday, October 4, 2021, 01:49:59 PM GMT+2, Roger C Guilherme ***@***.***> wrote: About this, I thought of an idea, which I don't know if it is possible, but I will share it for you to evaluate. Some systems embed images inside the database with base64 encoding. I evaluated a software some time ago that all the system's photo storage was embedded in the database itself as text with base64 encoding. I did a conversion test here with an 87kb photo and a text file was generated with 130,841 characters with 128kb, I don't know if this is a limiting factor but it worked. To convert an image to test I used this external tool: https://elmah.io/tools/base64-image-encoder/ To display in PFT I put: '<img src="data:image/jpeg;base64,'v99'">' or '<img src="data:image/png;base64,'v99'">'   I also found these links to help: - https://stackoverflow.com/questions/8499633/how-to-display-base64-images-in-html - https://base64.guru/developers/php/examples/decode-image - https://stackoverflow.com/questions/3967515/how-to-convert-an-image-to-base64-encoding — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[rogercgui]

Exactly! The portability of the bank without the need to parallel load a folder full of images is what made me think of this possibility.

Of course it is necessary to make an evaluation about the growth of the bank and also evaluate the purpose.

Thinking about textual documents in jpg format, for example, we wouldn't have the text indexing anyway. It would be necessary to do an OCR on the image, but in the case of photos, it would be an interesting solution.

The profile photos of the user base would be a good place to store the photos as base64, because it would solve the path problems that need to be configured each time we install.