Don't allow jpeg export of Big images

[will-moore]

From http://trac.openmicroscopy.org.uk/ome/ticket/10841
For Big images, if we try to run Batch_Image_Export with any format, we should return a "Not supported" message.

This is simply an extension of #30 to apply to ALL formats (not just OME-TIFF).

NB: haven't tested this locally because of issues with https://trac.openmicroscopy.org.uk/ome/ticket/10970

To test:

• Try to run Batch_Image_Export.py with any Big image, choosing format as JPEG, then again with OME-TIFF.
• Should get the same message with each.

[pwalczysko]

Bug: Error after try to execute Batch_image_export.py

• select /test_images_good/hamamatsu/philippe/fluorescence/PHAS 01.ndpi [Series 1] in user-4, read-only-1 on gretzky
• open in full viewer
• go Scripts -> Batch_image_Export
• error appears

Traceback (most recent call last):

  File "/home/omero/slave/workspace/OMERO-merge-develop/src/dist/lib/python/django/core/handlers/base.py", line 111, in get_response
    response = callback(request, *callback_args, **callback_kwargs)

  File "/home/omero/slave/workspace/OMERO-merge-develop/src/dist/lib/python/omeroweb/decorators.py", line 387, in wrapped
    retval = f(request, *args, **kwargs)

  File "/home/omero/slave/workspace/OMERO-merge-develop/src/dist/lib/python/omeroweb/decorators.py", line 424, in wrapper
    context = f(request, *args, **kwargs)

  File "/home/omero/slave/workspace/OMERO-merge-develop/src/dist/lib/python/omeroweb/webclient/views.py", line 2360, in script_ui
    raise ex

ValidationException: exception ::omero::ValidationException
{
    serverStackTrace = 
    serverExceptionClass = 
    message = Can't find params for 2. Stderr is in file 406

---stderr---
  File "./script", line 352
    if len(images) == 1:
    ^
IndentationError: unexpected indent

}


<WSGIRequest
GET:<QueryDict: {u'Image': [u'66']}>,
POST:<QueryDict: {}>,
COOKIES:{'sessionid': 'da84288d26375a9833f7fb421469e13f'},
META:{'DOCUMENT_ROOT': '/htdocs',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTPS': 'on',
 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'en-us',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_COOKIE': 'sessionid=da84288d26375a9833f7fb421469e13f',
 'HTTP_HOST': 'gretzky.openmicroscopy.org.uk',
 'HTTP_REFERER': 'https://gretzky.openmicroscopy.org.uk/omero/webclient/userdata/?experimenter=-1',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10 (KHTML, like Gecko) Version/6.0.3 Safari/536.28.10',
 'PATH': '/usr/local/bin:/usr/bin:/bin',
 'PATH_INFO': u'/webclient/script_ui/2/',
 'PATH_TRANSLATED': '/htdocs/webclient/script_ui/2/',
 'QUERY_STRING': 'Image=66',
 'REMOTE_ADDR': '10.12.1.88',
 'REMOTE_PORT': '55278',
 'REQUEST_METHOD': 'GET',
 'REQUEST_URI': '/omero/webclient/script_ui/2/?Image=66',
 'SCRIPT_FILENAME': '/home/omero/OMERO-CURRENT/var/omero.fcgi',
 'SCRIPT_NAME': u'/omero',
 'SCRIPT_URI': 'https://gretzky.openmicroscopy.org.uk/omero/webclient/script_ui/2/',
 'SCRIPT_URL': '/omero/webclient/script_ui/2/',
 'SERVER_ADDR': '134.36.65.227',
 'SERVER_ADMIN': '[no address given]',
 'SERVER_NAME': 'gretzky.openmicroscopy.org.uk',
 'SERVER_PORT': '443',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SIGNATURE': '<address>Apache/2.2.14 (Ubuntu) Server at gretzky.openmicroscopy.org.uk Port 443</address>\n',
 'SERVER_SOFTWARE': 'Apache/2.2.14 (Ubuntu)',
 'SSL_TLS_SNI': 'gretzky.openmicroscopy.org.uk',
 'wsgi.errors': <flup.server.fcgi_base.TeeOutputStream object at 0x3bd60d0>,
 'wsgi.input': <flup.server.fcgi_base.InputStream object at 0x3bd6bd0>,
 'wsgi.multiprocess': True,
 'wsgi.multithread': False,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'https',
 'wsgi.version': (1, 0)}>

[pwalczysko]

The above error is independent of the image you are trying to run Batch_image_Export on. It happens on small images as well. It does not happen with other scripts.

[will-moore]

@pwalczysko Thanks - That's just a silly bug that I missed since I couldn't test it locally. Fixing...

[bpindelski]

This works OK in general, but in particular two things seem confusing:

1. There is a green tick in the activities window even if the export didn't logically succeed (see screenshot)
   
2. The small i icon, when clicked, doesn't always display the script output - sometimes the URL is about:blank, other times after a couple of random clicks it's webclient/get_original_file/123

[will-moore]

Hmmm - We're getting a green tick now (instead of the error we were getting before) because we're checking / handling this case better, instead of getting an Exception.
cc @jburel @joshmoore Do we want some nicer way of the script telling the UI that it "Failed to do what was asked" but didn't throw any unexpected exception?
Also, from a UI point of view, cc Gus, should a "Not supported" message have a green tick, a red error (exception) or something else?

[joshmoore]

I'd vote on a red X. From the point of view of the API, this is likely a ValidationException, meaning something got passed to a method that it wasn't intended/designed for. We can always extend that to make a "BigImagesUnsupportedException`. (I'm serious)

[will-moore]

re.renderCompressed() doesn't throw API exception with Big Images (works OK on a 4k x 4k image).
Even for the OME-TIFF, where we did get that exception, the script runs "OK" no exception to runScript() and the exception simply appears in the script std err. So we have to pass the std.err manually in the client to know if the script threw an exception.

[joshmoore]

I was more saying that I'd consider the script to "throw" that exception. Of course, if you'd like us to push that deeper into one of the service methods we can look at that, too.

[pwalczysko]

The green tick: We are talking about Batch images export here. So please note that there might be a very good possibility of having a mixture of big and small images in your selection, big will be rejected, small will be processed. In this case the green tick makes perfect sense but you might never find out what happened with your big image jpeg which is missing, and which you have exported as well.

But the main functionality works fine, so I would recommend to merge this.

[will-moore]

@joshmoore Maybe we need to chat about this, since I'm not quite understanding you on this. How is the client supposed to know if the script 'Failed' or 'Succeeded'? By parsing of the stderr?

[joshmoore]

Happy to chat. Places to look:

• JobStatus.value == 'Error'
• ProcessPrx.poll() != 0
• ProcessCallback.processFinished(returnCode) != 0

All three of these would evaluate to True if an exception were thrown from the script itself. But all of that is likely outside the scope of this PR, and we should review all the scripts in terms of error codes. Also happy to file this away as an RFE if the current behavior is not confusing.

[joshmoore]

RFE ticket added (at high priority) https://trac.openmicroscopy.org.uk/ome/ticket/11147

Merging. Thanks all.

[mtbc]

Should this be rebased to dev_4_4?

[joshmoore]

Would probably be a good idea.

[sbesson]

--rebased-to #45