Post by: vader on November 23, 2019, 06:55:33 am
I installed OpenCamera, which allows you to tweak a few settings and tried to push the limits. I took some night photos of stars and was surprised. These are hand held, no editing of any sort. I haven"t taken any daytime ones (that I can share) yet. the built in camera isn"t bad, but OpenCamera allows you to use API2, and a host of extra features. I am sure I could get better shots if I steadied the cosmo, but it is an example of what you can do.
Uploaded in full quality so you can have a look.
Post by: NormMonkey on November 23, 2019, 09:48:48 am
Quote from: vader
I installed OpenCamera, which allows you to tweak a few settings and tried to push the limits. I took some night photos of stars and was surprised. These are hand held, no editing of any sort. I haven"t taken any daytime ones (that I can share) yet. the built in camera isn"t bad, but OpenCamera allows you to use API2, and a host of extra features. I am sure I could get better shots if I steadied the cosmo, but it is an example of what you can do.
Did you have any luck saving RAW photos? I tried but it pops up "Failed to save RAW" and the DNG files are 0B.
Post by: vader on November 23, 2019, 05:01:34 pm
Quote from: NormMonkey
Did you have any luck saving RAW photos? I tried but it pops up "Failed to save RAW" and the DNG files are 0B.
Same here - no go with raw. The best you can do is save 100% jpg or png from the jpg.
Post by: Daniel W on November 23, 2019, 05:27:14 pm
Quote from: vader
I am sure I could get better shots if I steadied the cosmo, but it is an example of what you can do. Uploaded in full quality so you can have a look.Thank you. At ISO 6400, appearing to be the max supported, I'd say these are not too noisy for a mid-range phone camera. For a 0.4s no-OIS handheld exposure at night, this is about as good as I think one could realistically expect, especially at a resolution as high as 5632x4224 pixels, which, lacking other telephoto means, should leave a healthy cropping margin. While this is by no means any conclusive camera test, it makes me a bit more confident that the Cosmo will be able to become my only everyday camera.
Post by: fluffypony on December 10, 2019, 05:34:40 am
Full size iPhone shot is here (https://i.imgur.com/ZlVmFQO.jpg), and the full size Cosmo shot is here (https://i.imgur.com/8iM8QN0.jpg), and I've attached them as well. To give you a better idea of the clarity difference, here is a close-up of the same area on the iPhone and Cosmo shots:
iPhone
Cosmo
Post by: Daniel W on December 10, 2019, 08:18:10 am
Quote from: fluffypony
The camera is passable, but it is quite mediocre compared to high-end smartphone cameras.Thank you. This is very useful. It's kind of interesting how certain diagonals in the Cosmo photo gets a pronounced two-pixel stair-step effect. I've blown up a small fragment to 1000% percent here:
It's almost as if the Cosmo is shooting at half resolution and then stretches the image, which, roughly, might be akin to what's going on here...
Each photosite (sensing element) in a camera sensor usually sits behind a red, green OR blue filter in a 2x2 (Bayer) pattern (with two green, as human eyes are more green-sensitive). The raw image gets full spatial (detail) resolution, but about half the color resolution, so the camera demosaics it, by cleverly sharing color between neighboring pixels. Done right, it can preserve almost all the detail while just smearing the color a tad (and human eyes has much lower color resolution anyway, which is why JPEG often saves color at half resolution). Less clever (but fast) is to just clump pixels together 2x2, which might work with, say, a 60Mpixel "raw" resolution, giving 15Mpixel final images (such a camera could do a "2x zoom" by "properly" demosaicing 15Mpixel from the center of the sensor), but starting with 24Mpixel, that gives 6Mpixel final images, unless stretched back to 24Mpixel...
While the Cosmo might do something a tad more sophisticated, I scaled down the full image to 50% in Windows MS-Paint, because it's primitive scaling just throws away half the pixels, both ways, and got (to me) NO visible loss of detail, which, to me, suggests the 24Mpixel image only had 6Mpixes worth of details. To me, this suggests the Cosmo could, technically, create more detailed images, with better software, but as long as the firmware won't let us save raw images, basically straight from the sensor, we might be stuck with this demosaicing, especially if it's done in hardware. When the dust settles a bit, I think we should urge Planet Computers to, if at all possible, support saving raw images. If not possible, it might be better to, if that's supported (is it?), shoot 6Mpixel images, which, usually, is enough, saves a bit of storage and makes on-device editing more feasible.
Post by: fluffypony on December 10, 2019, 09:00:48 am
Post by: maki.jouni on December 10, 2019, 09:44:14 am
Post by: NormMonkey on December 10, 2019, 02:41:35 pm
Quote from: fluffypony
The camera is passable, but it is quite mediocre compared to high-end smartphone cameras. I ran a quick comparison between it and my iPhone 11 Pro Max, and the difference is quite striking. Despite the Cosmo having double the resolution of the iPhone, the iPhone pics are brighter and a LOT crisper.Thanks @fluffypony! I hope more people will share their photos here as you and @vader have, to help get an idea of what this thing can do. I'm inspired to share now.
When you took those, was it with the built-in Camera app or did you use something else like OpenCamera? My impression is that the built-in Camera app is using a pretty harsh compression.
I wanted to add that iPhone and Samsung and other high-enders do a fair bit of un-commanded post-processing on their pictures, boosting the contrast, popping the colors, etc. The manufactures have (probably rightly) assumed that people don't want to spend their time tweaking on their own and would rather have their camera do these things by default.
That said, there is clearly more detail in the iPhone pic. I'm just unsure if that's on the camera or the default Camera app.
I'll take a couple of pics and post shortly.
Post by: NormMonkey on December 10, 2019, 03:25:46 pm
Built-in Camera app (6.32MB):
OpenCamera (6.12MB):
I take back my earlier impression about the built-in app. While it doesn't have much in the way of functionality, it doesn't seem any worse than OpenCamera at 100% JPEG.
Post by: shuntcap on December 10, 2019, 04:06:42 pm
Quote from: Daniel W
It's almost as if the Cosmo is shooting at half resolution and then stretches the image, which, roughly, might be akin to what's going on here..It's called interpolation, which is merely digitally scaling an image to a larger size without adding real detail. It's also a game shady manufacturers play to make their camera specs sound better. Trail cameras (for hunting) are notorious for this. I bought a Moultrie "14MP" trail camera which is actually just 2MP scaled up.
Most cell phone camera sensors are 1/2.3" in size (although the Gemini's rear camera sensor is even smaller). If you look at real point-and-shoot cameras, you won't find a single 1/2.3" sensor in 24MP. They max out at 20MP. Even more advanced cameras with 1" and 4/3" image sensors still only go up to 20MP. It isn't until you get to the much larger APS-C sensor size that you'll find 24MP of resolution. In general, the larger the sensor, the more detail and less noise you have in an image.
It's quite possible that Planet's suppliers pulled yet another fast one. "Sure, it's 24MP, really! Honest!" Given the Gemini's joke of a camera, I'd say it's safe to assume that Planet knows very, very little about cameras.
I was half expecting this, which is why my Cosmo still sits unopened in a drawer. I won't know what camera sensor is used until I get my hands on the kernel source... if I don't just sell the Cosmo first.
Post by: vader on December 10, 2019, 08:39:11 pm
Even on default settings, the photos are quite usable, and infinitely better than the gemini.
Post by: ianisthewalrus on December 10, 2019, 11:02:59 pm
Post by: shinkamui on December 11, 2019, 12:16:42 am
Post by: shuntcap on December 11, 2019, 01:47:52 am
Quote from: shinkamui
Personally, the benefit imo for using OpenCamera is mainly for the rudimentary EIS. The Noise reduction and HDR modes in API2 also tend to produce better looking photos to my eye, but where you see a day and night difference is in video. We really need a working GCam port TBH. OpenCamera has some great options, but I'd trade it all in for google image processing.The potential problem here is that the Cosmo might have gotten stuck with a 6-ish MP sensor, not a 24MP sensor. All the image processing in the world will not add detail to an image if the detail wasn't captured by the sensor in the first place. Sure, it is just fine for social media posts, but we were promised a "fantastic 24MP camera" (Planet's own adjective and resolution specification from the Cosmo's Indiegogo story page). It doesn't matter too much to me at this point because, after the Gemini camera disaster, I started carrying a real camera again like I did before smartphones! But it could spell the difference between my selling or keeping the Cosmo. I simply don't need another PDA with decade-old (or worse) camera technology.
Thanks for those pictures, fluffypony and NormMonkey, and I hope Daniel W's and vader's optimism wins.
Post by: shuntcap on December 11, 2019, 02:32:18 am
Quote from: NormMonkey
Took a couple of pics to compare the built-in Camera app to OpenCamera:According to the EXIF data embedded in the photos, they both came from "Camera Software: MediaTek Camera Application"
This is probably because it's MediaTek's JPEG codec that ultimately creates the image file regardless of what capture app is used. MediaTek's camera kernel drivers are fairly simple and limited in flexibility: set up some parameters, tell the sensor to capture, and the data is shot over to the proprietary JPEG engine. Out pops a file and that's all we get.
Post by: NormMonkey on December 11, 2019, 01:20:45 pm
Quote from: shuntcap
This is probably because it's MediaTek's JPEG codec that ultimately creates the image file regardless of what capture app is used. MediaTek's camera kernel drivers are fairly simple and limited in flexibility: set up some parameters, tell the sensor to capture, and the data is shot over to the proprietary JPEG engine. Out pops a file and that's all we get.
That may well explain why these two photos both seem to have similar compression artifacts even though I told OpenCamera to do 100% JPEG quality. Then the best OpenCamera can do is to not make worse what MediaTek's JPEG engine spits out. I would expect a true 100% quality JPEG to be larger than 6-7MB for a 24MP photo.
That would also explain why RAW doesn't work.
I really hope this is something that PC can work out in software. e.g. maybe MediaTek's driver has a RAW option that is currently disabled. If so, we might yet get good performance from this thing. If not, we may have here a good camera with a spudmaker bolted to its tail so that it only ever produces potato quality pics.
Post by: shuntcap on December 11, 2019, 05:57:47 pm
Quote from: NormMonkey
That may well explain why these two photos both seem to have similar compression artifacts even though I told OpenCamera to do 100% JPEG quality. Then the best OpenCamera can do is to not make worse what MediaTek's JPEG engine spits out. I would expect a true 100% quality JPEG to be larger than 6-7MB for a 24MP photo.Possibly, but I would expect the MediaTek JPEG codec to respect the Camera2 API option for JPEG compression level. It's more likely that the artifacts are due to software interpolation of a (much!) lower resolution image.
Quote
That would also explain why RAW doesn't work.The CMOS sensor does output RAW data over the MIPI bus, but how that gets handled is up to the OEM (MediaTek). MediaTek (and other hardware vendors) supplies a board support package and board reference design to its customers. It's very unlikely that Planet has the resources to write additional kernel drivers, so they're more likely to use whatever code MediaTek has already written. That limits their selection of an image sensor. I had originally assumed that Planet would choose the OV23850 sensor for their board design because that sensor is already in the MediaTek kernel (3.18 for the Gemini). That is a 23.8 MP 1/2.3" image sensor. Interestingly, it does have a 6MP resolution setting, the apparent resolution Daniel W calculated. In a very far-fetched scenario, the proprietary libraries could be incorrectly coded to work at only 6MP, but I highly doubt it. I've emailed Planet support asking what sensor is used. If they don't answer or don't know (they had to ask their ODM with the Gemini), I'll have to wait until they release the Cosmo kernel source code to know for certain what sensor is employed. I did not see any RAW option in the OV23850 kernel driver. It wouldn't be in there anyway, not in MediaTek's camera software model at least.
I really hope this is something that PC can work out in software. e.g. maybe MediaTek's driver has a RAW option that is currently disabled. If so, we might yet get good performance from this thing. If not, we may have here a good camera with a spudmaker bolted to its tail so that it only ever produces potato quality pics.
When I offered to assist Planet in tweaking their SP5509 image sensor code for the Gemini's rear camera, they essentially and politely said, "Thanks, but no thanks." Worse, they really didn't know anything about the sensor except that it was performing to QA specifications. They did very kindly try to get documentation for me but couldn't obtain any. I even tried to contact the vendor, SuperPix, but got no response. So Planet probably doesn't have much control over the behavior of the camera.
Post by: NormMonkey on December 12, 2019, 02:27:27 pm
I'll have to play with what termux-camera can do with it.
Has anyone had any interesting experience with camera apps other than the built-in Camera app and OpenCamera?
Post by: drpeter on December 12, 2019, 02:46:12 pm
Quote from: NormMonkey
FWIW, termux-camera-info suggests a max size of 4208x3120 for the rear camera. It does suggest it has "raw" capabilities.Is there any way simply to get a report of the sensor used? Other than asking Planet, which might prove unhelpful?
I'll have to play with what termux-camera can do with it.
Has anyone had any interesting experience with camera apps other than the built-in Camera app and OpenCamera?
Quoting a 24MP camera which is in fact simply an upscaled 6MP or 12MP sensor seems a bit like smoke & mirrors. Although, I sincerely doubt there is true 24MP resolution to be found in any sensor of this size. In which case, capping the resolution of output images to the true effective resolution of the camera system would be the sensible approach, unless they can be output in RAW for bespoke post-processing.
In the end however, if you're looking for that kind of quality you'd only be using a 'phone camera in extremis, when no more capable camera was available...
Post by: Daniel W on December 12, 2019, 05:39:32 pm
What if... it is, actually, worse? What if the default behavior of the "MediaTek Camera Application", which appears in the EXIF for Gemini rear camera photos too, for whatever silly reason, is to demosaic by clumping photosites together 2x2 and then interpolate back up to the advertised resolution? It would be CPU-friendly for sure, so it would reasonably be decently fast even on really low end hardware. It could perhaps be a factory fallback default, that the device maker is supposed to change.
That would give 24MP Cosmo photos 6MP worth of details, stretched back to 24MP and Gemini photos 1.25MP (1280x960) worth of details, stretched back to 5MP. It would be really bonkers, but it does kind of match the amount of detail that seems to come out of the Gemini rear camera.
In [a href=\'index.php?showtopic=35308\']this post[/a], I posted a photo of a page of text, from Gemini rear camera. I repeated my experiment with that picture today, reducing it to 50%, both ways, which, thanks to the crude code in Windows MS-paint, throws away half the pixels, both ways. Then I zoomed it to 200%, and - again - apparently NO detail was lost... The reduced and zoomed in picture was, to me, exactly as readable as the 5MP image. If anything, the processed image felt less objectionable, as it was fairly sharp and detailed, for a 1.25MP image, that is, while the 5MP image feels a tad out of focus.
Here's a composite example: (please click to see all the pixels)
Never mind the language (it's a fragment of an article about a local toy store). The left half is a completely unprocessed crop from the Gemini rear camera, warts and all. The right half, has been shrunk down, by throwing away every other pixel, both ways, and then scaled back by doubling the remaining pixels both ways. I saved it as a PNG, so I've added no other artifacts. No, they're not identical. The technically inclined can subtract one half of the image from the other and the result won't be completely black, but with the naked eye, can you spot ANY difference in the amount of detail?
I'm getting that sinking feeling in my stomach, that I might, regretfully, be on to something here... They shouldn't be THAT similar, lest the left half was created by stretching something that was half the resolution to begin with... On the other hand, maybe this suggests the SP5509 isn't QUITE as bad as we all think. Maybe it's just really craptastic image processing, that turns it into a glorified 1.25MP camera. Maybe, in theory, it would somehow be possible to get somewhat better pictures out of the SP5509 and, by extension, out of whatever module the Cosmo is using?
Post by: Daniel W on December 12, 2019, 05:58:16 pm
Quote from: drpeter
I sincerely doubt there is true 24MP resolution to be found in any sensor of this size.As far as the sensors are concerned, they do exist. The OmniVision OV23850, mentioned above by shuntcap is "smartphone-sized" ~1/2.3" (the way sensors are measured is a weird story in itself, but that's for another day) and has 23.8MP for real. [Source: https://www.ovt.com/sensors/OV23850 (https://www.ovt.com/sensors/OV23850)]. The Sony IMX576 is of similar size and has 24.8MP. The Samsung S5KGM2 even squeezes 48MP onto a 1/2.25" sensor, though, as it uses a so called Quad Bayer filter array, it's really meant to produce (really nice) 12MP final images, but it still has 48000000 photosites on a sensor that comfortably fits inside a phone. Whether the optics in a smartphone could resolve that much detail, is another question. My grasp on the diffraction limit for such systems is a bit fuzzy (pun intended), and is perhaps a bit off topic anyway, but 24MP should be possible to resolve, I think.
Post by: shuntcap on December 12, 2019, 07:39:51 pm
Quote from: Daniel W
24MP should be possible to resolve, I think.Yes, but it would be extremely noisy leading to a very high degree of noise reduction. A lot of texture detail (grass, clothing, hair) would be smeared by the noise reduction resulting in sharp contrast edges but oil painting-like textures elsewhere. It's usually better to go with a smaller sensor as the larger pixels take in more light and produce less noise.
On that note, here is the reply I received from Planet:
"The chipset on the Cosmo (Mediatek P70) is compatible with a single Samsung-made 20MP sensor. I couldn't, however, find any details about the part itself. It might be more relevant if you have a look at https://www.mediatek.com/products/smartphon...iatek-helio-p70 (https://www.mediatek.com/products/smartphones/mediatek-helio-p70), as our support team does not directly get involved with the supply chain."
At least it's a Samsung, not a sensor from SuperPix like the Gemini's. Here is Samsung's selection of mobile image sensors (under Product Selector):
https://www.samsung.com/semiconductor/image...e-image-sensor/ (https://www.samsung.com/semiconductor/image-sensor/mobile-image-sensor/)
There are three sensors in 20MP resolution. There are also two 24MP sensors. Until we get the Cosmo's kernel source, we won't know which one is used. A quick look at the Gemini's kernel source indicates that the MT6797 (the Gemini's processor) supports a handful of Samsung sensors.
Assuming that "20MP" is not a typo, our hunch that the images are being interpolated could be correct. But interpolated from what resolution? Certainly not 20MP! It's more like 6MP as we've discovered. Anyone care to try capturing at 20MP instead of 24MP to see if the detail level increases in the hope that the sensor is misconfigured to create Planet's advertised 24MP from a mere 6MP?
Post by: shuntcap on December 13, 2019, 01:48:02 am
Quote from: Daniel W
The Samsung S5KGM2 even squeezes 48MP onto a 1/2.25" sensor, though, as it uses a so called Quad Bayer filter array, it's really meant to produce (really nice) 12MP final images, but it still has 48000000 photosites on a sensor that comfortably fits inside a phone.Daniel W may be onto something here. All of the Samsung 20MP and 24MP mobile sensors are Tetracell, which is Samsung's answer to Sony's Quad Bayer array. Quoting Samsung (https://www.samsung.com/semiconductor/insig...-day-and-night/ (https://www.samsung.com/semiconductor/insights/tech-leadership/how-tetracell-delivers-crystal-clear-photos-day-and-night/)):
"When the camera is shooting in low-light conditions, the algorithm combines information and data from each group, essentially transforming four smaller pixels into a larger pixel. In bright lighting conditions, the re-mosaic algorithm remaps the pixels into a conventional RGB pattern through an algorithm called re-mosaic algorithm to produce high-resolution photos."
In other words, in dim lighting, 24MP becomes 6MP (24 divided by 4); in bright lighting, 24MP supposedly remains 24MP.
This invariably raises two questions:
1) Was fluffypony's iPhone/Cosmo comparison really done in dim lighting? Doesn't look it to me, and the low ISO ratings in the EXIF tag data confirm good lighting. To be sure, vader's night scenes report an ISO rating of 6399 (thanks, vader!)
2) How well does this "re-mosaic algorithm" really work with respect to reproducing an image of full resolution, not interpolated quarter resolution? Maybe it just doesn't work and that's the apparent software interpolation we're seeing, in which case we're stuck with a 6MP camera.
Everyone grab your smelling salts and sit down:
https://www.gsmarena.com/quad_bayer_sensors...-news-37459.php (https://www.gsmarena.com/quad_bayer_sensors_explained-news-37459.php)
"A Quad Bayer filter is a bit of a misnomer as it’s actually the same as a regular Bayer filter. What really changes is not the filter but the sensor behind it – these new sensors put four pixels behind each color square instead of just one.
"So, really these 48MP Quad Bayer sensors can’t offer much more detail than a 12MP sensor. Sensor and phone makers alike will tell you that smarter demosaicing algorithms can capture more detail, but our experience is that the gain is small – if there’s a gain to be had at all."
That spells a very low effective resolution for our Cosmo. If I'm right, don't blame Planet Computers, blame Samsung/Sony marketing.
Post by: shuntcap on December 13, 2019, 02:20:26 am
https://www.androidauthority.com/100mp-cameras-1016587/ (https://www.androidauthority.com/100mp-cameras-1016587/)
Highlights:
"Samsung’s 64MP GW-1 sensor calls this Tetracell technology... This is definitely not equivalent to a full resolution Bayer-filter sensor. The GW-1 provides just 16MP worth of color data, with some extra contrast data. The re-mosaic algorithm will pull out slightly more detail than a regular 16MP sensor, but certainly not anywhere near proper 64MP worth of detail."
"Quad-Bayer sensors are not equivalent to full resolution Bayer-filter cameras."
"These sensors help advertise a smartphone with a high pixel count and bigger pixels, but they're really neither."
"Ultimately, these huge megapixel numbers are mostly about marketing."
The facts seem to be leading to this conclusion: while the Cosmo's camera might produce better low-light images, it's really just a 6MP camera.
Post by: shuntcap on December 13, 2019, 02:56:04 am
"In our experience, the level of detail when switching between pixel binning is not huge. Many phones, such as the Redmi Note 7 Pro, actually perform better with pixel binning left on. This is due to the superior light capture performance and because the re-mosaic algorithm produces so-so results. For this reason, manufacturers often default to pixel binning rather than giving users high-resolution pictures."
My Cosmo is still sealed in a drawer... I won't open it until we get to the bottom of this.
Post by: drpeter on December 13, 2019, 12:16:19 pm
Quote from: Daniel W
Quote from: drpeterI sincerely doubt there is true 24MP resolution to be found in any sensor of this size.As far as the sensors are concerned, they do exist. The OmniVision OV23850, mentioned above by shuntcap is "smartphone-sized" ~1/2.3" (the way sensors are measured is a weird story in itself, but that's for another day) and has 23.8MP for real. [Source: https://www.ovt.com/sensors/OV23850 (https://www.ovt.com/sensors/OV23850)]. The Sony IMX576 is of similar size and has 24.8MP. The Samsung S5KGM2 even squeezes 48MP onto a 1/2.25" sensor, though, as it uses a so called Quad Bayer filter array, it's really meant to produce (really nice) 12MP final images, but it still has 48000000 photosites on a sensor that comfortably fits inside a phone. Whether the optics in a smartphone could resolve that much detail, is another question. My grasp on the diffraction limit for such systems is a bit fuzzy (pun intended), and is perhaps a bit off topic anyway, but 24MP should be possible to resolve, I think.
I don't doubt that phone sensors with such a theoretical pixel count exist, but whether they output images that contain genuinely higher spatial definition than sensors of the same size but with half the pixel count is another matter...
Given that mid-to-high-end dedicated SLR cameras ($1000+) haven't yet really usefully progressed beyond 24MP sensors, it's probably unrealistic to expect better genuine spatial resolution than 6-8MP from any phone camera sensor, still less from a low-volume non-specialist mid-range phone like Cosmo. Adequate for good snaps taken in favourable lighting conditions for viewing on a 6 inch screen is a realistic expectation.
Bear in mind that a 1/2.3" camera sensor has less than 1/10 the sensor area to work with as APS-C format DSLRs and even the somewhat larger sensors in high-end phone cameras such as the 1/1.7" Huawei P30 Pro have only 1/8 the sensor area of APS-C...
IMHO if you need better than full 8MP spatial resolution (which you don't for viewing snaps on a phone screen), you still need to buy and suffer the inconvenience of carrying a 'proper' camera- you can get a pretty good one second-hand for much less than the difference in price between a Cosmo and a high-end phone. Not forgetting the myriad other advantages a 'proper' camera will inevitably have over any phone camera for 'serious' as opposed to 'snap' photography.
Post by: vader on December 15, 2019, 07:33:43 pm
The main problem with small pixels, is a small well size. This means that amplification (ie. ISO) causes noise due to quantization. Keeping the ISO down, and exposure times long decreases the amplification, and hence noise for a better picture. The default camera app tends to go for quick shots with high ISO, resulting in more noise. Apps like OpenCamera can give you manual control so that you can lower the ISO and get a better shot, or alternatively in NR mode, take 4, 8 or even 12 shots and median filter to get rid of noise. So, I believe the camera module is quite capable, and with the correct software can take good shots.
EDIT: should have reread shuntcap's post a few above. Basically says the same thing. Quad bayer does have advantages (and disadvantages), but the take away is that it needs the correct settings to achieve good results, probably more so than standard bayer pattern sensors. With the right settings, however, it can produce excellent results.
Post by: drpeter on December 15, 2019, 10:10:34 pm
Quote from: vader
After a bit of digging, I found out some info on what I believe is the module in the cosmo. I believe it is the Samsung tetracell (quad bayer filter) 24MP 0.9um 1/2.3 inch sensor. This is a true 24MP sensor, which in low light, can automatically pixel bin for greater well depth. It isn't an 8mp upscaled to 24, and in my tests, it performs quite well. The actual model appears to be the 24MP ISOCELL Slim 2x7 ( https://www.samsung.com/semiconductor/minis...ocell-slim-2x7/ (https://www.samsung.com/semiconductor/minisite/isocell/mobile-image-sensors/isocell-slim-2x7/) ). Now there are conversations to be had about sensors with sub micrometer pixel sizes, but the main benefit is that in good light, it is easier to fill the well, and you can get good DR with high resolution. In lower light (eg. night mode), the sensor will bin pixels to gather more light per "pixel", but at lower resolution.
The main problem with small pixels, is a small well size. This means that amplification (ie. ISO) causes noise due to quantization. Keeping the ISO down, and exposure times long decreases the amplification, and hence noise for a better picture. The default camera app tends to go for quick shots with high ISO, resulting in more noise. Apps like OpenCamera can give you manual control so that you can lower the ISO and get a better shot, or alternatively in NR mode, take 4, 8 or even 12 shots and median filter to get rid of noise. So, I believe the camera module is quite capable, and with the correct software can take good shots.
EDIT: should have reread shuntcap's post a few above. Basically says the same thing. Quad bayer does have advantages (and disadvantages), but the take away is that it needs the correct settings to achieve good results, probably more so than standard bayer pattern sensors. With the right settings, however, it can produce excellent results.
Small correction: according to the link it's a 1/2.8" format sensor
Post by: vader on December 15, 2019, 10:24:26 pm
Quote from: drpeter
Small correction: according to the link it's a 1/2.8" format sensorYep, absolutely correct, I didn't pick that one up
Post by: drpeter on December 16, 2019, 12:23:29 am
Quote from: vader
Quote from: drpeterSmall correction: according to the link it's a 1/2.8" format sensorYep, absolutely correct, I didn't pick that one up
Also, are you sure it's this exact sensor?
Open Camera reports the max resolution as 5632 x 4224, which is slightly different to the 5664 x 4256 of this sensor (but the same as the main rear camera used in in the Galaxy A9, for example)
Post by: shuntcap on December 16, 2019, 01:52:14 am
Quote from: drpeter
IMHO if you need better than full 8MP spatial resolution (which you don't for viewing snaps on a phone screen), you still need to buy and suffer the inconvenience of carrying a 'proper' camera- you can get a pretty good one second-hand for much less than the difference in price between a Cosmo and a high-end phone. Not forgetting the myriad other advantages a 'proper' camera will inevitably have over any phone camera for 'serious' as opposed to 'snap' photography.The only good thing that came out of the Gemini's miserable rear camera, for me at least, was that I rediscovered the joy of using point-and-shoot cameras with true optical zoom lenses, not the fuzzy digital zoom garbage that cell phone cameras use. That's just software scaling. I regularly carry a Sony WX350 pocket camera, which is a mere 1" thick yet packs a 20x optical zoom. That camera is so small it fits in the coin pocket of my jeans. When I want better image quality or more manual control, I carry a still pocketable but bulkier Lumix ZS200 with a 1" sensor and 15x optical zoom: great image quality even in low light with an incredible optical zoom in a 1.8" thick package. With cameras this small, the inconvenience of carrying a proper camera becomes quite unnoticeable (unless you're a fan of ultra-tight pants).
With that in mind, the 16MP camera on my Moto Z Play actually resolves more detail than the 18.2MP Sony WX350 at wide angle and about as much detail as the 20MP Lumix ZS200 at wide angle due to its high quality lens (in good lighting only), so cell phone cameras can attain decent resolutions. Of course, that goes out the window once you hit the zoom controls on the real cameras. Disclaimer: I only bought the Moto Z Play because I backed the failed keyboard mod project on IGG, which led to the creation of the F(x)Tec Pro1. I despise virtual keyboards.
Post by: shuntcap on December 16, 2019, 02:10:10 am
Quote from: drpeter
Also, are you sure it's this exact sensor?I asked Planet what sensor is used. They didn't know the part number, but said it's a 24MP Samsung sensor (and confirmed that their original response of a 20MP sensor was a typo). There are only two Samsung mobile image sensors in 24MP, the S5K2X7 and the S5K2XA, both of which claim a resolution of 5664x4256. In the world of real cameras, two specs are often given: sensor resolution and effective resolution. There's usually a small crop of the sensor's full resolution due to the optics or packaging in front of it. If you could view the RAW image, you'd likely see the shadow of the lens barrel or at least some barrel distortion that is cropped out or otherwise removed during JPEG processing, thus reducing the final image resolution.
Open Camera reports the max resolution as 5632 x 4224, which is slightly different to the 5664 x 4256 of this sensor (but the same as the main rear camera used in in the Galaxy A9, for example)
Post by: shuntcap on December 16, 2019, 02:33:50 am
Quote from: vader
With the right settings, however, it can produce excellent results.Thanks, vader. Maybe I'll open my Cosmo after all. Now I'm just worried about getting a lemon!
Are you able to control binning in OpenCamera? Looking back at fluffypony's images (https://www.oesf.org/forum/index.php?topic=35912.msg293314#msg293314) and Daniel W's take on them (https://www.oesf.org/forum/index.php?topic=35912.msg293318#msg293318), it looks like pixel binning was employed when it didn't need to be since there was adequate lighting as evidenced by the low ISO rating in the EXIF data. When viewed at 100%, do you see this stair-stepping pattern in your images or do you see crisp diagonals like in fluffypony's iPhone sample? There's no good reason that a 24MP camera would resolve only a fraction of the detail of another 12MP camera unless perhaps pixel binning is forced. The iPhone is expensive, but the camera sensor isn't anything magical: 12MP is just 12MP.
Post by: novaldex on December 16, 2019, 05:00:13 am
I put it on my Cosmo pretty quickly and it works well. Okay, i'm still learning, but it does seem to allow me to tweak various settings pretty well, although i've not found anything about resolution yet. Still working on it
If it truly is a 6MP sensor i'll be happy with that, i'd rather it worked at a decent quality all the time rather than stretched itself & reduced quality in the end.
For proper photos i'll carry my Canon 80D when I need it.
Post by: rachid on December 16, 2019, 05:20:05 pm
Quote from: shuntcap
Quote from: drpeterAlso, are you sure it's this exact sensor?I asked Planet what sensor is used. They didn't know the part number, but said it's a 24MP Samsung sensor (and confirmed that their original response of a 20MP sensor was a typo). There are only two Samsung mobile image sensors in 24MP, the S5K2X7 and the S5K2XA, both of which claim a resolution of 5664x4256. In the world of real cameras, two specs are often given: sensor resolution and effective resolution. There's usually a small crop of the sensor's full resolution due to the optics or packaging in front of it. If you could view the RAW image, you'd likely see the shadow of the lens barrel or at least some barrel distortion that is cropped out or otherwise removed during JPEG processing, thus reducing the final image resolution.
Open Camera reports the max resolution as 5632 x 4224, which is slightly different to the 5664 x 4256 of this sensor (but the same as the main rear camera used in in the Galaxy A9, for example)
I found some references for S5K2X7 in the kernel files:
https://github.com/gemian/cosmo-linux-kerne...&q=++s5k2x7 (https://github.com/gemian/cosmo-linux-kernel-4.4/search?utf8=%E2%9C%93&q=++s5k2x7)
Not sure if that helps...
Post by: shuntcap on December 16, 2019, 06:31:22 pm
Quote from: rachid
I found some references for S5K2X7 in the kernel files:Thanks! I checked the Gemian github page the other day but somehow totally overlooked the Cosmo kernel source! Must have been distracted by my children... yeah, that's it...
https://github.com/gemian/cosmo-linux-kerne...&q=++s5k2x7 (https://github.com/gemian/cosmo-linux-kernel-4.4/search?utf8=%E2%9C%93&q=++s5k2x7)
Not sure if that helps...
Looking at drivers/misc/mediatek/imgsensor/src/common/v1_1/s5k2x7_mipi_raw/s5k2x7mipiraw_Sensor.c, it follows the same general format as other camera sensor drivers in the MediaTek kernels. But this setting caught my eye:
.sensor_output_dataformat = SENSOR_OUTPUT_FORMAT_RAW_Gr,//SENSOR_OUTPUT_FORMAT_RAW_4CELL_Gr,//SENSOR_OUTPUT_FORMAT_RAW_Gr,/* sensor output first pixel color */
The options for that variable are enumerated in drivers/misc/mediatek/imgsensor/inc/kd_imgsensor_define.h. It's interesting that there are a bunch of "4CELL" formats, possibly for Tetracell sensors. grep'ing through the other *s5*.c files shows a couple other Tetracell sensors that use 4CELL formats (20MP and 16MP sensors), while the two 24MP sensors do not.
Unfortunately, all of the initialization code is just magic numbers: register writes with no documentation.
I doubt I'll have time to try rebuilding and flashing a new kernel before the new year. Maybe by then I will have finally opened my Cosmo...
Post by: Daniel W on February 13, 2020, 05:49:17 pm
When doing the same thing in the stock camera app, the preview and the final photo matches much better, but there are so many other things that app can't do, so I'd like to be able to use Open Camera instead, but then I'd of course need to figure out how to get a correct viewfinder image. Any ideas, anyone?
Another issue I have is that, since the current camera driver seems to be doing a 2x2 pixel binning even in good light, my 24MP images only has about 6MP worth of details in them. That's usually enough for me, so I'd like to set the resolution to half the cameras native resolution, both ways, which would be 2816x2112. Reasonably, a sensor made with 2x2 binning in mind, would have a mode to output exactly half its native resolution, both ways, but the driver doesn't seem to allow that, which I find a bit weird. My only workaround right now is to shoot at 24MP, then use a photo editor to get down to 6MP and overwrite the original photo. Is there perhaps some app that could automate this, each time I take a picture, such that I wouldn't have to do it manually?
Post by: shuntcap on February 13, 2020, 08:22:54 pm
Quote from: Daniel W
As the stock camera app is quite barren, I tried using Open Camera, but even though I've set the preview size to match the photo size, they don't match. Were I, for example, to carefully frame, say, my computer keyboard such that it exactly fills the width of the preview, and then press the shutter, the resulting photo is quite a bit wider in all directions, as if the preview was a bit cropped on all sides. It doesn't seem to matter what resolution I pick.Odd. I don't have that issue with OC (version 1.47.3). Preview is set to WYSIWYG. I tried both 4:3 and 16:9 aspect ratios. All preview images match the output JPEG image in terms of framing (both width and height).
Quote from: Daniel W
Another issue I have is that, since the current camera driver seems to be doing a 2x2 pixel binning even in good light, my 24MP images only has about 6MP worth of details in them. That's usually enough for me, so I'd like to set the resolution to half the cameras native resolution, both ways, which would be 2816x2112. Reasonably, a sensor made with 2x2 binning in mind, would have a mode to output exactly half its native resolution, both ways, but the driver doesn't seem to allow that, which I find a bit weird. My only workaround right now is to shoot at 24MP, then use a photo editor to get down to 6MP and overwrite the original photo. Is there perhaps some app that could automate this, each time I take a picture, such that I wouldn't have to do it manually?You could just set OC to shoot at 4.9MP, swallow the detail loss, and pretend the year is 2011. Just kidding, I know you want 6MP. You're 100% correct, though, this sensor only outputs 6MP of detail. Calling it 24MP is a marketing scam. 24MP and 6MP photos show the exact same level of detail, with the 24MP version just scaled up. I've given up on the Cosmo camera. I just carry a tiny Sony WX350 (with true 20x optical zoom) when I want to pack light. But eventually I will play around with the camera driver code to see 1) if I can disable binning, and 2) if I can add a 6MP option. I'm not too optimistic, though.
Post by: Daniel W on February 14, 2020, 05:30:50 am
Quote from: shuntcap
Odd. I don't have that issue with OC (version 1.47.3). Preview is set to WYSIWYG. I tried both 4:3 and 16:9 aspect ratios. All preview images match the output JPEG image in terms of framing (both width and height).Thanks for checking. In the settings of Open Camera (1.47.3), I found that video stabilization was on. Apparently, that also affects the photo mode viewfinder. While the viewfinder IS a kind of video, I suspect OC isn't supposed to apply the stabilization setting in photo mode. After turning video stabilization off, my photo viewfinder now shows the full view.
Quote from: shuntcap
You could just set OC to shoot at 4.9MP, swallow the detail loss, and pretend the year is 2011. Just kidding...Well, that's what I'm doing for now, and five-ish MP is quite ok for my photo diary. The reason I'd want exactly half the sensor resolution is to minimize interpolation, to get as much detail as possible out of the megapixel count. I do have an app that can do batch resampling of 24MP images, but that means JPEG compressing each image twice, which isn't optimal.
[Edit]:Btw. for phones, 2011 is spot on, as I had a 5MP 2009 Nokia E72 until June, though as I mostly used dedicated cameras back then, to hit 5MP, I need to go back to my 5MP Canon Digital IXUS 500, replaced in 2005 by the 7MP IXUS 700.
Quote from: shuntcap
Calling it 24MP is a marketing scam.Yeah, but who's scamming? The (Samsung?) sensor has about 24 million photosites, so they're not lying per se. Planet just quotes a datasheet, and MediaTek doesn't really promise anything. Yet, the camera driver (by MediaTek?) seems to always do 2x2 binning - even on the Gemini. I've downsampled its 5MP images to exactly half resolution, both ways, with no loss of detail. But the Gemini at least HAS a mode for exactly 1280x960, while the Cosmo doesn't have a 2816 x 2112 mode, which I would be happy to use, if available.
Post by: NormMonkey on February 14, 2020, 01:31:25 pm
At this point, my two biggest wants from PlanetC are:
* A fix for the poor battery life
--- * If PlanetC can rework their firmware / drivers to let the thing achieve sleep, I imagine our Cosmos could at least last a weekend without needing a charge.
--- * I charge nightly and usually end the day around 25% to 40% depending how much I used it.
* A fix for the potato-quality camera
--- * If the sensor really is 24MP; and
--- * If the shite quality is down to a poor driver; then
--- * This should be a solveable problem
I'm not holding my breath on either of those things, though.
I went for the Cosmo for two reasons:
* Physical keyboard
--- * Awesome out of the box
--- * Breaks in and gets better with use
* Linux
--- * My original expectation was dual-boot; but
--- * Now it looks like Devuan-over-Android may be a better option
-- -- * Achievable immediately;
-- -- * without having to re-partition the device storage; and
-- -- * without wiping all my existing data and setup
Post by: guizmox on February 17, 2020, 08:54:32 am
Can someone provide me the information ?
Thank you
Post by: guizmox on February 25, 2020, 04:34:47 am
- Cosmo has a 24mp Samsung 4/3 Tetracell sensor (S5K2X7), 2.8 aperture size, focal length = 300mm
- Key2 has a 12 mp Samsung 4/3 Isocell sensor (S5K2L9), 1.8 aperture size, focal length = 389mm (a little wider compared to the cosmo)
I perform 3 tests using manual camera modes and using a 4000k white balance. I used the Key2 default camera app as it allows full camera controls (Key2 does not provide Camera 2 API, I can't use manual parameters on any other app) and Open Camera for the Cosmo (Cosmo supports Full Camera 2 API)
- ISO : 100, Shutter Speed : 1/15s
- ISO : 800, Shutter Speed : 1/125s
- ISO : 3200, Shutter Speed : 1/500s
What I observed so far :
- The device color calibration is not the same on both devices. Using the same white balance does not provide the exact same colors on final pictures (I obviously checked the results on a computer)
- Cosmo takes pretty good pictures at low ISO levels. Both devices performs quite equally if ISO < 800.
- At high ISO levels, Cosmo produces weird vertical lines, everything is over-denoised and blurry, more than with the Key2 (hard to tell is that post-processing is done in hardware or software)
- Both devices perform poorly on low-light situations. I suspect the lens to be crap on both devices : a lot of artifacts in low-light make me think about a low-quality lens (ex : the more you go away from the center of the picture, the more you have distorded perspectives and blur starts to appear)
- The Cosmo has a larger focus range : I can take macro-photos and get the focus where the Key2 is unable to focus.
- The Cosmo autofocus is SLOOOOOWWWWW....
Will post some pictures soon.
Post by: Zarhan on February 25, 2020, 05:03:36 am
What would be the correct resolution to use? There doesn't seem to be an option for exactly 1/4 of the maximum (with x and y half of the maximum values).
Post by: guizmox on February 25, 2020, 06:26:00 am
As you can see here : https://1drv.ms/u/s!AjXwOsvc6am5i8YAXZ8...t6xfdw?e=It74IG (https://1drv.ms/u/s!AjXwOsvc6am5i8YAXZ8fjSFCt6xfdw?e=It74IG)
I took 3 exact same pictures with 3 resolutions and as we can see, the 24mpx pictures are a 6mpx output resampling...
I'm not telling the pictures are bad, but you can safely choose a 6mpx resolution when taking pictures with the Cosmo
Post by: Zarhan on February 25, 2020, 06:43:53 am
Quote from: guizmox
I'm not telling the pictures are bad, but you can safely choose a 6mpx resolution when taking pictures with the Cosmo
Problem is that there is no 6 Mpix resolution available.
5632x4224 is the "native".
Close to 6 Mpix are
3264x2448 (8 Mpix)
2560x1920 (5 Mpix)
So I'm a bit concerned about using either of these in case there will be some interpolation and therefore fuzzying of detail that will happen. Or is there some way to set a custom resolution?
Post by: guizmox on February 25, 2020, 06:38:26 am
Post by: guizmox on February 25, 2020, 07:51:03 am
Quote from: Zarhan
Quote from: guizmoxI'm not telling the pictures are bad, but you can safely choose a 6mpx resolution when taking pictures with the Cosmo
Problem is that there is no 6 Mpix resolution available.
5632x4224 is the "native".
Close to 6 Mpix are
3264x2448 (8 Mpix)
2560x1920 (5 Mpix)
So I'm a bit concerned about using either of these in case there will be some interpolation and therefore fuzzying of detail that will happen. Or is there some way to set a custom resolution?
I would go for the 5mpx setting, the 8mpx would fit better with a 32mpx sensor.
Post by: Zarhan on February 25, 2020, 09:30:33 am
Quote from: guizmox
I would go for the 5mpx setting, the 8mpx would fit better with a 32mpx sensor.
Yeah, but it's not exactly correct.
I'm thinking that the best way forward here might be to keep camera shooting at 24 mpix, with JPEG quality to maximum, and then just do this in Termux:
Code: [Select]
mogrify -quality 95 -resize \>2816 ~/storage/dcim/OpenCamera/*.jpgEssentially, after shooting pics, just scan through all the files in camera directory, if they are larger than 2816 px in width, resize and also reduce jpeg compression level to lower value.
I'm not sure if this works for portrait pictures (is the rotation angle part of the EXIF data or directly part of the image). Have to test.
Post by: Zarhan on February 26, 2020, 12:36:17 pm
In OpenCamera, set image settings to jpg, quality 100, max resolution.
In termux, install imagemagick, and create script "resizepics", with content as above. I added "-verbose" switch so I can actually see what it's doing. You can edit the -quality value to your liking. The mogrify scans images and checks if image size is greater than 2816 px in width. If yes, it resizes it back to 6 mpix. The problem: This does not work for portrait images, as unlike most cameras the file is actually saved as portrait instead of saved as landscape and orientation stored in EXIF tag. I guess you can either check the orientation manually or lock orientation to landscape in Opencamera settings...but then you have to orientate manually later.
End result is that I can get perfect quality images without too much extra space consumption or valueless pixels.
Post by: Daniel W on February 27, 2020, 07:30:08 pm
Post by: Daniel W on March 04, 2020, 08:14:43 pm
Some random data:
Origin: Zhejiang, China
Sensor: CMOS
Chip: S5K2X7SP03
Special Features: Waterproof / Weatherproof
EFL: 3.96
F.NO: 1.7±3%
Lens size: 1/2.8 inch
Array size: 5664*4256
View angle: 77.5±3°
Focusing range: 8cm-infinity
Image quality: Center?2400LW/PH, Corner?1600LW/PH
Post by: Vistaus on March 05, 2020, 05:10:07 am
Quote from: Daniel W
Some random data:
Origin: Zhejiang, China
Sensor: CMOS
Chip: S5K2X7SP03
Special Features: Waterproof / Weatherproof
EFL: 3.96
F.NO: 1.7±3%
Lens size: 1/2.8 inch
Array size: 5664*4256
View angle: 77.5±3°
Focusing range: 8cm-infinity
Image quality: Center?2400LW/PH, Corner?1600LW/PH
Great find!
Post by: maki.jouni on March 05, 2020, 02:45:34 pm
Quote from: Daniel W
there's a link to a FCC PDFLittle bit off topic, but there is also punch of other documents on Cosmo related FCC site.
Post by: shuntcap on March 05, 2020, 11:58:21 pm
Quote from: guizmox
Yes, I confirm the pixel-binding mode. It's surely driver-coded.Correct, the binning is hard-coded in the kernel driver. I spent quite a bit of time playing with the driver a couple of weeks ago, modifying this and that, and testing the changes under a recompiled kernel. I was unable to improve the 6 MP effective resolution limit. The camera module setup is all done with "magic number" register writes. They are not commented. I believe there is likely a way to disable binning, but finding out how would require access to a confidential hardware reference manual for the chip (Samsung S5K2X7).
The driver file is drivers/misc/mediatek/imgsensor/src/common/v1_1/s5k2x7_mipi_raw/s5k2x7mipiraw_Sensor.c.
I did find a commented register write elsewhere in the MTK image sensor drivers that noted "binning_mode (0: disable, 1: enable)" for an S5K5E8 chip, but writing to the same register in the S5K2X7 driver had no effect whatsoever on the binning.
Sorry to be the bearer of bad news, everyone.
Post by: NormMonkey on March 06, 2020, 12:51:17 pm
Might not help with the binning issue, but the pictures I've gotten always seem quite processed and fairly low quality (what I would equate to "quality=75" when using ImageMagick), regardless of how high I set the quality parameters in the app. RAW mode would at least help with that.
Has anyone tested if the camera still does its binning shenanigans if the available light is very high?
Post by: drpeter on March 06, 2020, 08:31:59 pm
Quote from: shuntcap
Correct, the binning is hard-coded in the kernel driver.
This would seem to be a major bug in the Mediatek driver, admittedly one which Planet could not have anticipated.
Supposedly, the point of the Samsung technology in these sensors is to bin pixels only in situations of low light, but the driver appears to bin pixels regardless of the level of illumination. I can confirm that this does happen even when shooting in very good light levels.
As noted elsewhere, the images also appear over-processed, as if there has been an excessive application of noise reduction.
Overall it seems as though the driver is permanently fixed in a mode heavily optimised for 'low light' photography.
None of this matters too much for low-res viewing of a full image on a 'phone screen, where these issues are not visible, but they do cause problems when cropping to a small area of the image ('digital zoom') or viewing on a large hi-resolution screen. Under these circumstances, for outdoor scenic photography in good light the results are awful when compared side-by-side to my battered 5 year-old 16MP Galaxy Note 4.
I find it hard to believe this is anything other than a driver problem, rather than a hardware problem with the sensor.
Post by: shuntcap on March 06, 2020, 10:27:42 pm
Quote from: NormMonkey
I don't suppose while you were looking around at the driver, you noticed anything about enabling RAW mode?Sorry, I did not find any RAW settings in the driver. That was definitely something I was looking for. I also tested the camera in bright light (and made sure the ISO was low); 5MP and 24MP images of identical scenes had no noticeable difference in detail when viewed at 100% on a large monitor.
Has anyone tested if the camera still does its binning shenanigans if the available light is very high?
Post by: shuntcap on August 28, 2020, 08:20:55 am
See for yourself. Here is a random sample image I took yesterday evening, first with the stock image app, then with GCam saving in RAW. I used RawTherapee to view the .dng and slightly decreased the black level, increased the contrast and saturation a tad, and boosted the shadows a little. In other words, I barely touched the RAW image.
Stock camera app:
RAW:
100% crop from stock:
Same 100% crop from RAW. Note the HUGE jump in detail and color:
Another 100% crop from stock. Gloomy sky and muddy black trees:
Same 100% crop from RAW. Blue, partly cloudy sky, and detailed green trees:
Yet another 100% crop from stock, barely recognizable flowers and blotchy grass:
And the same 100% crop from RAW; ah, yes, colorful flowers and detailed grass texture:
Those of you who are paying close attention will notice that the out-of-camera crops from the stock app are larger in physical size (click or download them). I chose the default "24MP" resolution option for them. But as we have already established earlier in this thread, this is only a 6MP sensor. Now that I have RAW images, I have proof that is is ONLY A 6MP SENSOR. In fact, this GCam port saved the actual image in literally 1/4 of the full image, the rest being black. So why is it advertised as 24MP? It's INTERPOLATED, upscaled to 24MP for marketing purposes. In other words, it's a lie... sort of. It has only 6MP of pixel detail, but being a so-called tetracell sensor from Samsung, it has four times as much light detail. That means it works very well in low light with very little noise; that is, if you can save RAW images. And since it is only a 6MP sensor, we can't record 4K video.
But despite being only 6MP in resolution, the RAW images are incredibly detailed with excellent color. They matched or exceeded the detail level from the 12MP RAW images I took with a Galaxy S9 (standard sensor, not tetracell), but with much less noise. In other words, folks, this is a fantastic little 6MP sensor from Samsung that MediaTek has utterly destroyed!
Now some of you are wondering about other camera apps like OpenCamera. Garbage. Forget it. OpenCamera is great on other phones, but it produces the same toilet-quality images on the Cosmo as the stock camera app thanks to the underlying closed-source MediaTek libraries. And for whatever reason, it can't save RAW images (produces a zero-length file). At this point I don't know why the F1MinimalMod2.1 GCam port is able to save RAW while other apps can't, but I will surely find out in time if someone doesn't beat me to it. I may even port GCam to the Cosmo. After all, Planet Computers promised a "fantastic camera" (their own words on the Indiegogo story page). They have not delivered! But the Cosmo's camera sensor is indeed capable of delivering fantastic images! Planet Computers, are you reading this? Seriously, MediaTek, what were you thinking? How can you knowingly butcher such fantastic image quality and assume no one will notice?
So what about the JPEG images from GCam? They have the same high detail level as RAW (far greater than stock JPEG), but they're overexposed and mostly useless. You have to process the RAW .dng image instead, at least until I or someone else finds out why this GCam port in particular can save RAW but other apps can't. And video on the Cosmo is still awful: you'll get the same blotchy, poorly colored image quality as from stock JPEG output. I didn't find a GCam port that could record video.
As for lighting conditions, yes, it was late evening when I took those samples above. But even in strong sunlight, the difference in image quality between stock and RAW is equally striking. It's like comparing a 2006-era flip phone's camera with a modern DSLR. I strongly encourage all of you to try this out!
Post by: shuntcap on August 28, 2020, 09:00:36 am
Stock JPEG, scaled:
Same scene in RAW, scaled:
At first glance, the stock JPEG doesn't look half bad scaled down. But the colors are inaccurate. The RAW image shows the true colors. And when we look at 100% crops, the details pop out in the RAW.
Stock JPEG, 100% crop, with blotchy trees and grayish mountains and sky:
Same 100% crop from RAW, with sharp tree detail and correct colors:
Stock JPEG, 100% crop, blotchy grass and gravel road, no shadow detail:
Same 100% crop from RAW, detailed grass and gravel, with visible shadow detail:
Stock JPEG, 100% crop, more blotchy trees and ruined color:
Same 100% crop from RAW, great detail and accurate color:
Post by: cam1965 on August 29, 2020, 09:47:57 am
Please could you help me ? thanks
Post by: shuntcap on August 31, 2020, 08:30:11 pm
Hi. I have installed this apk. But when I took a photo app closes. Please see the error attached.
Please could you help me ? thanks
You need to disable the "motion photo" feature before you attempt to take a photograph. Tap the > icon to the left of the preview image. Look for "MOTION Auto" and tap the left option to disable motion photos. I also disabled face retouching at the top of the option list.
Second, you must allow the app to autofocus for you. If you tap to focus, the app will crash.
Third, this app is really only useful if you plan to process RAW (.dng) photos. You'll need to enable an option to save in RAW+JPEG. In the same pop-up menu that you activated by tapping the > icon, tap the gear icon in the lower right. This will bring you to the Settings menu. Under Advanced, enable RAW+JPEG control. By default, the RAW folder is /sdcard/Pictures/Raw/. You will need to transfer files from this folder onto your computer to process the RAW photos, unless you prefer to run an editor directly on the Cosmo. I'd recommend a computer with a large monitor, though.
Video doesn't record and timelapse crashes, but photosphere works. The colors are the usual MediaTek-induced mud, but better than nothing if photosphere is important to you.
Post by: Zarhan on September 01, 2020, 06:13:13 am
I like OpenCamera's UI and configurability...
Post by: cam1965 on September 01, 2020, 06:18:14 am
Hi. I have installed this apk. But when I took a photo app closes. Please see the error attached.
Please could you help me ? thanks
You need to disable the "motion photo" feature before you attempt to take a photograph. Tap the > icon to the left of the preview image. Look for "MOTION Auto" and tap the left option to disable motion photos. I also disabled face retouching at the top of the option list.
Second, you must allow the app to autofocus for you. If you tap to focus, the app will crash.
Third, this app is really only useful if you plan to process RAW (.dng) photos. You'll need to enable an option to save in RAW+JPEG. In the same pop-up menu that you activated by tapping the > icon, tap the gear icon in the lower right. This will bring you to the Settings menu. Under Advanced, enable RAW+JPEG control. By default, the RAW folder is /sdcard/Pictures/Raw/. You will need to transfer files from this folder onto your computer to process the RAW photos, unless you prefer to run an editor directly on the Cosmo. I'd recommend a computer with a large monitor, though.
Video doesn't record and timelapse crashes, but photosphere works. The colors are the usual MediaTek-induced mud, but better than nothing if photosphere is important to you.
Hi. It worked. Thank you so much !
Post by: Vistaus on September 01, 2020, 03:43:24 pm
Post by: shuntcap on September 01, 2020, 04:21:30 pm
Thanks for this great find! It works great, except that the image taken has a huge black area around it. Is there a way to eliminate that without cropping?
I'm working on it. My end goal is to either mod F1MinimalMod2.1.apk (again, as it's already a modded version of Google Camera) or patch OpenCamera to properly save RAW and use a software JPEG codec instead of MediaTek's muddy filth. I can't make any promises, but I'm working on it!
Note again that the huge black area is because the sensor is only a 6MP sensor, not the advertised lie of 24MP. The 24MP is merely software scaled with no addition of detail... and worse, MediaTek's JPEG encoder causes a significant reduction in detail and color, as we've seen in my RAW comparisons. But I'll let it slide because the 6MP sensor really is quite good!
Post by: shuntcap on September 01, 2020, 09:12:35 pm
Is there any easy way to make this "flow" automatic? Perhaps with a termux script? I would like to (semi)automatically convert these to JPG, because doing touchups when the photos are still raw are quite rare requirement for me (e.g. situations where white balance is ridicilously off).
I like OpenCamera's UI and configurability...
I have compiled ufraw-batch for Termux. It is a program to convert RAW images to other image formats, including JPEG. Get it below and save it somewhere under /data/data/com.termux/files/home:
https://www.dropbox.com/s/98hadotbylzv20a/ufraw-batch.bz2?dl=1 (https://www.dropbox.com/s/98hadotbylzv20a/ufraw-batch.bz2?dl=1)
[Local copy of it /Varti]
Give storage permissions to Termux in order to access /sdcard (where RAW images are stored): Hit Fn+Del to go to Settings, Apps & notifications, find Termux, Permissions, enable Storage.
Start Termux. You'll need to install some additional libraries:
Code: [Select]
apt install libexiv2 libtiff libpng libjpeg-turbo bzip2Decompress ufraw-batch:
Code: [Select]
bunzip ufraw-batch.bz2To convert a single RAW image (including cropping out the blackness), do this (and change the image filename, of course):
Code: [Select]
./ufraw-batch --out-type=jpg --crop-right=2816 --crop-bottom=2108 --exposure=2 /sdcard/Pictures/Raw/IMG_YYYYMMDD_HHMMSS.dngAnd, as the name implies, you can also batch convert multiple images:
Code: [Select]
./ufraw-batch --out-type=jpg --crop-right=2816 --crop-bottom=2108 --exposure=2 /sdcard/Pictures/Raw/*.dngYou can play around with the exposure and other options: look at the output from ./ufraw-batch --help
If you find some combination of settings that works well across all images, please share it with us!
Post by: rachid on September 02, 2020, 09:00:17 am
How did you found that gcamports? I tried about 20 Ports and every one of them crashed. I tried the port from mediatek phones and some other...
Post by: shuntcap on September 02, 2020, 04:41:00 pm
wow! Thanks, thanks and thanks!
How did you found that gcamports? I tried about 20 Ports and every one of them crashed. I tried the port from mediatek phones and some other...
Probably the same way you found them, except I tried 31 of them! https://www.celsoazevedo.com/files/android/google-camera/ (https://www.celsoazevedo.com/files/android/google-camera/)
I had read that the F1MinimalMod port worked on the F(x)tec Pro1 (does anyone here have one?), so I actually started with those, but tried a pile more (most of which crashed, refused to install, or had no picture).
Post by: spook on September 04, 2020, 12:50:56 am
Stock: https://imgur.com/a/HFs3H2X
RAW: https://imgur.com/a/VWGZySu
Post by: ianisthewalrus on September 07, 2020, 12:20:17 pm
Post by: cam1965 on September 07, 2020, 12:30:19 pm
" You need to disable the "motion photo" feature before you attempt to take a photograph. Tap the > icon to the left of the preview image. Look for "MOTION Auto" and tap the left option to disable motion photos. I also disabled face retouching at the top of the option list.
Second, you must allow the app to autofocus for you. If you tap to focus, the app will crash.
Third, this app is really only useful if you plan to process RAW (.dng) photos. You'll need to enable an option to save in RAW+JPEG. In the same pop-up menu that you activated by tapping the > icon, tap the gear icon in the lower right. This will bring you to the Settings menu. Under Advanced, enable RAW+JPEG control. By default, the RAW folder is /sdcard/Pictures/Raw/. You will need to transfer files from this folder onto your computer to process the RAW photos, unless you prefer to run an editor directly on the Cosmo. I'd recommend a computer with a large monitor, though.
Video doesn't record and timelapse crashes, but photosphere works. The colors are the usual MediaTek-induced mud, but better than nothing if photosphere is important to you."
Good Luck !
Post by: ianisthewalrus on September 07, 2020, 02:29:31 pm
Post by: shuntcap on September 07, 2020, 05:47:07 pm
https://www.dropbox.com/s/nckwdk9h106c794/gcam_for_cosmo_v1.apk?dl=1 (https://www.dropbox.com/s/nckwdk9h106c794/gcam_for_cosmo_v1.apk?dl=1)
1. Photos are now the correct size, no cropping needed, both JPEG and RAW.
2. Tap-to-focus now works.
3. JPEG exposure is now correct.
4. Motion photo has been removed since it was causing the app to crash if not manually disabled.
Still broken (and labeled as such in the app, English only):
1. Video
2. Panorama
3. Night Sight
4. Time Lapse
5. Slow Motion
I will keep working on the broken parts, but I make no guarantees about being able to fix them anytime soon.
This Google Camera port now makes the Cosmo camera usable! No longer will you have to hang your head in shame when you show your friends photos from your Cosmo, especially after bragging about the keyboard. No longer will a black cloud linger when you think, "I love the Cosmo, but the camera is just so awful!"
Enjoy.
Post by: spook on September 07, 2020, 09:19:20 pm
Post by: shuntcap on September 07, 2020, 10:16:59 pm
Thanks so much for this! I downloaded it and installed it straight away. I've only taken a couple of test photos in my office, but interestingly, even the jpgs in your modified app seem to look better than Open Camera. HEre are my very quick test results: https://imgur.com/a/COZaNi6 (blown up to 300%)
OpenCamera uses MediaTek's kernel driver and Android libraries to encode JPEGs, and they look dreadful. Scroll up through my previous posts for some comparisons. Stock camera app or OpenCamera, they will both look bad especially at a 100% crop. Google Camera, on the other hand, uses its own library to read the sensor directly, which is why the photos look so much better. MediaTek really fumbled here.
Looking at your sample crops, notice how the sun rays and clouds on the watch face are smudged away in the OpenCamera crop. Highlights are completely exaggerated, wood detail is smudged away then oversharpened. This is not OpenCamera's fault, it's MediaTek's.
The RAW image is the sharpest in terms of detail and fine texture, which is to be expected. Google Camera's JPEG is a drop down from there, losing some detail as noise reduction is applied (not much is needed on this sensor, by the way), and sometimes the HDR makes scenes look unrealistic due to overamplified dynamic range. But if RAW is a 10/10, GCam's JPEG is a 7/10, and OpenCamera/stock app is a 2/10... in my opinion.
Post by: spook on September 07, 2020, 11:19:10 pm
Post by: a1astair on September 07, 2020, 11:30:08 pm
In Google Photos, JPG resolution is 2816 x 2108, DNG resolution is 2800 x 2092.
In Windows 10, Explorer reports the JPG resolution to be the same, but the DNG resolution is now 940 x 702!
If I upload the DNG on my Windows PC to Google Photos, the resolution is back at 2800 x 2092.
What Windows package allows you to view DNG files at the native resolution? I tried IrfanView and the built-in Windows 10 photo viewer and they all downsize the photos.
Post by: shuntcap on September 08, 2020, 01:02:00 am
In Windows 10, Explorer reports the JPG resolution to be the same, but the DNG resolution is now 940 x 702!
If I upload the DNG on my Windows PC to Google Photos, the resolution is back at 2800 x 2092.
What Windows package allows you to view DNG files at the native resolution? I tried IrfanView and the built-in Windows 10 photo viewer and they all downsize the photos.
RAW files typically have an embedded preview image of much lower resolution. That's probably what Windows is showing you.
I use RawTherapee on a Linux machine to process RAW images, but a Windows 64-bit port exists:
https://www.rawtherapee.com/downloads/ (https://www.rawtherapee.com/downloads/)
Post by: kaim on September 08, 2020, 10:33:26 am
Blackview BV9600
BLU Vivo XI+
Doogee V
Elephone A5
Leagoo S10
Nokia 5.1 Plus
Nokia X5
Oppo A3
Oppo A7x
Oppo F7
Oppo F9
Oppo F9 Pro
Oppo R15
Panasonic Eluga X1
Realme 1
UMiDIGI F1
UMiDIGI Z2 Pro
Vernee M8 Pro
Vivo V11i
Vivo X21i
Vivo Y97
Vivo Z3i
Post by: spook on September 09, 2020, 02:56:02 am
What Windows package allows you to view DNG files at the native resolution? I tried IrfanView and the built-in Windows 10 photo viewer and they all downsize the photos.
Any RAW viewer - like LightRoom - should be able to open the RAW file. You can also use Darktable if you want a free one on Windows.
Post by: ianisthewalrus on September 09, 2020, 05:18:08 pm
Post by: mibry on September 10, 2020, 05:51: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”
Regards
Mibry
Post by: oe9fwv on September 10, 2020, 06:50:57 am
I can install F1MinimalMod2.1.apk though.
Can you help?
Post by: DragonInWhite on September 10, 2020, 07:22:19 am
I am posting this on behalf of @DragonInWhite from discord
“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”
Regards
Mibry
Finally got an account here.
Firstly, thanks for taking the effort to help port the app over and make the cosmo's camera more usable. Really appreciate all you done.
Anyway, taking pictures with spacebar or enter is just a suggestion, not a demand. No obligation but be great if you could put that it. Just did not wanna come across as being ungrateful and demanding.
Post by: ianisthewalrus on September 10, 2020, 09:19:25 pm
I tried to install the apk on my Cosmo, but I get an error message: App was not installed.
I can install F1MinimalMod2.1.apk though.
Can you help?
uninstall the old gcam app first, then try the new one.
Post by: ianisthewalrus on September 13, 2020, 06:51:30 pm
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.
just a heads up :-)
Post by: Hount on September 14, 2020, 03:16:03 am
I did a quick rundown between Stock camera app, Opencamera and your port of gcam. Needless to say that gcam blew the competition out of the water.
Stock camera and Opencamera photos are ~identical to me (atleast on default settings)
One thing I noticed is that gcam photos are "only" 5.9 Mpix in size. And on some very fine details with good light conditions I can interpret more info from stock camera apps 23.8Mpix photo. (yes, I've read this thread and discussion about Cosmo's Samsung made camera sensors true capabilities. But I was left in impression that the stock app (api) is just doing something wrong and there could be more information to be fetched from the sensor, right?
But generally most of the things are so much better on gcam's photos that I've switched completely to that (atleast for now)
Post by: Zarhan on September 15, 2020, 12:09:45 pm
I have compiled ufraw-batch for Termux. It is a program to convert RAW images to other image formats, including JPEG. Get it below and save it somewhere under /data/data/com.termux/files/home:
https://www.dropbox.com/s/98hadotbylzv20a/ufraw-batch.bz2?dl=1 (https://www.dropbox.com/s/98hadotbylzv20a/ufraw-batch.bz2?dl=1)
Give storage permissions to Termux in order to access /sdcard (where RAW images are stored): Hit Fn+Del to go to Settings, Apps & notifications, find Termux, Permissions, enable Storage.
Start Termux. You'll need to install some additional libraries:Code: [Select]apt install libexiv2 libtiff libpng libjpeg-turbo bzip2
I finally got around trying this...are you using some other Termux? I just installed mine from play store. The package manager is still pkg, not apt, and libexiv2 is not available as a package. Is this meant for the Devuan installation as per the other thread or something like that (requires root)?
Post by: cam1965 on September 15, 2020, 05:13:14 pm
$ ufraw-batch
CANNOT LINK EXECUTABLE "ufraw-batch": library "libgthread-2.0.so" not found
So I had to install glib and littlecms to work. ( the error was gone ).
It saves in .ppm ( I have installed file viewer for android to open it ).
Or ufraw-batch --out-type=jpeg ( img file ) to save in jpg
Thank you all.
Post by: shuntcap on September 16, 2020, 01:09:44 am
I have compiled ufraw-batch for Termux. It is a program to convert RAW images to other image formats, including JPEG. Get it below
I finally got around trying this...are you using some other Termux? I just installed mine from play store. The package manager is still pkg, not apt, and libexiv2 is not available as a package. Is this meant for the Devuan installation as per the other thread or something like that (requires root)?
This was intended for use with Termux from the Play Store. However, this step is no longer required, as I released an updated .apk on September 7th that solves the crop and overexposure problems: https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708 (https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708)
Saving as RAW in GCam is now purely optional since the JPEGs are fully usable.
Post by: spook on September 16, 2020, 01:11:41 am
Thank you shuntcap!
I did a quick rundown between Stock camera app, Opencamera and your port of gcam. Needless to say that gcam blew the competition out of the water.
Stock camera and Opencamera photos are ~identical to me (atleast on default settings)
One thing I noticed is that gcam photos are "only" 5.9 Mpix in size. And on some very fine details with good light conditions I can interpret more info from stock camera apps 23.8Mpix photo. (yes, I've read this thread and discussion about Cosmo's Samsung made camera sensors true capabilities. But I was left in impression that the stock app (api) is just doing something wrong and there could be more information to be fetched from the sensor, right?
But generally most of the things are so much better on gcam's photos that I've switched completely to that (atleast for now)
This is interesting, and I think it has to do with why companies can claim a camera is x megapixles when the sensor isn't actually capable of shooting at that resolution. I'm pretty vague on this - and I'm sure someone here can correct me if / where I am wrong - but the way that I understand it is the camera chip can "create" pixels to a fair degree of accuracy. For example, if the sensor picks up a red pixel next to another red pixel, the chip can create another red pixel between them with a reasonable assumption that it is accurate. Obviously, things are more complicated when different colour pixels are next to each other, but I believe it does some fancy algorithms to work out what pixel it should create. I think this is called interpolation. Gurus on this forum - am I correct or completely off the mark?
Post by: shuntcap on September 16, 2020, 01:29:05 am
One thing I noticed is that gcam photos are "only" 5.9 Mpix in size. And on some very fine details with good light conditions I can interpret more info from stock camera apps 23.8Mpix photo. (yes, I've read this thread and discussion about Cosmo's Samsung made camera sensors true capabilities. But I was left in impression that the stock app (api) is just doing something wrong and there could be more information to be fetched from the sensor, right?
MediaTek's JPEG engine oversharpens and exaggerates certain details, while smearing away most of the rest. That's probably why in rare occasions details may appear sharper in the stock JPEG versus GCam's JPEG. Try comparing a RAW image from GCam to a stock interpolated 24MP image. Also keep in mind that even with GCam's advanced JPEG engine, some details are lost during noise reduction. If you want to preserve the greatest amount of detail, shoot in RAW and then edit to taste in a RAW image editor, applying minimal noise reduction before saving your final JPEG. Finally, for the most effective pixel-peeping comparisons, try a large monitor, not the Cosmo's LCD.
As for only being 5.9MP, that is correct, that is the sensor's native resolution, and that's exactly why our expensive modern Cosmo "phone" cannot even record 4K video which requires at least 8MP of native (not interpolated) resolution.
Post by: shuntcap 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.
Post by: shuntcap 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.
Post by: Zarhan on September 16, 2020, 08:21:28 am
This was intended for use with Termux from the Play Store. However, this step is no longer required, as I released an updated .apk on September 7th that solves the crop and overexposure problems: https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708 (https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708)
Saving as RAW in GCam is now purely optional since the JPEGs are fully usable.
Ah, thanks for the clarification! Looks good.
Post by: Zarhan on September 17, 2020, 07:48:01 am
It seems I can have HDR or HDR+, but not completely off.
Post by: shuntcap 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.
Post by: TauPan on September 19, 2020, 01:51:06 pm
I've tried to download your gcam mod but a new browser tab opens (chrome on android) and closes again and nothing is downloaded.
This was intended for use with Termux from the Play Store. However, this step is no longer required, as I released an updated .apk on September 7th that solves the crop and overexposure problems: https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708 (https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708)
Saving as RAW in GCam is now purely optional since the JPEGs are fully usable.
Post by: Vistaus on September 19, 2020, 04:14:20 pm
Hi!
I've tried to download your gcam mod but a new browser tab opens (chrome on android) and closes again and nothing is downloaded.This was intended for use with Termux from the Play Store. However, this step is no longer required, as I released an updated .apk on September 7th that solves the crop and overexposure problems: https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708 (https://www.oesf.org/forum/index.php?topic=35912.msg296708#msg296708)
Saving as RAW in GCam is now purely optional since the JPEGs are fully usable.
It's a strange browser issue. I had the same issue with Vivaldi, but not with Yandex. Not sure where the problem lies.
Post by: TauPan on September 20, 2020, 05:52:47 am
Hi!
I've tried to download your gcam mod but a new browser tab opens (chrome on android) and closes again and nothing is downloaded.
It's a strange browser issue. I had the same issue with Vivaldi, but not with Yandex. Not sure where the problem lies.
Ah, thanks for that hint. It works if I copy the url, open a new tab and then paste. :)
Post by: sup on September 24, 2020, 06:12:06 am
I also found out I need to enable HDR+ in the settings to get betterlooking pictures (taking of a picture than takes around five cseconds).
Post by: Vistaus on September 24, 2020, 06:54:27 am
Is there any way to take a macro picture with the app by Shuntcap? I cannot seem to find a way to modify focus distance.
I also found out I need to enable HDR+ in the settings to get betterlooking pictures (taking of a picture than takes around five cseconds).
5 seconds? I think Planet shipped you the wrong Cosmo 'cause I tried HDR+ on a few Cosmos now and it only takes 2 seconds.
Post by: sup on September 24, 2020, 07:05:59 am
Post by: sup on October 03, 2020, 06:56:16 am
However, today, the app stopped taking pictures with HDR+ enabled. It seems to be taking a picture but nothing gets saved. It happened once before when I turned on video, but a reboot fixed that. Now a reboot does not help and neither does removing and reinstalling the app. Any ideas (for now I turned the HDR+ feature off, but Iactually like its results)?
Post by: Vistaus on October 03, 2020, 07:02:10 am
Post by: sup on October 03, 2020, 04:20:09 pm
Post by: Daniel W on October 14, 2020, 04:16:02 pm
MediaTek seems to first use heavy noise reduction, thus smearing away fine details, and then tries to sharpen the result, which creates an artificial threshold, where details either gets lost in the first step or over sharpened in the second. Maybe that works for some applications, but from an aesthetic view, GCam does noticeably better.
Though I don't intend to use RAW files at all, I'm still saving both formats, just in case. I regard the RAW files a bit like having insurance, except this one is almost free, as I can delete RAW files for which the corresponding JPEG from GCam came out fine.
I have noticed that the GCam viewfinder has a much lower framerate than when using the MediaTek software stack. That makes it less useful for anything that moves. I would presume GCam snaps a sequence of low resolution still images, rather than streaming video. This GCam build is also fairly barren when it comes to photography settings. None of those observations are meant as criticism though. I find it quite amazing this thing works at all. As of now I'm using GCam for point and shoot photography, which, for me, covers most of my regular use cases.
Now when this proof of concept exists and shows that things like correct resolution is possible, I hope Planet will be able to improve the built-in imaging software stack too. Then again, I also hope for world peace.
Post by: shuntcap on October 15, 2020, 08:06:19 pm
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 (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.
Post by: spook on October 16, 2020, 09:56:27 pm
Post by: ianisthewalrus on October 17, 2020, 08:51:47 pm
Post by: spook on October 17, 2020, 11:01:32 pm
Post by: shuntcap 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.
Post by: Daniel W on October 25, 2020, 03:49:15 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.
For me, the brightness slider works in both versions, though in reverse, that is, moving the slider to the left, makes both the viewfinder and the JPEG image brighter, while moving the slider to the right, makes both the viewfinder and the JPEG image darker. This is consistent with GCam thinking it's working in portrait mode, as moving the brightness slider to the left in landscape would correspond to moving it up in portrait mode, and making the image brighter when the slider moves up, is probably the intended behavior.
Interestingly enough, if I switch to the front camera, the taps are indicated where I actually tap, but the brightness slider is still reversed (left = brighter).
Post by: sup on October 25, 2020, 04:41:37 pm
Post by: shuntcap on October 26, 2020, 12:31:31 am
Post by: shuntcap 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?
Post by: sup on October 28, 2020, 01:31:24 pm
Post by: spa on October 28, 2020, 10:39:23 pm
Post by: Daniel W on October 29, 2020, 12:32:36 pm
So the key word here is "seems", it seems ;-)
For the record, which I should have mentioned, I am on stock, unrooted V23 (Cosmo-9.0-Planet-07062020-V23) and I am not using any screen rotation software that I'm aware of. The grid I was talking about, is the visual grid in the viewfinder, intended to aid composition. I have it on just to make it easier for me to see where, exactly, the center of the viewfinder is. I am only experiencing this "rotation" for the visual indication of taps in the viewfinder and only when using the rear camera.
I did a few tests before, tapping at some random outdoor scenery and somehow managed to fool myself into thinking GCam set the focus where it drew the "feedback circle", but using a better test scene, I can conclude GCam sets the focus correctly. It's just the feedback circle that gets drawn elsewhere.
Edit:
Edit2:It seems webp attachments currently doesn't scale. Kudos to Varti for converting it to png.
Post by: Varti on October 29, 2020, 12:44:58 pm
EDIT: it seems like webp images are not automatically resized when they are uploaded as inline attachments, while other filetypes work as expected. I have taken the liberty of converting your attached image to png and of re-attaching it to your post. I'll ask the author of the inline attachments mod to add support for webp images as well.
Varti
Post by: Daniel W on October 29, 2020, 01:39:35 pm
Post by: shuntcap 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.
Post by: shuntcap on October 29, 2020, 07:07:24 pm
... 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.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.
Post by: shuntcap on December 02, 2020, 12:22:16 am
Download Version 3 of GCam for the Cosmo here:
https://www.dropbox.com/s/t36cufk1se59uri/gcam_for_cosmo_v3.apk?dl=1 (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.
Post by: Zarhan on December 02, 2020, 06:57:31 am
Post by: sup on December 02, 2020, 01:08:32 pm
Post by: shuntcap 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.
Post by: sup on December 03, 2020, 04:34:17 am
Post by: Daniel W on December 03, 2020, 12:41:40 pm
To me, it's more important that you looked into the viewfinder stream than whether you could actually do much about it or not, and the same goes for the peculiarities of the HDR+ mode. Now, we all know these are limitations not easily worked around, and, thus, things we probably will have to learn to live with. Still, thanks to your effort, we are now in a much better position than when we were stuck with just the really cheap kit lens... um... default camera software stack, that is.
A tad off topic, while I think the F(x)tec Pro1 X certainly seems interesting, even offering a Scandinavian keyboard layout, for us so inclined, from measuring available images, its horizontal key pitch seems to be about 9.7mm, which reminds me a bit too much about another Fx, my old Casio FX-850P, on which I typed quite a lot back in the days (I even wrote a ~100 location text adventure on it, now since long lost to battery failure and lack of secondary storage...) and while I think its 10.2mm pitch keyboard performed remarkably well for its size, I had my fill of "how small can you go" around the time of my SonyEricsson P990 (with a horizontal pitch of around 5mm, the tininess of which I thought was super cool back then...) so, personally, I am going to take my chances with the Astro, especially as the "RockUp" slider, should it actually work well (here's to hoping), would enable the first "as-wide-and-tall-as-the-device" physical keyboard on a slider phone, which, at least in theory, would seem, to me, like the ultimate form factor for a smartphone with a physical keyboard, since it maximizes the keyboard size, without interfering with portrait mode usage and doesn't require hacks like a secondary something (which, to me, typically is a hallmark of sub optimal design) to work well... oh, well, we'll see.
Somewhat back on topic, could Planet just get the 48-mega-photosite Astro sensor to actually output unresampled 12MP images, I think we'd be off to a decent start. Time will tell.
As a closing remark, should Cosmo GCam v3 turn out to be the final version, that's probably what I'll be using for >90% of my digital photos, for as long as I keep using the Cosmo. As that realistically means I'm going to, on average, use GCam at least once a day, that means it, and thus you, shuntcap, will likely, until Planet manages to ship the Astro, make my life a little bit better, on a daily basis. For that I am grateful.
Post by: sup on December 03, 2020, 03:49:39 pm
Do we know if anybody from Planet reads this? Is there a way to let them know about this? I am not even sure they are aware of the issue and that it is solvable.
Post by: Vistaus on December 03, 2020, 04:43:01 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.
I haven't backed the Astro either and maybe I could live with the Pro 1 X keyboard, but I'm a Dvorak guy and Fxtec doesn't offer a Dvorak version, sadly...
Post by: shuntcap on December 31, 2020, 08:50:37 pm
Download v4 here:
https://www.dropbox.com/s/oj7p3a0qbauylbl/gcam_for_cosmo_v4.apk?dl=1 (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.
Post by: spa on December 31, 2020, 09:16:20 pm
Post by: drpeter on December 31, 2020, 10:38:34 pm
Post by: Zarhan on January 02, 2021, 03:19:49 pm
Post by: spa on January 04, 2021, 01:06:25 am
I will wish the "camera sounds" setting was still there.
Post by: shuntcap on January 04, 2021, 01:41:44 am
The "camera sounds" setting that existed in v3 is no longer available in v4.Odd. I see the sounds settings on mine (same v4 that I released), and if the ringer is enabled, I hear a shutter sound.
I will wish the "camera sounds" setting was still there.
Does anyone else have the issue spa is seeing?
Post by: Zarhan on January 04, 2021, 08:04:06 am
The "camera sounds" setting that existed in v3 is no longer available in v4.Does anyone else have the issue spa is seeing?
I will wish the "camera sounds" setting was still there.
Nope - "Camera sounds" settings is visible (localized, even).
Post by: spa on January 04, 2021, 09:12:25 am
The v3 settings screen.
https://drive.google.com/file/d/1rJRgO7r5gAyS2QGzX6oZoF3Tx0LU8hVn/view?usp=sharing
The v4 settings screen.
https://drive.google.com/file/d/1bmS7glnIRYdrXLKp9KRDtXJESFeBRaP-/view?usp=sharing
It's strange.
Post by: Daniel W on January 12, 2021, 01:20:36 pm
Just to add to the statistics, I see the camera sound toggle in v4.
Once thing that breifly threw me for a loop, was that, on my Cosmo, v4 didn't replace v3, but was installed in parallel to v3. I guess this might depend on the "ported fresh from scratch" part. Launching directly after installation, started v4, but my shortcut on the home screen kept pointing to v3, which later made me start the wrong version, and getting confused a few times, until I noticed I had two identical icons in my app drawer. In a way, I appreciate the parallel install, as it allows me to compare things between the versions more easily, and after updating my shortcut, I can now conveniently launch v4 from my home screen. I'll probably uninstall v3 pretty soon and for those not interested in going back and forth between v3 and v4, I'd recommend uninstalling v3 before installing v4, just to lessen the risk of confusion.
Post by: MarionNash on May 09, 2021, 09:35:33 am
Post by: Rahab D on June 02, 2021, 06:57:19 am
Thank you very much: now the camera does what it should!
I read you don't support Astro. How will we do it? Your optimization changes functionality substantially.
Should we petition for a device to be made available to you to work on?
Or a subscription to buy one for yourself?
I don't know ... I'm open to every possibility, but I would like to see the same result on Astro. :o
Post by: da9l on September 23, 2021, 09:55:58 am
Post by: Colin The Dolphin on September 23, 2021, 12:11:01 pm
Post by: da9l on September 23, 2021, 01:35:03 pm
And what a difference this app does to the device camera! It actually goes from being useless to becoming usable and quite okay actually!
Post by: shuntcap on September 30, 2021, 12:30:31 am
I read you don't support Astro. How will we do it? Your optimization changes functionality substantially.Sorry for my long absence from the forum. I've pretty much shelved the Cosmo as I just haven't had much free time to hack on it.
Should we petition for a device to be made available to you to work on?
Or a subscription to buy one for yourself?
I don't know ... I'm open to every possibility, but I would like to see the same result on Astro. :o
I still won't be backing the Astro, but I've been watching the updates. This time around they're paying close attention to the camera image quality. They just might get the camera working right finally. But if they don't, I have backed the Pro1 X which supposedly has the same camera sensor as the Astro. I plan to port GCam to the Pro1 X once I receive my device, and that port might just work on the Astro, too.
Post by: Onkel Otto on April 06, 2022, 06:37:15 pm
I was am using the "gcam_for_cosmo_v4.apk" published by shuntcap in post #123 since its release on my COSMO without any problems.
Today i realized, that the app does not start anymore. When I try to start it, a message is shown "camera was closed".
I can tap on "App-Information" or an "Close App", but this does not provide any solution.
I reinstalled the GCam app - no change.
The original COSMO camera app is working and takes pictures.
I did some web search and found the "solution" here:
https://github.com/lukaspieper/Gcam-Services-Provider
Quote
"This app "simulates" the Google Play Services that the Google Camera app (Gcam) requires, allowing the camera app to be used on devices without Google Play Services.
Comparison: microG
microG is a open source re-implementation of the Google Play Services (client side). Among other things, signature spoofing is used to achieve this goal. In comparison, this app only aims to get Gcam running without Play Services. Therefore this app does not need any security compromising hacks or permissions (no Internet access, no storage access and of course no root access)."
I have completely removed Google Play Services from my Cosmo and replaced it with microG.
But when I checked my Cosmo now after reading on the mentioned github page, I realized, that the "microG Services Core" app was missing. It was gone. I have no idea, why.
I reinstalled "microG Services Core" and shuntcap's GCam port was working again.
I did not know, that the GCam app requires Google Play Services.
Post by: Daniel W on April 08, 2022, 07:30:16 pm
I did not know, that the GCam app requires Google Play Services.Me neither, though as G in GCam stands for Google, I expected them to depend on their own services, for certain features. Thank you for confirming. Good to know.
When shuntcap adapted a particular build of GCam, intended for another phone with the same sensor, to make it work on the Cosmo, there was probably no intention to remove Google dependencies, but rather to make features work, which probably explains why the dependencies are still there.
Post by: shuntcap on April 16, 2022, 02:31:47 am
When shuntcap adapted a particular build of GCam, intended for another phone with the same sensor, to make it work on the Cosmo, there was probably no intention to remove Google dependencies, but rather to make features work, which probably explains why the dependencies are still there.Versions v1-v3 were adapted from an existing mod of GCam intended for another phone with a different sensor, actually. v4 was a clean port from scratch to bring in additional features that were knocked out of the other phone's version. But Daniel is absolutely correct: my only goal was to improve the poor camera performance on the Cosmo by providing a good software alternative.
Post by: Onkel Otto on May 10, 2022, 05:38:04 pm
It was definitively not my intention to complain about any GCam dependencies. I did not know that GCam depends on the Google Play Services. I just wanted to inform other people about this "finding". Because I think, that I am not the only one, who replaced Google Play Services with microG. And when the "microG Services Core" app can disappear on my Cosmo for unknown reasons, it can happen on other devices too. It took me 2 or 3 hours to find the solution.
I thought, my finding may be helpful for somebody sometimes and save him or her some time.
@shuntcap
I really appreciate your GCam mod. Thank you very much, that you provided it.
It was not my intention to blame you for not removing the GCam dependencies.
I am really sorry, if my post caused this wrong impression and want to apologize.
Onkel Otto
Post by: Daniel W on May 12, 2022, 11:15:23 am
Post by: shuntcap on May 24, 2022, 03:56:44 am
I have the impression, that my post #147 caused some wrong emotions.No need to apologize; I never took it the wrong way. I'm a software engineer and you provided useful and interesting feedback. Thanks! That's one way we engineers improve our products... although in this case, I don't plan to do any more work on GCam for the Cosmo.
Post by: Dom (shymega) on May 30, 2022, 01:52:42 pm
Post by: shuntcap on June 05, 2022, 12:08:42 am
shuntcap -- can you publish the sources? Without the sources, we/I can't adapt GCam for Lineage or stock for Astro, Cosmo, Gemini. Otherwise we'd have to start again.I'll think about it. I never release code for public consumption (paid or free) without thoroughly documenting and cleaning the code and build process, and that's what I have to think about here. It's not exactly easy code to read, as it is entirely reverse-engineered, disassembled, undocumented assembly language (or the Java VM equivalent thereof), except for my own modifications which are documented.
By the way, it can't be ported to the Gemini as the image sensor cannot output raw data. I tried.
Post by: Dom (shymega) on June 11, 2022, 04:21:51 pm
OK about Gemini. Sucks. I think publishing regardless before it's ready isn't necessarily a bad thing. Look at CoDiOS and codid - both nowhere near ready, but still being committed and it's nice to see the evolution...