[FR] Multiple Part Pictures

[Islendur]

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

• [x] 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?

[Islendur]

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 https://github.com/inventree/InvenTree/pull/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

[matmair]

Maybe to expand from where my suggestion with the attachment model comes from:

• I find the current solution to https://github.com/inventree/InvenTree/issues/5532 to be working but a bit tacked on - file logic is in the parts table
• there are requests for thumbnails of attachments https://github.com/inventree/InvenTree/issues/5048 / https://github.com/inventree/InvenTree/issues/5531
• moving logic for everything files into single model would make it easier to improve overall handling of files (S3 / external data storages)
• reducing API endpoints would be great to make the product easiert

[Reza98Sh]

@matmair

As far as I understood from your comment,

you mean we should save part images like other files using the attachment table.

How can we differentiate a regular attachment from a part image?

[matmair]

There is a lot of possibilities. You could add a boolean field 'use_as_image' or you could add a flag 'use_cases' or you could use the already enabled tagging to set a special tag.

[wolflu05]

And how do we handle image previews and all that custom logic? I am not sure if that is the right approach.

[SchrodingersGat]

I feel there is enough separation of use-case here to warrant a separate model. But, refactoring to use the django files API more cleanly would be a good thing

[matmair]

And how do we handle image previews and all that custom logic? I am not sure if that is the right approach.

Using the same image-field that does it now

[Islendur]

maybe not the best approach but would having the images as attachment to the part in a table above the normal attachment table such as "part images" be easier? then you could also aquire the pictures easily if you need them for documentation purposes ect.

you could also add a additonal collum and use the existing table. the extra collum would be "attachment type" then you can easily distinguish the attachments. currently there is a comment collum this could be utilized but a seperate collum would most likely be more clean.