Sherloq 0.89 Issues with auto_bright_thr=0

[JohnConnor01]

I have been testing the new version of Sherloq 0.89 after the recent changes. There are some observations I have noticed since "auto_bright_thr=0" has been added. From what I've seen, this is making it very difficult/impossible to to separate the signal and noise. My post will be in reference to the initial post. Initial Post: https://github.com/GuidoBartoli/sherloq/issues/86 Isolated patches were showing up on a photo, and this was being cited as areas affected by clipping. There was also a Histogram comparison being shown. As the RGB intensity values get pulled significantly to the left, it becomes harder and harder to separate the signal from the noise for specific images. So I wanted to adjust the settings to see if these areas still appeared when there was barely any clipping of the RGB intensity values (anything over 255 gets clipped & autobright is activated). I will show these examples below. First there are some important points to make: 1.) Adding this 1 setting, and seeing the patches go away. Does not mean clipping was causing the patches to appear in the first place. 2.) These very patches were in almost identical areas on this same photo in Dark Table - a completely separate application. I will illustrate this below. I also did not see the original poster mention the Dark Table results. I am not sure if he was unaware, but checking other applications for corroborating results would be one of the first things I would do in a situation like this. 3.) Autobright was not being called in Sherloq 0.87. Even though it was being cited as the reason for clipping, and subsequently the reason for patches showing up on a photo. To address this, auto_bright_thr=0 was added to Sherloq 0.89. This will potentially cause a wholesale shift in RGB intensity values of many photos read by Sherloq 0.89. And it will not prevent clipping with all RAW photos.

The next point is very important 4.) This is also going to default to the settings that were present in the original RAW File. Because in this case, the settings in the original RAW file were the thing that caused the RGB intensity values to shift to the left significantly. If I am trying to critically analyze a RAW file, why would I also want to 100% trust the RAW file? This is another reason why it would be great to have a user option.

This point is also very important. 5.) Adding auto_bright_thr=0 will NOT prevent clipping. It will prevent clipping in the photo (atadams) shared. But it will not prevent clipping universally. And this was implemented as a way to eliminate clipping- which it will clearly not do universally as highlighted below. Which makes a stronger case for a user option.

I used the same image from the original post. And I tried 3 different settings: auto_bright_thr=0.0015 auto_bright_thr=0.003 auto_bright_thr=0.005

As the RGB intensity values get pulled to the left - more and more noise is being introduced to the analysis. I will start with (auto_bright_thr=0) on Signal Separation so you can see the progression.

This is what the same image looked like on Sherloq 0.87 with Signal Separation & Bit Plane. These same areas showed up on Dark Table (below)- an entirely different application.

This is the same image compared with Sherloq 0.87 and Sherloq 0.89.

Below. I will show auto_bright_thr=0.0015. Signal Separation, Bit Plane, Histogram. As you can see even with 0.0015, the patchy areas still appear. Histogram on auto_bright_thr=0.0015 Now I will move to auto_bright_thr=0.003 Histogram on auto_bright_thr=0.003 Lastly, this is auto_bright_thr=0.005 Histogram on auto_bright_thr=0.005

I mentioned earlier that adding auto_bright_thr=0 and seeing these patches go away. Does NOT mean that clipping from an autobright setting was causing the patches to appear in the first place in Sherloq 0.87. There is a more plausible answer and that is auto_bright_thr=0 is pulling some photos RGB intensity values to the left and making it very difficult/impossible to separate the signal from the noise. This is simply causing the image to be flooded with noise, making forensic analysis impossible. (This does not happen with ALL RAW photos. And we have already demonstrated how numerous RAW photos will still be clipped with this setting)

Given there is a second application, Dark Table, that shows the same areas as Sherloq 0.87. And given how significant these changes have been to all photos analyzed with Sherloq. I would greatly appreciate if there could be a user option for this. (typo was corrected)

Thank you.

[BakersTutz]

The auto brightness threshold is the percentage of pixels that will be clipped after brightening. The auto brightness doesn’t get “activated” after the clipping exceeds a certain amount. It’s already on and the default threshold is 1%.

Those patches in your signal separation screenshots are the areas that are being clipped due to the auto brightness. This is something you DON’T want to happen. You are compromising your image data this way.

“As the RGB intensity values get pulled to the left - more and more noise is being introduced to the analysis.” Nope. That noise is already there in the original image. When you are clipping the highlights, you are removing the noise. You are not adding any noise.

[vincent-wmtm]

This issue appears to be a duplicate of https://github.com/GuidoBartoli/sherloq/issues/93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

[Ray9T]

Excellent analysis @JohnConnor01 and thank you for the tests, I agree there is no proof of clipping resulted in the patches on the image. auto_brightness_thr=0, in this case (due to small set of pixels out of range) is disabling auto brightness, and consuming values set in the original file, and for all practical reasons this is the end of investigation as we lack options to view the image without consuming these values.

An erroneous and unproven proposition that the default setting 0.01 clips the image, therefore the right value is 0 has resulted in strange behavior. Please note: Rawpy does not recommend setting the value to 0, and to begin with this setting was absent in the previous version. Like someone mentioned earlier, there are other ways to avoid clipping.

With this setting, we're going to consume the settings the potential fabricated RAW image sets (with calibrated values to hide issues). If such a setting must be introduced, i request author to allow users to set their settings.

[JohnConnor01]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results.

In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

[vincent-wmtm]

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it?

The issue creator blocked everyone from the discussion before your darktable screenshots could be discussed. The settings you're using in darktable are extreme and essentially creating the strange visuals you're seeing out of nothing. You could reproduce this with just about any other image that had strong highlights.

Regardless, this is essentially the same complaint regarding the same code change and probably doesn't need its own thread. https://github.com/GuidoBartoli/sherloq/issues/93

[JohnConnor01]

The auto brightness threshold is the percentage of pixels that will be clipped after brightening. The auto brightness doesn’t get “activated” after the clipping exceeds a certain amount. It’s already on and the default threshold is 1%.

Those patches in your signal separation screenshots are the areas that are being clipped due to the auto brightness. This is something you DON’T want to happen. You are compromising your image data this way.

“As the RGB intensity values get pulled to the left - more and more noise is being introduced to the analysis.” Nope. That noise is already there in the original image. When you are clipping the highlights, you are removing the noise. You are not adding any noise.

Is the goal of Photo Forensics to have zero clipped RGB intensity values? This is a forensics tool. Not a basic image viewer. (Also we demonstrate numerous times in this thread that many RAW photos will STILL be clipped with this setting. More examples below.)

Separately. You made a declarative statement in your response. “Those patches in your signal separation screenshot are the areas being clipped due to the auto brightness”

Where is your evidence of this? Because if you add the setting that makes it go away. And then the histogram shows no clipping? Is that the sum total evidence you have for this?

What would be your explanation for why these exact areas also show up on an entirely different application, Dark Table?

[JohnConnor01]

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it?

The issue creator blocked everyone from the discussion before your darktable screenshots could be discussed. The settings you're using in darktable are extreme and essentially creating the strange visuals you're seeing out of nothing. You could reproduce this with just about any other image that had strong highlights.

Regardless, this is essentially the same complaint regarding the same code change and probably doesn't need its own thread. #93

I would suggest corroborating results from an entirely different application is as significant as anything that was shown in the original post. In a thorough analysis. That would be one of the first things analyzed.

I’m sure there are other changes that can be made to the code to make those patches go away. But it also doesn’t mean the thing that was changed - causes those patches in the first place. More thorough investigation and research is always needed.

For the record. Please see the response about corroborating results from other applications.

[TJPofTexas]

I have confirmed what @vincent-wmtm is saying about the issue @JohnConnor01 is observing in darktable by loading the image in question and presenting the result below.

It seems to be a severe misapplication of black levels during import which is causing considerable clipping on @JohnConnor01's image.

See example below of IMG_1839 taken by Jonas De Ro, which exhibits no clipping with default CR2 raw load settings in darktable.

Further, if this image is then saved as jpeg and then imported in Sherloq (even in 0.87C), it does not exhibit this clipping observed by @JohnConnor01.

This seems to be a case of user error and incorrect settings by @JohnConnor01

[PeterWem]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results.

In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

Canon uses black level 1023, 1023, 1023 and 1023 for that image. Hit reset and read the manual.

The darktable developers locked the two threads the user MediaTruth created. This due to harassment from MediaTruth.

https://discuss.pixls.us/t/verifying-whether-this-image-has-been-doctored/41894/

https://discuss.pixls.us/t/odds-of-subject-distance-similarities-to-a-2-decimal-point-with-a-mix-of-camera-settings/41920/2

Canon U.S.A. trashed one of two threads due to harassment. Even if the first thread was removed you can still view all the posted images https://community.usa.canon.com/t5/media/gallerypage/user-id/232911/tab/all

[MediaTruth]

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it?

The issue creator blocked everyone from the discussion before your darktable screenshots could be discussed. The settings you're using in darktable are extreme and essentially creating the strange visuals you're seeing out of nothing. You could reproduce this with just about any other image that had strong highlights. Regardless, this is essentially the same complaint regarding the same code change and probably doesn't need its own thread. #93

I would suggest corroborating results from an entirely different application is as significant as anything that was shown in the original post. In a thorough analysis. That would be one of the first things analyzed.

I’m sure there are other changes that can be made to the code to make those patches go away. But it also doesn’t mean the thing that was changed - causes those patches in the first place. More thorough investigation and research is always needed.

For the record. Please see the response about corroborating results from other applications.

Interesting. Your images show no significant changes in patch areas as the settings changed from 0.005 to 0015. But somehow 0 is hiding these patches with additional noise.

I observe the absence of any noise patterns/patches in luminance settings. That's strange!

Clipping is a direct result of intensity and corelates with luminosity, yet we see no pattern in Luminosity but only in specific color channel, this is a huge red flag.

See example of a genuine image clipping: luminosity and color noise patterns correlate

Luminosity noise shows, which is a primary indicator for clipping.

Color channel indicator

In the image that referenced to make the code change (auto_bright_thr=0) No Luminosity clipping anywhere

No Luminosity clipping on the areas with patches

Patches (unlikely to be clipping) shows up ONLY on specific color channels

Using Raw Therapee to indicate Clipped areas ( If any)

I used Raw Therapee to check if the areas pointed by Tony as clipping in 1837 image he shared, and there is no indication these patches are due to clipping (i.e. going over intensity 255). The change made in recent version is likely based on an erroneous assumption, and one image/set.  

Anyone in forensics know this is a red flag, and code changes made to hide these artifacts may not be the best approach.

---

Might be worth going over what Clipped Pixels are:

Clipping occurs when the intensity value of a pixel exceeds the maximum value the camera sensor can record. This happens in very bright areas of the scene, like the sun or highlights reflecting off chrome.

The Connection between Clipped pixels and Luminosity

Luminosity helps identify areas where clipping might occur. By analyzing the distribution of luminosity values/pattern, you can see if there are significant peaks at the maximum intensity level, indicating potential clipping. -Clipped pixels directly affect the perceived luminosity of the image in those specific areas. Since the actual intensity information is lost, clipped pixels appear as distorted in luminosity noise, losing detail. This intensity when recorded at the sensor should corelate with noise in color channels. This is the nature of a genuine image,

For a forensic tool it is extremely important to allow user customization based on image complexity and fabrications, and my request is to allow user settings when settings like auto bright_thr=0 can be detrimental to investigation and impedes investigation when such settings are hard coded.

The images you're sharing @JohnConnor01 are intriguing, and a demands additional investigation. For a case of single image or images from the same set, if people have objection, they can always get it verified by professional services. But the tooling should cater to wide set of use cases and what-if scenarios.

[JohnConnor01]

Please see all 4 photos with this mountain from the file we are discussing. Given that this specific area is the area in the original photo that has the patches, I wanted to analyze this area/asset on the other 3 photos. If what we see in the original photo is because of clipping. I would not expect to see this same area show issues in the other 3 photos. (Additional clarifying point. I’ve been following this discussion online for the last couple weeks. I’ve seen most forensic results be dismissed because of clipping. Not just patchy areas. But most everything other than a blank noise profile. So I wanted to assess the other 3 photos that have the same area in it. Not necessarily for patchy areas. To see if there is additional corroborated results that might suggest the issue is with the asset/area/photo. And not the settings. If the explanation for the other 3 photos is also clipping. That’s fine - it would just require a longer discussion about clipping, angles, luminosity, etc. If the position is that this is the way it’s supposed to look. That is a completely different conversation)

I am using Sherloq 0.89. And I will set the auto_bright_thr=0.005 for all 4. Link to file with 19 photos https://drive.google.com/file/d/1JT0KOI1yJEtZVzdQtVBHWzyKujFDlBrb/view

Original Photo 1837

1839

1840

1841

[JohnConnor01]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results. In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

Canon uses black level 1023, 1023, 1023 and 1023 for that image. Hit reset and read the manual.

The darktable developers locked the two threads the user MediaTruth created. This due to harassment from MediaTruth.

https://discuss.pixls.us/t/verifying-whether-this-image-has-been-doctored/41894/

https://discuss.pixls.us/t/odds-of-subject-distance-similarities-to-a-2-decimal-point-with-a-mix-of-camera-settings/41920/2

Hello. Well I am not MediaTruth so I can't speak for other people. I am simply addressing an issue about an open source forensic tool changing a setting.

But nothing said in your post addresses the fact the Dark Table the software showed areas in the same places Sherloq 0.87 did. So a different application corroborated the results. The same results that were rejected on Sherloq, and the reason cited was clipping. Clipping was causing the patches to show up.

And I just analyzed all 4 photos in the same area. Can you please see my last response and reply to that.

[MediaTruth]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results. In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

Canon uses black level 1023, 1023, 1023 and 1023 for that image. Hit reset and read the manual.

The darktable developers locked the two threads the user MediaTruth created. This due to harassment from MediaTruth.

https://discuss.pixls.us/t/verifying-whether-this-image-has-been-doctored/41894/

https://discuss.pixls.us/t/odds-of-subject-distance-similarities-to-a-2-decimal-point-with-a-mix-of-camera-settings/41920/2

I 've nothing to do with that post and don't appreciate these constant personal attacks and spamming.

[JohnConnor01]

I have confirmed what @vincent-wmtm is saying about the issue @JohnConnor01 is observing in darktable by loading the image in question and presenting the result below.

It seems to be a severe misapplication of black levels during import which is causing considerable clipping on @JohnConnor01's image.

See example below of IMG_1839 taken by Jonas De Ro, which exhibits no clipping with default CR2 raw load settings in darktable.

Further, if this image is then saved as jpeg and then imported in Sherloq (even in 0.87C), it does not exhibit this clipping observed by @JohnConnor01.

This seems to be a case of user error and incorrect settings by @JohnConnor01

For the record. Please see that Dark Table is also being cited for clipping in the same areas.

A 2nd app is being cited for clipping in the same areas as Sherloq 0.87

[TJPofTexas]

Are you BobbyO_ from Twitter / X?

[JohnConnor01]

**For the rest of the thread

Can we please keep the conversation 100% focused on the substance at hand.**

Specific changes were made to an open source software tool that impacts the way it works. I’m simply trying to understand the case for:

The clipping on 0.87 was causing the patches/areas to show up on the original photo 1837.

I am showing information and analysis that anyone can replicate. And asking, IF it was the clipping that was causing the issue in 1837. Would we expect to be seeing any issues with the same area in the other photos? Given those are different photos.

[GreatRevealer]

Another user on X seems to have had the exact same issue, with the exact same photos and everyone was able to show him how the problem was not with the images, but with how Sherloq loaded CR2 RAW images.

These posts will probably help you solve your problem also.

https://x.com/BobbyO_/status/1803462039634952408

This user WSAdvisor_ was ALSO having the exact same issues with the exact same images, so this may also help you...

https://x.com/WSAdvisor_/status/1793731789649019342

[JohnConnor01]

Another used on X seems to have had the exact same issue, with the exact same photos and everyone was able to show him how the problem was not with the images, but with how Sherloq loaded CR2 RAW images.

These posts will probably help you solve your problem also.

https://x.com/BobbyO_/status/1803462039634952408

This user WSAdvisor_ was ALSO having the exact same issues with the exact same images, so this may also help you...

https://x.com/WSAdvisor_/status/1793731789649019342

I do appreciate the information but unfortunately that doesn’t address this issue. This is about auto_bright_thr=0 and the new settings on Sherloq. I’ll copy/paste the earlier post. But thank you for sharing. For the rest of the thread. Can we please keep the conversation 100% focused on the substance at hand. Specific changes were made to an open source software tool that impacts the way it works. I’m simply trying to understand the case for:

The clipping on 0.87 was causing the patches/areas to show up on the original photo 1837.

I am showing information and analysis that anyone can replicate. And asking, IF it was the clipping that was causing the issue in 1837. Would we expect to be seeing any issues with the same area in the other photos? Given those are different photos.

[JohnConnor01]

I appreciate any thoughtful analysis of the conversation at hand.

I am noticing alot of comments that aren’t addressing the issues I am raising. For that I may have to moderate the thread.

Hopefully we can stay focused on auto_bright_thr=0 and whether or not it makes sense to have a user option given how significant the changes are. And how little supporting evidence was originally presented.

I would appreciate anyone’s thoughts on the 4 different photos on 0.89 with auto_bright_thr=0.005

[GreatRevealer]

The clipping issue is caused by auto bright.

If you manually turn off auto_bright, the clipping issue will go away completely.

As you increase the threshold clipping ratio, more and more pixels are allowed to be clipped, as observed in your four test photos.

If you import the raw photo through darktable without manipulating black levels and export a jpeg, then import that to Sherloq, you will also see there is no clipping.

It appears the clipping is an error you are introducing in darktable by dramatically changing the black levels.

What made you change these settings in this way? This is a very unusual change to make.

Also, are these images part of some photo competition? I see everyone working on the same photos like maybe it's a school project.

Are you all working together or against each other? Hopefully you're not breaking your teachers rules by cheating to get answers here...

[PeterWem]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results. In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

Canon uses black level 1023, 1023, 1023 and 1023 for that image. Hit reset and read the manual. The darktable developers locked the two threads the user MediaTruth created. This due to harassment from MediaTruth. https://discuss.pixls.us/t/verifying-whether-this-image-has-been-doctored/41894/ https://discuss.pixls.us/t/odds-of-subject-distance-similarities-to-a-2-decimal-point-with-a-mix-of-camera-settings/41920/2

I 've nothing to do with that post and don't appreciate these constant personal attacks and spamming.

So why did you right now upload the picture of the sunset, original posted by the harasser?

[JohnConnor01]

I am getting more and more comments that don’t address the issues.

I analyzed all 4 photos in the same area on Sherloq 0.89. With auto_bright_thr=0.005.

Please address that if you are going to comment. Or other issues raised in this thread. Like auto_bright_thr=0 will NOT prevent RAW photos from being clipped. And we showed numerous examples.

[JohnConnor01]

This issue appears to be a duplicate of #93 and should probably be closed. @JohnConnor01 you can add info over there if needed.

I have not seen any responses in regards to the same areas showing up on a different application? If I missed it could you please link it? One of the first things you would look at in a situation like this is other applications and whether or not they can corroborate the results. In this case. The results from Sherloq 0.87 were corroborated by Dark Table. In the same areas.

Canon uses black level 1023, 1023, 1023 and 1023 for that image. Hit reset and read the manual. The darktable developers locked the two threads the user MediaTruth created. This due to harassment from MediaTruth. https://discuss.pixls.us/t/verifying-whether-this-image-has-been-doctored/41894/ https://discuss.pixls.us/t/odds-of-subject-distance-similarities-to-a-2-decimal-point-with-a-mix-of-camera-settings/41920/2

I 've nothing to do with that post and don't appreciate these constant personal attacks and spamming.

So why did you right now upload the picture of the sunset, original posted by the harasser?

I have no idea what that is but I blocked this user for spamming.

Please address the 4 photo analysis on Sherloq 0.89. Or something about the issue being discussed. Auto_bright_thr=0

[BakersTutz]

There is absolutely no reason why anyone would allow the highlights of an image to clip on purpose, if the intent is to conduct a forensic analysis and to determine potential photo manipulation.

It is recommended to either turn off auto bright completely, or keep it turned on with the threshold set to 0% clipping. You need to retain ALL of the image data if you want a complete and accurate analysis.

[SacredCowBBQ]

Alex Tutubalin, a representative for LiBRaw LLC, the maker of the RawPy library which wrote raw.postprocess(), the function in question, recommends using 'auto_bright_thr' set to 0 to avoid clipping over over-exposed images.

This is exactly the update that has been applied to Sherloq in 0.89d. This is a good change, and one worth keeping.

See their post here: https://www.libraw.org/node/2267

---

Now that that is out of the way!

@JohnConnor01 / BobbyO_, everyone can see right through you and knows what you are doing!

https://x.com/BobbyO_/status/1803462039634952408

These are the exact same images you posted to Twitter!

You keep trying to side step this.

What you are doing is trying to harrass and defame Jonas De Ro by fraudulently and deceptively producing evidence that his images are fake by using an EDUCATIONAL TOOL that is unofficial!

You are blocking EVERYONE and ignoring them when the provide the answer you can wait on Ray9T, MediaTruth, or NaturalML to come agree with you.

[JohnConnor01]

I’ll share the 4 photo analysis again. It is important to emphasize these are 4 different photos taken at different times, angles, different lighting, etc etc.

(Additional clarifying point. I’ve been following this situation online for the last couple weeks. Most forensic results I’ve seen are dismissed because of clipping. Not just patchy areas. But most everything other than blank noise profiles.)

And the explanation is clipping.

Please respond to this specifically or I have to moderate There is too much spam.

[JohnConnor01]

There is absolutely no reason why anyone would allow the highlights of an image to clip on purpose, if the intent is to conduct a forensic analysis and to determine potential photo manipulation.

It is recommended to either turn off auto bright completely, or keep it turned on with the threshold set to 0% clipping. You need to retain ALL of the image data if you want a complete and accurate analysis.

Also numerous examples have been given in this thread showing how many RAW photos will still be clipped with the setting auto_bright_thr =0

[JohnConnor01]

BLOCKING ALL SPAM

This is a serious issue and an original issue was opened on this. The image being presented by the original poster. Is photo 1837. So I looked at the other photos in that file because in this case it would be very relevant given the explanation is clipping. Everything about that would be relevant.

Please only address the corroborated results with DarkTable and/or - and more preferably address the 4 photo analysis

[JohnConnor01]

I do want to highlight some important details.

1.) The original post that cited the issue with Sherloq 0.87 referenced the photo 1837. 2.) The original poster attributed the patches around the Mountain to clipping. 3.) He then advocated for adding auto_bright_thr=0 because after he used that command, the patches on the Mountain go away.

There are other explanations for why the patches go away after adding that setting. And seeing them go away after adding it is not proof that clipping was causing them to begin with.

The original post/author introduced photo 1837 and used it as an example to suggest Sherloq 0.87 was clipping the photos and that specifically was causing patches to show up around the mountain.

So given there are 4 photos with this same area in it. Analyzing the same area in other photos would be a great way to test this thesis.

Everything in my post is relevant to the original post made.

[JohnConnor01]

Please keep all future comments about the issues in this thread. The 4 photo analysis. The explanation that was given in the original photo - clipping. Clipping in general on a photo, where that happens, and how that evolves photo to photo based on numerous variables. And the new setting that significantly changes the way the application operates auto_bright_thr=0. That was originally introduced by the first post/author in part because photo 1837 was showing patches on this area. All 4 photos analyzed on auto_bright_thr=0.005.

Also. Please see post below showing how the setting auto_bright_thr=0 will NOT prevent clipping universally. Even though it’s been implemented as a default setting. It will prevent clipping for the photos shared by (atadams) but it will not prevent clipping universally.

Which makes the case much stronger for a user option because part of the reason it was being implemented was to prevent clipping.

(For additional clarity on the specific issue I am raising. I have been following this story for the last couple weeks online. I have seen most forensic results be attributed to clipping. Not just patchy areas. Most anytning that doesn’t show a blank noise profile has been cited for clipping. That is why I wanted to know if the advocates of the new settings would suggest this is also clipping, or if they think this is how the photo should look.)

1.) There is no correlation between the clipped RGB intensity values in the original post with photo 1837. And the patches shown on the photo.

2.) Expected luminosity patterns that correlate to the patches is non existent. The patches only show up in the Red channel suggesting this is not related to clipping.

[atadams]

I wrote a script to output the pixels clipped by rawpy’s auto_bright. Using the default setting (auto_bright_thr=0.01) on IMG_1837 from my issue 86 post, the white pixels in the image below are clipped from the red channel.

This is the clipped pixels compared to the Bit Plane Value tool.

And the Error Level Analysis tool

Both tools are just showing the clipped pixels.

If we animate the auto_bright_thr setting from 0 to 0.01 in 0.001 steps, the relationship between the clipped pixels and these tools is even more visible.

Bit Plane Value

Error Level Analysis

You will see similar results in Sherloq's other tools, e.g., Signal Separation.

I can't imagine why anyone would want these flawed results unless they were intentionally trying to make images look manipulated. Another risk of having auto_bright_thr as an option is an inexperienced user might turn it on without knowing the ramifications and draw false conclusions about any image they view.

I see no reason for a forensic app to allow clipping an image in this way. My recommendation is to not make auto_bright_thr=0 an option. It will only give a tool to the malicious user to misuse Sherloq or confuse the naive user.

Personal Note

It's obvious that users who are not acting in good faith have been very active on this repo recently. @GuidoBartoli has done a remarkable job with this app. There isn't another open-source tool like it. He does not deserve to have to deal with this type of activity.

I appeal to users not acting in good faith to leave this project alone.

[JohnConnor01]

In reference to the @atadams post.

I created this account to address this issue specifically. My account being relatively new should have no impact on the information and analysis I am presenting. It should be 100% about the substance being discussed.

@atadams brought up this issue originally. He cited clipping in the photo 1837. And he suggested auto_bright_thr=0 would be a good default setting for the entire application.

To reiterate a couple earlier points about the original post. 1.) Showing a Histogram channel comparison before and after auto_bright_thr=0, and showing how the patches go away after the setting is applied. Is not proof that clipping was causing the patches to appear in the first place. I am simply trying to do a further analysis on whether or not the explanation given (clipping) makes sense based on much of the information I have reviewed in this thread. 2.) There are other explanations for why the patches go away after auto_bright_thr=0 as I have highlighted in this post.

I am clearly trying to explore all options. Which is what someone would do who was acting in good faith. And test this thesis of "clipping is causing this to happen". Which is why I referenced results from Dark Table because this was being attributed to a setting in Sherloq (moreso Rawpy) - and corroborated results from a different application would be one of the first things someone would analyze. I also analyzed the same area on all 4 photos that have that area in it.

I would appreciate if all future posts reference the specific information shown in this thread.

[MediaTruth]

Tony,

1. You are yet to prove the clipped areas are corelated to the patches. It's clear how you are avoiding this ask
2. Clipping happens in either highlights or shadows, and one can find the correlation in luminosity. In your image there exists no such correlation. Color is an outcome of light hitting the sensor, for the color intensity to spike, there must be a corresponding luminosity patch.
3. auto_bright_thr=0 is not a tool to recover clipped pixels, it's working on your image for a very different reason as i mentioned few times. By not applying brightness, the settings in the original file are being consumed, which is shifting the values to the left. This is not a universal clipped pixel recovery setting, it's anything but that. It's auto brightness setting that "reacts" to % of clipped pixels. I don't know why you're misrepresenting the definition of this setting.
4. Your argument for "auto_bright_thr=0" can be flipped to say it's enabling fabricated images to hide their alterations. Your sample size is 1 to support your argument. And since this setting works in your favor to mask the patches, you are hurling personal attacks and shutting the door on everyone else. Your case is not even based on random sampling, and proper documentation. It's based on your "statements" . Do you see the problem?
5. Please avoid making personal remarks and comments on intentions, when your logic, reasoning is based on a single set of images and your explanation for this setting is downright flawed.
6. Your observation of changes on a single image does not mean your conclusion is right.

7. See the image below, the with the same "auto_bright_thr=0", there is still good number of pixels clipped.

Conclusion: This setting auto_bright_thr=0 is NOT a universal fix for clipping. Period. It's not even intended to do that.

Link to image Link to image

[JohnConnor01]

Thank you for posting this @MediaTruth.

If the purpose of the setting auto_bright_thr=0 is to eliminate the clipping of pixels with Sherloq 0.89. This setting will clearly not do that as highlighted below. It may do this for the images @atadams presented.

This setting will NOT do that universally. BUT it is being added as a default setting anyway to address this issue. Which makes the case for a user option that much stronger. @GuidoBartoli I am trying to explore all possibilities which is exactly what someone would do who is acting in good faith.

[atadams]

You are yet to prove the clipped areas are corelated to the patches. It's clear how you are avoiding this ask

I think @GuidoBartoli is smart enough to see exactly what is going on.

[MediaTruth]

You are yet to prove the clipped areas are corelated to the patches. It's clear how you are avoiding this ask

I think @GuidoBartoli is smart enough to see exactly what is going on.

Smartness is knowing that sample size =1 is no proof. Knowing Cause and effect may be unrelated is smartness. You clearly misrepresented the definition of auto_bright_thr=(float) and changes based on such erroneous assumptions must be grounds for review. You and your team's persistent personal attacks can wait until you show meaningful proof, agree?

[JohnConnor01]

You are yet to prove the clipped areas are corelated to the patches. It's clear how you are avoiding this ask

I think @GuidoBartoli is smart enough to see exactly what is going on.

I am simply trying to test the thesis: Clipping is causing the patches to appear on the photo in 1837. And I am exploring all possibilities which is what someone would do who is acting in good faith.

There are other explanations for why the patches go away after auto_bright_thr=0, and I have highlighted those in this thread. None of the other explanations have been addressed/explored publicly when discussing this issue from what I can see. 1.) Adding auto_bright_thr=0 and seeing the patches go away. Is not proof that clipping caused the patches to show up in the first place. A thorough analysis would include exploring all possibilities for why the patches show up to begin with. 2.) This setting WILL NOT prevent clipping as highlighted in the earlier post. It will prevent clipping in the specific photo @atadams shared. But it is not a universal solution for clipping. Which makes the case stronger for a user option.

@atadams I would appreciate if all future comments address the information cited in this thread.

[JohnConnor01]

Please see the explanation given by @atadams for why there should be NO user option.

But adding auto_bright_thr=0 is NOT a universal solution for clipping as highlighted in this thread.

So this setting is being advocated for as a way to prevent clipping, but it will only do that for specific photos - like the ones referenced by @atadams.

This is why a user option is important. Other important reasons have also been cited in this thread.

But as shown this will NOT universally prevent clipping.

[JohnConnor01]

To further illustrate how auto_bright_thr=0 is not a big picture solution for clipping. Here are two additional examples of RAW photos being clipped on the new settings. Auto_bright_thr=0 is activated on both photos analysis.

Photo 1: Photo 2: https://www.imaging-resource.com/PRODS/canon-6d-mark-ii/Y_MG_1068.CR2.HTM

Analysis of Photo 1 on Sherloq 0.89 with auto_bright_thr=0

Analysis of Photo 2 on Sherloq 0.89 with auto_bright_thr=0

[JohnConnor01]

Two more examples of a RAW photos being clipped on Sherloq 0.89 with auto_bright_thr=0

All we are asking for is a user option given how heavily auto_bright_thr=0 impacts the analysis process. If the reason this was being implemented was to prevent RAW photos from being clipped - we have illustrated how this command will clearly not prevent clipping. It will prevent clipping for the original image(s) @atadams presented. But it is not a solution that will prevent clipping for other RAW photos.

@atadams would appreciate your feedback on these issues.

Link to image 1: https://www.imaging-resource.com/PRODS/sony-a99-ii/Y_DSC1428.ARW.HTM

Link to image 2: https://www.imaging-resource.com/PRODS/canon-1dx-ii/Y-Sigma24-70A-1DXII-CQ3I7572.CR2.HTM

Clipping on RAW Photo 1

Clipping on RAW Photo 2

[atadams]

Two more examples of a RAW photos being clipped on Sherloq 0.89 with auto_bright_thru=0

All we are asking for is a user option given how heavily auto_bright_thru=0 impacts the analysis process. If the reason this was being implemented was to prevent RAW photos from being clipped - we have illustrated how this command will clearly not prevent clipping. It will prevent clipping for the original image(s) @atadams presented. But it is not a solution that will prevent clipping for other RAW photos.

The camera’s sensor clipped your example images. That is the data the camera captured. Nothing is lost. That situation completely differs from rawpy clipping an image and throwing out existing data.

I can’t see any legitimate reason why a user doing an honest image forensics evaluation would want to lose data when opening a file.

[Ray9T]

Two more examples of a RAW photos being clipped on Sherloq 0.89 with auto_bright_thru=0 All we are asking for is a user option given how heavily auto_bright_thru=0 impacts the analysis process. If the reason this was being implemented was to prevent RAW photos from being clipped - we have illustrated how this command will clearly not prevent clipping. It will prevent clipping for the original image(s) @atadams presented. But it is not a solution that will prevent clipping for other RAW photos.

The camera’s sensor clipped your example images. That is the data the camera captured. Nothing is lost. That situation completely differs from rawpy clipping an image and throwing out existing data.

I can’t see any legitimate reason why a user doing an honest image forensics evaluation would want to lose data when opening a file.

Then focus then should be on getting the full data, and not brightness hacks. Besides, there is NO correlation to patches and clipped data. You must establish that first.

Raw Therapee also shows the same spots on your image

[atadams]

Then focus on getting the full data, and not brightness hacks Tony.

That's what auto_bright_thr=0 does. It makes sure you get the full data and none is thrown out.

[JohnConnor01]

Two more examples of a RAW photos being clipped on Sherloq 0.89 with auto_bright_thru=0 All we are asking for is a user option given how heavily auto_bright_thru=0 impacts the analysis process. If the reason this was being implemented was to prevent RAW photos from being clipped - we have illustrated how this command will clearly not prevent clipping. It will prevent clipping for the original image(s) @atadams presented. But it is not a solution that will prevent clipping for other RAW photos.

The camera’s sensor clipped your example images. That is the data the camera captured. Nothing is lost. That situation completely differs from rawpy clipping an image and throwing out existing data.

I can’t see any legitimate reason why a user doing an honest image forensics evaluation would want to lose data when opening a file.

Legitimate Reasons why a user doing an honest image forensics evaluation would NOT want auto_bright_thr=0 as a default setting with no option for users.

1.) Showing histogram/signal separation results before/after auto_bright_thr=0. And highlighting how the patches go away after auto_bright_thr=0, is NOT proof that clipping caused the patches to appear. There are other explanations which have been highlighted in this thread. 2.) This is also going to default to the settings that were present in the original RAW File. Because in this case, the settings in the original RAW file were the thing that caused the RGB intensity values to shift to the left significantly. If I am trying to critically analyze a RAW file, why would I also want to 100% trust the RAW file? This is another reason why it would be great to have a user option. 3.) There are already MANY other RAW photos being clipped with the new version 0.89 after auto_bright_thr=0 has been added. I acknowledge atadams answer above, but he is advocating for NO user option because of clipping. When tons of RAW photos will still be clipped on 0.89 after the recent changes. 4.) These results were corroborated by at least one other (completely different application) Dark Table 5.) The lack of supporting evidence for the initial issue opened by @atadams. Auto_bright_thr=0 is now a default setting on Sherloq 0.89. So ALL photos analysis will be impacted by these changes. When there was very little supporting evidence for the changes. 6.) Apparently now there is a 3rd application corroborating the results: Raw Therapee. This is significant in that we have TWO different applications corroborating the results.

[atadams]

Raw Therapee also shows the same spots on your image

The fact that you can manipulate the image in another app to highlight the pixels rawpy was clipping is not surprising.

This argument is nonsense.

[Ray9T]

Then focus on getting the full data, and not brightness hacks Tony.

That's what auto_bright_thr=0 does. It makes sure you get the full data and none is thrown out.

It only does that for your image, it's not the intended purpose of the setting. No one should disable critical auto brightness scaler to get full data, that is wrong. For example, raw.raw_image_visible gives you accesses to the full visible RAW image data. Brightness hack only works for your image.

[JohnConnor01]

Raw Therapee also shows the same spots on your image

The fact that you can manipulate the image in another app to highlight the pixels rawpy was clipping is not surprising.

This argument is nonsense.

If you are looking at results of a photo on a forensic application. And you believe those results are in error.

Why wouldn't you check other applications to see if they also corroborated the results? This seems like one of the first things you would do?

[Ray9T]

Raw Therapee also shows the same spots on your image

The fact that you can manipulate the image in another app to highlight the pixels rawpy was clipping is not surprising. This argument is nonsense.

If you are looking at results of a photo on a forensic application. And you believe those results are in error.

Why wouldn't you check other applications to see if they also corroborated the results? This seems like one of the first things you would do?

It's surprising that Tony hasn't established a proof that clipping resulted in patches. But pushed a very specific setting to universally disable brightness to accommodate his image patches from showing up. Nothing sounds right about this. If the intent is to get full data, that should be the ask, and not the setting and it's specific values.

[JohnConnor01]

For the record please see that TWO other applications have corroborated the results.

This has been dismissed as nonsense by the person who opened this issue.

[atadams]

It only does that for your image, it's not the intended purpose of the setting. No one should disable critical auto brightness scaler to get full data, that is wrong.

Auto brightness isn't disabled. auto_bright_thr=0 only assures no clipping (I.e., data loss) takes place when auto brightness is applied.

This issue has over 40 comments. Don't you think it's been discussed enough?