http://imagej.273.s1.nabble.com/vsi-file-corruption-Mac-tp5018990p5019001.html
Ah...I'll look for bit this - thank you. We have the .ets files, but are
not copying them. I want to say that we have had success with only the .vsi
copying is being done by macs. Might there be some convention clash?
> Hi Kenneth,
>
> the .vsi format can have an additional directory with the same name as
> the vsi file (but the ".vsi" stripped off), containing *.ets files.
> Maybe that directory did not get copied?
>
> Michael
>
> ________________________________________________________________
>
> On 28/06/2017 21:53, Kenneth Sloan wrote:
> > One more thing: while copying the .vsi file tends to corrupt it, running
> a plugin which uses BioFormats Importer to read the file from the original
> location always works.
> >
> > The corruption is specific to COPYING the .vsi file.
> >
> > --
> > Kenneth Sloan
> >
[hidden email] <mailto:
[hidden email]>
> > Vision is the art of seeing what is invisible to others.
> >
> >
> >
> >
> >> On Jun 28, 2017, at 14:50 , Kenneth Sloan <
[hidden email]>
> wrote:
> >>
> >> This one is strange.
> >>
> >> Environment: Mac, OS/X (may be specific to iMacs running slightly older
> version of OS/X, may be specific to the use of an external disk drive.
> >>
> >> We have .vsi files which contain two series. One series is a depth
> stack of ~20 16bit grayscale images. The other is at lower resolution and
> contains 3 planes. We are using the first series.
> >>
> >> With a well-formed .vsi file, manually running BioFormats prompts for a
> choice of which series to use. Running BioFormats Importer from an ImageJ
> java plugin, we can successfully import the correct series.
> >>
> >> With a CORRUPTED .vsi file, manually runnint BioFormats simply opens
> the second series (the first one is invisible)
> >> Running BioFormats Importer from an ImageJ java plugin produces the
> second series (which is not useful).
> >>
> >> Looking at the meta-date, it appears that the CORRUPTED files contain
> LESS meta-data (details available to anyone who knows what to do with it).
> >>
> >> How do the files become CORRUPTED? It seems that simply copying the
> file (either to another disk, or even to the same disk, will SOMETIMES
> corrupt the file. Some copies have been successful - but some (probably
> most) have produced corrupted files.
> >>
> >> Both the well-formed and corrupted files are exactly the same length.
> >>
> >> It looks to me as if some character in the middle of the meta-data
> becomes mangled.
> >>
> >> NOTE: I have seen the corrupting AND correct copying behavior on the
> SAME FILE.
> >>
> >> I’m stumped. I’ll probably try to get hex dumps of a correct and a
> mangled file to try to generate more clues.
> >>
> >> Does this ring any bells? Is there a .vsi file expert out there? With
> some effort, I think I can provide a correct, and mangled, version of one
> of these files to anyone who has the necessary knowledge.
> >>
> >> Note that this *may* be either a Mac issue, or a disk issue. As near
> as I can make out, all the offending copies were FROM a specific external
> drive, and done on one of two iMacs.
> >>
> >> One last twist…the person who generated most of these files was German,
> and may have used a Mac with German settings at some point.
> >>
> >> But…note that I have personally done two copies FROM the primary
> external drive TO a different external drive. One corrupted…and the second
> one did not. So, whatever is going on is intermittent.
> >>
> >> It’s *possible* that there may be a way to REPAIR the damage, once
> done. That’s what I’ll be working on right now - comparing good and bad
> copies to see if there is an easy way to patch the bad copies. I’m not
> really optimistic about that.
> >>
> >> --
> >> Kenneth Sloan
> >>
[hidden email] <mailto:
[hidden email]>
> >> Vision is the art of seeing what is invisible to others.
> >>
> >>
> >>
> >>
> >
> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>