starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support images as front view image in rack #1258

New Issue
Closed
opened 2025-12-29 16:30:50 +01:00 by adam · 10 comments
adam commented 2025-12-29 16:30:50 +01:00
Owner
Copy Link

Originally created by @taenzerme on GitHub (Sep 22, 2017).

Originally assigned to: @jeremystretch on GitHub.

Issue type

[x] Feature request

Environment

  • Python version: 3.4.2
  • NetBox version: v2.1.5-dev

Description

As netbox did add support for images with devices it would be great to support choosing one of these as a front view image that is displayed in the rack view.

I already tried to implement this:

screenshot 2017-09-22 13 11 31

screenshot 2017-09-22 13 15 55

I did some quick code changes in my fork at https://github.com/taenzerme/netbox/tree/image-as-frontview. I guess doing it with a seperate element (and some z-index/position tweaking) inside the markup would be the cleaner way, but the inline style CSS works for me at the moment.

Maybe this could be helpful for the rest, too?

Originally created by @taenzerme on GitHub (Sep 22, 2017). Originally assigned to: @jeremystretch on GitHub. ### Issue type [x] Feature request ### Environment * Python version: 3.4.2 * NetBox version: v2.1.5-dev ### Description As netbox did add support for images with devices it would be great to support choosing one of these as a front view image that is displayed in the rack view. I already tried to implement this: ![screenshot 2017-09-22 13 11 31](https://user-images.githubusercontent.com/3618912/30742024-a215bcac-9f97-11e7-8e60-7a4b90ce9fcd.png) ![screenshot 2017-09-22 13 15 55](https://user-images.githubusercontent.com/3618912/30742157-2e192d74-9f98-11e7-8fa6-3ea4b751a931.png) I did some quick code changes in my fork at https://github.com/taenzerme/netbox/tree/image-as-frontview. I guess doing it with a seperate <img/> element (and some z-index/position tweaking) inside the markup would be the cleaner way, but the inline style CSS works for me at the moment. Maybe this could be helpful for the rest, too?
adam added the status: accepted label 2025-12-29 16:30:50 +01:00
adam closed this issue 2025-12-29 16:30:50 +01:00
adam commented 2025-12-29 16:30:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 28, 2017):

We wouldn't want to use the ImageAttachment model here: we can just add front_image and rear_image file fields to the DeviceType model.

The hard part is manipulating the uploaded image to look halfway decent in the rack elevation. A 1U device in NetBox is rendered as a 226x19 pixel block, so there isn't a lot of space to work with. An uploaded image would need to be stripped of bordering whitespace and manipulated to ensure its height and width meet the specified dimensions. We could allow for larger images, but that would require downsizing in the browser which probably wouldn't look great.

@jeremystretch commented on GitHub (Sep 28, 2017): We wouldn't want to use the ImageAttachment model here: we can just add `front_image` and `rear_image` file fields to the DeviceType model. The hard part is manipulating the uploaded image to look halfway decent in the rack elevation. A 1U device in NetBox is rendered as a 226x19 pixel block, so there isn't a lot of space to work with. An uploaded image would need to be stripped of bordering whitespace and manipulated to ensure its height and width meet the specified dimensions. We _could_ allow for larger images, but that would require downsizing in the browser which probably wouldn't look great.
adam commented 2025-12-29 16:30:51 +01:00
Author
Owner
Copy Link

@darkstar commented on GitHub (Sep 29, 2017):

Just something to consider early:
since devices can contain subdevices that can be slotted into them, there will be a desire to also have those slot devices represented with an image overlay. I'm thinking of a blade chassis, for example.

@darkstar commented on GitHub (Sep 29, 2017): Just something to consider early: since devices can contain subdevices that can be slotted into them, there will be a desire to also have those slot devices represented with an image overlay. I'm thinking of a blade chassis, for example.
adam commented 2025-12-29 16:30:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 29, 2017):

since devices can contain subdevices that can be slotted into them, there will be a desire to also have those slot devices represented with an image overlay

The ratio of development time needed to value delivered for a feature like this is extremely high. It would take quite a bit of time and effort to implement such a novelty. I think it's reasonable to support elevation images as requested in the initial comment, but that's probably as far as we'll go. (For the people who really want pretty pictures, there are several tools costing $10K+/yr that will provide them.)

@jeremystretch commented on GitHub (Sep 29, 2017): > since devices can contain subdevices that can be slotted into them, there will be a desire to also have those slot devices represented with an image overlay The ratio of development time needed to value delivered for a feature like this is _extremely_ high. It would take quite a bit of time and effort to implement such a novelty. I think it's reasonable to support elevation images as requested in the initial comment, but that's probably as far as we'll go. (For the people who _really_ want pretty pictures, there are several tools costing $10K+/yr that will provide them.)
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@girlpunk commented on GitHub (Nov 3, 2017):

Could this (and the sub-devices) be handled more easily with SVGs?

@girlpunk commented on GitHub (Nov 3, 2017): Could this (and the sub-devices) be handled more easily with SVGs?
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@taenzerme commented on GitHub (Nov 7, 2017):

@jeremystretch I understand where you're coming from. My request was not intended to go into a "full blown" solution for this. I never thought about sub-devices and wouldn't go as far as taking it there at all. If someone really needs to represent its blade server structure one can always do this - in Photoshop ;-)

@cyberjacob I thought about this, too. Actually I don't know if that really is worth the effort as we're simply taking photos of our racks with a smartphone and slice them in Photoshop.

The real value of photos here is that it helps in support on site when you have racks that have several different types of hardware (i.e. "It's the NIC port on the far right!")

@taenzerme commented on GitHub (Nov 7, 2017): @jeremystretch I understand where you're coming from. My request was not intended to go into a "full blown" solution for this. I never thought about sub-devices and wouldn't go as far as taking it there at all. If someone really needs to represent its blade server structure one can always do this - in Photoshop ;-) @cyberjacob I thought about this, too. Actually I don't know if that really is worth the effort as we're simply taking photos of our racks with a smartphone and slice them in Photoshop. The real value of photos here is that it helps in support on site when you have racks that have several different types of hardware (i.e. "It's the NIC port on the far right!")
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 7, 2017):

@cyberjacob brings up an interesting idea. Can we render the entire rack elevation in SVG using the HTML5 canvas? Would be nice to ditch the convoluted layered approach currently in use.

@jeremystretch commented on GitHub (Nov 7, 2017): @cyberjacob brings up an interesting idea. Can we render the entire rack elevation in SVG using the HTML5 canvas? Would be nice to ditch the convoluted layered approach currently in use.
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@Schnatterowski commented on GitHub (Jan 12, 2018):

I just had a look at the way opendcim is handling this. They're downsizing larger PNGs to 226x21 pixels in the browser. You can look at it here (login with dcim/dcim):

http://www.opendcim.org/demo/cabnavigator.php?cabinetid=1

If you look at the Cisco switch, the original image is 501x48 pixels. I think the browser-downsized version looks OK. Anyway, one could argue that it's the user's responsibility to use front/rear device images that look good enough for his/her purpose.

I vote for browser-downsizing, as it's more flexible. One can use perfectly fitting images in the target resolution, then there's nothing to downsize. Anybody using larger images, even with a different ratio, would have to decide for himself if he's happy with the result.

A max resolution and file size check could (and probably should) still be implemented.

Thanks for considering this.

@Schnatterowski commented on GitHub (Jan 12, 2018): I just had a look at the way opendcim is handling this. They're downsizing larger PNGs to 226x21 pixels in the browser. You can look at it here (login with dcim/dcim): http://www.opendcim.org/demo/cabnavigator.php?cabinetid=1 If you look at the Cisco switch, the original image is 501x48 pixels. I think the browser-downsized version looks OK. Anyway, one could argue that it's the user's responsibility to use front/rear device images that look good enough for his/her purpose. I vote for browser-downsizing, as it's more flexible. One can use perfectly fitting images in the target resolution, then there's nothing to downsize. Anybody using larger images, even with a different ratio, would have to decide for himself if he's happy with the result. A max resolution and file size check could (and probably should) still be implemented. Thanks for considering this.
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 2, 2018):

Blocked by #2248

@jeremystretch commented on GitHub (Aug 2, 2018): Blocked by #2248
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Jan 9, 2019):

I'm going with @jeremystretch here:
We should add front_image and rear_image file fields to the DeviceType model.
As long as there is no specific logic to convert the data during upload (you could use "python-resize-image"), the user himself is responsible for keeping the size during upload.
I think this is sufficient for a first current implementation.
@jeremystretch What do you think ?

@tb-killa commented on GitHub (Jan 9, 2019): I'm going with @jeremystretch here: We should add front_image and rear_image file fields to the DeviceType model. As long as there is no specific logic to convert the data during upload (you could use "python-resize-image"), the user himself is responsible for keeping the size during upload. I think this is sufficient for a first current implementation. @jeremystretch What do you think ?
adam commented 2025-12-29 16:30:52 +01:00
Author
Owner
Copy Link

@girlpunk commented on GitHub (Jan 10, 2019):

That sounds very reasonable for an MVP, and should be fairly easy to expand on in the future.

@girlpunk commented on GitHub (Jan 10, 2019): That sounds very reasonable for an MVP, and should be fairly easy to expand on in the future.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1258
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?