Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta data is different between ImageJ and RBioformats #11

Closed
gvogler opened this issue Mar 14, 2018 · 8 comments
Closed

meta data is different between ImageJ and RBioformats #11

gvogler opened this issue Mar 14, 2018 · 8 comments

Comments

@gvogler
Copy link

gvogler commented Mar 14, 2018

Hi!

I am getting different results for CXD files imported with ImageJ vs RBioformats. A couple of fields (related to image scale) are all set to '1' in RBioformats, whereas the same file metadata in ImageJ is correctly identified (using Bioformats plugin, 5.8.1).

Any ideas? This is a great R library, and for an automated file analysis I really would need this feature. A sample file can be found here:

https://www.dropbox.com/s/5txk8b1rorzs7m8/Data1051.cxd?dl=0

Best,

Geo

@aoles
Copy link
Owner

aoles commented Mar 20, 2018

Dear Geo,

many thanks for reporting this. Thank you for sharing the sample file. It would be really helpful if you could also provide some code which illustrates the issue, along with the expected values. For example, you could use the following template to filter by pattern.

Cheers,
Andrzej

meta = read.metadata("Data1051.cxd")
globalMetadata(meta, pattern=...)

@gvogler
Copy link
Author

gvogler commented Mar 20, 2018

Sure thing - here is the code I am using:

library(RBioFormats)
library(reshape2)

meta.data <- read.metadata("Data1051.cxd")

  # Get timecodes for all frames
  g <- melt(meta.data$globalMetadata)
  g$L1 <- paste0(g$L1,"    ")
  g$Field <- as.numeric(unlist(lapply(g$L1, function(x) substring(x,gregexpr(' ',x)[[1]][1]+1,gregexpr(' ',x)[[1]][2]-1))))
  g$Type <- unlist(lapply(g$L1, function(x) substring(x,gregexpr(' ',x)[[1]][[2]],gregexpr(' ',x)[[1]][[3]])))
  g$Type2 <- unlist(lapply(g$Type, function(x)gsub("[[:space:]]", "", x)))
  
  cxd_fields_timecodes <- g[which(g$Type2 == "Time_From_Start"),]
  cxd_fields_timecodes <- cxd_fields_timecodes[order(cxd_fields_timecodes$Field),]
  cxd_fields_intervals <- g[which(g$Type2 == "Time_From_Last"),]
  cxd_fields_intervals <- cxd_fields_intervals[order(cxd_fields_intervals$Field),]
  
  scale_factor <- g$value[which(g$L1 == "factor    ")]
  magnification <- g$value[which(g$L1 == "magnification    ")]
  # Add time interval to Metadata
  meta.data$coreMetadata$time_interval <- mean(cxd_fields_intervals$value, na.rm = TRUE)
  meta.data$coreMetadata$resolution <-   scale_factor * magnification

Scale factor and magnification should be (from ImageJ and the original recording software)

factor = 0.260000	;Current Calibration Scale Factor
magnification = 2.000000	;Current Calibration Magnification

but is

1

@aoles
Copy link
Owner

aoles commented Mar 21, 2018

Thank you for providing the sample code! Actually, there might be a problem with the postprocessing, as the annotation itself seems to be extracted properly:

library(magrittr)

res = meta.data %>% globalMetadata(pattern="factor|magnification")

## $factor
## [1] "0.260000\t;Current Calibration Scale Factor"
##
## $magnification
## [1] "2.000000\t;Current Calibration Magnification"

You could then use something along the following lines to perform the conversion to numeric.

lapply(res, function(x) as.numeric(gsub("\t;.*$", "", x)))

## $factor
## [1] 0.26
## 
## $magnification
## [1] 2

@gvogler
Copy link
Author

gvogler commented Mar 21, 2018

Perfect solution! I'm glad the problem was outside Rbioformats :-) Excellent package!

@gvogler gvogler closed this as completed Mar 21, 2018
@gvogler
Copy link
Author

gvogler commented May 9, 2018 via email

@aoles
Copy link
Owner

aoles commented May 13, 2018

Hi Geo,

thank you for reaching out and for reporting the disappointing performance of read.metadata. I will look int this, I've opened a dedicated issue in order to better keep track of it.

Best,
Andrzej

@gvogler
Copy link
Author

gvogler commented Sep 26, 2018 via email

@aoles
Copy link
Owner

aoles commented Sep 28, 2018

Long time no see :)

Thanks for reporting this, I will have a look into it. I have opened a dedicated issue #14 to keep track of it, if you have any further comments or observations please post them there.

Cheers,
Andrzej

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants