Forums - Inception android example

6 posts / 0 new
or Register
Last post
Inception android example
NB
Join Date: 18 May 15
Posts: 6
Posted: Sun, 2017-11-19 21:39
Top

Hello all,

Is there an InceptionV3 android example which is as simplified as alexnet?

 

Thanks,

Nitin

  • Up0
  • Down0
Re: Inception android example
bofu
Join Date: 5 Nov 17
Posts: 2
Posted: Wed, 2017-11-22 22:55
Top

Hi,

The Android example in SNPE v1.6.0 is only for AlexNet, but you can modify the source codes by following these tips:

  1. Change input/output layer names

    AlexNet uses (data, prob) as (input, output) layer names.
    Inception v3 (default model w/o retraining) uses (Mul:0, softmax:0) as (input, output) layer names.
     
  2. Modify RGB values in the writeRgbBitmapAsFloat function

    For example, you can modify (all the r, g, b have to be modified)

    b = ((rgb) & 0xFF) - meanImage.get();

    to

    b = (((rgb) & 0xFF) - imageMean) / imageStd;  // imageMean = 128, imageStd = 128.0f

    Note: Inception does not use meanImage.
     
  3. Update extractModel's target from "alexnet" to your Inception v3.
  • Up0
  • Down0
Re: Inception android example
NB
Join Date: 18 May 15
Posts: 6
Posted: Wed, 2017-11-29 19:57
Top

Thanks for the detailed insight. Let me try this.

Regards,

Nitin

  • Up0
  • Down0
Re: Inception android example
zhangguangjin
Join Date: 13 Nov 17
Posts: 2
Posted: Sun, 2017-12-03 17:37
Top

it works,thanks

  • Up0
  • Down0
Re: Inception android example
vivek10.gupta
Join Date: 27 Jul 17
Posts: 11
Posted: Thu, 2017-12-14 05:40
Top

HI,

Can you please explain the significance of imageMean = 128, imageStd = 128.0f

  • Up0
  • Down0
Re: Inception android example
madhavajay
Join Date: 15 Mar 18
Posts: 22
Posted: Mon, 2018-04-30 12:45
Top

Thank you that worked for me too! :) That was the hint I needed to check the image normalization steps of SSD and COCO.

I think it would help if that was mentioned in the Qualcomm sNPE SDK docs.

This is normalisation which means taking the image and removing any differences between it and the average image in the training set.

This is done during training and so if you don't do it during inference the accuracy wont be there.

The way normalisation is done is usually across each color channel the average value across the entire training set is subtracted from each image and its pixels. So that for example if bright red is over represented in the data set it doesnt learn a large bias towards images with those colours.

The model is SSD Mobilenet v1 COCO, which means it was trained on the COCO image set.

However I don't believe 128 is correct as the average for all pixel values, so I looked at some other examples:

 
# R, G, B
mean_color = [123, 117, 104] # The per-channel mean of the images in the dataset. Do not change this value if you're using any of the pre-trained weights.
 
 
 
public static final float MEAN_B = (float) 103.94;
public static final float MEAN_G = (float) 116.78;
public static final float MEAN_R = (float) 123.68;
 
Seems that RGB, 123, 117, 104 are more correct. I didnt notice any difference in changing them on a few simple sample images.
 
However, the / Standard Deviation of 128 provides me with much lower % accuracy than the normal SSD.
 
I suspect the scaling factor for standard deviation is lower than that, a lower number should mean a brighter image.
 
When I tweak mine to around 108 I get the same accuracy on SSD as I do with the DLC file in sNPE with the exact same reference image being loaded as a PNG and fed directly as a Bitmap to both code paths. With the 128 mean 128 std its much worse.
 
  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.