[FR] Multiple Part Pictures

[VMT-Solutions]

Please verify that this feature request has NOT been suggested before.

• I checked and didn't find a similar feature request

Problem statement

some parts its hard to decide which picture represents the part the best so you have to decide which angle you want to show in the thumbnail. this can sometimes make it hard to distinguish between parts without having to look it up manually

Suggested solution

for some parts it would be benefitial to be able to upload a few pictures from diffrent angles.

Describe alternatives you've considered

uploading extra picture files in attachment, but this is not as intuitive.

Examples of other systems

in a typical webshop for example there is a field to the left or under the picture where you can click the other pictures available

Do you want to develop this?

• I want to develop this.

[SchrodingersGat]

We have received similar requests from other users too. It would require someone to step up and develop it. Is this something you are interested in?

[VMT-Solutions]

i will look into it or aquire the help needed.

[Reza98Sh]

@SchrodingersGat
Can I work on this issue ?

[SchrodingersGat]

Sure, happy for you to work on it! Please LMK how you are intending to approach it as it will require some significant API and UI changes

[Reza98Sh]

Of course!
I think there are two approaches for implementing this:

1. Move the image field to a separate table and connect it to the Part table with a ForeignKey.
   In this approach, you need to write a manual migration file to migrate the existing images.

2. Add multiple image fields to the Part model (for example, three image fields).
   This approach doesn’t require a manual migration, but the number of photos is limited, and it will create a lot of empty fields for parts that don't have multiple images.

---

One other thing I noticed is that InvenTree uses django-stdimage, which has been deprecated.
Does InvenTree team have any plans to use an alternative for this package?

[matmair]

I would like to introduce a variant of 1: move the image (and the stdimage logic) to the attachments table and enable selecting a primary and associated attachments. That would make re-using images possible - see #5532

Regarding django-stdimage; I looked into its suggested replacement this spring:

• There are dependency issues
• I am vary of changing the image format to something only browsers really understand

[SchrodingersGat]

Writing logic to separate out "images" from standard "attachments" may prove cumbersome. We could do something similar to what we did in #7420 - make a single UploadedImage model which any model type can reference.

suggested fields:

• image: The image file
• model_type: The type of associated model (see "Attachment")
• model_id: PK of the linked model
• primary: True for the "primary" image associated with a model (only one primary per linked model)

Migrating the existing "image" field for Part and Company model will be simple. And separating the "images" into a separate table from generic attachments means that we can use the "std-image" field (or use some other logic specific to images)

[hillsandales]

It would be helpful to be able to link one image to the internal part, but then link another image to the Manufacturer Part and another and the Supplier Part.

I'm working on adding some vacuum tubes, and have a generic 12AX7 part, but multiple manufacturers make this, and multiple suppliers sell each of those. Right now, if I link an image to the Internal Part, it shows up as the Manufacturer part, which doesn't really represent the part purchased (e.g. each manufacturer often has its own logo on their version of the 12AX7 tube)

It seems like the prior suggested method of implementation would be the most flexible in allowing this behavior as well as multiple images per model as well.

[SchrodingersGat]

@hillsandales good point regarding images for specific supplier parts. Currently the hard-coding against a "Part" instance is restrictive. So, I think that a new model which is similar to the attachment model, but is handled specifically with images in mind, is the way to go here.

It will need to be carefully considered though based on how we currently handle part images. There is some extra logic there to:

a) Allow sharing of the same image between multiple parts
b) Because of a), prevent images from being automatically deleted when a part is deleted

Additionally, we currently generate thumbnails for each image automatically for faster web rendering. That needs to be retained - can't be pulling down multiple megabyte images just to render in a table