Messages

16

Astro Slide - Hardware / Re: Camera - is it IMX586?

« on: January 16, 2021, 07:15:31 am »

Planet announced the camera for Astro a while back to be 48MP from Sony. To me it sounds like the IMX586 model, so once again the true resolution is more like 12MP than 48 MP (https://www.nextpit.com/48-mp-or-not-look-at-sony-new-camera-sensor), but still a nice improvement over the Cosmo. Apparently, the final results can be quite different (and that is from phones that use an additional camera): https://www.notebookcheck.net/Sony-IMX586-Comparison-Review-Five-48-MP-smartphones-face-off-in-a-camera-duel.428434.0.html.

None of the phones in that review uses a MediaTek chipset.  They are as follows:
Asus ZenFone 6: Qualcomm                                                   
Honor View 20: HUAWEI                                                     
OnePlus 7: Qualcomm 
Xiaomi Mi 9: Qualcomm
ZTE Axon 10 Pro: Qualcomm

To see what a 48MP sensor looks like in a MediaTek phone, take a look at GSMArena's photo comparison tool:

https://www.gsmarena.com/piccmp.php3?idType=4&idPhone2=8310&idCamera1=300738&idCamera3=300610

In this link I have selected three phones:
Oppo Reno4 Pro 5G, 48MP (MediaTek chipset)
Motorola Moto Z Play, 16MP (standard sensor, not Quad Bayer or Tetracell)
OnePlus 7(48MP, Qualcomm chipset)

I chose the Oppo Reno4 Pro 5G because I figured it's probably the newest 48MP MediaTek-based phone in the GSM Arena database.

I chose the 2016-era Moto Z Play, with its "smaller" 16MP sensor, as a benchmark.  I also happen to own one because I backed the failed Moto Keyboard mod in 2017.

I randomly chose the OnePlus 7 from the list of phones in the article that sup provided.

In good lighting, the Moto Z Play wins easily in texture detail and resolving power.  Look at the street map: well-defined edges and small but legible text.  Look at the fabric patches: sharp, detailed texture.  It trails the OnePlus 7 in the paper currency detail, however, but that's the exception.

Even in low light (click the "Low light" image), the Moto Z at worst matches the image quality of the Oppo (and smokes the OnePlus).  At best, it looks much more natural (to me) than the Oppo with its interpolated image.  I would have expected the Oppo's 48MP sensor to perform much better than the Moto Z Play's in low light, but this is apparently not the case.  The Moto Z Play also easily beat the ZenFone 6 (false color artifacts and noise), the Honor View 20 (smeared away all detail), and the Xiaomi Mi 9 (smeared away all detail).  The ZTE Axon 10 Pro is not available in the comparison tool.

My point of this demonstration is two-fold.  First, according to the marketing, the 48MP sensors should be blowing away the 16MP in detail resolution and texture reproduction, especially in low light, but in almost all cases they fall behind, often way behind.  Second, the Oppo (MediaTek) images looks pretty bad in my opinion, with lots of jagged edges and halos due to interpolation and oversharpening.  And that's an improvement over the first Oppo 48MP model I picked, the Oppo F11 Pro.  Compare the route colors on the map with the Moto Z Play or the OnePlus 7.  They're all wrong, just plain wrong!  They look like the burnt colors from the Cosmo under the MediaTek stack.  So there's a smidgen of hope that the Astro's color reproduction will be improved over the Cosmo's using MediaTek-based image capture, but don't expect much of anything for sharpness and texture.  And above all, don't fall for the marketing hype.

17

Astro Slide - Hardware / Re: Camera - is it IMX586?

« on: January 16, 2021, 06:13:28 am »

I took the liberty of transcribing Planet's answer to a backer's question about the Astro's expected camera quality.  This is from Indiegogo's Astro Slide update #20, January 15, 2021:

"The second video addresses the questions that we were asked by you, our backers, this week."

https://youtu.be/SgQ8NTituUA 8:02-9:24

CHRIS BIGNELL - XL COMMUNICATIONS: "Entienne asks about the camera quality in terms of uh, you know, the, within the Cosmo, the MediaTek stack did not give um, did not support the full capabilities of the sensor, uh, that I know is something that has been improved over time, uh, is there likely to be, uh is that likely to be a problem with Astro Slide, or is that something that we think we've resolved?"

DR JANKO MRSIC-FLOGEL - CEO, PLANET: "So we think there'll be a huge improvement in the camera, uh, one because uh, the uh, the sensor is a Sony sensor, it's a high quality, you know, Tier 1 sensor, and uh, uh, the pre-- it's 48 megapixel and high quality with uh, um, standard oriented, so basically uh uh um uh, a square-type orientation, um, um, a square-type organization of the CMOS, whereas the uh, CMOS sensor, whereas the, uh, the previous sensor was a 24, uh, megapixel sensor from Samsung which has a hexagonal organization of CMOS, so basically it's, it's far be-- the n-- the new sensor not just that it has a larger resolution but it's uh, uh, the-- the organization of pre-- the CMOS sensor is actually better so you'll get a, a far superior performance."

CHRIS BIGNELL: "Good to hear, thank you, and I'd also like to thank Felagund and Colin W., two other backers that asked the same question around the camera."

God bless them for trying and I wish them the best, but wow... Planet has absolutely zero understanding of the Cosmo camera issue. The backer understood.  He obviously read our Cosmo camera forum posts.  Planet did not!  The issue lies entirely with the MediaTek software stack!  It's not a question of needing higher resolution.  It's not a question of "CMOS hexagonal organization" versus "CMOS square organization" (whatever that means).  The sensor itself, as we have proven, takes sharp, detailed, beautiful photos with the right software: Google Camera ported to the Cosmo (https://www.oesf.org/forum/index.php?topic=35912.msg297145#msg297145) which completely bypasses the MediaTek imaging stack for photos.

Regarding hexagonal or square pixel arrays, Planet's explanation truly left me scratching my head.  Samsung's Tetracell and Sony's Quad Bayer are both Bayer filter mosaics in a square pixel array, albeit with multiple adjacent pixels for each color.  But the colors are still staggered.  Neither is a hexagonal pixel array, which is very uncommon, and if the Cosmo's Samsung sensor were, it would actually be a computational improvement (but not an image improvement).  And neither has any bearing on MediaTek's inability to properly process raw image data.

It's also amazing how the Cosmo camera issue magically "has been improved over time."  Wonder how that happened.

I think GCam would produce fantastic photos with a 48MP Quad Bayer sensor.  But for the record, I am not backing the Astro.

18

Cosmo Communicator - General Discussion / Re: Camera

« on: January 04, 2021, 01:41:44 am »

The "camera sounds" setting that existed in v3 is no longer available in v4.
I will wish the "camera sounds" setting was still there.

Odd.  I see the sounds settings on mine (same v4 that I released), and if the ringer is enabled, I hear a shutter sound.

Does anyone else have the issue spa is seeing?

19

Cosmo Communicator - General Discussion / Re: Camera

« on: December 31, 2020, 08:50:37 pm »

Merry Christmas and Happy New Year!  GCam for the Cosmo v4 is here!

Download v4 here:
https://www.dropbox.com/s/oj7p3a0qbauylbl/gcam_for_cosmo_v4.apk?dl=1

New for v4, which has been ported fresh from scratch using stock Google Camera 7.2.018:
1. The option to disable HDR+ now works.  Note that this saves interpolated 24MP photos.  The stream from the sensor in this mode is YUV_420_888, not RAW, and RAW file saving is disabled in this case.  There is no difference in detail between Samsung's marketing-driven interpolated 24MP photos and 6MP photos taken in "HDR+ on" mode.  Don't blame me, the YUV stream is 24MP and GCam is just saving it as such.  I didn't see a convenient way in the code to resize it but I might look at this again in the future.
2. Video stabilization has been added.  This is electronic, not optical, so there is a crop (in addition to the crop already incurred by video mode).
3. Night Sight now works, though it is only marginally better than Enhanced HDR+ in low light due to excessive noise.
4. Viewfinder resolution has increased from 640x480 to 1920x1080 (but is neither faster nor slower than before).  More scene detail is visible in the preview now.
5. Slow Motion has been removed.  It will never work on the Cosmo, which can only output 30 FPS maximum.  Slow motion requires 60+ FPS.
6. Panorama has been fixed.  It uses MTK video libraries with smearing and washed-out colors, so don't expect too much from it.
7. Microvideo now works (Motion).  The files are saved as MVIMG_YYYYMMDD_HHMMSS.jpg, but they contain an MP4 video concatenated onto the end of the JPEG data.  Tap "ALL PHOTOS" in the photo viewer to switch to Google Photos where the microvideo will play.  There is a bug that garbles the timeline color on the Cosmo on microvideo files captured in "HDR+ on" mode (but not in "HDR+ off" mode for some reason).  However, the microvideo plays correctly, and on non-Cosmo devices, the timeline displays properly in Google Photos.  To extract the microvideo from the image in Google Photos, scroll down a bit, tap Export, Export as Video, Export.
8. Removed Time Lapse since after extensive debugging it does not appear likely to work on the Cosmo.
9. The tap-to-focus bug in Enhanced HDR+ mode is actually an overexposure issue with the Cosmo sensor.  Tapping to focus changed the exposure, but the sensor was tuned for the Pixel's sensor, not the Cosmo's, and the code invalidated the shot due to perceived overexposure.  This bug still exists as it's very hard to isolate, but I have greatly improved the success rate for enhanced HDR+ shots.  Previously many would fail before even tapping to focus.  This is now fixed with some tweaks to the rear sensor exposure.  This should alleviate the temptation to tap to focus after a shot failure, which enters the buggy state.  Keep in mind that enhanced HDR+ is best in dimmer lighting.  Aim it at the sun and you'll get a white picture.
10. Lens Blur has been added.  This takes a 2560x1920 photo and allows you to change the focus point and the amount of background blur.

I want to thank san1ty, the developer of F1MinimalMod, for creating his GCam mod.  Although v4 is an entirely new port and no longer based on F1MinimalMod, we wouldn't even have GCam for the Cosmo if I hadn't discovered that his port somewhat worked on the Cosmo.  His work was also instrumental in helping me get past three problems in my new v4 mod.

20

Cosmo Communicator - General Discussion / Re: Camera

« on: December 02, 2020, 08:18:38 pm »

Thank you Shuntcap. By the way, and I of courrse have zeo expectations, have you ordered Astro? I am afraid it would need something similar because I have vey low expectations from Planet Computers when it comes to photography.

No, I have not backed the Astro and I do not plan to.  I did back the Pro1 X, though.  As a programmer, I prefer a keyboard with a lot more keys than what Planet offers, even if I won't be able to touch type on it.  I also prefer an organization that is more transparent with its backers.  Plus, the camera in the  Pro1 X is a known entity, the IMX363, the same camera sensor used in the Pixel 3, 4, and 5.

You may be right about the Astro's camera.  Given how bad the Gemini's rear camera was, and how badly MTK butchered the Cosmo's rear camera, and given that Astro's front camera is likely still the same low quality 5MP camera that the Gemini and Cosmo have (based on Astro's specs), we backers and consumers have every reason to anticipate the worst for the Astro's camera.  It's simply Planet's track record.  If they can break that, great.

21

Cosmo Communicator - General Discussion / Re: Camera

« on: December 02, 2020, 12:22:16 am »

It's now been over a month since my last release.  I haven't been able to fix the HDR+ capture issue (capture may fail without a tap-to-focus), nor have I been able to fix the slow still image preview frame rate.  This will probably be my last release.  I'm getting tired of working on GCam (or just getting old and tired from working on GCam...)

Download Version 3 of GCam for the Cosmo here:
https://www.dropbox.com/s/t36cufk1se59uri/gcam_for_cosmo_v3.apk?dl=1

Version 3 just has two small fixes:
1. Tap-to-focus animator circle now appears where tapped instead of being rotated 90 degrees CCW.
2. Minor increase in captured image sizes (RAW is now 2816x2108 from 2800x2092, JPEG is now 2832x2124 from 2816x2108).  I don't know why the RAW is slightly smaller than the JPEG, but I am capturing at the sensor's reported active array size of 2832x2128.

Sorry to disappoint.

For those interested in the underlying details, I have spent countless hours debugging this thing, and I actually did speed up the preview considerably by changing the sensor output stream format from RAW to YUV_420_888, but that resulted in GCam being unable to capture images.  It really needs a RAW stream, which is just too much data for the Cosmo hardware to send at a high rate.  I ported an older version of GCam (6.1 for the Pixel 3) which had a high preview frame rate and verified that it was indeed using a YUV stream, but the images it saves are noticeably inferior to the current version and are closer to those produced by the stock camera app.  It also fails to save RAW images.  Regarding HDR+ capture failure, I traced that down to an odd state in the autofocus system that, as far as I can tell from the Camera2 API documentation, should not happen.  This odd state is entered when the user taps the screen to lock focus while in HDR+ mode, then quickly moves or pans the scene which triggers a reset of the autofocus mode (from AUTO to CONTINUOUS_PICTURE), but the focus state does not reset to passive scan/lock.  I don't see this behavior in OpenCamera, the stock camera app, or in the older version of GCam I ported, but none of those produces images as crisp and chromatically accurate as the current version.  The workaround is to either restart GCam or simply tap to focus again.  If the screen has never been tapped to focus, HDR+ appears to work without issue.

22

Cosmo Communicator - General Discussion / Re: Camera

« on: October 29, 2020, 07:07:24 pm »

It's just the visual feedback of that tap that gets drawn in a rotated fashion...

I will poke around to see if I can fix it, along with the other list of issues.

... and it's fixed!  I wish all the fixes were that fast.  Unless anyone is in a hurry, I'll just wait until I have some other fixes (working on HDR+ issue) before releasing.

23

Cosmo Communicator - General Discussion / Re: Camera

« on: October 29, 2020, 06:51:40 pm »

It's just the visual feedback of that tap that gets drawn in a rotated fashion...

Ah, now I understand.  Being the extreme minimalist that I am, I had disabled all animations in the developer options menu, so I never even saw any circular tap animation.  This might be the first time that I actually see a use for "eye candy" in a GUI.  Of course, it needs to be rendered properly to be useful.  I will poke around to see if I can fix it, along with the other list of issues.

24

Cosmo Communicator - General Discussion / Re: Camera

« on: October 28, 2020, 12:59:30 pm »

In my experience, touch focus behaves the same way in both v1 and v2 of GCam for the Cosmo. If I tap the screen at "12 o'clock", the screen shows the tap at "9 o'clock". If I tap at "3 o'clock, the screen shows the tap at "12 o'clock" and so on. The touch focus point ends up the correct distance from the center of the viewfinder, but rotated 90 degrees counter-clockwise. To me, it seems GCam thinks it's in portrait mode and somehow gets confused. The way Gcam draws the GUI seems to support this theory. With either of the grid options activated, and knowing I have to tap the desired distance from the center, but 90 degrees clockwise ahead of where I actually want to focus, I have been able to sort of work around this issue (but, if possible, please fix it). Tapping the viewfinder dead center works correctly, as that's the same spot, regardless of rotation.

Are you saying that even in the options grid, you have to manually "rotate" your finger position 90 degrees CCW to register the correct tap location?

As for the viewfinder, I don't find that the tap-to-focus is rotated.  In fact, I added a debug print and GCam does indeed believe it's in landscape mode.  I set up a test scene with objects at various distances and in different viewfinder quadrants, and each tap focuses correctly.  Furthermore, the padlock icon on the EV slider bar is oriented correctly for landscape layout.  If I force-rotate the Cosmo into portrait, the padlock then orients correctly for portrait layout.  Tap-to-focus also works correctly in portrait.

The EV slider actually works correctly according to the brightness icon, which is black on the right half and white on the left half.  So according to the icon, sliding left should brighten the image, while sliding right should darken it, which is exactly what it does.  I originally thought the slider wasn't even working, but that was because I was already in a dark environment and GCam had automatically adjusted the brightness to its maximum.

My Cosmo build number, if it matters, is v23 (Cosmo-9.0-Planet-07062020-V23).

Is anyone else experiencing rotated taps?

25

Cosmo Communicator - General Discussion / Re: Camera

« on: October 26, 2020, 12:31:31 am »

Thanks for the feedback, Daniel W and sup.  I have the same issue with HDR+ not saving unless first tapped to focus.  And nice analysis of the portrait rotation, Daniel W.  These issues should be fairly trivial to fix once I find where they are, but that's the time-consuming part, finding things in over 600,000 lines of decompiled, undocumented code.

26

Cosmo Communicator - General Discussion / Re: Camera

« on: October 17, 2020, 11:34:43 pm »

Not sure if it is just me, but the touch to focus is now working. except when I touch a point on the screen, it focuses on a different point...

I noticed that today, too.  I also noticed that I can't change the EV level (level indicator changes but the exposure doesn't).  I'll check into both issues.  I'm also investigating why the preview framerate is so slow.  I ported another (older) version of GCam with fewer features but that framerate is fine, so I should be able to fix it in time.

27

Cosmo Communicator - General Discussion / Re: Camera

« on: October 15, 2020, 08:06:19 pm »

Hello everyone,

I've created another update to GCam for the Cosmo.  Please download v2 here:
https://www.dropbox.com/s/9fwf3qkau1a3f8l/gcam_for_cosmo_v2.apk?dl=1

New v2 fixes and features:
1. Front-facing camera now takes photos instead of crashing.
2. Video now works. Supported resolutions are 1920x1080 and 1280x720, selectable in the settings menu under "Ultra-high resolution video (1080p)" (so named because it was meant for 4K, which the Cosmo cannot do).  Be forewarned: the video quality is merely the same as that of the stock camera app.  Video is recorded through MTK's software stack.
3. Space bar can now operate the shutter button.  In the settings menu under Gestures, select "Shutter" for the volume key action.  This will allow both the space bar and volume keys to operate the shutter.  The buttons on back of the LCD (on the fingerprint reader) also work, as they are actually mapped to volume keys.  You can also use the space bar to start and stop video recording, but note that you will hear the space bar click in your video.
4. Added an HDR OFF button to the pop-up options to disable HDR, but I'm not yet convinced that it actually disables it.
5. Removed the HEVC option which doesn't work on the Cosmo due to MTK library limitations.

28

Cosmo Communicator - General Discussion / Re: Camera

« on: September 18, 2020, 01:07:08 am »

Is there some way to turn off the HDR in the GCam build?

It seems I can have HDR or HDR+, but not completely off.

Judging from the disassembled code, no.  It's built into the image processing flow and didn't look to be optional.  If you truly need to bypass the HDR, try shooting in RAW and post-processing.  I agree, the HDR goes overboard sometimes and I'd prefer to be able to disable it.  I got more accurate results (matching real life) by shooting RAW and boosting the shadows.  I'll check the code again when I resume working on the other issues.  Maybe I overlooked something.

29

Cosmo Communicator - General Discussion / Re: Camera

« on: September 16, 2020, 01:36:54 am »

I think I found another thing that is broken in your mod, the front/internal camera crashes the app when trying to take a picture.

Right you are!  I will see about fixing that when I return from vacation at the end of the month.

30

Cosmo Communicator - General Discussion / Re: Camera

« on: September 16, 2020, 01:33:43 am »

“A suggestion for the take photo with enter or spacebar. There's already one for volume control, so im guessing he could tweak that one.

taking photos by tapping on the screen tends to shake the phone. prob due to the weight distrobution or something”

I like this idea and will look into adding it.  After all, that is why we backed or purchased the Cosmo, so we could use a real keyboard instead of relying on the touch screen.