CURSOR: potential bug between write and read crop model for bgr rgb swap channel order.

[bw4sz]

This issue was written by an AI model. I don't have time to investigate and i'm unsure how important it may or may not be. It was found incidentally during development. I'd like someone to follow up, confirm and implement the fix. This is one of those times that because it was found by a model, we want human eyes on it to get it some veracity.

CropModel.write_crops saves images with swapped R/B channels

Summary

CropModel.write_crops() reads image data via rasterio (RGB order) then saves with cv2.imwrite(), which interprets the array as BGR. This silently swaps the red and blue channels in all saved crop PNGs. Since training loads these PNGs via ImageFolder/PIL (which reads them back as-is), the model trains on BGR data. At inference time, BoundingBoxDataset reads directly from rasterio in correct RGB order, creating a channel mismatch that degrades classification performance.

Location

https://github.com/weecology/DeepForest/blob/main/src/deepforest/model.py#L303-L308

img = src.read(window=((int(ymin), int(ymax)), (int(xmin), int(xmax))))
img = np.rollaxis(img, 0, 3)  # RGB from rasterio
cv2.imwrite(img_path, img)    # cv2 interprets this as BGR

Suggested fix

Replace cv2.imwrite with PIL, which preserves channel order:

from PIL import Image

Image.fromarray(img).save(img_path)

Or convert before writing:

img = cv2.cvtColor(img, cv2.COLOR_RGB2BGR)
cv2.imwrite(img_path, img)

[Googoochadwick]

Hey, I am reviewing the content and code.

[bw4sz]

Okay this looks genuinely important.

I grabbed a few examples of the project I was working on.
Changing channel order does switch predictions.

Sample 1: true=Clangula hyemalis | RGB→Mola mola | BGR→Somateria mollissima | match=False
Sample 2: true=Fulmarus glacialis | RGB→Phoca vitulina | BGR→Larus marinus | match=False
Sample 3: true=Fulmarus glacialis | RGB→Larus argentatus | BGR→Larus marinus | match=False
Sample 4: true=Rissa tridactyla | RGB→Calidris alba | BGR→Larus marinus | match=False
Sample 5: true=Calonectris diomedea | RGB→Ardea alba | BGR→Phalacrocorax auritus | match=False

[vickysharma-prog]

@bw4sz Thanks for the detailed analysis! Your examples clearly show how channel mismatch impacts predictions.

My understanding of the bug:

The issue is a channel order inconsistency between training and inference:

1. Training pipeline:

   • write_crops() reads via rasterio (RGB)
   • Saves via cv2.imwrite() which interprets as BGR
   • Saved crops have R↔B swapped
   • Training data loader reads these "swapped" images
   • Model learns on incorrect channel order

2. Inference pipeline:

   • BoundingBoxDataset reads via rasterio (correct RGB)
   • Model expects BGR (what it trained on)
   • Mismatch → degraded performance

For the fix, I'd suggest Option 2 (PIL) as cleaner:

from PIL import Image
Image.fromarray(img).save(img_path)
This avoids BGR/RGB confusion entirely since PIL preserves the original channel order.

Questions to consider:

Should we also check if the reading side (training data loader) has any cv2 dependencies that might introduce similar issues?
For users with existing saved crops, should there be a version warning or migration note?
Happy to help with testing if needed!

[Pritika2512]

Hi, I looked into this issue and it seems that the current implementation already uses PIL (Image.fromarray) instead of cv2.imwrite, which preserves RGB channel order.

Can you confirm if this issue is still relevant or already resolved?

[vickysharma-prog]

Hi @Pritika2512 welcome!👋
Great to see your interest in the Deepforest

That main already uses PIL here that was fixed in #1310 by @Googoochadwick. The original bug was that rasterio reads in RGB order but cv2.imwrite assumes BGR, so saved crops had red and blue channels silently swapped. Ben's samples above showed how much that threw off classification neither channel order matched the true label.

@bw4sz this one can probably be closed since #1310 addressed it (the PR used "Related Issue" instead of "Fixes" so it didn't auto close).

@Pritika2512 if you're looking to contribute, filtering
issues by the "good first issue" "bug" those labels help you to figure out your first issue.

[Pritika2512]

Hi! Thanks for the clarification.

I looked into #1310 and understood that the issue was caused by channel mismatch (RGB vs BGR), which has now been resolved by switching to PIL for saving images.

It makes sense that this issue can be closed since the root cause has already been addressed.

I’ve also started contributing to other parts of the project and would love to work on more issues. Please let me know if there are any good first issues or areas where I can help.

Thanks again!