Bug: Thumbnail generation after import

[jburel]

Thumbnails seem to be correctly generated and displayed in the import window.
Then back to the data manager, the thumbnails displayed are all black when browsing dataset.
It does not happen for all images

The problem is certainly related to the getThumbnailBySet method

Problem noticed for example with al3d, avi

[pwalczysko]

It also happens intermittenlty for noaa-hrd/AL112001_1009_0130 and for nikon/carol/316 S30-2 B90 G120 R100 030.tif. The thumbnails were black in Data Manager as described above, then, after images were opened in Full Viewer (not sure if this is the cause), the thumbnails started to appear correctly in Data Manager. Compared with Web, the same thumbnails there had similar behaviour..

[jburel]

Note that the problem disappears when one image is viewed or viewed in web.

[jmoore]

For the case seen by Roger where thumbnails appear in pairs, my guess is that it's caused by a swallowed exception on setPixelsId. (See upcoming log for full details).

 37 2013-01-16 15:10:10,746 INFO  [        ome.services.util.ServiceHandler] (l.Server-1)  Meth:    interface ome.api.ThumbnailStore.setPixelsId
 36 2013-01-16 15:10:10,746 INFO  [        ome.services.util.ServiceHandler] (l.Server-1)  Args:    [1150]
 35 2013-01-16 15:10:10,751 INFO  [                 org.perf4j.TimingLogger] (l.Server-1) start[1358345410746] time[5] tag[omero.call.exception]
 34 2013-01-16 15:10:10,751 WARN  [        ome.services.util.ServiceHandler] (l.Server-1) Unknown exception thrown.
 33 
 32 org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [ome.model.meta.Experimenter#>
 31     at org.hibernate.engine.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:637)
 30     at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:305)
 29     at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:246)
 28     at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:112)
 27     at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
 26     at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:679)
 25     at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:671)
 24     at org.hibernate.engine.CascadingAction$5.cascade(CascadingAction.java:252)

[pwalczysko]

Similar behavior with .pgm. The thumbnail was black in Data Manager, okay in importer window.
This time, the black thumbnail persisted, although the image was opened twice in full viewer.
See screenshots

[pwalczysko]

Another format with black thumbnail (Data Manager only) is .txt (test_images_good/text/a_fixall_buta1a2.txt). Compare with Howe (screenshots). This time, the thumbnail does not appear okay even after the image was opened in full viewer.
The thumbnail is displayed okay though in Web Client on Gretzky (screenshot).

[jburel]

Tested locally with a fresh build of develop

`
Submodule path 'components/bioformats': checked out 'fe1a095045607bedf7e375fc1b26182d04f22545'

1a4c781 (HEAD, origin/develop, origin/HEAD, thumbnails) Merge pull request #621 from joshmoore/bump-submods

`

I could not reproduce the problem noticed during yesterday's testing against gretzky

[jburel]

Debugging

ome.conditions.InternalException:  Wrapped Exception: (org.hibernate.NonUniqueObjectException):
a different object with the same identifier value was already associated with the session: [ome.model.meta.Experimenter#0]
	at org.hibernate.engine.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:637)
	at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:305)
	at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:246)
	at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:112)
	at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
	at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:679)
	at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:671)
	at org.hibernate.engine.CascadingAction$5.cascade(CascadingAction.java:252)
	at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:392)
	at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:335)
	at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:204)
	at org.hibernate.engine.Cascade.cascade(Cascade.java:161)
	at org.hibernate.engine.Cascade.cascade(Cascade.java:127)

[jburel]

Exception thrown while trying to reset the default. Improve the error handling in insight.

[rleigh]

Alternate thumbnails are now black

[rleigh]

With the latest changes to the bfPixelBuffer on current gretzky builds, alternate thumbnails in the importer window are no longer a copy of the previous series; they are now black. See above screenshot.

[jburel]

This required some investigation. Mark could you do it?

[jamoore]

Jean-Marie mentioned this needing evaluation sooner rather than later. Moving to blocker.

[mtbcarroll]

I'll find time this week to start investigating.

[mtbcarroll]

Tried importing al3d, avi, pgm, haven't yet reproduced the issue locally. Will try gretzky on a day when it's not being used for file format testing.

[mtbcarroll]

I'm still not seeing this; today on gretzky I've tried importing al3d, avi, nikon/carol, noaa-hrd, pgm and the thumbnails come fine. The al3d/Iron Plate.al3d.ome.xml one is black but it's black after I've looked in the full image viewer and refreshed and whatnot too, so I'd guess that's a different issue.

[mtbcarroll]

(yes, it turns out for al3d that "OME-XML file doesn't contain any BinData?, so it is expected to be black")

[mtbcarroll]

Also tried importing the same files in a local non-merge develop build, still works fine, and no exceptions in the logs.

[mtbcarroll]

Please reopen if it is observed again. In that event, any further clues about how to reproduce it would be great.