I've been looking for an open source image editor that I can embed in my app for managing my vintage ad archives (https://adretro.com). Basically I just need to rotate, crop, adjust color. But the images come from from the archive database rather than upload. And I want to work with them quickly, rather than save/open like a desktop app. Last time I looked I couldn't find something with good documentation that was easy to get started with. Right now I bulk edit in Google Photos.
Did you consider using WebGPU, or creating a bridge between WebGPU / WebGL for this? Also, have you considered deploying on Cloudflare Pages [1] (unlimited bandwidth) instead of netlify?
The biggest difference for you is probably that WebGPU has compute shaders and WebGL does not, they are pretty nice if you want to implement more complex algorithms.
That's true. But current shaders are very simple.
The big issue I have with WebGPU is that it's still not supported by all browser (see Safari) while WebGL is nowadays everywhere.
I work on a MacBook and I need to make sure that at least Safari (soooo many issues/ bugs/ specific behaviours it drives my crazy) works fine
Would be very nice if it is provided as a library to be able to integrated into another app with partial/full customizations for UI with different theme and stack.
Excellent work. The UI looks very clean and functional. It's feature packed. Good choice on using WebGL. It has support everywhere in most if not all browsers.
You are right thanks for the heads up!! It currently works in linear color space. I wasn't familiar with the issue.
I need to figure out if it's enough in Webgl to add gl.SRGB8_ALPHA8 when loading/ copying textures or I should gamma correct in all the color handling shaders. Will do some testing to figure it out.
AFAIK gl.SRGB8_ALPHA8 will only make sure the filtering of the lookup happens in linear sRGB (because filtering involves multiplications).
But values returned from the texture lookup must also be linear for any calculations afterwards to make sense.
AFAIK you'd need to set internal format to SRGB8_ALPHA8 and the format to RGBA. Then the returned color is also linear.
However, according to [1], this combination is only allowed if the result type is requested UNSIGNED_BYTE, i.e. as 8bit/channel. That would mean you will get banding on gradients because 8bit/channel is not nearly enough to represent linear color.
I.e. the type should be at least HALF_FLOAT or FLOAT but the table suggest WebGL 2.0 does not support this. I'm not a realtime graphics person, so I may be missing something. And obviously, there must be some workaround for WebGL.
Furthermore, the final linear->non linear sRGB conversion must be done, too. I.e. before displaying the result. AFAIK the sRGB framebuffer GL extension can take care of this. But again, not sure.
The whole topic of color spaces (vs color models, i.e. RGB is a color model, not a color space) and gamma is not trivial.
Almost everyone starting out with any kind of computer graphics involving display/manipulation of colors gets this wrong first time because they do not know about this/assume this is trivial.
Don't be discouraged. A good read is [2]. While it specifically addresses color pipelines in VFX/film, all in there applies equally to a simple non-linear sRGB image (a typical JPG, e.g.) being manipulated and then displayed or saved out as 8bit/channel again.
I don't know if I have to thank you or just hate you! Spent best part of the day figuring out the whole srgb-linear thing.
Well the workflow should now be srgb correct! Had to fix some of the shaders and they now work, except for the vignette one that unexpectedly sucks in linear space but will replace it with another one soon.
Turns out adding gl.SRGB8_ALPHA8 for loading textures (excluding LUTs) and closing the pipeline with a linear-to-sRGB transform did the trick. Plus making sure the filters where working in the correct space.
No significant banding issues with 8bit depth images (except for the above-mentioned vignette filter). I did test with various gradients and sample images where I compared pixel by pixel. Apparently it holds quite well. Of course the 8bit limitation sucks and I'll keep looking for workarounds.
If you have the possibility to stress test it a little bit I would be forever grateful.
By the way, I'll add image blending soon which should help spotting colorspace errors.
Couple of issues I had: on mobile (Brave on Android) the touch controls for cropping are very janky. Feels like it steals control each time the picture updates maybe?
It's hard to see the controls under the picture on this small screen. Could you add a control to adjust the size of the controls and shrink the picture maybe?
As for the more complex UI modules (ie crop) in theory it shouldn't be too difficult to build a vanilla-js separate module, but not sure I'll have the time as these kind of solutions need to take into account so many use-cases and edge-cases that they easily become a nightmare to maintain ...
I'm so glad this exsist. I've been meaning to get something similar started, but did not due to one reason or the other. I'll definitely try to contribute.
This looks great, well done. However, I find one of the main tools I'm always looking for is the ability to resize an image. I want to retain the exact dimensions, just shrink the number of pixels. I can't spot that, is it there? Or would you consider adding it?
I must admit this baffles me a little. Width and heights are measured in pixels.
The number of pixels of an image is width x height (eg a raw image 256x256 means it has 256*256 = 65.536 pixels = 262.144 bytes - if RGBA8). I cannot reduce its pixels and keep the same width and height or viceversa.
I can
a) reduce the quality of an image with a lossy compression (in download if you select jpg you can reduce the quality which will in turn reduce the file size)
b) scale an image when displayed in a browser (canvas.style.width > canvas.width) but the underlying image will still be canvas.width
Apologies, by dimensions, I did mean aspect ratio. All I mean is keep the same image, but reduce the number of pixels, and lose some clarity, to reduce the size of the file.
Your suggestion above doesn't work. Try it. It keeps the picture aspect ratio, but it crops the picture. I don't want to crop it, I want to shrink the number of pixels but keep the same image (with loss of clarity because reducing pixels).
MS Paint, Resize/Skew option. Ctrl-W is the hotkey.
It allows you to resize either in terms of pixel count or percentage. The percentage approach is very nice for just putting 50 in both horizontal and vertical fields and getting an image half as large in both dimensions, but showing the same image (with reduced quality, because fewer pixels) and at the same aspect ratio.
"Random data is introduced to background images when the image is read back by the website. If a website merely renders data to the background, it will render without alteration. Although typically this does not happen, if the website reads the image data in the background (and potentially displays it to you again), it will have subtle noise that may affect how the image is displayed."
I tried to figure out how to crop an image and found nothing. There doesn't seem to be a crop feature as far as I could tell. I'm sure it's probably there, but not easy for anyone to figure out. Would be super easy to make it intuitive right?
I tried it again, and finally noticed you have to click the corner of the image to move the selection area. It works, but then I didn't see a "Crop" button. Only trying to be helpful, and not complaining. Nice work tho on this component.
No no I absolutely need this kind of feedback thanks! Being a solo developer is very difficult to gage usability and UX is definitely not my strength.
I tried to integrate the crop/ composition in the natural workflow of image processing, without a discreet "crop" button. But I guess it's not necessarily the most intuite thing to do :)
I'd like it if there were separate buttons for (a) reset a section (e.g. colors) back to the default and (b) do not use a section (e.g. colors). Right now, turning (e.g.) colors off loses the settings there. Maybe I missed something though.
I too agree this is great, and see space for another low-hanging UI tweak:
Allow editing numbers to right directly, instead of only using the slider. I really dislike using sliders beyond a first general impression because it is too slow to get things exactly as I want them. I would guess this is a relatively common sentiment.
One feature I don't see but would love to see is text overlay, but that is perhaps moving away from the spirit of the project.
Actually it's very easy to implement in a webapp. I will just need to think if there's a sleeker way to do it in terms of UI than just adding a simple input box ... although generally simpler is better so
I have done similar. It is pretty easy, you just have the slider update the input, that is used for the actual calculations. If I ever get past looking and actually download, I will do it.
a) the Ø at the right of a section resets the section's settings back to default zeros (it becomes white when available)
b) closing a section doesn't lose it's settings, unless of course it has been reset
As for a button that allows to "temporarily" disable a section (but keeping it's modified settings underneath), yes it's a very good idea
It would be nice if I can feed an image blob to it, and return the edited image as a blob programmatically - i.e. without the need for an UI to open or download the image. That will help integration/embed it into other apps.
The constructor requires
- a canvas (which can be an OffscreenCanvas)
- an arrayBuffer with the image (which you easily get from a blob with "await blob.arrayBuffer();" )
Batch processing in the browser would be limited by memory space and therefore everything would have to be queued (even if on more webworkers) and very slow/ unreliable IMHO.
What I'll implement next, if there's a request, is the possibility to save the recipes of the adjustments (crop/ perspective excluded) in order to quickly apply them to subsequent images
in the editor, do add a way to load sample random image to try out the editor instead of having to uploading my own (which most won't bother / don't trust / can't do at work).
This is awesome!!! One small UX ask would be to manually edit the values instead of using the sliders. Since this is Open Source (thank you) I may try to tweak that this weekend.
let me know of any usability issue. I tried different combinations and this seemed intuitive for me (compared to other solution), but of course I'm too biased.
thanks. It started as a proof of concept for a custom reactivity engine (based on signals and tagged template literals). But while at it I realised I needed something quick and easy for my needs.
I already have a prototype for a self-hosted photogallery that integrates this editor (something like https://immich.app to give you an idea). But it's still too early to share
I've been looking for an open source image editor that I can embed in my app for managing my vintage ad archives (https://adretro.com). Basically I just need to rotate, crop, adjust color. But the images come from from the archive database rather than upload. And I want to work with them quickly, rather than save/open like a desktop app. Last time I looked I couldn't find something with good documentation that was easy to get started with. Right now I bulk edit in Google Photos.
CropperJS is very simple and easy to use: https://fengyuanchen.github.io/cropperjs/
There is also React-Cropper if you want to CropperJS with React: https://github.com/react-cropper/react-cropper
Thanks I'll check it out again. Last I looked I think it was v1 branch.
Did you consider using WebGPU, or creating a bridge between WebGPU / WebGL for this? Also, have you considered deploying on Cloudflare Pages [1] (unlimited bandwidth) instead of netlify?
[1] - https://pages.cloudflare.com/
Apparently it isn't unlimited: https://news.ycombinator.com/item?id=42713451
oh wow, i had no idea. thanks!
I did consider WebGPU but I couldn't find many advantages for the current use case.
Yes I'm planning to move to the edge as soon as it's in a later stage of development
The biggest difference for you is probably that WebGPU has compute shaders and WebGL does not, they are pretty nice if you want to implement more complex algorithms.
That's true. But current shaders are very simple. The big issue I have with WebGPU is that it's still not supported by all browser (see Safari) while WebGL is nowadays everywhere.
I work on a MacBook and I need to make sure that at least Safari (soooo many issues/ bugs/ specific behaviours it drives my crazy) works fine
I don't have a mac, but my understanding is that Safari Technology Preview [0] has WebGPU support (might need a change a setting too).
[0]: https://developer.apple.com/safari/technology-preview/
Would be very nice if it is provided as a library to be able to integrated into another app with partial/full customizations for UI with different theme and stack.
The README mentions it uses this library - https://github.com/xdadda/mini-gl.
As mentioned in another comment, this is just a UI for https://github.com/xdadda/mini-gl
Excellent work. The UI looks very clean and functional. It's feature packed. Good choice on using WebGL. It has support everywhere in most if not all browsers.
Does this do operations involving multiplications in linear color space?
It seems to use mini-gl[0] for the filtering. I had a brief look at the mini-gl source and it seems to use color as-is?
If that were true, for 99% of content that people would upload -- stuff in non-linear sRGB --, the filters would do the wrong thing.
Or am I missing something?
[0] https://github.com/xdadda/mini-gl
You are right thanks for the heads up!! It currently works in linear color space. I wasn't familiar with the issue.
I need to figure out if it's enough in Webgl to add gl.SRGB8_ALPHA8 when loading/ copying textures or I should gamma correct in all the color handling shaders. Will do some testing to figure it out.
AFAIK gl.SRGB8_ALPHA8 will only make sure the filtering of the lookup happens in linear sRGB (because filtering involves multiplications).
But values returned from the texture lookup must also be linear for any calculations afterwards to make sense.
AFAIK you'd need to set internal format to SRGB8_ALPHA8 and the format to RGBA. Then the returned color is also linear.
However, according to [1], this combination is only allowed if the result type is requested UNSIGNED_BYTE, i.e. as 8bit/channel. That would mean you will get banding on gradients because 8bit/channel is not nearly enough to represent linear color.
I.e. the type should be at least HALF_FLOAT or FLOAT but the table suggest WebGL 2.0 does not support this. I'm not a realtime graphics person, so I may be missing something. And obviously, there must be some workaround for WebGL.
Furthermore, the final linear->non linear sRGB conversion must be done, too. I.e. before displaying the result. AFAIK the sRGB framebuffer GL extension can take care of this. But again, not sure.
The whole topic of color spaces (vs color models, i.e. RGB is a color model, not a color space) and gamma is not trivial.
Almost everyone starting out with any kind of computer graphics involving display/manipulation of colors gets this wrong first time because they do not know about this/assume this is trivial.
Don't be discouraged. A good read is [2]. While it specifically addresses color pipelines in VFX/film, all in there applies equally to a simple non-linear sRGB image (a typical JPG, e.g.) being manipulated and then displayed or saved out as 8bit/channel again.
[1] https://registry.khronos.org/webgl/specs/latest/2.0/#TEXTURE...
[2] https://www.imageworks.com/sites/default/files/2023-10/Cinem...
I don't know if I have to thank you or just hate you! Spent best part of the day figuring out the whole srgb-linear thing.
Well the workflow should now be srgb correct! Had to fix some of the shaders and they now work, except for the vignette one that unexpectedly sucks in linear space but will replace it with another one soon.
Turns out adding gl.SRGB8_ALPHA8 for loading textures (excluding LUTs) and closing the pipeline with a linear-to-sRGB transform did the trick. Plus making sure the filters where working in the correct space.
No significant banding issues with 8bit depth images (except for the above-mentioned vignette filter). I did test with various gradients and sample images where I compared pixel by pixel. Apparently it holds quite well. Of course the 8bit limitation sucks and I'll keep looking for workarounds.
If you have the possibility to stress test it a little bit I would be forever grateful.
By the way, I'll add image blending soon which should help spotting colorspace errors.
a whole new rabbit hole to get sucked into !! ahahah
Nice work.
Couple of issues I had: on mobile (Brave on Android) the touch controls for cropping are very janky. Feels like it steals control each time the picture updates maybe?
It's hard to see the controls under the picture on this small screen. Could you add a control to adjust the size of the controls and shrink the picture maybe?
Sorry, this at the moment is desktop only. Maybe in the future I'll work on a separate PWA, but UI would need a complete re-design
I’m getting some touch control issues and inability to download the image on iOS.
Nice. I tried it with an image from Unsplash. Maybe you can use the Unsplash API[1] to give people an example to play with.
[1]: https://unsplash.com/developers
Will have a look at this thanks! in the meantime I've added a quick sample gallery to test the editor out
Hey, awesome work! This is sorely needed in the OSS package space.
Are you taking into account separation of concerns? I could see myself adopting this if the UI were customizable in Vue, React, etc.
The actual webgl engine is packaged as a separate library https://github.com/xdadda/mini-gl
As for the more complex UI modules (ie crop) in theory it shouldn't be too difficult to build a vanilla-js separate module, but not sure I'll have the time as these kind of solutions need to take into account so many use-cases and edge-cases that they easily become a nightmare to maintain ...
I'm so glad this exsist. I've been meaning to get something similar started, but did not due to one reason or the other. I'll definitely try to contribute.
Whenever you feel like, ping me on github
Really nice work. I had been using Photopea for cropping and quick edits when preparing references for painting but this is super clean and simple.
This looks great, well done. However, I find one of the main tools I'm always looking for is the ability to resize an image. I want to retain the exact dimensions, just shrink the number of pixels. I can't spot that, is it there? Or would you consider adding it?
I must admit this baffles me a little. Width and heights are measured in pixels. The number of pixels of an image is width x height (eg a raw image 256x256 means it has 256*256 = 65.536 pixels = 262.144 bytes - if RGBA8). I cannot reduce its pixels and keep the same width and height or viceversa. I can a) reduce the quality of an image with a lossy compression (in download if you select jpg you can reduce the quality which will in turn reduce the file size) b) scale an image when displayed in a browser (canvas.style.width > canvas.width) but the underlying image will still be canvas.width
Maybe I'm missing something
I assume they meant aspect ratio instead of dimensions.
oh, in that case it's enough to go in the crop section, select "pic" to keep the current "picture" aspect ratio and resize the crop box
Apologies, by dimensions, I did mean aspect ratio. All I mean is keep the same image, but reduce the number of pixels, and lose some clarity, to reduce the size of the file.
Your suggestion above doesn't work. Try it. It keeps the picture aspect ratio, but it crops the picture. I don't want to crop it, I want to shrink the number of pixels but keep the same image (with loss of clarity because reducing pixels).
Mhh. Maybe if you can show me an editor/app that does what you require will help me figure out how it works and replicate it
MS Paint, Resize/Skew option. Ctrl-W is the hotkey.
It allows you to resize either in terms of pixel count or percentage. The percentage approach is very nice for just putting 50 in both horizontal and vertical fields and getting an image half as large in both dimensions, but showing the same image (with reduced quality, because fewer pixels) and at the same aspect ratio.
done! added in the "composition" menu and fully integrated in the workflow
I preferred just having an input with the correct pixels rather than % (to keep UI clean) but you'll get the same result
Is there any interference from "anti-fingerprinting" which corrupts the image canvas?
ehm, what? I'm not familiar with this issue
https://support.mozilla.org/en-US/kb/firefox-protection-agai...
"Random data is introduced to background images when the image is read back by the website. If a website merely renders data to the background, it will render without alteration. Although typically this does not happen, if the website reads the image data in the background (and potentially displays it to you again), it will have subtle noise that may affect how the image is displayed."
Ok interesting. I'll investigate thanks
I tried to figure out how to crop an image and found nothing. There doesn't seem to be a crop feature as far as I could tell. I'm sure it's probably there, but not easy for anyone to figure out. Would be super easy to make it intuitive right?
it's the composition menu ... will rename it
just select the area you wish to crop and then move to the other settings (colors, ...) to edit it
I tried it again, and finally noticed you have to click the corner of the image to move the selection area. It works, but then I didn't see a "Crop" button. Only trying to be helpful, and not complaining. Nice work tho on this component.
No no I absolutely need this kind of feedback thanks! Being a solo developer is very difficult to gage usability and UX is definitely not my strength.
I tried to integrate the crop/ composition in the natural workflow of image processing, without a discreet "crop" button. But I guess it's not necessarily the most intuite thing to do :)
I'm the new member of your QA team now! haha. I'll try to crop again when you're ready. :)
I did this but when I hit download, I got back the original image instead of the cropped image.
Extremely nice work.
I'd like it if there were separate buttons for (a) reset a section (e.g. colors) back to the default and (b) do not use a section (e.g. colors). Right now, turning (e.g.) colors off loses the settings there. Maybe I missed something though.
I too agree this is great, and see space for another low-hanging UI tweak:
Allow editing numbers to right directly, instead of only using the slider. I really dislike using sliders beyond a first general impression because it is too slow to get things exactly as I want them. I would guess this is a relatively common sentiment.
One feature I don't see but would love to see is text overlay, but that is perhaps moving away from the spirit of the project.
I don't do web based development (all native desktop), but I'd be quite surprised if this was "low hanging".
We have widgets that do this in Ardour and they were far from simple to implement.
Actually it's very easy to implement in a webapp. I will just need to think if there's a sleeker way to do it in terms of UI than just adding a simple input box ... although generally simpler is better so
I have done similar. It is pretty easy, you just have the slider update the input, that is used for the actual calculations. If I ever get past looking and actually download, I will do it.
Editing number yes, will do next as I agree it's high priority from a usability pov.
numbers input added
Thank you!
thanks Just to better understand your request.
a) the Ø at the right of a section resets the section's settings back to default zeros (it becomes white when available) b) closing a section doesn't lose it's settings, unless of course it has been reset
As for a button that allows to "temporarily" disable a section (but keeping it's modified settings underneath), yes it's a very good idea
Yes, that was my suggestion, correctly understood.
added thanks for the suggestion
It would be nice if I can feed an image blob to it, and return the edited image as a blob programmatically - i.e. without the need for an UI to open or download the image. That will help integration/embed it into other apps.
maybe using the underlying webgl library could help your usecase? https://github.com/xdadda/mini-gl
The constructor requires - a canvas (which can be an OffscreenCanvas) - an arrayBuffer with the image (which you easily get from a blob with "await blob.arrayBuffer();" )
This does useful things easily. How hard would it be to use it as a batch process?
Batch processing would ideally require a backend.
Batch processing in the browser would be limited by memory space and therefore everything would have to be queued (even if on more webworkers) and very slow/ unreliable IMHO.
What I'll implement next, if there's a request, is the possibility to save the recipes of the adjustments (crop/ perspective excluded) in order to quickly apply them to subsequent images
in the editor, do add a way to load sample random image to try out the editor instead of having to uploading my own (which most won't bother / don't trust / can't do at work).
Great advise. Will add it next.
Bust just to be clear, images are handled 100% locally on the user machine. No data is sent to servers, no adv, no cookies, nothing ...
wow, awesome turnaround dev time, i see the feature req has shipped already. \^-^/
Yup I get that.
sample images added. thanks for the tip
This is awesome!!! One small UX ask would be to manually edit the values instead of using the sliders. Since this is Open Source (thank you) I may try to tweak that this weekend.
done!
This is neat. Any plans to add blurs and related effects?
yes, I don't use them but if required it will be easy to add
Very cool! What's the license, and how does it compare to some of the other croppers/editors out there? Was it mainly the GL integration?
Ops forgot to add MIT license As for the underlying modules on which it relies Will fix it shortly
I like this. It reminds me of Snapseed. Feature request if it isn’t too hard, the ability to overlay an image and blend them together.
Easy, will add to the TODOs
Lol, I added a todo yesterday: "find or build good image cropper, ideally gl based" ;)
Guess the search might be over, thanks!
let me know of any usability issue. I tried different combinations and this seemed intuitive for me (compared to other solution), but of course I'm too biased.
What does comparable refer to here? Web based image editors? Like what?
there are several web based image editors leveraging webgl out there.
Some of them are very good such as https://img.ly/products/photo-sdk or https://www.polarr.com/web/ or https://pqina.nl/pintura/
I hope to match some of them in terms of features, but with a lightweight and opensource solution
Hey! Thanks for mentioning Pintura :) And good luck with the project!
Nice! Good performance, clean UI, and core functionality.
thanks. It started as a proof of concept for a custom reactivity engine (based on signals and tagged template literals). But while at it I realised I needed something quick and easy for my needs.
I already have a prototype for a self-hosted photogallery that integrates this editor (something like https://immich.app to give you an idea). But it's still too early to share
Thank you for sharing!
What's the license?
MIT. thanks for point that out, I did forget to add it
good AF
thanks!