No display of images with default configuration

[henning-gerhardt]

After a long time I created a new virtual machine with a new Kitodo installation (1.11.2) with a local database. So no changes in the configuration files should be necessary. After adding needed ruleset file, adjusted goobiopac.xml file for using SWB catalogue, creating a small project and for this project a template with 4 steps (creating process with status done, uploading images with status open, metadata editing with status closed and dms export with status closed). With this template I created a new process and uploaded some files into the created images directory `master_media` with correct owner and file rights. After closing upload step I switched to metadata editor to add some structure and metadata objects. But all uploaded files are not visible.

After some changes of parameters DIRECTORY_PREFIX, DIRECTORY_SUFFIX and MetsEditorDefaultSuffix I explored that parameter MetsEditorDefaultSuffix must be set to same content as parameter DIRECTORY_SUFFIX.

Did I something wrong or should the parameter MetsEditorDefaultSuffix changed to display images on a default configuration?

[henning-gerhardt]

Maybe this issue is relevant to issue #129 as dms export is influenced by this parameter too.

[matthias-ronge]

The first folder the application looks for is one that ends with DIRECTORY_SUFFIX and does not start with DIRECTORY_PREFIX. If there is no such folder, it uses the first of any folders ending in MetsEditorDefaultSuffix (independent of whether it starts with DIRECTORY_PREFIX or not). [These lines are duplicated in both instances of the code. One of both blocks each can be deleted safely We already had that discussion, I remember. But this was obviously before the code merge.] If there is no such folder either, the folder name used (i.e. in error message that there is no folder) is composed of process title, _ and DIRECTORY_SUFFIX.

The code causing this behaviour is located in Prozess.java and FolderInformation.java (duplicate, subject to #568).

[henning-gerhardt]

It is all right, but new users does not expect this behaviour.

They put files into this automatic generated directory and expect that this files are displayed. They does not expecting that this directory is ignored or that they must create a different directory and must put all files into this directory to get image files displayed.

Changing DIRECTORY_PREFIX does not help as the next created process use this new content of DIRECTORY_PREFIX to create the new image directory.

In my humble opinion must value of MetsEditorDefaultSuffix changed to same of DIRECTORY_SUFFIX. Maybe a notice should be added to MetsEditorDefaultSuffix that the directory with this ending is preferred used for displaying inside metadata editor and for export usage (to fix #129).

[matthias-ronge]

A good solution would be to have a folder look-up method that takes an enum as input with constants for the different reasons/usages of the folders that it should look up. As far as I know, there are at least four different usages for images:

1. preview generation in meta-data editor
2. passed as variables to shell script calls (i.e. OCR)
3. PDF download button
4. conditional file group generation on export depending on existence of folder

Maybe there are more options that I am not aware of. There are also three levels of input images that we have to deal with:

• Pre-generated preview images (typically JPEG, low resolution, to use as preview in meta-data editor so that they do not need to be generated on the fly—this is a typically only used if preview generation on the fly is too slow, imagine ≥ DIN A0 maps, scanned with 600 dpi)
• Source images (typically uncompressed TIFF, high(er) resolution, with image filters applied) that should be used for preview image generation, if there are no pre-generated images, and output in presentation or PDF generation.
• Raw images (typically TIFF, too). Raw images have no image filters applied, and may even be higher resolution. They may be required if the project sponsor wants raw images to be saved. They should not be used for preview or output generation, unless none of the above is available, because image post processing is missing.

How usages interact with image folders (depending on presence) is not absolutely clear.

[matthias-ronge]

I would like to suggest to keep this issue open, because clean-up is required here. I would prefer a solution that allows variable directories to be specified in the core configuration:

# define some directories that are used
directory.legacy_raw=orig_{0}_tiff
directory.legacy_source={0}_tiff
directory.raw=master_{0}_media
directory.source={0}_media
directory.web={0}_small
directory.ocr={0}_ocr
directory.alto={0}_alto

along with project specific settings which folders shall be used for what, and which folders shall be created automatically:

<goobiProjects>
  <project name="default">
    <foders usage="METADATA_EDIOR">web,source,raw</foders>
    <foders usage="PDF_CREATION">source,web,raw</foders>
    <foders usage="CHECK_FILEGROUP">source</foders>
    <foders usage="someStringAvailableToVariableReplacer">source,raw</foders>
    <createFolder>source</createFolder>
    <createFolder>ocr</createFolder>
    <createFolder>alto</createFolder>

Something this way. Maybe the core configuration is unneccessary at all and it can go all into the project config?

[henning-gerhardt]

I would suggest:

• discussion of clean-up directory handling /usage should be moved to its own issue
• a general configuration for this directories independent of projects and a project specific configuration if somebody needs this (1)
• a good explanation how to use this directory configuration

(1) we have about 20 project configurations inside goobi_project.xml, adding 20 identical directory configuration parts is something which should be avoided as long there is no project configuration inheritance (for example define everything in default project and in inherited projects you overwrite only necessary parts - but this is an other story).