also i wrote “maybe it is not camera support problem, bc DNG editor is 2012year and my PS upd is not last…so im cant know reason…”
maybe is reason that no one dev say nothing about will they do support or not or this is different problem.
p/s since you moderator can you lock this topic to reply here only devs and me?
bc i understand that people will come and can do nothing with this, bc is devs topic…
thank you
@heckflosse
if i can do something let me know. I will help with everything. thats why am I here
or at least will it be solve after or a problem in another and better not wait?
@dssdd, if the software doesn’t have the color primaries for your camera, the colors won’t look right. I just tried to open your second raw file in my software, which uses both the dcraw and RawTherapee camera data, and your camera wasn’t found.
To the pink colors, first here’s the histogram of your second image, data right out of the DNG file with no processing other than a conversion from integer to floating point 0.0-1.0
That green line at the right is your camera’s saturation point, where it can no longer record a valid light intensity. It’s a green line because the green channel is in front. The pixels counted there can no longer express the measured tone, or the asserted color, from the scene, they’re just arbitrarily white. Both the software you came from and RawTherapee can engage algorithms that make up pixels that look nice instead of flat white, but in terms of what the scene contained there’s no data.
Further, when white balance correction is applied, the three channels shift accordingly, and that single spike becomes three separate ones, and the pink shade is because the green channel is the left-most spike and the other two are close or at the right. Software usually scales the image so they all three go back to saturation, or it does some “reconstruction” trick.
I think these two things describe why your colors are off.
@ggbutcher
thank you
It looks logical that the software does not support the camera.
I thought so too at first. but as I already wrote another software is much older, and also can not have camera support …
and not only in that photo where the sky is gray, not pink,
but also regarding the profile editor, the RT does not understand the profiles made by it, and this is also a problem, because I can not even manually correct them.
anyway, I just want to get an off answer from the developers, if it’s really problem only in camera support, or not, and help them to more speedy implementation of it if I can.
regards
The metadata tags your camera as “SM-G970F”. I Googled it, and it appears to be a Samsung S10 cellphone, no? That’s somewhat new territory for us old folk…
Nominally, what it takes to insert minimal camera support is to shoot an image of a color target and use it to produces a camera profile. My granddaughter has a S10, next time she visits in the daylight, I can make such an image. Assuming the US version has the same sensor…
As cellphones incorporate the software to shoot raw, this’ll be new territory for support…
The squares in the upper image part represent overexposed areas within the RAW data. Which means the light was so bright that the sensor data is corrupt.
Programs like Rawtherapee or others can only try to ‘imagine’ what data could have been there.
Resulting problems often are flawed white balances:
To set the white balance I first tool a sample from the ‘grey’ sky in the top-right. The result is a greenish image, which you can see in the left half of the screenshot
On the right side you see the white balance taken from a sample from the stonewall in the center (where the small rectangle is). Here the white balance looks good.
What works different in various programmes are the algorithms for highlight reconstructions for overexposed areas.
Sometimes they look good, sometimes they create weird colors.
My recommendation: Take a properly exposed photo and load it into Rawtherapee and Photoshop. I don’t think that there will be bigger problems.
Edit: For highlight reconstruction programs look for colors around the overexposed areas and try to move them into them. Could be that some details like these fine lines are lost. In these areas it is not easy to detect valid data.
I’m guessing that this, plus the fact that the Galaxy S10 has three back-facing cameras (plus 2 front facing, although it’s hard to imagine taking the selfie cameras seriously), will make things difficult unless each camera/sensor combination can be identified.
Cameras:
12 Megapixel f/1.5-2.4 variable aperture camera with 960 FPS slow-mo, 4k, etc
is true, but not affect our case, bc only one camera can shoot in raw in all devices…
and different models have different code name SM-G9*** but only two mods.
@heckflosse
its ok, im wait, but please just dont forget about me compleatly
Please don’t make your prejudice about open source projects into a self-fulfilling prophecy. You need to adjust your expectations for open source projects.
It’s entirely up to the developers to decide if they want to work with timelines and so forth, or just cherry-pick issues along the way. You might think this means a project is badly organised, but that’s the reality whenever something is done entirely by volunteers.
Don’t assume your issue needs priority, simply because it affects you.
Keep a constructive dialogue when the developers aren’t as quick as you would like, don’t get defensive.
hey bro, with all respect, but what the hell self-fulfilling prophecy???
from the start i ask only for easy and short answer that clear situation -
“yes, we will take about for X-weeks”
or
“no, we will not take, until there is no possibility and we do not see it in the next six months, later - perhaps.”
like that, it’s so simple and it’s damn banal politeness.
I do NOT command “quickly add urgently, bastards,” NO.
I’m not aware of your situation, right? simple explanation of intentions, and approximate timelines …
why make me a villain?
