I didn't design the current messages to support per-pixel segmentation, and I'll have to look into how that is usually represented to get a good idea of how to craft a message for it. My initial guess is that it will be a separate message type from `Classification` and `Detection`. On the topic of the parameter server, I think it's worth having a discussion about representation format. From talks with other OSRF folks, I don't think it's a good idea to use a tree of parameters; a single parameter would be better. For example, if you are loading the ImageNet class names, that's 1000 items on the parameter server, just to store the names. Add object meshes, sizes, etc., and it could balloon very quickly. While JSON/XML/YAML might work equally well in terms of expressive power, with XML, we can be sure that both C++ and Python will have the ability to read the database. TinyXML is already included as a low-level dependency in ROS C++, but the same can't be said for a YAML or JSON parser. Rather than allow people to use whatever's convenient, I think it's worth it to restrict/recommend everyone to use a format that can be parsed from more languages. We could do it in the REP, but not enforce it, so if someone really wants to use YAML in their Python-only implementation, they could do so. That's my position, but I'm interested in hearing other ideas. --- [Visit Topic](https://discourse.ros.org/t/proposal-new-computer-vision-message-standards/1819/12) or reply to this email to respond. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: