[Caffe]:Check failed: out_num_ * inner_num_ == bottom[1]->count()

最新推荐文章于 2019-10-31 16:37:28 发布
原创 最新推荐文章于 2019-10-31 16:37:28 发布 · 1.9k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文针对Caffe训练过程中出现的特定错误进行了详细分析，并提供了解决方案。指出Softmax层会检查输入，确保其符合网络层输出的标准格式，并正确对应标签。解决方法在于调整SoftmaxWithLoss层中分类输出与标签的顺序。
部署运行你感兴趣的模型镜像

错误

当使用Caffe进行训练时，出现如图所示的错误。
这里写图片描述

在网上找答案，发现有人说调换label和data的顺序。
一直以为是调换数据层的顺序，然而，并不是。

解决方法

Softmax层会对输入做检测，判断第一个输入是不是网络层的输出，即NxC。
然后再判断该输出和标签label是否对应。

网上所指的data是说分类层的输出。
对调顺序是值在SoftmaxWithLoss层进行！！！

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

pspnet训练时报错Check failed: outer_num_ * inner_num_ == bottom[1]->count()
weixin_38410551的博客
05-21 651
Check failed: outer_num_ * inner_num_ == bottom[1]->count() (497025 vs. 504100) Number of labels must match number of predictions; e.g., if softmax axis == 1 and prediction shape is (N, C, H, W), l...
Check failed: axis_index < num_axes() (1 vs. 1) axis 1 out of range for 1-D Blob with shape
dongfang1984的博客
06-07 6869
这两周在做跨年龄的人脸识别。我用的是两个网络共同训练。有点像孪生网络（网络的浅层共享参数，深层用正交子空间，提取判别特征）。 在运行的时候爆出题目一样的error Check failed: axis_index *** Check failure stack trace: *** 思考了好久，也从开始追踪代码。看log。并没有什么异常。然后在log中发现如下信息：
FCNs Check failed: outer_num_ * inner_num_ == bottom[1]->count()
qq_30024069的博客
12-27 1335
FCNs 问题： softmax_loss_layer.cpp:47] Check failed: outer_num_ * inner_num_ == bottom[1]-&gt;count() (205700 vs. 617100) Number of labels must match number of predictions; e.g., if softmax axis == 1 a...
caffe源码分析 vector<Blob<Dtype>*>& bottom
西伯利亚的蓝眼睛
05-28 4009
Blob：4个维度 n x c x h x w
caffe报错Check failed: outer_num_ * inner_num_ == bottom[1]->count() (524288 vs. 1024
lanyuxuan100的博客
04-20 6842
在使用FCN进行训练自己的数据时，导入数据启动训练后出现如下提示： 这个错误提示表示给的label维度不对。经调查发现是在到入标签数据时，有个类型转换 后面修改为： 于是就可以了。
undefined reference to `caffe::Net float ::Net(std::__cxx11::basic_string char,问题解决
qq_38469553的博客
09-25 3500
在原本能正常使用的caffe中修改代码后重新编译，会产生如下错误： CXX/LD -o .build_release/tools/caffe.bin .build_release/tools/caffe.o: In function `test()': caffe.cpp:(.text+0x15b3): undefined reference to `caffe::Net&lt;float&gt...
caffe训练出错：Check failed: status == CUDNN_STATUS_SUCCESS (4 vs. 0) CUDNN_STATUS_INTERNAL_ERROR
山中有石为玉
02-12 9328
1、caffe调用caffe train出错： F0212 20:20:50.783892 23403 cudnn_conv_layer.cpp:53] Check failed: status == CUDNN_STATUS_SUCCESS (4 vs. 0)  CUDNN_STATUS_INTERNAL_ERROR *** Check failure stack trace: *** ...
MobileNet-SSD报错Check failed: status == CUDNN_STATUS_SUCCESS (4 vs. 0) CUDNN_STATUS_INTERNAL_ERROR
goodxin_ie的博客
04-06 4658
初始编译环境ubuntu16.04+CUDA8.0+Opencv3.4+cudnn5.1 编译原版的caffe-ssd，下面三项命令全部通过 make all -j16 make runtest -j16 make pycaffe 但是执行MobileNet-SSD中的demo.py时，报错Check failed: status == CUDNN_STATUS_SUCCESS (4 vs...
精选资源
Check failed: error == cudaSuccess (74 vs. 0) misaligned address
01-08
以下摘自github hoszbh的回答 https://github.com/BVLC/caffe/issues/5729 modifying cudnn_conv_layer.cpp and aligning the address to be multiples of 32. ... max_workspace = (max_workspace + m-1) / m * m;
SSD移植
公独何人，心如止水。
10-10 3974
1，报错Check failed: label < num_classes (5 vs. 5) 打开train_tv_logo.prototxt搜索num_classes改为9（8classes+1）2，报错Check failed: num_priors_ * num_classes_ == bottom[1]->channels() (62136 vs. 34520) . 理解：在mult
smooth_L1_loss_layer.cpp:28] Check failed: bottom[0]->channels() == bottom[1]->channels() (12 vs. 84
qq_36219202的博客
06-07 5626
用faster RCNN训练自己的数据时候遇到的问题，具体为使用vgg16的end_2_end训练 这种问题一般都是train.prototxt的类别数没有改好导致的 在的vgg16的end_2_end下的train.prototxt需要改的是 data层的num_classes: n (自己要训练的类别+1，1代表背景) 以及 roi_data层的num_classes:n cls_s
Caffe vgg-SSD训练错误【Check failed 0 == bottom[0]-count() % explicit_count (0 vs
happyday_d的博客
10-31 527
Caffe vgg-SSD训练错误【Check failed: 0 == bottom[0]->count() % explicit_count (0 vs. 8) bottom count (74088) must be 】 问题描述： VGG-SSD训练自己的数据时出现如下错误： 解决方案： 检查test.prototxt中mbox_conf_reshape层 layer { na...
[Caffe]:关于Check failed: shape[i] >= 0 (-2 vs. 0)错误
cham_3
11-21 6935
错误发现及分析当使用caffe训练网络的时候，出现如题错误，我们可以分析下日志，日志如下： 我们可以看出，在错误发生前生成的Top shape:64 2048 4 4 。也就是feature size是4 × 4的。然后再看看pool5对应的pooling layer的设置： 发现pooling的核大小被设置成7，这就是问题的所在了。解决方案 改变输入图像的大小，可以使feature m
caffe之Check failed: !lines_.empty() File is empty错误
编程之路
08-13 1313
I0813 20:39:10.270206 38816 layer_factory.hpp:77] Creating layer ImageData1 I0813 20:39:10.272202 38816 net.cpp:100] Creating Layer ImageData1 I0813 20:39:10.272202 38816 net.cpp:418] ImageData1 -&gt;...
caffe训练数据时出现了Check failed: data_怎么办？
cym1990的专栏
06-17 8013
如下图所示： 原因: 训练样本的图像尺寸太小，在池化层pool5的时候，输入图像的尺寸已经小于kernel核的大小了，经过池化之后，下一步输入就变成了0x0，因此会报错。 解决办法： 在转换图像格式的时候，设置宽度和高度即可。 convert_imageset.exe --backend=leveldb --resize_width=64 --resize_heigh
Caffe模型调试中的错误总结
BockSong的博客
08-16 1714
错误：Cannot copy param 0 weights from layer '...'; shape mismatch 即model和prototxt定义的模型不一样。通常是fine-tune时图片尺寸有了调整，或者改了网络结构想要train时去掉weight参数即可。   错误：Check failed: error == cudaSuccess (2 vs. 0) out of ...
UnsatisfiableError: The following specifications were found to be incompatible with each other: Output in format: Requested package -> Available versionsThe following specifications were found to be incompatible with your system: - feature:/win-64::__win==0=0 - caffe-cpu -> ipython -> __unix - caffe-cpu -> ipython -> __win Your installed version is: 0
最新发布
03-11
<think>好的，我现在需要帮助用户解决在Conda环境中安装caffe-cpu时遇到的包依赖冲突问题，特别是UnsatisfiableError。首先，我得回忆一下Conda处理依赖冲突的常见方法，以及caffe-cpu可能需要的依赖项。 首先，用户遇到了UnsatisfiableError，这通常是因为Conda无法找到同时满足所有依赖关系的包版本组合。可能的原因包括不同包之间的版本不兼容，或者某些包在指定平台（这里是win-64）上不可用。 接下来，我应该考虑用户使用的环境。用户提到是win-64系统，所以需要确认caffe-cpu是否有适用于Windows的预编译版本。有时候，某些包可能只在Linux或macOS上可用，或者需要从特定的渠道安装。 然后，用户可能已经尝试过直接安装caffe-cpu，但遇到了冲突。我需要建议他们创建新的干净环境，这样可以避免现有环境中其他包的影响。使用conda create命令指定Python版本，比如Python 3.6，因为某些旧版本的包可能不支持更新的Python版本。 另外，指定渠道也很重要。除了默认的conda-forge，可能还需要添加pytorch或其他渠道。比如，用户之前安装过pytorch-nightly-cpu，所以可能相关依赖来自那里。需要确保这些渠道被正确添加，并且优先级合适。 如果直接安装失败，可能需要手动安装核心依赖项，比如protobuf、glog、hdf5等，先安装这些包可能会帮助解决依赖关系。此外，用户可能需要安装特定版本的包，比如使用conda install caffe-cpu=1.0=blas_openblas来指定构建变体，这可能会影响依赖的解决。 如果问题仍然存在，可以考虑使用mamba，因为它比conda更快且更擅长解决复杂的依赖关系。安装mamba后，用mamba代替conda命令可能会有更好的结果。 另外，用户可能需要检查包是否存在于指定的渠道和平台上。使用conda search caffe-cpu --channel conda-forge --platform win-64来确认可用性。如果不存在，可能需要从源码编译或者寻找其他安装方式，比如pip。 最后，如果所有方法都失败，考虑使用Docker来隔离环境，避免系统级的依赖冲突。或者，参考社区资源，如GitHub Issues或Stack Overflow，看看其他人是如何解决类似问题的。 总结一下，解决步骤应该是：创建新环境→指定渠道和包版本→使用mamba→手动安装依赖→检查包可用性→寻求替代安装方法或社区帮助。需要一步步引导用户尝试这些方法，并解释每个步骤的目的，比如为什么指定Python版本或使用特定渠道。</think>### 分步解决Conda环境中caffe-cpu安装的依赖冲突问题 1. **创建独立环境** 新建一个干净的conda环境，避免与其他包冲突： ```bash conda create -n caffe_env python=3.6 # 建议使用Python 3.6，某些旧版本依赖兼容性更好 conda activate caffe_env ``` 2. **添加必要渠道** caffe-cpu通常需要从`conda-forge`渠道安装： ```bash conda config --add channels conda-forge conda config --set channel_priority strict ``` 3. **尝试安装核心依赖** 手动安装关键依赖以降低冲突概率： ```bash conda install protobuf glog hdf5 openblas ``` 4. **安装caffe-cpu** 指定版本和构建变体（若已知）： ```bash conda install caffe-cpu=1.0=blas_openblas # 指定使用OpenBLAS的构建版本 ``` 5. **使用Mamba加速依赖解析** 若conda解析速度过慢，可用mamba替代： ```bash conda install -n base mamba -c conda-forge mamba install caffe-cpu -c conda-forge ``` 6. **检查包可用性** 验证包在目标平台是否存在： ```bash conda search caffe-cpu --channel conda-forge --platform win-64 ``` 若输出为空，则需改用其他安装方式[^1][^3]。 --- ### 替代方案 1. **使用Docker容器** 若Conda持续失败，可采用预构建的Docker镜像： ```bash docker pull bvlc/caffe:cpu ``` 2. **从源码编译** 手动编译时能更灵活控制依赖版本： ```bash git clone https://github.com/BVLC/caffe.git cd caffe # 修改Makefile.config中BLAS=open make all -j4 ``` --- ### 常见冲突原因 1. **Python版本过高** caffe-cpu对Python≥3.7支持有限，建议使用Python 3.6。 2. **OpenCV版本冲突** 若环境中存在其他OpenCV版本，需先卸载： ```bash conda remove opencv ``` --- ### 验证安装 成功安装后执行： ```python import caffe print(caffe.__version__) # 应输出1.0.0 ```
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值