How to pass a normalized image float32 through Pynq driver for Hardware Inference for Super resolution?

[Arbiter-glitch]

I was using FINN flow for super resolution.
For training using brevitas, we pass the image pixel values by normalizing it between 0 and 1 and the predictions are also between 0 and 1. After training we export the onnx format and through finn flow we get the bit file and driver file for deployment using pynq. But in the io_shape_dict in the driver
io_shape_dict = {
# FINN DataType for input and output tensors
"idt" : [DataType['INT8']],
"odt" : [DataType['UINT8']],
# shapes for input and output tensors (NHWC layout)
"ishape_normal" : [(1, 40, 40, 1)],
"oshape_normal" : [(1, 80, 80, 1)],
# folded / packed shapes below depend on idt/odt and input/output
# PE/SIMD parallelization settings -- these are calculated by the
# FINN compiler.
"ishape_folded" : [(1, 40, 40, 1, 1)],
"oshape_folded" : [(1, 80, 80, 1, 1)],
"ishape_packed" : [(1, 40, 40, 1, 1)],
"oshape_packed" : [(1, 80, 80, 1, 1)],
"input_dma_name" : ['idma0'],
"output_dma_name" : ['odma0'],
"number_of_external_weights": 0,
"num_inputs" : 1,
"num_outputs" : 1,
}
is in this format. Which says that the input tensor datatype should be of "int8" and the output should be of "uint8". If I pass a normalized image input.npy in float32. I get an error saying that the value is not in the bounds of the datatype. If i pass a "int8" image to get over this error, although after inference in finn hardware, the output seems be internally converted from float to uint8 value? But the output is far from what is
check.zip
expected. How can I solve the problem of passing a normalized image to finn hardware through Pynq?
My model files, train code, pynq deploy package are attached.

[auphelia]

Hi @Arbiter-glitch, the dictionary is derived from the model that you used to generate a bitfile with FINN, so you cannot influence the model by changing the dictionary for the PYNQ driver.
It might be helpful for you to have a look into this notebook: https://github.com/Xilinx/finn/blob/main/notebooks/advanced/4_advanced_builder_settings.ipynb
My assumption is that your input was marked as floating point and so the first MultiThreshold node was not converted to HW (FINN support currently integer-only compute) and the input to the node after this MultiThreshold is probably int8. Please have a look at the notebook, because there is a similar scenario shown (in that case image classification) and it is explained how to solve it (by implementing custom steps to add pre-processing).

[Arbiter-glitch]

Thanks, I have applied it according to the notebook provided. However, there is still a considerable difference between the output and the expected output. Expected output is the output image received while passing the input image through the software model.
I have included the intermediate models and the build_dataflow_steps.py in the zip file as well as the output received through finn and the expected output. The notebook for running in Pynq is also included. I don't know whether I am doing anything wrong. Also, I took out the last mul node because it is just dividing by 255 to get the output between 0 and 1. I use latest FINN branch. I trained the network outside the Finn docker. Then exported the qonnx format to Finn.
check.zip