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.
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
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.
"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."
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
