Hi @wiswedel, hi all,
I think the funky characters are kind of normal as these, I suppose to recall, are some sort of control but not really text characters. When these strings are displayed, they’ll get interpreted no matter what. Though, I tried copy & pasting the string into Sublime which can / should be able to cope with that and still see them.
Anyways, about the purpose, I am working on a a simple appraoch to extract the XML Meta Data. These are easily extractable when the binary object is converted to a string. Purpose is to create a workflow to identify duplicated images.
About your idea to limit the amount of characters dispalyed. Mabye a lazy loading upon the cell size is getting increased might provide a better experience. It might also allow to still copy the entire cell content comapred to a capped string. It also seems the amount of characters are cut off liek an excerpt but based on Knime’s behavior they actually might not?
What makes me curious, though, is the contradicting behavior of Knime. Whilst only a fixed amoutn of cells are hold in memory, it seems, based on the heavy disk throughput, the entire data is getting read.
@carstenhaubold coming to your question, I am using the default setting which means I am using the default row based backend.
@ScottF glad to help. I have added the corresponding images to the originally posted workflow about the MD5 issue and uploaded it to the HUB. I noticed that the UI, upon trying to configure the row filter, became totally blocked again but only little to no CPU and zero disk I/O. I waited for several minutes but the config dialogue didn’t want to open. Heap space indicator, CPU utilization of around five to six percent and a 0.1 % disk I/O did indicate Knime was working. At the end I had to force quite Knime agian 
I can consistently reproduce teh instability for the Row Filter “3_IMG_0941”. I first attached it to the table creator to configure it, the re-wired and executed it. Upon trying to configure it, Knime again “collapsed”.
Upon saving and opening the workflow I observed yet again another, not experienced before, sitaution. Knime did some extensive disk I/O but before, even opening the same workflow right after app launch, the workflow opened rather quick. The usual loading window with the progress bar did not appear.
Hope that helps!
Cheers
Mike