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 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 ?
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?
Currently:
The color conversion matrix for raw file is sRGB.
The display colorspace of WebGL context is sRGB.(depends on your browser’s setting but should be sRGB normally)
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.
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.
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…
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!
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 ?
EDIT
Sorry, it really does look different … and i’m on v0.15
PS
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 ?
worked flawlessly for me (ARW from sony a7)
