svsticky / chroma

Manage photo albums on S3 buckets. Successor to Pxl and Rstr
1 stars 1 forks source link

Image processing asynchronously #8

Closed SilasPeters closed 9 months ago

SilasPeters commented 10 months ago

As mentioned in #3 by @TobiasDeBruijn, all images uploaded are synchronously converted from JPG to PNG. He marked it as a todo, hence this issue :).

My vision is that all images should, speaking abtractly, be processed as soon as they are uploaded, but this should not slow down user interaction. The album should be marked as 'being processed' and after that published automatically.

Question to @TobiasDeBruijn: would it be a big nuisance to implement that images are not converted to PNGs but just displayed as they are, supporting both JPG en PNG and potentially more? Converting seems like something which might not be necessary, or does this have a reason other than easing implementation on the front-end?

Final note When implementing this, perhaps it is interesting to prepare chroma to have some uploading pipeline. It seems to me that implementing said things above overlaps greatly with the following idea. When uploading pictures to chroma, the user might configure the album opting in to things like image compression, sorting, creating previews and what not. The user should not have to wait for these things, so perhaps a pipeline can pick all these tasks up and publish the album afterwards, notifying the user of every stap and its progess.

TobiasDeBruijn commented 10 months ago

My vision is that all images should, speaking abtractly, be processed as soon as they are uploaded, but this should not slow down user interaction. The album should be marked as 'being processed' and after that published automatically.

Yep! Currently --> PNG conversion happens synchronously. Scaling of the images to W400 and W1600 does happen asynchronously. This task is triggered when an image is created.

Question to @TobiasDeBruijn: would it be a big nuisance to implement that images are not converted to PNGs but just displayed as they are, ...

Not really, though it does add inconsistency and potentially complexity for third (or first party for that matter) API users. The frontend converts the image to Base64 and displays this using a HTML native <img> element (with a small layer on it from Vuetify):

return 'data:image/png;base64,' + 
    this.bytes.reduce((data, byte) => data + String.fromCharCode(byte),
);

To support JPEG as well, we need to:

I myself prefer we stick to PNG, but make the conversion happen asynchronously, which is rather easy to make work. Or maybe even better, switch to WebP

Final note ...

I like this idea! These options could be presented to the user on album creation and in the album edit view. Though it probably deserves its own issue.