There is also React-Cropper if you want to CropperJS with React: https://github.com/react-cropper/react-cropper
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?
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.
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...
Yes I'm planning to move to the edge as soon as it's in a later stage of development
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
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?
Are you taking into account separation of concerns? I could see myself adopting this if the UI were customizable in Vue, React, etc.
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 ...
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();" )
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.
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
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.
We have widgets that do this in Ardour and they were far from simple to implement.
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
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 ...
Guess the search might be over, thanks!
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
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
just select the area you wish to crop and then move to the other settings (colors, ...) to edit it
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 :)