You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the API provides a way to give the location of the input file for processing and requires the desired location of the output. This inhibits the flexibility of the library to some extent.
Another way would require the API to deal directly with the image matrices rather than the location and the onus of I/O would fall on the developer. However, completely eliminating the current API would pose a problem to people who are looking for plug-n-play solution. Thus, it might be better to support both the forms of API.
Any suggestions are welcome. Thanks!
The text was updated successfully, but these errors were encountered:
Hi @sahildua2305, I was thinking about including the api such that the I/O operations are taken care by the user, and the api will take an input image Numpy matrix and provide the processed result as a Numpy output image matrix.
One advantage of constraining the type of input as Numpy image matrix would be easy validation of input, however, it maybe wise to include the other types (blob, array) of the input image. A certain restriction has to be made on the type of input. What do you think about this?
Currently, the API provides a way to give the location of the input file for processing and requires the desired location of the output. This inhibits the flexibility of the library to some extent.
Another way would require the API to deal directly with the image matrices rather than the location and the onus of I/O would fall on the developer. However, completely eliminating the current API would pose a problem to people who are looking for plug-n-play solution. Thus, it might be better to support both the forms of API.
Any suggestions are welcome. Thanks!
The text was updated successfully, but these errors were encountered: