Mixing
TensorFlow Estimator ServingInputReceiver features vs receiver_tensors: when and why?
In a previous question the purpose and structure of the serving_input_receiver_fn is explored and in the answer:
def serving_input_receiver_fn():
"""For the sake of the example, let's assume your input to the network will be a 28x28 grayscale image that you'll then preprocess as needed"""
input_images = tf.placeholder(dtype=tf.uint8,
shape=[None, 28, 28, 1],
name='input_images')
# here you do all the operations you need on the images before they can be fed to the net (e.g., normalizing, reshaping, etc). Let's assume "images" is the resulting tensor.
features = {'input_data' : images} # this is the dict that is then passed as "features" parameter to your model_fn
receiver_tensors = {'input_data': input_images} # As far as I understand this is needed to map the input to a name you can retrieve later
return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)
the answer's author states (in regards to receiver_tensors):
As far as I understand this is needed to map the input to a name you can retrieve later
This distinction is unclear to me. In practice, (see this colab), the same dictionary can be passed to both features and receiver_tensors.
From the source code of @estimator_export('estimator.export.ServingInputReceiver') (or the ServingInputReceiver docs:
features: ATensor,SparseTensor, or dict of string toTensoror
SparseTensor, specifying the features to be passed to the model. Note:
iffeaturespassed is not a dict, it will be wrapped in a dict with a
single entry, using 'feature' as the key. Consequently, the model must
accept a feature dict of the form {'feature': tensor}. You may use
TensorServingInputReceiverif you want the tensor to be passed as is.
receiver_tensors: ATensor,SparseTensor, or dict of string toTensor
orSparseTensor, specifying input nodes where this receiver expects to
be fed by default. Typically, this is a single placeholder expecting
serializedtf.Exampleprotos.
After reading, it is clear to me what the purposes of features is. features is a dictionary of inputs that I then send through the graph. Many common models have just a single input, but you can or course have more.
So then the statement regarding receiver_tensors which "Typically, this is a single placeholder expecting serialized tf.Example protos.", to me, suggests that receiver_tensors want a singular batched placeholder for (Sequence)Examples parsed from TF Records.
Why? If the TF Records is fully preprocessed, then this is redundant? if it is not fully pre-processed, why would one pass it? Should the keys in the features and receiver_tensors dictionaries be the same?
Can someone please provide me with a more concrete example of the difference and what goes where, as right now
input_tensors = tf.placeholder(tf.float32, <shape>, name="input_tensors")
features = receiver_tensors = {'input_tensors': input_tensors}
works... (even if maybe it shouldn't...)
python tensorflow tensorflow-estimator
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
add a comment |
In a previous question the purpose and structure of the serving_input_receiver_fn is explored and in the answer:
def serving_input_receiver_fn():
"""For the sake of the example, let's assume your input to the network will be a 28x28 grayscale image that you'll then preprocess as needed"""
input_images = tf.placeholder(dtype=tf.uint8,
shape=[None, 28, 28, 1],
name='input_images')
# here you do all the operations you need on the images before they can be fed to the net (e.g., normalizing, reshaping, etc). Let's assume "images" is the resulting tensor.
features = {'input_data' : images} # this is the dict that is then passed as "features" parameter to your model_fn
receiver_tensors = {'input_data': input_images} # As far as I understand this is needed to map the input to a name you can retrieve later
return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)
the answer's author states (in regards to receiver_tensors):
As far as I understand this is needed to map the input to a name you can retrieve later
This distinction is unclear to me. In practice, (see this colab), the same dictionary can be passed to both features and receiver_tensors.
From the source code of @estimator_export('estimator.export.ServingInputReceiver') (or the ServingInputReceiver docs:
features: ATensor,SparseTensor, or dict of string toTensoror
SparseTensor, specifying the features to be passed to the model. Note:
iffeaturespassed is not a dict, it will be wrapped in a dict with a
single entry, using 'feature' as the key. Consequently, the model must
accept a feature dict of the form {'feature': tensor}. You may use
TensorServingInputReceiverif you want the tensor to be passed as is.
receiver_tensors: ATensor,SparseTensor, or dict of string toTensor
orSparseTensor, specifying input nodes where this receiver expects to
be fed by default. Typically, this is a single placeholder expecting
serializedtf.Exampleprotos.
After reading, it is clear to me what the purposes of features is. features is a dictionary of inputs that I then send through the graph. Many common models have just a single input, but you can or course have more.
So then the statement regarding receiver_tensors which "Typically, this is a single placeholder expecting serialized tf.Example protos.", to me, suggests that receiver_tensors want a singular batched placeholder for (Sequence)Examples parsed from TF Records.
Why? If the TF Records is fully preprocessed, then this is redundant? if it is not fully pre-processed, why would one pass it? Should the keys in the features and receiver_tensors dictionaries be the same?
Can someone please provide me with a more concrete example of the difference and what goes where, as right now
input_tensors = tf.placeholder(tf.float32, <shape>, name="input_tensors")
features = receiver_tensors = {'input_tensors': input_tensors}
works... (even if maybe it shouldn't...)
python tensorflow tensorflow-estimator
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
add a comment |
In a previous question the purpose and structure of the serving_input_receiver_fn is explored and in the answer:
def serving_input_receiver_fn():
"""For the sake of the example, let's assume your input to the network will be a 28x28 grayscale image that you'll then preprocess as needed"""
input_images = tf.placeholder(dtype=tf.uint8,
shape=[None, 28, 28, 1],
name='input_images')
# here you do all the operations you need on the images before they can be fed to the net (e.g., normalizing, reshaping, etc). Let's assume "images" is the resulting tensor.
features = {'input_data' : images} # this is the dict that is then passed as "features" parameter to your model_fn
receiver_tensors = {'input_data': input_images} # As far as I understand this is needed to map the input to a name you can retrieve later
return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)
the answer's author states (in regards to receiver_tensors):
As far as I understand this is needed to map the input to a name you can retrieve later
This distinction is unclear to me. In practice, (see this colab), the same dictionary can be passed to both features and receiver_tensors.
From the source code of @estimator_export('estimator.export.ServingInputReceiver') (or the ServingInputReceiver docs:
features: ATensor,SparseTensor, or dict of string toTensoror
SparseTensor, specifying the features to be passed to the model. Note:
iffeaturespassed is not a dict, it will be wrapped in a dict with a
single entry, using 'feature' as the key. Consequently, the model must
accept a feature dict of the form {'feature': tensor}. You may use
TensorServingInputReceiverif you want the tensor to be passed as is.
receiver_tensors: ATensor,SparseTensor, or dict of string toTensor
orSparseTensor, specifying input nodes where this receiver expects to
be fed by default. Typically, this is a single placeholder expecting
serializedtf.Exampleprotos.
After reading, it is clear to me what the purposes of features is. features is a dictionary of inputs that I then send through the graph. Many common models have just a single input, but you can or course have more.
So then the statement regarding receiver_tensors which "Typically, this is a single placeholder expecting serialized tf.Example protos.", to me, suggests that receiver_tensors want a singular batched placeholder for (Sequence)Examples parsed from TF Records.
Why? If the TF Records is fully preprocessed, then this is redundant? if it is not fully pre-processed, why would one pass it? Should the keys in the features and receiver_tensors dictionaries be the same?
Can someone please provide me with a more concrete example of the difference and what goes where, as right now
input_tensors = tf.placeholder(tf.float32, <shape>, name="input_tensors")
features = receiver_tensors = {'input_tensors': input_tensors}
works... (even if maybe it shouldn't...)
python tensorflow tensorflow-estimator
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
In a previous question the purpose and structure of the serving_input_receiver_fn is explored and in the answer:
def serving_input_receiver_fn():
"""For the sake of the example, let's assume your input to the network will be a 28x28 grayscale image that you'll then preprocess as needed"""
input_images = tf.placeholder(dtype=tf.uint8,
shape=[None, 28, 28, 1],
name='input_images')
# here you do all the operations you need on the images before they can be fed to the net (e.g., normalizing, reshaping, etc). Let's assume "images" is the resulting tensor.
features = {'input_data' : images} # this is the dict that is then passed as "features" parameter to your model_fn
receiver_tensors = {'input_data': input_images} # As far as I understand this is needed to map the input to a name you can retrieve later
return tf.estimator.export.ServingInputReceiver(features, receiver_tensors)
the answer's author states (in regards to receiver_tensors):
As far as I understand this is needed to map the input to a name you can retrieve later
This distinction is unclear to me. In practice, (see this colab), the same dictionary can be passed to both features and receiver_tensors.
From the source code of @estimator_export('estimator.export.ServingInputReceiver') (or the ServingInputReceiver docs:
features: ATensor,SparseTensor, or dict of string toTensoror
SparseTensor, specifying the features to be passed to the model. Note:
iffeaturespassed is not a dict, it will be wrapped in a dict with a
single entry, using 'feature' as the key. Consequently, the model must
accept a feature dict of the form {'feature': tensor}. You may use
TensorServingInputReceiverif you want the tensor to be passed as is.
receiver_tensors: ATensor,SparseTensor, or dict of string toTensor
orSparseTensor, specifying input nodes where this receiver expects to
be fed by default. Typically, this is a single placeholder expecting
serializedtf.Exampleprotos.
After reading, it is clear to me what the purposes of features is. features is a dictionary of inputs that I then send through the graph. Many common models have just a single input, but you can or course have more.
So then the statement regarding receiver_tensors which "Typically, this is a single placeholder expecting serialized tf.Example protos.", to me, suggests that receiver_tensors want a singular batched placeholder for (Sequence)Examples parsed from TF Records.
Why? If the TF Records is fully preprocessed, then this is redundant? if it is not fully pre-processed, why would one pass it? Should the keys in the features and receiver_tensors dictionaries be the same?
Can someone please provide me with a more concrete example of the difference and what goes where, as right now
input_tensors = tf.placeholder(tf.float32, <shape>, name="input_tensors")
features = receiver_tensors = {'input_tensors': input_tensors}
works... (even if maybe it shouldn't...)
python tensorflow tensorflow-estimator
python tensorflow tensorflow-estimator
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
asked Nov 21 '18 at 10:50
SumNeuronSumNeuron
1,168824
1,168824
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53410469%2ftensorflow-estimator-servinginputreceiver-features-vs-receiver-tensors-when-and%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53410469%2ftensorflow-estimator-servinginputreceiver-features-vs-receiver-tensors-when-and%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
