get_dataloaders

[livneor207]

cannot load get_dataloaders

[fredO13]

from ellipse_rcnn.utils.data import get_dataloaders

there is no such thing as 'get_dataloaders' in ellipse_rcnn.utils.data...

[wdoppenberg]

Hi,

I don't have much time besides work. This is ofcourse a glaring omission but happened because I worked with a dataset I could not publish. However, I'm currently (from time to time) working on the feature/fddb branch which will allow anyone to use Face Detection Data Set and Benchmark (FDDB) to train their own models.

[fredO13]

thanks ! I can't wait !

[wdoppenberg]

@fredO13 You can try out training if you checkout the feature/fddb branch. Let me know if it works for you

[fredO13]

I'll do it and let you know if it works. Thanks

[fredO13]

Hi @wdoppenberg,
I'm currently trying out the feature/fddb branch, but I get an error on line 27 of model.py :
weights: WeightsEnum | str = ResNet50_Weights.IMAGENET1K_V1
it says :

TypeError: unsupported operand type(s) for |: 'StrEnumMeta' and 'type'

[wdoppenberg]

@fredO13 Ah that might be because of the new type annotation syntax in Python 3.10. You can solve this by either removing the type annotation for now, or by upgrading your env to 3.10 or above

[fredO13]

Sorry, I didn’t understand this. From: shree-exofield ***@***.***> Sent: mercredi 15 mars 2023 10:27 To: wdoppenberg/ellipse-rcnn ***@***.***> Cc: Omnes, Frederic ***@***.***>; Mention ***@***.***> Subject: Re: [wdoppenberg/ellipse-rcnn] get_dataloaders (Issue #4) ***External email warning: This email originated outside the company. Please do not click links or open attachments unless you were expecting this communication.*** I found this function in data.py file in older commits, that may be useful to you if you are still working. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/wdoppenberg/ellipse-rcnn/issues/4*issuecomment-1469651564__;Iw!!AB_04_y_3-SRqw!8iBeeAoOJf_cY0vqNVQkN9SSg6Hws4mtexmQHK910su4yOFoO9wp8WPT6M34iZReQNojDA-SvCGVumClyYPUHKOsB1IqaUHyzQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AMGBSBCJCAHXQMOQIDK6AKLW4GDNJANCNFSM6AAAAAASI4ZKQY__;!!AB_04_y_3-SRqw!8iBeeAoOJf_cY0vqNVQkN9SSg6Hws4mtexmQHK910su4yOFoO9wp8WPT6M34iZReQNojDA-SvCGVumClyYPUHKOsB1L6NVg8Pg$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[shree-exofield]

With reference to your older comment on 15 Feb 2022 you were unable to find *get_dataloaders* function, I was pointing out that you will have that function in data.py from this repo in older commits by the main author. That function is useful to get your data loaded and further used for training. Thank you.

…

On Fri, 17 Mar 2023 at 21:13, fredO13 ***@***.***> wrote: Sorry, I didn’t understand this. From: shree-exofield ***@***.***> Sent: mercredi 15 mars 2023 10:27 To: wdoppenberg/ellipse-rcnn ***@***.***> Cc: Omnes, Frederic ***@***.***>; Mention ***@***.***> Subject: Re: [wdoppenberg/ellipse-rcnn] get_dataloaders (Issue #4) ***External email warning: This email originated outside the company. Please do not click links or open attachments unless you were expecting this communication.*** I found this function in data.py file in older commits, that may be useful to you if you are still working. — Reply to this email directly, view it on GitHub< https://urldefense.com/v3/__https:/github.com/wdoppenberg/ellipse-rcnn/issues/4*issuecomment-1469651564__;Iw!!AB_04_y_3-SRqw!8iBeeAoOJf_cY0vqNVQkN9SSg6Hws4mtexmQHK910su4yOFoO9wp8WPT6M34iZReQNojDA-SvCGVumClyYPUHKOsB1IqaUHyzQ$>, or unsubscribe< https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AMGBSBCJCAHXQMOQIDK6AKLW4GDNJANCNFSM6AAAAAASI4ZKQY__;!!AB_04_y_3-SRqw!8iBeeAoOJf_cY0vqNVQkN9SSg6Hws4mtexmQHK910su4yOFoO9wp8WPT6M34iZReQNojDA-SvCGVumClyYPUHKOsB1L6NVg8Pg$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>> — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A43ZSJ2QOKA7DA7BDS6JP7TW4SBCPANCNFSM6AAAAAASI4ZKQY> . You are receiving this because you commented.Message ID: ***@***.***>

[fredO13]

Hi. I finally managed to have the training work on the FDDB dataset which is fine for me. Now I'd like to know, as in issue #1 how I could test it ? I also wonder if there could be an issue with the loss_ellipse not decreasing as stated in issue #5 (see bellow) :

Using 16bit native Automatic Mixed Precision (AMP)
GPU available: True, used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]

| Name | Type | Params

0 | model | EllipseRCNN | 55.2 M

55.2 M Trainable params
0 Non-trainable params
55.2 M Total params
110.394 Total estimated model params size (MB)
Epoch 9: 100%|█| 2845/2845 [50:59<00:00, 1.08s/it, loss=1.52, v_num=1, loss_classifier=6.48e-7, loss_box_reg=2.87e-7, loss_ellipse=1.440, loss_objectness=0.001, loss_rpn_box_reg=0.00287, total_loss=

thanks

[shree-exofield]

you can save the model in .pth format with the help of .ckpt checkpoints generated while training and use it further to test on test-images. Refer this file to save your model (https://github.com/wdoppenberg/crater-detection/blob/main/src/detection/save_run.py).

Refer this while testing (https://github.com/wdoppenberg/crater-detection/blob/main/src/detection/evaluate.py).Require little modifications to plot the detection on the images from dataset.

[shree-exofield]

Does loss is fluctuating for you and able to have convergence ?

[fredO13]

you can save the model in .pth format with the help of .ckpt checkpoints generated while training and use it further to test on test-images. Refer this file to save your model (https://github.com/wdoppenberg/crater-detection/blob/main/src/detection/save_run.py).

Refer this while testing (https://github.com/wdoppenberg/crater-detection/blob/main/src/detection/evaluate.py).Require little modifications to plot the detection on the images from dataset.

This seems to be working for the ckpt to pth conversion part :
`
import torch
from ellipse_rcnn.core.model import EllipseRCNN
from ellipse_rcnn.core.model import EllipseRCNNLightning

model = EllipseRCNN()
lightning_model = EllipseRCNNLightning.load_from_checkpoint('path/to/checkpoint/epoch=9-step=28450.ckpt', model = model)
torch.save(model.state_dict(), './weights/weights.pth')
`

[fredO13]

Epoch 0: 0%| | 1/2845 [00:12<10:02:08, 12.70s/it, loss=3.66, v_num=2, loss_classifier=1.350, loss_box_reg=0.0012, loss_ellipse=1.570, loss_objectness=0.732, loss_rpn_box_reg=0.00621, total_loss=3.660]
Epoch 0: 19%|█▏ | 543/2845 [02:14<09:31, 4.03it/s, loss=1.51, v_num=2, loss_classifier=0.00158, loss_box_reg=0.000372, loss_ellipse=1.420, loss_objectness=0.0888, loss_rpn_box_reg=0.0159, total_loss=1.530]
Epoch 0: 51%|██ | 1463/2845 [04:03<03:49, 6.02it/s, loss=1.59, v_num=2, loss_classifier=0.000769, loss_box_reg=3.26e-5, loss_ellipse=1.410, loss_objectness=0.0304, loss_rpn_box_reg=0.00325, total_loss=1.440]
Epoch 0: 80%|███▏| 2281/2845 [05:29<01:21, 6.93it/s, loss=1.74, v_num=2, loss_classifier=0.000193, loss_box_reg=1.47e-5, loss_ellipse=1.540, loss_objectness=0.0332, loss_rpn_box_reg=0.00556, total_loss=1.580]
Epoch 0: 100%|█████| 2845/2845 [06:30<00:00, 7.29it/s, loss=1.53, v_num=2, loss_classifier=2.28e-6, loss_box_reg=6.12e-6, loss_ellipse=1.450, loss_objectness=0.0207, loss_rpn_box_reg=0.00244, total_loss=1.480]

total_loss is moving up and down, I guess loss_ellipse is doing so...

[wdoppenberg]

This is the same behaviour I see. What probably needs to happen is that the loss function for the ellipse prediction <-> target loss is either fixed or replaced. Something like Wasserstein distance could be considered.

Unfortunately I don't have time in the coming month, so feel free to give this a go. I will try to assist as much as I can.

[fredO13]

I tried to change the ellipse loss function to "kullback-leibler", the loss remains at 1 at every iterration, but this is because the displacement term is infinite !

[fredO13]

for this loss, it seems displacement_term is infinite because it overflows fp16.
I tried to train using fp32, I don't get infinite values anymore, but still the exp(-displacement) is too close to zero for the ellipse loss to decrease

[shree-exofield]

Do you getting the proper detection of only the boxes from faster_rcnn part ? for my case the other losses are getting very small but the saved trained model won't show the detection of boxes properly on the image. My intention is to get at least get those boxes correct at the initial phase, then look for the ellipse_loss . how the FASTER-RCNN can be trained first ? and other thing to be noted when I am NOT using the ellipse_loss it shows less fluctuation in the other losses comparatively.

for this loss, it seems displacement_term is infinite because it overflows fp16. I tried to train using fp32, I don't get infinite values anymore, but still the exp(-displacement) is too close to zero for the ellipse loss to decrease

[fredO13]

all boxes are empty

[shree-exofield]

what you mean by that ?

all boxes are empty

[PoseZhaoyutao]

from ellipse_rcnn.utils.data import get_dataloaders

there is no such thing as 'get_dataloaders' in ellipse_rcnn.utils.data...

Hello, I have this error when downloading this project, it should be a blogger capacity problem, I hope you can pass me this h5 file with the consent of the blogger
This allows me to continue working on the related get-dataloaders function！

fetch: Fetching reference refs/heads/main
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
error: failed to fetch some objects from 'https://github.com/wdoppenberg/ellipse-rcnn.git/info/lfs'

Thanks！