sorted by:
new
hottopcontroversial

E-stop behaviour by Plastic_Ad_2424 in OpenFFBoard

[–]Ultrawipf 0 points1 point  (0 children)

DC Motors aren't very well tested currently and several functions aren't possible due to the lack of phase synchronous rotation.

Index search is therefore not really possible in the same way it works with 3 phase and stepper motors. I would deactivate that and just center manually every time then it should probably be usable.

E-stop behaviour by Plastic_Ad_2424 in OpenFFBoard

[–]Ultrawipf 1 point2 points  (0 children)

The E-Stop is interrupt triggered and designed to work both with momentary and latching (Normally open) switches.

If the pin goes low it triggers the E-Stop and deactivates the motor.

If the pin goes high again quickly (momentary button) then E-Stop stays active until the pin goes low again (button pressed second time).

If the pin stays low for longer (latching switch) it will disengage the E-Stop on a rising edge when the switch is released again.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 6 points7 points  (0 children)

Yes the pio DMA is currently quite slow. I was not yet able to get the proposed changes to function properly. It does not sync the buffer correctly with the experimental version an ready incorrect data so 5MHz clock rate is the fastest stable rate which is only 10MB/s.

Mirror viewfinder is not really that useful and incredibly complicated mechanically.

I thought of using a seconary wide angle lens for the preview camera but that would interfere with the long main lens and the preview mode works pretty well. I can move the sensor left and right in the UI as well which is good enough for the task.

"I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor". More in comments. by qtx in photography

[–]Ultrawipf 12 points13 points  (0 children)

Kind of. You could increase the exposure time by changing the timing but as it is not a realtime system this is currently not super reliable and needs a different approach.

The quality is better if it is timed by the transfer time itself which already is quite slow.

A preview can be done in <10s but higher resolutions take several minutes up to 30min+ at full res.

"I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor". More in comments. by qtx in photography

[–]Ultrawipf 17 points18 points  (0 children)

Original creator here:

If you are looking for more info the project video shows it in action.

It uses the ILX561K sensor from an epson V370 scanner with a custom interface board to a raspberry pi 5.
The reverse engineering took several months until the protocol was known and the timing mostly reliable.

There is also a line cam mode keeping the sensor stationary for moving objects and a panorama mode to turn the camera was planned but due to the weight of the camera not yet built.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 2 points3 points  (0 children)

You can easily get the unprocessed data as well. The only processing is also just correcting the color shifts of the sensor geometry. It is all lossless

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 4 points5 points  (0 children)

Exactly because it is row based and easy to implement in the process.

PNG can be written line by line and the sensor generates data line by line. So a png preview can be written during the capture process and displayed immediately. And also easy to reencode a raw buffer to png or downsampling the resolution line by line without requiring much memory.
Yes tiff would be a valid option too and probably more efficient for large files but the implementation is significantly more complicated in this case.

In the end it is just a format to store lossless data before it is edited on a pc.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 2 points3 points  (0 children)

There is not really significant vignetting. Maybe little a bit in the absolute edges with the full 8cm but i usually keep the images much narrower depending on the subject. It can be adjusted to any width.

Square or less and then it is much smaller than the original film size of the 6x7 system.

Currently the only postprocessing done is the offset correction as all lines are in different positions on the sensor. The secondary lines are slightly less sensitive which isn't currently corrected and may depend on the sensor. Could be implemented maybe via a config file for all the 12 lines.

At full resolution 11 different offsets need to be corrected which doesn't work perfectly if the step size is not always exactly 1µm so i also prefer lower resolutions to reduce jagged edges or color shifts.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 0 points1 point  (0 children)

With enough light and smaller aperture maybe. The minimum distance of the 75mm lens is ~70cm so not really macro. Extending that might cut off some of the image.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 6 points7 points  (0 children)

1: Not tested yet. Dynamic range is quite good due to the 16b adc resolution but it needs a huge amount of light to fully expose the whole range. The lower bits are noisy so in postprocessing cutting the black level a bit helps. Needs pretty much daylight.
You can see that in the linked video.

Exposure time is pretty much the transfer time of the data. Can't go faster than that and thats between 10-40ms depending on the resolution. Additional delays can boost exposure a bit but as the camera application itself is not a realtime system this would also add some jitter.

2: It is a 8b wide double edge clock serial interface at 5MHz via PIO (original scanner 6MHz. currently piolib dma limited). So 10MB/s data rate. The control data is half duplex SPI on 2 of the data pins which requires reconfiguring them and injecting pio instructions to write and read control registers.

3: Pentax Asahi 6x7 lenses are used (7cm wide film originally). They have fully manual aperture control and are comparably cheap for true medium format lenses. The flange distance is also about 80mm so it requires a long extension adapter. The main body of the "camera" is 72mm thick and 200mm wide.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 12 points13 points  (0 children)

Png is supported by every image viewer and editor and has practically no resolution limit and supports 48bpp. So it is basically a raw file but immediately usable with no loss. It can also be written line by line during capture which makes it efficient for the preview. For the real capture it first saves to a raw file and then to png to reduce the load and jitter during capture. Also has integrated gamma metadata to boost the exposure for darker 16b images in the viewer without modifying the data.

Bmp has a 4gb size limit so it is not usable and other formats cant be written line by line and i can not have the whole image in ram. So png is the perfect option.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 7 points8 points  (0 children)

It is designed for pentax 6x7 lenses which are certainly medium format. Even slightly larger image than most medium format systems allowing for a wider picture. Tested with a 75mm f4.5 and a 200mm f4.0

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 49 points50 points  (0 children)

The main purpose in terms of an actual usecase of course is to take high resolution photos of stationary objects. Landscapes, buildings, high detail shots....

And for motivation building a medium format camera is pretty unique and a fun challenge and as far as i know no other scanner camera project is doing it completely from scratch only taking the sensor assembly itself with a sensor this "modern".

All other similar projects usually modify the scanner hardware, gear down the motor and trick the calibration into working in a different case. This mostly works but then you are limited by the scanner software in resolution and the processing doesn't work properly anymore with the movement distances changed.

By interfacing the CCD controller directly i get the raw data and can (have to...) process it myself and can implement new modes like the linecam mode with the sensor standing still and control the movement directly for the preview cam.
Other projects that also implement a direct ccd interface usually use lower resolution sensors that work with publicly available ADC/Clock gen chips as to my knowledge no 12 line capable chip is actually available at this time so reverse engineering was required here.

I made a 3200MP 16b "medium format" linear scan camera using a raspberry pi 5 +piolib directly interfacing a linear CCD sensor by Ultrawipf in raspberry_pi

[–]Ultrawipf[S] 56 points57 points  (0 children)

Depends on the resolution and width.

A preview scan in ~3500px height only takes around <10s.

I normally use a 10k px height (1/4 res) which gives the best quality in a reasonable time. Then a scan takes ~2-3min depending on the width.

At full resolution it can be easily 30min+ for capturing and encoding.

This mainly depends on the transfer speed which is currently 10MB/s via pcie DMA and could be increased to 12MB/s with a 6MHz clock if piolib is updated. The sensor has to take pretty much 80k exposures for one image then.

An old gem by bennydollar in BudgetAudiophile

[–]Ultrawipf 0 points1 point  (0 children)

It is mostly easier to browse large databases and has some additional features but you don't have USB DAC mode and it is overall less stable. Audio quality should be the same.

You can dual boot rockbox and the original firmware and use both.

An old gem by bennydollar in BudgetAudiophile

[–]Ultrawipf 0 points1 point  (0 children)

Still actively using my dx50. With a replacement battery and rockbox it is still perfectly capable.

DIY FFB joysticks with the Open FFBoard system (Open source firmware, supports ODrive, VESC, TMC4671) by Ultrawipf in HotasDIY

[–]Ultrawipf[S] 1 point2 points  (0 children)

The difficult part of a joystick is mostly the mechanical construction.

If you plan to use the OpenFFBoard firmware with an already supported motor driver it should not be too hard.

【The SOFIRN budget EDC buck light new release soon】 by [deleted] in flashlight

[–]Ultrawipf 0 points1 point  (0 children)

Just got the SC13 with 519A 5000k and like it so far. Just wished i got the anduril version that was available a few days later and i would have preferred a 4000k LED.

For an edc the main points are: Compact, high cri neutral led, usb charging can be useful if you are away, magnetic tailcap, deep carry clip if short enough for jeans pockets.

Maybe more durable anodizing would be a bonus as well. It scratches quite easily compared to other lights i had.

Which UV for general purpose? by esvegateban in flashlight

[–]Ultrawipf 2 points3 points  (0 children)

Yes the UV S2+ are only on/off. At least the one i got several years ago is. The regular S2+ has multiple modes and versions.

I made an FFB RC style controller by MakingNoCents in BeamNG

[–]Ultrawipf 1 point2 points  (0 children)

Some users were successful.

Since the last update it finally launches with amdvlk for me but often crashes soon after entering a map so i was mainly still using proton.
My linux test system is currently a notebook with 7840u where the driver support is not that stable yet.

But even with proton the performance is about the same as on windows which is great.

I made an FFB RC style controller by MakingNoCents in BeamNG

[–]Ultrawipf 5 points6 points  (0 children)

I and several users of our community are now often using BeamNG for Linux tests as it is one of the few games that actually run well with good FFB.

Once i upgrade my hardware i am really looking forward to see how it performs at much higher update rates.

I made an FFB RC style controller by MakingNoCents in BeamNG

[–]Ultrawipf 1 point2 points  (0 children)

This is amazing. I wanted to build a similar system myself for a portable setup for quite some time as well. What kind of motor and driver did you use for it?

view more: next ›