Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: a1ex on February 27, 2018, 03:37:29 PMAs I said, this new version doesn't play well with my camera. I can't get the histogram to display - menu item is on, but grayed out. It works in the 2017Aug07 version, if that's helpful (not sure if you're looking for something new or just how the 1100D display looks in general).
Can you try a few more different screens? In particular, raw histogram has some fine details (the vertical bars). A large console should also help. Also, a large zoom on fine print, please (even if it's just a small part of the screen in the picture).
Quote from: a1ex on February 27, 2018, 06:20:45 AM
Also looking for a high-res photo of the camera display (large enough to see the individual pixels), showing ML menu with any recent build.
If it's hard to get the entire screen in focus, just focus on some problem areas (e.g. some icon or fine print that doesn't look well).
Quote from: Pelican on December 29, 2012, 09:43:49 PMThe % sign in C is the modulus operator. Your code is calculating 0x4860 (18528 decimal) mod 0xff (255 decimal), which is 0xa8 (168 decimal). What you actually want is the low byte of auto_iso_range, which can be retrieved either by changing 0xff to 0x100 in your existing code or simply using the & operator instead of the "%" operator (my preference), i.e. raw2iso(auto_iso_range & 0xff).
I've tried to print the auto iso range with this line:
bmp_printf(fnt, 455, 92, "%d-%d", raw2iso(auto_iso_range >> 8 ) , raw2iso(auto_iso_range % 0xff));
and I've got strange value for the max.
After I check the raw values I found this
if auto_iso_range is 0x4860
then auto_iso_range >>8 is 0x48 (good) but auto_iso_range % 0xff is 0xa8 ! (wrong) which is exactly 0x48 + 0x60
I'm not really a hardcore C programmer so I couldn't figure out what circumstances causes this result.
It happens with other values too (between 0x4858 and 0x4878)
Any idea?
Page created in 0.094 seconds with 14 queries.