Introducing RawWorks - A New Web App for Editing Raw Photos

Link →

RawWorks is a web-based photo editing tool.


  1. Web-based access, no installation required.
  2. Offline photo editing with PWA.
  3. Real-time histogram rendering.
  4. Export in XMP/PP3.
  5. Fast performance.
  6. Won’t upload any file.
  7. Easy thumbnail comparison.
  8. Basic editing features.


  1. It only supports a small range of raw files yet.
  2. Due to the limitations from web browser, loading thumbnails may be a little bit slow for some slow removable disk.
  3. Do not support chrome in android yet.

It’s also fully open sourced:

It’s still in early stage. Hope you guys like it~


Looks very cool, looking forward to further development! Thanks for sharing.

1 Like

Forgive my ignorant questions (not a web programmer), but is there dependency between that and your other rust projects somehow? If so, is it integer based as well rather than float?

Thanks for this! It works well. Just tried it with a nikon .nef file. I noticed that what I saw while editing was little different to the export, but I expect that’s a Firefox color issue. If I can use this on my Android phone it might be very useful. Will try it…

Cool and rather fast for a thing in a browser :smiley: worked flawlessly for me (ARW from sony a7)
Is it color managed, I get the felling that the exported result is not exactly as shown in the web page. I left the page without saving so I can’t check, will try again soon.

Could the state be saved to show again when re accessing the page ?

RawWorks use quickraw for decoding and demosaicing only. The result 16bit unsigned integer data will be ported to WebGL for rendering.

Since I uses mediump in the shader, so the rendering process is 16bit float precision.


Shouldn’t be. It directly uses canvas.toBlob to export the whole image.

And I’ve tried in Firefox 107 in macos, don’t encounter the same issue.

The problem you meet, maybe caused by the colorspace settings in canvas. I’ll try to fix it.

1 Like

It is color managed. But the parameters used are not exposed to users for now.

result is not exactly as shown in the web

Maybe it’s caused by the color space issue in canvas. I’ll try to fix this.

Could the state be saved to show again when re accessing the page ?

It cannot for now. But it’s not hard to implement this feature.

Looks interesting, I’ll check back later when hopefully either DNG (my phone) or CR3 (my Canon 850D) raw files are supported.

Sorry but it does not support Canon raw files yet. :smiling_face_with_tear:

@123sg @clind

I’ve test the raw file in windows, macos and linux. But still cannot see the color difference between the exported JPG and the one shown in the web. Could you provide more information about the color difference issue?


  1. The color conversion matrix for raw file is sRGB.
  2. The display colorspace of WebGL context is sRGB.(depends on your browser’s setting but should be sRGB normally)
  3. The exported JPG does not contain any colorspace information.(handled by the browser)

Maybe the problem is, browsers won’t set any colorspace info into the JPG file. And you guys have a color managed JPG viewer program. So the empty-colorspace JPG is displayed in non-sRGB colorspace which causes the color difference.

@123sg @clind

I’ve update a new version v0.0.14 which will add a exif tag colorspace:sRGB to the exported JPG.

Hope it can fix the issue you guys encounter.

I tried it again just now, and it’s still the same. I am running Win 11, Firefox and my screen is profiled. However I’m using windows Photos to view the jpg, which I believe is not color managed.
I’m not at all sure that the problem is not related to my settings or browser. I will try it in Edge in a few minutes.
Here’s a screen shot… hope it shows what I’m seeing. It’s actually more contrast that seems different.

And the Raw file, in case it helps. Licensed Creative Commons, By-Attribution, Share-Alike.
DSC_1059.NEF (20.5 MB)

Just tried in Edge, and also tried viewing the jpg it creates in GIMP instead of Photos.
This one looks different to my last one cause I redid the edit in Edge. So don’t compare it to my last screenshot.
Still seems to be a difference there… sorry to be a nuisance! EDIT: looking again I’m not so sure now. Maybe Edge works better. EDIT no2. It’s still there, but not so obvious in the screenshot…

The browser haven’t update RawWorks to the latest v0.0.14 yet.


For this one, it’s v0.0.14. So the issue seems to be fixed.


Oops. Apologies - I should have seen that. I just tried it again in Firefox, (the new version this time) and while I still feel like there is a very slight difference, it’s effectively a match. Thanks for the quick response and fix!

a very slight difference

I figured out the real problem here.

Both Safari and Firefox won’t embed an ICC profile in the JPEG file, but Chromium based browser will.

Later, I’ll add an option for user to choose between some standard ICC profiles to be embed in the JPEG file, then the issue can be finally fixed.

1 Like

A new version v0.0.15 has been released.

  • For Firefox and Safari, both an EXIF tag, Color Space, is set to sRGB and an sRGB IEC61966-2.1 ICC profile is embedded.
  • For Chromium-based browsers, since they will automatically embed the working ICC profile in the output JPEG, RawWorks will only set the EXIF Color Space tag to sRGB.

Hey, look like it may be fixed, I tried and sampled a few points with colour checker and it matched … (I hope this protocol is valid !)
I upload
top is rawWorks in firefox, bottom is geeqie (color managed) and I use a display profile.

I tried to scale the bottom image to a perfect match to the top image and aligned both in gimp then toggled the “difference” layer mode and it gives this interesting result :

Apart from artefact probably resulting from the imperfect (by nature) resizing extrapolation algorithm result I ended up with a green patch on top of the red/purple coat of my daughter… and it seems to be the only significative mismatch between the 2 pictures.
Dopes it worth investigating ?

Sorry, it really does look different … and i’m on v0.15
Screenshot_2023-01-18_09-06-02 diff

To be on the safe side, I checked opening an image in firefox and geeqie and doing the same Gimp difference layer mode manipulation and achieved perfect match (using a local PNG, I’ll check jpg if you think it’s relevant)

Can somebody else, using display profile (to be in the same conditions) confirm this ?

1 Like