<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Cambria">Hi S<font face="Cambria">ebastien,<br>
<br>
<font face="Cambria">We have tried bfconvert <font
face="Cambria">on the <font face="Cambria">.r3d file </font>on<font
face="Cambria"> </font></font></font></font></font><font
face="Cambria"><font face="Cambria"><font face="Cambria"><font
face="Cambria"><font face="Cambria">RHEL5 </font></font></font></font></font><font
face="Cambria"><font face="Cambria"><font face="Cambria"><font
face="Cambria"><font face="Cambria">and RHEL<font
face="Cambria">6</font></font></font></font> distros<font
face="Cambria"> and with three different versions of java </font></font></font>(1.6,
1.7, 1.8) and the problem persists. One thing we noted is that when
we try to read the generated tiffs, we get an error message - see
below tiffinfo output. Would this be any indication where the
problem might be?<br>
<br>
Best,<br>
- Alex<br>
<br>
<br>
<font face="Cambria"><font face="Cambria"><font face="Cambria"><font
face="Cambria">[56] : tiffinfo vala.0.10.tiff <br>
TIFF Directory at offset 0x8 (8)<br>
Image Width: 1025 Image Length: 1024<br>
Resolution: 153846, 153846 pixels/cm<br>
Bits/Sample: 32<br>
Sample Format: IEEE floating point<br>
Compression Scheme: None<br>
Photometric Interpretation: min-is-black<br>
Samples/Pixel: 1<br>
Rows/Strip: 1<br>
Planar Configuration: single image plane<br>
ImageDescription: <br>
Software: OME Bio-Formats<br>
TIFFFetchDirectory: vala.0.10.tiff: Can not read TIFF
directory count.<br>
TIFFReadDirectory: vala.0.10.tiff: Failed to read directory
at offset 0.<br>
</font></font><br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 03/11/2016 01:17 AM, Sebastien
Besson (Staff) wrote:<br>
</div>
<blockquote
cite="mid:78DFBEB1-4B22-4452-849A-E85399578092@dundee.ac.uk"
type="cite">
<pre wrap="">Hi Alex,
thanks for letting us know. Keep us posted about the outcome of your
investigation.
Best,
Sebastien
</pre>
<blockquote type="cite">
<pre wrap="">On 10 Mar 2016, at 00:22, Alexandre Cunha <a class="moz-txt-link-rfc2396E" href="mailto:cunha@caltech.edu"><cunha@caltech.edu></a> wrote:
Hi Sebastien,
Many thanks for taking the time to check on this and reporting here.
I have done an investigation on the redhat cluster that I am having the problem and, although not conclusive yet, I found out just a few minutes ago that it seems the problem might be with the system itself. A simple run of "pnmpsnr a.pgm b.pgm" is reporting that the "images don't differ" while in fact they strongly do. There has been a major kernel update on the system and this might have screwed things up. I apologize for the possible false alarm. Again, this is not conclusive yet and the investigation continues but please put on hold any work with the .r3d problem I reported. The culprit might be on our end after all. I will report back.
Best,
- Alex
On 03/09/2016 12:54 PM, Sebastien Besson (Staff) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Alex,
thanks for the additional information. I tried to reproduce your issue on CentOS 6.7
with one of the r3d files in our data repository. However I was unsuccessful at
reproducing it. After converting the image using the same command as you
posted and importing both the original and the converted one into OMERO, pixels
have the same intensities.
Would it be possible for you to upload one of your failing images at
<a class="moz-txt-link-freetext" href="http://qa.openmicroscopy.org.uk/qa/upload/">http://qa.openmicroscopy.org.uk/qa/upload/</a>
Best,
Sebastien
</pre>
<blockquote type="cite">
<pre wrap="">On 8 Mar 2016, at 19:13, Alexandre Cunha <<a class="moz-txt-link-abbreviated" href="mailto:cunha@caltech.edu">cunha@caltech.edu</a> <a class="moz-txt-link-rfc2396E" href="mailto:cunha@caltech.edu"><mailto:cunha@caltech.edu></a>> wrote:
Hi Melissa,
The output of md5sum is the same for both systems. The tiff validation is nothing special. I did a visual check of a few slices and they are totally off, the .r3d is a FISH image with a few bright spots on a dark background, all float values, and the generated tiff is a saturated bright all over for some slices and a mix of saturated and dark pixels for others. I also checked a few pixel values using "gmic -o -.asc". Though the tiffinfo reporst 32-bit floats on the Redhat system, the actual values seem to be integers at 16-bit quantization, it doesn't make sense. Some unsolicited conversion is being done.
I tried different versions of java, installed an up-to-date libtiff, but the problem persists on the Redhat system - not on Ubuntu. I didn't build bfconvert from source but used bftools.zip to deploy it in both systems. I can't tell for sure if there is something wrong with the Redhat cluster - it is, after all, a possibility - but this is the only application I am aware is behaving oddly.
Let me know if you would like me to send directly to you the .r3d I am using for tests and a few generated tiff slices.
Best,
- Alex
On 03/08/2016 06:32 AM, Melissa Linkert wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Alex,
Thank you for reporting this.
</pre>
<blockquote type="cite">
<pre wrap="">We run bfconvert to convert .r3d files, (Deltavision, 32-bit floats) into tiff slices, as in
bfconvert -separate file.r3d slice.%c.%z.tiff
for further processing. It works well under Ubuntu 14.04 but it chokes under Red Hat Enterprise Linux Server release 6.7 producing faulty tiff slices (pixel values are incorrect, e.g. all pixels have 65535). In my tests I use bfconvert versions 5.0.2 and 5.1.8 on both systems.
</pre>
</blockquote>
<pre wrap="">
We're trying a few things to duplicate the problem now, but in the
meantime could you please confirm that the output of 'md5sum file.r3d'
is the same on both systems? It would also be useful to know which
software is being used to validate the converted TIFF files, as that
may help to point us in the right direction.
Regards,
-Melissa
On Mon, Mar 7, 2016 at 7:01 PM, Alexandre Cunha <<a class="moz-txt-link-abbreviated" href="mailto:cunha@caltech.edu">cunha@caltech.edu</a> <a class="moz-txt-link-rfc2396E" href="mailto:cunha@caltech.edu"><mailto:cunha@caltech.edu></a>> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi,
We run bfconvert to convert .r3d files, (Deltavision, 32-bit floats) into tiff slices, as in
bfconvert -separate file.r3d slice.%c.%z.tiff
for further processing. It works well under Ubuntu 14.04 but it chokes under Red Hat Enterprise Linux Server release 6.7 producing faulty tiff slices (pixel values are incorrect, e.g. all pixels have 65535). In my tests I use bfconvert versions 5.0.2 and 5.1.8 on both systems.
I was wondering if this is a known problem on RedHat machines and/or .r3d files. Any advice?
Many thanks,
- Alex
---
[607] : bfconvert -version
Version: 5.1.8
VCS revision: 9eb8da31c1f01989f439963b9cc215b4398bedd8
Build date: 12 February 2016
OR
(bfconvert -version
Version: 5.0.2
VCS revision: 0c4215a
Build date: 27 May 2014)
lsb_release -a
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 6.7 (Santiago)
Release: 6.7
Codename: Santiago
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty
_______________________________________________
ome-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a> <a class="moz-txt-link-rfc2396E" href="mailto:ome-users@lists.openmicroscopy.org.uk"><mailto:ome-users@lists.openmicroscopy.org.uk></a>
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">_______________________________________________
ome-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a> <a class="moz-txt-link-rfc2396E" href="mailto:ome-users@lists.openmicroscopy.org.uk"><mailto:ome-users@lists.openmicroscopy.org.uk></a>
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users</a>
</pre>
</blockquote>
<pre wrap="">
The University of Dundee is a registered Scottish Charity, No: SC015096
_______________________________________________
ome-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
ome-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users</a>
</pre>
</blockquote>
<pre wrap="">
The University of Dundee is a registered Scottish Charity, No: SC015096
_______________________________________________
ome-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ome-users@lists.openmicroscopy.org.uk">ome-users@lists.openmicroscopy.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users">http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users</a>
</pre>
</blockquote>
<br>
</body>
</html>