Question on "auto_bright_thr=0 " and if it can be turned into a user setting.

[MediaTruth]

@GuidoBartoli and other contributors.

I observed a recent modification in the Utility.py code, which has impacted some of my work. My request is for you to consider transforming this specific setting into a user-configurable option or a toggle. I believe that exploring such options and possibilities will help address various user needs compared to hard coding this

Regarding the comment, I found no supporting evidence that setting "auto_bright_thr=0" is related to RAW data “clipping”, when such a setting was absent to begin with. If there is any evidence, I would appreciate the opportunity to read up on it and potentially discuss it with camera manufacturers to understand the validity and nature of this clipping behavior.

The setting was introduced based on these (unproven) conditions

1. Patches correlating to clipping
2. auto_bright_thr=0Setting recovers clipping. Value 0 is not even listed as recommended when this setting is used. 0.01 is default for a reason.

---First point is unproven. ---Second point strangely only applies to the image(s) from Tony!

Sure, absence of this setting isn't helping Tony's case, and that is where forensics come in. Isn't it? To the contrary, the setting does not make clipping go away in any other authentic image from public domain I analyzed (more on that below)

Here's the rationale received for hard coding this specific setting. I agree, getting full data is a fair ask.

also mentioned that this setting "only assures no clipping"

Question. Is this the right setting to achieve "Full data"? Are we sure this isn't messing with essential brightness controls. Documentation says otherwise. rawpy documentation says otherwise. raw.raw_image_visible gives accesses to full visible RAW image data, convert to 16bit array, and set the clipping threshold to 0. So my argument is setting with auto_bright_thr=0 universally to achieve this objective is not the right tradeoff.

Instead of analyzing the image for why it's being shifted to the right (likely to compensate for low brightness/exposure,), and why the patches show in the first place, we changed the app to make the problem go away.

Consider the following

1. When "auto_bright_thr=0" is set, the image processing code refrains from automatically adjusting brightness based on an analysis of average brightness. This behavior is crucial for forensic work, we would want the analysis of average brightness to detect alterations. Regression to the mean is a powerful tool, in any context and worth keeping it as an option.

2. Instead, the image’s brightness changes based on the original input (that is highly noisy). In the case of a compromised RAW file, maintaining original input or consistent brightness across altered images can inadvertently hide imperfections.

3. Alterations in the RAW file may leave traces in the Bayer data, but the image can be packaged with settings to conceal these imperfections.

4. The crux of the issue lies in the possibility that an “Original RAW file” masquerading as a genuine file with synthetic sensor information could include settings that undermine the very mechanism detecting anomalies. Consequently, accepting these settings as-is poses a significant risk, in my opinion.

More about this setting:

Details

Automatic brightness adjustment: Working with raw images, it's common to have pixels with intensity values exceeding the maximum limit (often represented by a value of 1). These pixels are referred to as clipped pixels. Automatic brightness adjustment attempts to fix this issue by increasing the brightness of the entire image, masking the anomalies and potential fabrications with it.

auto_bright_thr (float): When this setting is present, and This parameter sets the threshold for triggering automatic brightness adjustment. It represents the acceptable ratio of clipped pixels in the image. The default value is 0.01, which means that if more than 1% of the pixels in the image are clipped, automatic brightness adjustment will be activated.

In simpler terms, auto_bright_thr defines how sensitive the RAWPy library is to clipped pixels in a raw image. A lower threshold (e.g., 0.005) means the library will be more aggressive in automatically adjusting brightness to recover clipped highlights, while a higher threshold (e.g., 0.02) means it will tolerate a higher percentage of clipped pixels before taking action. Setting it to 0 disabled automatic brightness and sets values sets in original image. Which is counterproductive in image forensics for various reasons including noise in lower intensities or making it challenging to discern fabrications.

Attention

It's important to note that automatic brightness adjustment can introduce noise to the image. Therefore, it's crucial to find the right balance between recovering clipped highlights and preserving image quality. You can adjust the auto_bright_thr value based on your specific needs and the characteristics of the raw image.

---

Note: : The image referenced in Issue 86 to make the change shows no luminosity clipping, which is the first indicator of highlight clipping for the patch areas. The reason for patches is very likely to be different, in the absence of luminosity patterns, and by turning off brightness scaler and consuming image settings as is can impede analysis. If we need to go into the image analysis itself, we can do that, but I feel it's outside the scope of this application, and must be designed with spectrum of use cases, and not to custom fix one image or selective set of images.

This is a RAW file loaded on 0.89d, notice the clipping is present even after the setting is set to 0, supporting the reasoning shared above.

Link to image Link to image Link to image Link to image

Link

I used Cr2 files where I can so Author can do an apples-to-apples comparison where applicable.

---

My Request to the author of this powerful app, which I've been using for years now.

My final request is to kindly consider making the "auto_bright_thr=0" setting a user-selectable option., either as a toggle or a radio button. Happy to answer any questions you have Author/Contributors.

[MediaTruth]

My references:

• "Process control" for forensic investigation https://www.scribd.com/document/517338131/C-PROC-Electronic-Evidence-Guide-2-1-EN-June-2020-web3-docx
• Digital Forensics & Incident Response https://www.sans.org/digital-forensics-incident-response/
• International Journal of Digital Crime and Forensics https://www.igi-global.com/journal/international-journal-digital-crime-forensics/1112
• https://photo.stackexchange.com/questions/70955/how-does-raw-prevent-ugly-digital-clipping

[BakersTutz]

Auto Brightness Threshold defaults to 0.001 (0.1%). Why would you want to clip and throw away part of your image data? You are going to get skewed results. It should be set to 0.

[TJPofTexas]

The setting is described in the documentation for RawPy, which is library from which the function is being called in line 204 of Utility.py.

The documentation for RawPy can be found here: https://letmaik.github.io/rawpy/api/rawpy.Params.html

It seems from RayT's comment that they do not understand how raw.postprocess() is used to ingest raw images, and how certain settings can result in unintentional edits being made to the raw photo which result in loss of image fidelity, sensor noise data, and other information which would be necessary to evaluate an image for the purpose of identifying manipulation.

From the documentation:

"auto_bright_thr (float) – ratio of clipped pixels when automatic brighness increase is used (see no_auto_bright). Default is 0.01 (1%)."

The setting employed, "auto_bright_thr=0", simply prevents the auto brightness setting from being allowed to clip any pixels when the brightness is being adjusted.

Considering the application, a forensic photo evaluation utility, it is prudent to minimize the impact to data fidelity caused by clipping during image import.

The now employed setting (0.89d) as listed below seems appropriate for the majority of use cases. However, a user could make changes to Utility.py as their use case dictates.

raw.postprocess(use_auto_wb=True, auto_bright_thr=0)

[MediaTruth]

Auto Brightness Threshold defaults to 0.001 (0.1%). Why would you want to clip and throw away part of your image data? You are going to get skewed results. It should be set to 0.

Please re-read my request as I'm asking for a user option as opposed to hard setting.
Secondly which part of the image is being thrown away? Why are specific areas being thrown away that are interestingly also look edited? Regarding the Brightness setting. A. There is no proof of clipping. B. There is no proof of clipping targeting specific areas or ranges. c. Request is for a user option.

Thanks

[MediaTruth]

The setting is described in the documentation for RawPy, which is library from which the function is being called in line 204 of Utility.py.

The documentation for RawPy can be found here: https://letmaik.github.io/rawpy/api/rawpy.Params.html

It seems from RayT's comment that they do not understand how raw.postprocess() is used to ingest raw images, and how certain settings can result in unintentional edits being made to the raw photo which result in loss of image fidelity, sensor noise data, and other information which would be necessary to evaluate an image for the purpose of identifying manipulation.

From the documentation:

"auto_bright_thr (float) – ratio of clipped pixels when automatic brighness increase is used (see no_auto_bright). Default is 0.01 (1%)."

The setting employed, "auto_bright_thr=0", simply prevents the auto brightness setting from being allowed to clip any pixels when the brightness is being adjusted.

Considering the application, a forensic photo evaluation utility, it is prudent to minimize the impact to data fidelity caused by clipping during image import.

The now employed setting (0.89d) as listed below seems appropriate for the majority of use cases. However, a user could make changes to Utility.py as their use case dictates.

raw.postprocess(use_auto_wb=True, auto_bright_thr=0)

But Sherloq had no such setting to begin with in previous versions.

You are indicating that the setting when used, defaults to 0.01, and therefore it might be worth keeping it at 0. But in the case of sherloq, in the previous version, it was not a setting at all, so your argument may not be applicable.

Besides, i dont understand the contention, does the user option hurt?

---

I highly encourage you to re-read your statement. Setting "auto_bright_thr=0" is a possible param WHEN the setting is used . As opposed to Sherloq NOT using the setting to begin with.

Do you know how many other settings are not bring called by Sherloq that are part of RawPy library, why not make an argument for all those settings, when many of these other settings are extremely problematic.

_""auto_bright_thr (float) – ratio of clipped pixels when automatic brighness increase is used (see no_auto_bright). Default is 0.01 (1%)."

The setting employed, "auto_bright_thr=0", simply prevents the auto brightness setting from being allowed to clip any pixels when the brightness is being adjusted."_

[JohnConnor01]

Auto_bright_thr was not even being called in the earlier version 0.87? Use_auto_wb was in 0.87, but auto_bright_thr was not. Your position is the autobright uses a default of 0.01 and that it should be changed to 0. But the setting wasn’t even present in Sherloq?

[MediaTruth]

Auto_bright_thr was not even being called in the earlier version 0.87? Use_auto_wb was in 0.87, but auto_bright_thr was not. Your position is the autobright uses a default of 0.01 and that it should be changed to 0. But the setting wasn’t even present in Sherloq?

Indeed, thanks for chiming in.

The auto_bright_thr parameter in the RAWPy library is used to control automatic brightness adjustment in raw images.

Here's more I could find on "auto_bright_thr" setting, which tells me this was not needed as a setting to begin with, or if included best f provided as a user option.

Details

Automatic brightness adjustment: When working with raw images, it's common to have pixels with intensity values exceeding the maximum limit (often represented by a value of 1). These pixels are referred to as clipped pixels and can appear as bright white areas in the image. Automatic brightness adjustment attempts to fix this issue by increasing the brightness of the entire image.

auto_bright_thr (float): This parameter sets the threshold for triggering automatic brightness adjustment. It represents the acceptable ratio of clipped pixels in the image. The default value is 0.01, which means that if more than 1% of the pixels in the image are clipped, automatic brightness adjustment will be activated.

In simpler terms, auto_bright_thr defines how sensitive the RAWPy library is to clipped pixels in a raw image. A lower threshold (e.g., 0.005) means the library will be more aggressive in automatically adjusting brightness to recover clipped highlights, while a higher threshold (e.g., 0.02) means it will tolerate a higher percentage of clipped pixels before taking action.

It's important to note that automatic brightness adjustment can introduce noise to the image. Therefore, it's crucial to find the right balance between recovering clipped highlights and preserving image quality. You can adjust the auto_bright_thr value based on your specific needs and the characteristics of the raw image.

Cases where clipping might happen

The images with heavy haze like one shared by before are nearly impossible to experience clipping. Infact the exif data on the image has a very different story to tell in terms of exposure and light compensation, indicating absence of strong light.

[JohnConnor01]

Auto Brightness Threshold defaults to 0.001 (0.1%). Why would you want to clip and throw away part of your image data? You are going to get skewed results. It should be set to 0.

Question. Why is there an assumption Auto Brightness is being called on in the earlier version? Use_auto_wb is clearly being called. But auto_bright_thr is not here. Is the assumption that every command in RawPy is being called on?

[jkphillyfan]

Setting "auto_bright_thr=0" adds a lot of noise to the image. Please consider a user option instead.

[JohnConnor01]

The auto_bright_thru is being added to version 0.89 even though it wasn’t being called in 0.87, and the reason given was clipping. Signal separation was referenced on the original post. The specific patches shown on the photo are being attributed to clipping. These patches were clear on Signal Separation, Bit Plane, and Error Level Analysis on version 0.87. They also align very closely with what we see on Dark Table as we adjust the contrasts. Even though autobright is not being called in 0.87, the assumption seems to be that it is being called, and having a significant impact on the image analysis.

The original post says explicitly: “The clipped areas are standing out” as he references the patches on the mountain. So a command that was not being called in 0.87, is being blamed for isolated patches showing up on an image for Signal Separation, BitPlane, and ELA?

That also align with what we see on an entirely different application, Dark Table?

I would also appreciate if there could be an option for users.

[vincent-wmtm]

@MediaTruth I have to admit I'm confused by this issue. Much of the information you've provided here actually seems to directly contradict the point you're trying to make? I think you may have misunderstood a lot of the documentation you're reading here. Especially when it comes to how these default values work and the overall behavior of the auto brightness functionality with a given clipping threshold. Strangely, you also seem to have brought several people with you to a previously very quiet repository that misunderstand these concepts in exactly the same way you do. Very curious.

Regarding your desired 'user setting' - this would be an incredibly niche feature, as it would be intentionally altering the data of your image at the time of loading and could potentially result in erroneous values under certain conditions. I seem to remember there was an issue here intended to directly address these relevant edge cases to prevent problems going forward. As such, it seems like you're specifically requesting an option to enable regression for these edge cases? I can't imagine a workflow where that makes sense, but I won't presume to know anything about the work you're doing.

If you really want this feature, I think you might have been better served forking the repository and adding the toggle yourself. It seems you've spent considerably more time in this thread trying to be persuasive about your desired toggle than the hour or less it would have taken to actually build this functionality yourself.

As a friendly note and aside: It's really not good etiquette to block everyone that has a question or constructive criticism for you. That makes it appear you're trying to create an illusion of consensus by shutting dissenting voices out of a conversation where you're trying to push for a very specific outcome.

Lastly, I also feel I should remind you that a single user having multiple free accounts is a direct violation of the GitHub Code of Conduct and the GitHub Terms of Service.

[MediaTruth]

@MediaTruth I have to admit I'm confused by this issue. Much of the information you've provided here actually seems to directly contradict the point you're trying to make? I think you may have misunderstood a lot of the documentation you're reading here. Especially when it comes to how these default values work and the overall behavior of the auto brightness functionality with a given clipping threshold. Strangely, you also seem to have brought several people with you to a previously very quiet repository that misunderstand these concepts in exactly the same way you do. Very curious.

Regarding your desired 'user setting' - this would be an incredibly niche feature, as it would be intentionally altering the data of your image at the time of loading and could potentially result in erroneous values under certain conditions. I seem to remember there was an issue here intended to directly address these relevant edge cases to prevent problems going forward. As such, it seems like you're specifically requesting an option to enable regression for these edge cases? I can't imagine a workflow where that makes sense, but I won't presume to know anything about the work you're doing.

If you really want this feature, I think you might have been better served forking the repository and adding the toggle yourself. It seems you've spent considerably more time in this thread trying to be persuasive about your desired toggle than the hour or less it would have taken to actually build this functionality yourself.

As a friendly note and aside: It's really not good etiquette to block everyone that has a question or constructive criticism for you. That makes it appear you're trying to create an illusion of consensus by shutting dissenting voices out of a conversation where you're trying to push for a very specific outcome.

Lastly, I also feel I should remind you that a single user having multiple free accounts is a direct violation of the GitHub Code of Conduct and the GitHub Terms of Service.

Thank you for your feedback. I apologize if my previous communication caused any confusion. Let’s focus on the technical aspects and not on personal aspects. You made statements without providing any explanation as for why you think I misunderstood anything. Your entire post is ad-holmium and unnecessary.

If you seek additional details, kindly express that explicitly. However, refrain from assuming a position that allows denying requests without a thorough understanding of the subject.

If you really want this feature, I think you might have been better served forking the repository and adding the toggle yourself. It seems you've spent considerably more time in this thread trying to be persuasive about your desired toggle than the hour or less it would have taken to actually build this functionality yourself.

Vincent, again while I appreciate your feedback, I believe it’s unnecessary to single out any individual when discussing requests. If you’d like to engage in a technical or objective discussion, I’m open to accommodating that.

[Ray9T]

As a community, we must have each other’s backs and avoid personal attacks.

Just a heads-up: some image fabricators might blame clipping in RAW images to cover up their edits. They might say the overexposed spots are just unavoidable clipping, but really, they could be hiding fabrications there.

So, if you’re investigating and need to compare images with or without auto brightness to get a clearer picture, that sounds like a reasonable ask.

[GreatRevealer]

Your claim that turning off auto brightness will hide clipping is completely wrong. The auto brightness setting now implemented ensures auto bright NEVER clips the image. This is how a forensic analysis tool should work; preserving image fidelity foremost.

It's odd that you're so adamant about having someone else make these changes to their repo for essentially a special use case to add a feature that is far from easily justified in the context of forensic photo evaluation.

Knowing your background and what you will obviously do to twist and present such changes in your favor is, to me, proving your dishonesty. Those who know you know you would use these edits to continue to argue Jonas' photos are fake and the hoax MH370 videos are real so you and others can continue profiting off of clicks despite the horribly tragic reality of that case. Utterly reprehensible.

Why don't you make these special use case edits to your own fork?

Or just edit utility.py file yourself for the exceedingly rare cases when an honest user might somehow need different settings?

[NaturalML]

I'm a Photographer with decent exposure to rawpy and hopefully can add something to this discussion.

@MediaTruth, you’re right. We need to separate clipping and brightness, and think this trough and ask ourselves the nature of this setting and it's relation to the outcome.

The auto_brightness_thr=0 setting is unrelated to actual clipping; it’s actually about how brightness should react based on the percentage of clipped pixels indicated by rawypy, which isnt part of the brightness control. In a RAW, there's almost always pixels that's outside the intensity range, and this setting at "0" blocks the brightness application on RAW images that is critical for SNR and forensics.

However when called, a value of 0 is not a recommended setting, and for those in forensics, auto_brightness_thr=0 should be avoided due to unpredictable behavior. Best if this setting is left out completely.

The library clearly explains the behavior of this setting, and it’s not related to clipping but rather how brightness adjustments are applied based on the clipped pixels. The same principle applies to the exp_shift exposure setting ( be cautious when applying either settings) https://letmaik.github.io/rawpy/api/rawpy.Params.html

This is to setting for when automatic brightness is set based on ratio of clipped pixel that rawpy determines (value consumed) and subsequently trigger automatic brightness. For a fabricated image these values can vary a lot and 0 forces the setting to very sensitive and not recommended,

If a fabricated image is investigated, we do not want this setting as 0 results in inconsistent brightness applied, one that can adversely effect your image noise too and investigation. Value 0 for auto_bright_thr will always adjust brightness regardless of the number of clipped pixels. This automatic aggressive adjustment is undesired and likely introduces noise in the image, potentially obscuring subtle manipulations or details depends on what one might want to call it.

If automatic brightness adjustment is necessary, it's might be prudent to use no_auto_bright=True. If you are willing to tolerate a slight possibility of automatic brightness correction for extreme cases (such as highly underexposed or overexposed images), you can experiment with auto_brightness_thr=(value)

If your preference is for complete control over image brightness and you want to avoid any automatic adjustments, use no_auto_bright=True. Again, if you are open to a slight possibility of automatic brightness correction for extreme cases, you can try adjusting auto_brightness_thr=0. Keep in mind that this may not fully prevent auto-brightness adjustments.

Edit: I can now see Sherloq previous brightness adjustments implementation in global settings and don't quite get the need for auto brightness thr settings called again.

Regarding clipping, it is related to the intensity of light hitting the sensor and cannot be resolved solely by adjusting the brightness setting. For RAW images, if you must use brightness in conjunction with other settings, then advise converting to a 16-bit array and adjusting the thresholds is recommended to avoid clipping. In all honesty, the app might already be handling this

The code above, it’s puts a lot of trust in the RAW image creator to not fabricate and hide flaws behind settings that come with RAW files, so as always, I advise caution with these settings in the forensics world. It’s okay to introduce these settings if you’re into an image viewer for display, but not for forensics.

[JohnConnor01]

The likelihood of this being an issue with Sherloq goes down when you see the exact same areas being highlighted on other applications like Dark Table.

These are the things you would analyze if you were approaching this objectively and exploring all possibilities. This becomes even more important when you see the lack of supporting evidence presented for this on the original post.

Autobright was not even being called in 0.87. Just because it’s in RawPy doesn’t mean it was being called? And adding auto_bright_thru=0 to version 0.89. And seeing these isolated patches go away. Is not proof that clipping causes the patches to show up in the first place.

There are more plausible explanations. Like auto_bright_thru=0 is introducing excess noise and inconsistency. The logic behind WHY this setting would introduce excess noise makes sense. And those patches in those very specific isolated areas - are corroborated by an entirely different application - Dark Table. (Is the new assumption that Sherloq 0.87 and Dark Table are both glitching? In the exact same areas?)

I will show same screenshots below of version 0.87 vs 0.89. I would appreciate a user option until more testing can be done.

0.87 vs 0.89
0.87 vs 0.89 0.87 aligning with Dark Table

[GuidoBartoli]

I read all the comments here, no need to continue discussing here, please continue on https://github.com/GuidoBartoli/sherloq/issues/96 where I will post my answer.