Known Bugs & Problems

When developing and expanding complex software such as the Virtual Light Table, the occasional occurrence of various technical problems and bugs can never be completely avoided. It seems indispensable to me to deal with these as transparently as possible so that users are aware of the current state of the software and know which problems are currently being addressed or will soon be corrected in a new release version.

Reporting discovered bugs is very welcome. See also the section "How can I report a bug?" below.

Please note: bugs will remain as "solved" in the list until they have become part of a new software version. They will be noted down in the version log and removed from this list.

List of Registered Bugs & Problems

If you click on an item, you will get a more in-depth description of the problem.

Type
Short Description
Status
Entry Date
🐞 Bug
Undo/Redo Disturbs Annotation Pins
The undo/redo feature of the VLT casually interferes with the annotation pins on the main table. This will result in unexpected behaviour of the pins, like showing up on the wrong sides or showing up whilst you were hiding them in the first place.
⚡ Problem
Annotation Pins and Object Changes
Annotation Pins are fixed to a specific location (x and y coordinate) on an object. However, if you change the object (e.g. by replacing the underlying image of a side, or by using a different masking technique), the reference values for the x and y coordinates change. Therefore, the pin will no longer be in the correct position.
It is unclear so far how to solve this issue. One way could be to simply delete all pins when changing an object. However, this would also include scientific remarks done in the past that could not be redone again. Detached pins could also cause a warning, prompting the user to re-position their pins before they can save the table. A third option might be to add the pins to the upload view, such that the user can rearrange the pins before finally editing the object.
⁉ Improvement
Computational Time for Segmentation
The automatic segmentation of images is a computationally expensive and thus time-consuming task. The larger the images (and the older the computer's configuration), the longer the inference for the machine learning process will take. However, maybe there are ways to speed up the process a bit without introducing even much more computational complexity. No matter how large the input image, the window size of the used machine learning model will remain the same. And one cannot change a lot in the size of the image, as the machine appears to be very dependent on the object's size resolution. However, this might lead to cases where many samples in the sliding window approach do not even contain an object, but rather a completely unicolored background. If such samples could be immediately detected and skipped, this would already mean some boost in time.
⁉ Improvement
Segmentation Models for Lower Resolutions
Machine learning models for the automatic segmentation of papyrus images are somewhat dependent on the resolution of the input image. Tests have shown that a model trained for images of 400ppi resolution significantly perform worse if the resolution of the input image deteriorates too much from that value. The development of resolution-independent networks for the semantic segmentation of images is an ongoing research. A way of mitigating this problem might be to provide different models for a range of input resolutions. New machines for resolutions of 50, 100 and 200ppi are in preparation.
🐞 Bug
Data Requests without Internet Connection
During the start of the Virtual Light Table, the software requests for some files to check its capabilities, available models and new software versions. However, if there is no working internet connection, requests to the internet will automatically fail. This currently results in an exception error popup and it seems the VLT can no operate. However, the VLT is supposed to work offline as well, and should thus mask such problems and simply hide aspects that would require a working internet connection.
⚡ Problem
Handling of Large Image Files
The Virtual Light Table is a graphical application that works under the bonnet with web technology, more precisely with a chromium-based browser as the render engine. Even with commercial graphics editing programmes, problems can arise if the input data is unusually large. This can happen, for example, for high-resolution images of objects that may even have been stitched.

The canvas or the stage, which are used to display objects on the Virtual Light Table, are not necessarily designed for this. Problems may arise if the input files are too large.

I currently see three solutions for this:
  • The user can independently ensure that the files have an appropriate size by reducing the image files before the input into the VLT.
  • The VLT itself can be given a limit for the size of the image files. If an image is larger than appropriate, it is automatically reduced in size. Of course, this means that for a later export all position-related data must be scaled accordingly.
  • For the presentation in the export view, where the highest possible quality of the source images is unavoidable, the use of IIIF could become interesting.

In addition, thought must also be given to whether and how saving and, above all, forwarding can function with large images.
🐞Bug
MacOS and Python
There seems to be a problem with the VLT on MacOS (at least some systems) recognising an installed and working python distribution. Usually, when the VLT does not recognise a working python environment (i.e. it cannot call a python script using the commands python or python3) it automatically closes and opens the python download webpage. This is intentional, as the VLT cannot work without python. Surprisingly, it seems this can even occur IF there is a working python distribution installed.

Solution: It seems that the installation of Xcode Command Line Tools helped for the Python command to work again. So if you hit this problem as well, try opening a terminal and install Xcode via xcode-select --install. I'm not quite sure about the technical details here, but at least it seems to have worked so far.
🐞Bug
TPOP Image Selection Button not Working
When selecting fragments from the Turin TPOP collection and there are no images defined for a side of the object, this usually means that there IS an image, but I have no algorithmic chance to identify it correctly. Therefore, there is a button that let's you choose manually. However, the recto version of this button does not seem to work.

A workaround is to select an image for the verso, then switch sides, making that image recto, and now selecting the real verso.
🐞Bug
TPOP Image Selection Button not Showing Up When Image Deleted
When working with images from the Turin TPOP collection and removing at least one side of the object in the editing window, the TPOP Image selection button should show up, allowing you to choose from the array of available images. However, it does not. This needs to be fixed.
🐞Bug
Automatic Segmentation for Images Too Small
The models for the automatic segmentation have a specific input window size, e.g. they require an input of 256x256 pixels. IF the input image is too small, because it has been scaled down for resolution reasons or maybe because the source image itself was too small already, the segmentation will fail without a meaningful error. Instead, the error should be clarified. Additionally, images that are too small should be rescaled (keeping the aspect ratio) such that they fulfil the minimum requiremens of the machine.
🐞Bug
Recentering Images in the Export View
It sometimes happens that the recto and/or verso view in the export window become decentered for whatever reason. It's not possible to recenter them accordingly afterwards. This needs to be fixed. For now, the easiest workaround for this is to simply close the export view and reopen it again.

How Can I Report a Bug?

In general, the more information on a problematic software behaviour you can provide, the easier it becomes to identify, locate and eventually fix the problem for the developer. Therefore, please provide all the information you have available. This may include the following:

In addition, you should add the VLT's logging files that might give me a better view on what happened during execution. You will find the two files (log.txt and log_scripts.txt) in your computer's application subfolder.

You can also reach this folder by opening the Loading Window of your VLT and clicking on the greyed out path field at the top in case you haven't changed your default save location. This should open a file explorer to your default save folder, which is a subfolder of the application folder. If you move one level up in the file structure, you should find the two files.

Send all information you can gather to me using my contact details.

Aside from that, you can also submit a GitHub Issue to inform me about your problem.