Downloads

In order to use the offline tester / visualizer tool for testing your solution locally, you'll have to modify your solution by adding the main method that interacts with the tester / visualizer via reading data from standard input and writing data to standard output. Since you do not change the implementation of methods getFigures and getPartLabels, this doesn't affect the way your solution works when being submitted to our server.

To simulate a single test case, your program should read the following data from standard input in this exact order (each integer/string is located in a separate line):

Integer H.
Integer W.
Integer iLen specifying the number of elements in image.
Integers image[0], image[1], ..., image[iLen - 1], in this order.
Integer tLen specifying the number of elements in text.
String text[0], text[1], ..., text[tLen - 1], in this order.
Integer callType indicating what type of test case this is (detecting figures or part labels).

Once this data is read, pass it to your implementation of getFigures method (if callType is 1) or of getPartLabels method (if callType is 2) and let ret be the return value. Write the following data to standard output in this exact order (each integer/string in a separate line):

Integer len denoting the number of elements in ret.
Strings ret[0], ret[1], ..., ret[len-1], in this order.

Make sure to flush the standard output after all this data is written.

In other words, you should implement the following pseudocode in the main method of your solution:

    H = parseInt(readLine())
    W = parseInt(readLine())

    iLen = parseInt(readLine())
    for (i=0; i < iLen; i++)
        image[i] = parseInt(readLine())

    tLen = parseInt(readLine())
    for (i=0; i < tLen; i++)
        text[i] = readLine()

    callType = parseInt(readLine())

    if callType == 1
        ret = getFigures(H, W, image, text)
    else
        ret = getPartLabels(H, W, image, text)

    printLine(length(ret))
    for (i=0; i < length(ret); i++)
        printLine(ret[i])

    flush(stdout)

In order to run the tester / visualizer, you should use one of the following two commands:

java -jar PatentLabelingVis.jar -exec "<command>" -img <image_file_name> -txt <patent_text_file_name> -ans <answer_file_name> -fig
java -jar PatentLabelingVis.jar -exec "<command>" -img <image_file_name> -txt <patent_text_file_name> -ans <answer_file_name> -prt

The first command simulates a call of getFigures and the second one simulates a call of getPartLabels.

<command> is the command you would use to execute your solution. If your compiled solution is an executable file, the command will just be the full path to it, for example, "C:\TopCoder\solution.exe" or "~/topcoder/solution". In case your compiled solution is to be run with the help of an interpreter, for example, if you program in Java, the command will be something like "java -cp C:\TopCoder Solution".

<image_file_name> is the name (absolute or relative to JAR's working directory) of the image which should be used for the test. We only guarantee the correct work of the tester on images from the provided training set (though in practice it should be able to work with other monochrome images as well).

<patent_text_file> is the name of file containing the patent's text. If there is no text available, you need to provide an empty file.

<answer_file_name> is the name of file containing the expected correct answer for this test case. It must be in the same format as ".ans" files in "figures" and "parts" folders of the training dataset.

Additionally you can use the following parameters (all are optional):

-dlev <debug_level>. Used to control the amount of output generated by the tester. The debug level of 0 would display only the score and errors. The level of 1 additionally displays execution time, performance/correctness scores, intersection/precision/recall measures. The level of 2 will also display the progress of the testing process.
-vis <result_image_file_name>. This allows to visualize the result produced by your solution into the file provided in result_image_file_name. Note that disregarding of file's extension, the resulted image will always be in JPEG format.
-tc <color>. You can choose the color used to draw the correct (expected) bounding boxes. This option (and all subsequent options) only makes sense if you use -vis option. The color must be a string of 6 hexadecimal characters. First two characters denote the red component in hexadecimal system, second two characters denote the green component and last two characters the blue component. Alternatively, it's possible to provide the string "NONE" (quotes for clarity), which means that expected boxes must not be visualized. The default color is red.
-tw <width>. This allows to choose the width of the expected boxes (in pixels). The default value is 3.
-yc <color>. This is the color used to draw the boxes produced by your solution. The format is the same as in -tc option. The default color is blue.
-yw <width>. This is the width of the boxes produced by your solution. The default is 3.
-mc <color>. This is the color used to draw matching boxes (matches by the scoring algorithm during intersection measure calculation). "NONE" would mean that matching boxes should not be distinguished from other boxes (but it doesn't mean that they must not be drawn at all). The default value of this parameter is "NONE".
-mw <width>. This is the width of matching boxes. The default value is 3.

You can print any debug information of your solution to the standard error stream and it will be forwarded to the standard output of the tester.

We made our best to produce a tester / visualizer tool that is convenient to use. However, if you notice that it lacks some features convenient for you, you are allowed to download the source code and modify it according to your needs.

For more information on using offline testers, please check the following recipe draft from TopCoder Cookbook. Note that this is not a troubleshooting thread, please use the match forum for questions instead.