600 Dpi To Megapixels

[Carol Gudes]

Howare the Canons? The particular model I was looking at is around 200 dollars and i was just curious to see if the quality for scanning 3mm and 120 film and slides is acceptable? I realize it's not going to be on par with the super high res razor sharp scans made by pro labs (at $4.00-10.00 PER IMAGE) but just wanted to get an idea if results were of decent quality. The scanner I was looking into is the Canon 8800F. Thanks in advance!

Wow, didn't expect to get so many responses! And Kelly, I work at Wal-Mart and we DO sell junky 5mp cameras in blister packs ;-) So as I understand it it's a quantity vs. quality job. Like comparing a 10mp point and shoot 199.99 Kodak to a 10mp Nikon D200? Just because they're both 10 megapixels doesn't mean the quality of the sensor is the same on both.

I've also been looking at the Epson 4990. They claim (here we go again) 6400 optical but they actually list the dmax which is quoted as 3.4 From my understanding that's pretty decent. I was unable to find a dmax quote for the Canon 8800F, would anyone perhaps know where I could find that information? Thanks in advance,

Yes, I've read about this. Sadly, it isn't me, because I'd surely be making more money than I am now selling cameras to people who think that a "scene mode" on a point and shoot means that the camera superimposes your portrait in front of a pre-loaded landscape photo backdrop of Hawaii. I actually had to explain this to a disappointed woman today; that a scene mode refers to exposure compensation settings for conditions such as "snow" and "beach" which attempts to compensate for the resulting underexposure, because theoretically, the camera's built in light meter is not as smart as my customers. ;-) So...does anyone know where I can find a photographer to assist in the Boston area? Because Wally World is for the birds.

I try to upload my vector works shutterstock page. But This page always give me error about your .EPS artwork must be bigger than 4 megapixels size ! This is strange, because vector file how count with "megapixel" but, i try after my artwork export something.eps, open it Adobe Illustrator, in AI i will set "artboard" size is 4000x4000 pixel than later save as something.eps, after this i upload shutterstock then accepted. Sorry for my English, but all this extra steps make me be tired. In Affinity designer is this have anywhere settings ?

i need minimum 4mp. so i will set it bigger but all this ways i try nothing changed. Even file size is always see 38.3 kb !.. i use 300 dpi and nothing change !.. How is it possible this is "impossible" before i make it in affinity than later open in adobe illustrator, there i can resize artboard and later okay but it not work anymore too after adobe illustrator cc 2020 ! ? two different programs, before i did, now i can't ?! What changed i don't know.

I know .eps, .AI vb. vector formats how is it possible can be count with megapixels ! But shutterstock need it, before with Adobe Illustrator i set atrboard size 4000x4000 and it will be okay. But now even with Adobe Illustrator it not work ! What changed i don't understand that. Ayyway, today i want to learn don't need Adobe Illustrator for this, but i see impossible save .EPS file with Affinity Designer 4,6,8,20 megapixel ?! I will trying add screenshots here now. I hope that screenshots help for understanding my problem.

I try artboard 6000x4000 or 4000x3000 pixel in Adobe Illustrator, but when i save .EPS interesting nothing changed all different artboard size files same visible ! Nothning changed in AdobeIllustrator CC2020... I add another screenshot

I created a 3000x2000px sized document with 72dpi and exported it to EPS. When I upload it to Shutterstock, I get the message "The size of your artwork (not the size of the artboard) must be at least 4 megapixels.".

I recently found myself selling a Leica Q2 in favor of its inspiration, the Leica M. Having begun snapping photos in the film era, and having experienced the ineffable finesse of prints from a film Leica CM I owned years ago, I immediately revered my pre-owned M10. Gradients overlapped like silk sheets, and colors came out rich yet unsaturated. It reminded me of film.

More detail, more information, more cropping power: I sought more resolution than a 24-megapixel sensor could provide. Expecting the same M10 look, yet augmented by an additional 16-megapixels, I further eroded my credit limit and purchased a pre-owned M10-R.

Revisiting my M10 shots, I felt that warm, fuzzy feeling again. Smoothness soothed me like nectar (or something stronger). In a panic, I consulted a photographer friend and mentor who is also a Leica Akademie instructor. He explained what I was seeing, and why.

By trading the M10 for more resolution, I had scrapped the Golden Mean. In another panic, I canceled the sale of my M10, had it returned to sender, posted the M10-R for sale, and became a 24-megapixel black sheep.

Of course, he then mentioned how the new Leica M11 can do this too with its backlit sensor, but also allows for triple resolution and renders a smooth, film-like quality. This means, if only I could afford it, I could have something like my desired M10 look at 18-megapixels, the manageable file size of 36-megapixels, and the cropping ability of 60-megapixels, all in one camera, depending on my needs. What would Aristotle make of such a spread? Maybe such all-encompassing technology finally respects the Golden Mean.

The Megapixels camera application has long been the most performant camera application on the original PinePhone. I have not gotten the Megapixels application to that point alone. There have been several other contributors that have helped slowly improving performance and features of this application. Especially Benjamin has leaped it forward massively with the threaded processing code and GPU accelerated preview.

All this code has made Megapixels very fast on the PinePhone but also has made it quite a lot harder to port the application to other hardware. The code is very much overfitted for the PinePhone hardware.

To address the elephant in the room, yes libcamera exists and promises to abstract this all away. I just disagree with the design tradeoffs taken with libcamera and I think that any competition would only improve the ecosystem. It can't be that libcamera got this exactly right on the first try right?

Alsa UCM config files are selected by soundcard name and contain a set of instructions to bring the audio pipeline in the correct state for your current usecase. All the hardware specific things are not described in code but instead in plain text configuration files. I think this scales way better since it massively lowers the skill floor needed to actually mess with the system to get hardware working.

The first iteration of Megapixels has already somewhat done this. There's a config file that is picked based on the hardware model that describes the names of the device nodes in /dev so those paths don't have to be hardcoded and it describes the resolution and mode to configure. It also describes a few details about the optical path to later produce correct EXIF info for the pictures.

This works great for the PinePhone but it has a significant drawback. Most mobile cameras require an elaborate graph of media nodes to be configured before video works, the PinePhone is the exception in that the media graph only has an input and output node so Megapixels just hardcodes that part of the hardware setup. This makes the config file practically useless for all other phones and this is also one of the reason why different devices have different forks to make Megapixels work.

So a config file that only works for a single configuration is pretty useless. Instead of making this an .ini file I've switched the design over to libconfig so I don't have to create a whole new parser and it allows for nested configuration blocks. The config file I have been using on the PinePhone with the new codebase is this:

Instead of having a hardcoded preview mode and main mode for every sensor it's now possible to make many different resolution configs. This config recreates the 2 existing modes and Megapixels now picks faster mode for the preview automatically and use higher resolution modes for the actual picture.

Every mode now also has a Pipeline block that describes the media graph as a series of commands, every line translates to one ioctl called on the right device node just like Alsa UCM files describe it as a series of amixer commands. Megapixels no longer has the implicit PinePhone pipeline so here it describes the one link it has to make between the sensor node and the csi node and it tells Megapixels to set the correct mode on the sensor node.

This is the preview pipeline for the PinePhone Pro. Most of the Links are already hardcoded by the kernel itself so here it only creates the link from the rear camera sensor to the csi and all the other commands are for configuring the various entities in the graph.

The Mode commands are basically doing the VIDIOC_SUBDEV_S_FMT ioctl on the device node found by the entity name. To make configuring modes on the pipeline not extremely verbose it implicitly takes the resolution, pixelformat and framerate from the main information set by the configuration block itself. Since several entities can convert the frames into another format or size it automatically cascades the new mode to the lines below it.

In the example above the 5th command sets the format to RGGB8 which means that the mode commands below it for rkisp1_resizer_mainpath also will use this mode but the rkisp1_csi mode command above it will still be operating in RGGB10P mode.

3a8082e126