Fresh image processing #258
Conversation
| @@ -65,6 +65,7 @@ public: | |||
|
|
|||
| public slots: | |||
| void setAngle(double angle); | |||
| void setScaledImage(const QImage& image, double scale = 1.0); | |||
There was a problem hiding this comment.
scaled image is just the image used in the UI, not the one used when recognizing. See Displayer::getImage.
There was a problem hiding this comment.
It's just for testing. As far as i remember from our previous discuss about it, i should extend interface of Displayer.
This is actually non-trivial. The Displayer always queries the images directly from the source (i.e. an image file or pdf or djvu document) with the appropriate resolution, either for displaying in the gui, or for passing to tesseract for OCR. The getImage image method is only there for selection tools etc which need to operate on the currently displayed image. Conversely, a setImage method would make little sense because you would only be setting the image used for the UI at the current zoom level etc.
I see two options:
Parametrize the processing steps, so that they are applied to each rendered image, as is done for brightness, contrast etc, see
https://github.com/manisandro/gImageReader/blob/master/qt/src/DisplayRenderer.cc#L31
But I fear this might be too slow.
Otherwise you'd need to have the processing algorithms create a new temporary image, which is then passed to the displayer as a source. To make it elegant, you could actually extent the Source structure
https://github.com/manisandro/gImageReader/blob/master/qt/src/SourceManager.hh#L32
to allow specifying an alternative path to use instead of the path actually specified by the source, and if that path is not empty, then that image is used instead. This has the benefit that you don't need to pollute the source list in the UI with extra entries for the processing output. This alternative path entry would probably have to be a
QMap<int, QString>
since for multi-page documents you will need a temporary image for each page. For multi-page there is the additional challenge when to generate these temproary images, since generating them all at once will probably be to slow. Probably better to just generate them on demand.
I hope this makes sense to you.
There was a problem hiding this comment.
You'll probably want to do something similar to DisplayRenderer::adjustImage.
There was a problem hiding this comment.
Actually it depends on what operation you are performing, if they are operations which take a long time and should not be repeated everytime the image is redrawn, then you'll probably want to create a new temporary image with the operations applied, and then use that as source.
There was a problem hiding this comment.
Hah, it's quite difficult to choose, because different image operations have different duration: from milliseconds to seconds. E.g. denoising is very expensive operation.
then you'll probably want to create a new temporary image with the operations applied, and then use that as source.
Create on disk and then reload from disk?
There was a problem hiding this comment.
You can look into image_processing sources: i use for it Doxygen.
There was a problem hiding this comment.
I'm familiar with doxygen, but again, I'm not convinced it helps much here besides blowing up the size of the source files.
There was a problem hiding this comment.
About SourceManager::addSource method: but in this case as fasr as i understand my temporary item will be added to QListWidgetItem. Is it ok?
There was a problem hiding this comment.
Another idea could be to extend the Source struct by adding a QMap<int,QString> preprocessedImages, where you store, for each page, the preprocessed image. If such a page exists, the Displayer will render that image instead of the one of the original source. You can then give the user the option to revert to the original image, in which case the entry in preprocessedImages is simply discarded. This approach would also make it easy to apply the algorithms to all pages of a multipage document, without polluting the sources list with tons of entries.
There was a problem hiding this comment.
I like this idea.
|
Also please check UI. Now it's simple set of buttons for performing different algorithms. |
|
How do you envison the UI in the releasable version? If they remain simple button, I suppose a combobox with the respective entries in the advanced image controls toolbar would work just as well. |
|
Also, how likely is that an algorithm will "wreck" an image? If that can happen, you'll either need a preview or a undo/redo. Preview is easier I suppose ;) |
Of course, always there is some chance to make error in image processing algorithm :-) This question is very important and should be discussed. I see several ways to deal with it:
|
I want to clone UI from Abbyy FineReader to gIR. And in FineReader they have separate dock widget for image processing. Image proccesing UI will not be easy buttons. We will extend it with some customizable features: e.g. user must to be able to regulate denoise power, because we can't do it automatically. |
|
For a start I'd just add a notification bar asking the user whether he wants to apply the change. |
|
Do you have any other warnings/suggestions? |
|
Nope, with correct source logic and polished UI should be good! |
|
Ok, nice. Thank you for the review :-) |
|
Hi @zamazan4ik, I've finally ended up releasing 3.3.0, so we can start again with feature work, if you are still interested in pursuing this. |
|
Closing since this appears to be abbandoned. |
Hello @manisandro .
I have createdfresh branch for image processing stuff. Can you check it please?