Cross section area pixel measurement discrepancies between imagej and cell profiler



Hi all!
I managed to create a working pipeline for measuring the csa of muscle’s fibers, but i noticed something strange. The pipeline work well in recognizing and counting the areas of every fiber, but the area in pixels, compared to the same area analysed previously with the csa imagej plug-in, is at least 3-4 time bigger.
I know from previous work that imagej is right and i suppose that in my pipeline, inadvertently, i implemented a module that enhance the pixel density for the image.
Or at least something similar.
Unfortunately, i can’t figure out which module is causing this problem and, due to this, i can’t implement a “correction factor” in my measurement.

Someone can give me some hint about this?

thank-you in advance

CSAworking20x_2.0.cpproj (411.4 KB)


Can you also give us an example image, and preferably also the “correct” answer for that image?

I’m not precisely sure how this would be possible unless your image at some point got resized, so we’ll need so help getting this troubleshot.


@bcimini here you can find a link to two sample images i used and a excel file where i summarized the differences in the results.
I too think that somewhere in the pipeline i resized the image.

Strangely, i noticed that if i divide all the data obtained for all the images for 1.6*2 i obtain a result similar to imagej.
1.6 is the conversion factor from pixel to micrometers that i use, but i multiply the pixel area only once in my pipeline.
Plus, i suppose that cellprofilre doesn’t provide the result directly in micrometers right?
looking at the graphs i see that the overall distribution maintain the same shape, but in cell profiler look magnified.


Hi! I tried to test the pipeline on other images like this one, but every time the program give back this error:

I’m pretty much stuck with this pipeline at this point.


ok. errore resolved, but i still can’t understand why the two measurement are so different. Any idea to help me? thanks


Indeed, CellProfiler does not report values in units of micrometers (there is no place to enter this information, as you may have noted).

It instead reports values in units of pixels. If it is an area metric then one would indeed expect your pixel-to-micrometer constant to be squared (1.6^2). If it is a linear metric (such as perimeter), one would expect it to be only 1.6x.

Does that help to explain? My guess is that if you adjusted ImageJ’s pixel-to-micrometer conversion factor to equal 1, both softwares would yield the same results.


Thank you for the answer.
Unfortunately the imagej data were provided to me by my superior to test the pipeline.
To be sure about the result i used the same conversion method that they used, that is to multiply the area in pixel, obtained from the program, for 1.6.
I’ll try to follow your hint and test out if the result yield is the same changing the scale in imagej.
What baffled me is that even the result in pixels is widely different and, looking at an histogram of said data, i can clearly see that the distribution “shape” is conserved, but in cell profile is magnified several time.



ah, i did notice that if i take my results in pixel from cellprofiler and divide it for 2 i obtain a pretty similar total mean value.



If you still would like me tot take a look, would you be kind enough to “renew” your folder that has the spreadsheet files so that I can see them, and re-upload your pipeline? I want to see exactly what values you’re comparing between to try to resolve this, but the spreadsheet in the box is expired and we’re having problems at the moment downloading files that are more than ~7 days old due to a forum migration issue.


Hi @bcimini,
i will not be able to re-upload everything before Monday.
I think that the problem about these discrepancies can be split in two parts.
The first part was a math error that i resolved after checking again the confocal used by the laboratory that gave me the imagej data.
Now i have two pretty close results. In imagej i obtain a mean of 2727,802 micrometers (CSA), in cell profiler 2132,096.
I believe that this is due my tentative to thicken the laminin “net” to fill the holes in it and make more stable and accurate the procedure to identify the objects.
Now i’m pretty much stuck searching for a way to first restore, at least in part, the laminin net, without compromising the measurement.
If i use the module to identify the objects without working on the net it generates to many errors, forcing me to edit a lot of object manually. I understand that a manual editing is needed, but i would like to reduce it to a minimum.
I have with me the pipeline and some images similar to the ones that i uploaded.

CSAworking20x_2.0.cpproj (892.5 KB)

here are some images


i decided to change approach and did a makeover to my pipeline.
Fortunately this week i followed a course for imaging done by Nikon and now my mantra is “Binary is better”.
Now the pipeline is more slender and accurate.
CSA_3.0.cpproj (1.3 MB)

Probably this time @Minh will not have a seizure looking at the pipeline. ahah

if you all have suggestions to improve the pipepline they are more than welcome.

Btw… i will test the old images to check if this time the area measurements are matching


Ok. did the test on a new set of images .nd2 of a calibrated confocal.
From the image properties i know that i have 0.62 um/px.
My math is 1/0.62^2= conversion factor, than i take this factor and multiply my areas for it.
Bummer is that i have areas 10 times bigger of what should be.
Usually a murine tibiali CSA go fro 100 to 7000 um, in this case i have CSA that go form 1000 to 64.000.
I don’t think that is a pipeline problem, but i fear that our confocal, with the time, lost its calibration.

Funny thing is that without the math the measurements are in the right range. ahah



May I ask about the need for using a conversion factor, when you already knew a pixel size?

For example, consider an imaginary object of size 10 x 10 squared pixel, it should be the same size in any softwares, not just ImageJ or CellProfiler.

Given that 1 pixel = 0.62 micron, then such 10x10 object would be = 0.62 x 0.62 x 10 x 10 = 38.44 squared micron, no matter what software was used.
(as Anne mentioned, if you don’t do any conversion in any software, just purely measure the area in squared pixel, we suspect both softwares should report similar values)

You can try a toy test: create an image of a 10x10 object by Photoshop or Powerpoint, then measure it under ImageJ and CP.


P.S: your images are pretty ! but probably you may want to rescale them (inside CellProfiler) to have better contrast and segmentation.


effectively for the .nd2 images i can use directly the math AREA x 0.62^2.
Instead, for the TIFF i don’t know what conversion to do. This images are not taken by me and are from an associated laboratory that literally just sent me the images writing " just multiply for 1.6" without telling me what 1.6 is.

At the end is just a matter of math, so i’ll send them the measurement in pixel and they will do their share.

With the nd2 i had problem because who took them didn’t even look at the LUT, giving me over saturated images… but cell profiler is really good.

About you P.S. can you explain the theory behind the effect of rescaling on the segmentation? Rescaling will not change the area measured? and the contrast on a binary image is still valuable?

Ps. a little request for a the future… is possible to include a “thick” option for the object’s outline in the “EditObjects” module? If i fill them i lose the possibility to identify an undersegmentation in an object and the normal outline is too thin. ^^



Totally agree the conversion is purely math and can be done by anyone who works with spreadsheet.

I soon realized that you will be using the “masks” for your onward analysis. In that case please don’t mind about the contrast. It’s only helpful if you have faint raw images. Rescaling helps stretch the image, for e.g. using 0.05-0.95 intensity percentile instead of min-max, the signal-to-noise ratio might be then improved in some cases, and thus helpful for the segmentation.

Regarding the thick/thin option in EditObjectsManually, it’s actually an useful suggestion. Others may know it better, but I’m with you :smiley:


If you want to make an official feature request, you can do so in this repo here. Create a PR with a markdown file of your request (and anything you can do to help find what changes would need to be made in the code!).

Thanks for the input!