Add a test to audit tool: fail if volume has no images

[TBRC-Travis]

Audit tool should trigger an error if a volume only contains scan request files and no images

This issue arose out of https://github.com/buda-base/library-issues/issues/315

[TBRC-Travis]

Write use case for this scenario, and consider making tests configurable per user since this test case isn't necessary for all users

[TBRC-Travis]

This test only applies to the "images" folder for a given work. If an image group folder under the "images" directory contains only 2 scan request files, and no images, then the audit test should fail. why? because if we sync a work with a volume that only contains scan request files it shows up on the website as having images, which isn't the case.

[jimk-bdrc]

@TBRC-Travis How can a machine distinguish between a scan images and regular images? What if an imagegroup contains only two monochrome images?

[TBRC-Travis]

I suppose we can't unless we want to start embedding some kind of distinguishing metadata in our scan request files.

IMHO this is a highly improbable edge case, so my vote would be to go ahead and let it fail and if there really was a two-page volume with monochrome images then allow for the test to be disabled after the fact.

[jimk-bdrc]

Resolved: create a test for a minimum number of files in ArchiveParent and DerivedImageGroup parent. Test property is in shell.properties. Error can also be a warning.

[eroux]

I had to sort scan request pages for thumbnail generation, one easy way to check is the width / height in pixels

[jimk-bdrc]

That works when you have reference materials, (i.e. pages which have different aspect ratios) but might fail when scan request page size == image page size. Since audit tool is a desktop product as well as a centralized website (soon), it has to be simple and reliable, and can't contain too many heuristics about its content.

…

On Thu, Feb 4, 2021 at 11:11 AM Elie Roux ***@***.***> wrote: I had to sort scan request pages for thumbnail generation, one easy way to check is the width / height in pixels — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH7LSRL3CPDBWOP4XWCZK43S5LBKTANCNFSM4UMFLFZQ> .

[jimk-bdrc]

There is a very reliable heuristic which doesn't involve examining a file's internals - it's the eXists database: IG XML DOC. See archive-ops #256 The return has image groups:

<work:volumeMap>
<work:volume imagegroup="I1PD34157" num="1"/>
<work:volume imagegroup="I1PD34158" num="2"/>
</work:volumeMap>

Querying each image group with the same query https://www.tbrc.org/xmldoc?rid=I1PD34157 gives the files in the image group, as well as the "intro images"

<imagegroup:images tbrcintro="2" total="0"/>

It should be simple enough to capture this output and make decisions on what is there. (Note there's a variant result which could have <imagegroup:images tbrcintro="2" total="2"/> in which case there's a pipe delimited list of images, which could be taken to be the scan request images.

[jimk-bdrc]

Can we use a BUDA equivalent?

[jimk-bdrc]

See buda-base/lds-queries#70 for solution. http://purl.bdrc.io/query/table/AO_iginfo?R_RES=bdr:I0886