updating eynollah README, how to use it for use cases

[vahidrezanezhad]

No description provided.

[cneud]

Does <output image> here expect a filename or a path? Because when it uses the path it would be nicer to be consistent with the CLI documentation for layout analysis and also call this <output directory>.

[vahidrezanezhad]

Binarization for a single image requires a filename (preferably in PNG format). As you suggested, I can update this to accept a file path instead. However, this change would also affect the OCR-D framework. What are your thoughts on this, @kba?

[kba]

We can adopt the OCR-D processor if the API changes but IIUC this would only be about the CLI, i.e. replacing the arguments with the same -i/-o options as eynollah layout? If so, then fine by me.

[cneud]

After giving it some more thought, I would prefer to adapt the eynollah binarization CLI to follow the example of layout analysis CLI, i.e. it should work like this:

eynollah binarization \
  -i <single input image> | -di <directory containing image files> \
  -o <output directory> \
  -m <directory containing model files>

So this would require some changes in the binarization CLI:

1. Change the order of arguments (input and output before models)
2. Add mandatory -i also for single input image file
3. Make -o mandatory and always use inputfilename.bin.png as output filename
4. Use -o for both cases, single and batch image processing outputs (no more -do)

But imo it should make it more easy and intuitive to use the different modules for end users and via OCR-D wrappers.

[cneud]

I would remove this and include the directory flow in the example call above, just like it is for layout analysis.

[cneud]

Suggested change

	<input image> \
	<input image> | -di <directory containing image files> \

[cneud]

Is this correct? For directory input, the flag -di can be used, but for a single image there is no -i flag?

[vahidrezanezhad]

yes it is the case