Why do I get such different values for R, G and B for very similar photos?

I previously asked this question here. .Since then I have been finding answers little by little to the doubts that have arisen.

In short, I am applying a mask to a series of photos of a sample which is changing color over time. From each of these photos I am measuring the mean R, G and B values within the mask and then transforming them to L, a and b, and finally obtaining the Delta E values between each photo and the first one.

At first, with small samples, everything worked well, and I was able to obtain graphs like the following:

these from samples such as the following:

However, then, using larger samples, I am getting values like the following:

As I said, the only thing I did was to increase the sample size (plus change the time between each photo from about three per second to one per second, and increase the total number of photos by almost 2000).

The origin of the problem seems to be in the measurement of the values of R, G and B, because from these I did the rest of the calculations. For the large sample, where the error occurs, the values of R, G and B go up and down drastically in a strange way from photo 100 to 1800, more or less.

I checked photo 98, 99, 100 and 101 and at first sight they are identical, so the error is not born (apparently) from the analyzed photos.

These are the photos when all start to fail.

I use two codes, the first one (made by Data Analyst, shared by himself in one of the links I put in my first question) to make the mask and verify that it has a correct shape and size. And the second one to apply this mask to each of the photos of the sample and obtain from this process the values of R, G, B, L, a, b and Delta E. Finally, I also use another one to make the graphs. I share them in case you need to see them.

So, what could be going on, why from two very similar photos do you get values for R, G and B that do not make sense, why with the other sample does this error not occur?

It is worth to say that analyzing the photos 100 and 101 (where the delivered data go crazy) in the first code (the one that creates the mask) i get similar values for R, G and B, nothing like the ones delivered by the second code. So it is likely that the error has to do with the precision used for the numbers (and not with the code itself, as it was used for the small sample correctly) in addition to the fact that as the color change is more gradual in this large sample, the values from photo to photo are more similar. If the error arises from here, could you help me to correct it? I tried to make some changes but the error persisted, and I'm not very good at programming without the help of AI (my bad).

Thanks in advance!

[DGM]

When I run the masking and DE code on those two images, I get a DeltaE of 0.015 -- much smaller than expected from the graph.

I'm assuming that you're generating the mask off of frame 1 and then reusing that mask for all remaining frames. If so, it may be a matter of how frame1 is influencing the mask generation, or it might simply be a problem which requires more than two subsequent frames to show up.

It might help to have a copy of the frame used for mask generation, and a number of frames (e.g. 5-10) in the vicinity of frame 100.

[Vicente]

I used different frames to make the mask, and I had the same problem with all of them.

I share with you the first 5 frames and from frame 90 to frame 110. Please note that the photos with the number 100 and 101 in their names are the ones I shared at the beginning. This is because the code to obtain DE starts counting from frame 2, so in the graph, they are the 99 and 100 frame.

edit: the values of DE that I am calculating in the second code is for each frame with the FIRST frame.

[DGM]

I've been messing around, and I haven't been able to replicate the problem.

Bear in mind that step is simply because of the jump from frame5 to frame90. Otherwise, the trend seems quite continuous.

I haven't found anything that jumps out as an obvious oversight in the code that might allow some sort of periodic error. The one possibility that crosses my mind is maybe you have more than one run of photos that got dumped into the same directory, and dir() is picking them up in an alternating fashion. Depending on how they're sorted, such a scenario might not be obvious when glancing at the directory in a file browser. That's just a guess though.

I might keep messing around with it, but that's where I am right now.

[Vicente]

Well, I noticed that after running the second code (the one that calculates the values) the variable "baseFileName" ends up in "pruebatiempo_999.png" instead of the 2700 picture.

Then I took a look at the variable "imageFiles" and look:

You were right. You can also see the photos in between that make the graph oscillate.

I add some code to make the function sort the files in imagefiles and then,

I should have stopped to review all the variables. My bad. Bad habits for using AI for program I think, I don't know.

Thank you for pointing out this detail.

[DGM]

Oof yeah. I normally try to write numbered files using zero padding to avoid that. At least it's sorted now.

Answer 1

[Image Analyst]

It looks like your data for the latter plots is oscillating on an alternating element basis between two curves, hence the "solid" looking plot. Something is happening starting around image #100. It's like every other image is changing brightness.

Presumably the delta E is with respect to the very first image (not between adjacent frames), so upload that first image, plus some images between 1 and 100, and some right around the transition at the end, like around image #1900.

I don't think you're doing calibrated color measurement so the LAB values are just arbitrary (would not agree with spectrophotometer) and if there is a sudden change in illumination, then that would cause a sudden change in the LAB values, even though your sample did not change. I think you should also monitor the mean intensity of the left 30% of the image. Also plot that to make sure there is no change in it.

[Vicente]

Yes, the data starts to oscillate in frame 100. I don't think I mentioned it, but yes, that gives the chart the solid look. It could be a change in brightness, but it would be weird since at the time of taking the photos I didn't notice anything unusual.

I shared in the other reply some photos. I don't know if that's the right way to share these files on this forum, but the ZIP files had to be less than 5 mb in size, so I had to make several.

Yes, it is clear to me that there is no calibration, and that this influences when obtaining the values of L, a and b. I have seen in other questions here the .rar file you have shared that includes a guide to do a calibration and color correction, in addition to the calibration in illumination. I haven't done these because the system I put together gives me some confidence, and as I showed above it has worked for me with other samples.

How can I get the average intensity? I did a quick search and found different ways to do it, but no specific function. By 30% on the left you mean the "solid part of the graph", right?

edit: Well, I found how to find the average intensity of the R, G and B channel. I plotted the results and you can see the same abrupt change starting from photo 100. What does this mean? The strange thing is that looking at the images one by one you don't see any noticeable luminance, focus, gain, definition, etc change.

[Image Analyst]

@Vicente if you don't see an abrupt change in brightness in the image then there should be no substantial change in the average intensity. It's probably due to incorrect (alphanumeric) sorting of your list of filenames. For example alphanumerically sorted names would go like 1.txt, 10.txt, 11.txt...2.txt, 20.txt, 21.txt and so on. You might like to read this:

https://blogs.mathworks.com/pick/2014/12/05/natural-order-sorting/

or else just use dir() to get the time stamps and sort your filename list by the time stamp.

[Vicente]

Yes, there was the error, dir() read the files in an unexpected way.

Thanks for the link, very useful. And for the help too.