DIY 31 Megapixel Enlarger

michaelbirkmose said:

I took a hiatus from my darkroom experiments and went down a rabbit hole designing - and having CNC machined - a carrier plate to mount the LCD in anodized black aluminum. It just arrived today, and I’m excited to get back to experimenting. Looks pretty neat!View attachment 411154View attachment 411155View attachment 411156

Click to expand...

Nice! Looking really professional.

Back at it. First prints with the new mounting platform and the protective film of the display. It is SO much nicer to work with this setup. It also seems like micro contrast got a lot better (that annodized black aluminium kills a lot of glare/light leaks)

I received my Raspberry Pi 5 today, so now it’s time to build the 3rd generation of my software, trying to make it as accurate as possible using DRM/KMS + GBM + EGL + OpenGL ES, running on Pi OS Lite with no window manager. The aim is to control the display with minimal jitter and maximum reproducibility. The nice thing about these APIs is that you can actually measure when things are latched, whether you miss vblanks, etc., so you get a good idea of whether your exposure is consistent.

Running the panel as 1-bit and using time modulation for tonal control yields the cleanest results in my experience. Direct 8-bit exposure produced noticeable artifacts every time I tried it (most apparent in monotone areas).

My biggest challenge right now is the highlights (toe of the paper), which need very little exposure - they build density fast. I’ll experiment with more diluted developers and other darkroom tricks, but I really want the exposure pipeline to be as accurate as possible to help with precision, especially in the highlights given they’re the trickiest for me. So I’m having fun going a bit more low-level.

One nice side effect of driving the display directly with DRM/KMS is that it basically becomes plug-and-play for timing. I don’t have to mess with modelines or force modes like others reported - the Pi just reads the EDID and I can use the panel’s preferred timing exactly as it is.

For example, I can see the mode I need straight from the EDID:

sudo cat /sys/class/drm/card1-HDMI-A-1/edid | edid-decode

Block 2, DisplayID Extension Block:
Version: 1.2
Extension Count: 0
Display Product Type: Extension Section
Video Timing Modes Type 1 - Detailed Timings Data Block:
DTD: 2840x4320 19.994380 Hz 1:1 87.175 kHz 263.270000 MHz (aspect 1:1, no 3D stereo, preferred)
Hfront 120 Hsync 20 Hback 40 Hpol N
Vfront 20 Vsync 4 Vback 16 Vpol N
Checksum: 0x16
Checksum: 0x90

And in my code I simply ask DRM for that “preferred” mode and use it:

drmModeModeInfo mode = chosen_conn->modes[0];
for (int m = 0; m < chosen_conn->count_modes; m++) {
if (chosen_conn->modes[m].type & DRM_MODE_TYPE_PREFERRED) {
mode = chosen_conn->modes[m];
break;
}
}

michaelbirkmose said:

I took a hiatus from my darkroom experiments and went down a rabbit hole designing - and having CNC machined - a carrier plate to mount the LCD in anodized black aluminum. It just arrived today, and I’m excited to get back to experimenting. Looks pretty neat!View attachment 411154View attachment 411155View attachment 411156

Click to expand...

Wow, that's really nice. I have a Durst L1200 as well, and I also have the same display on order. Would you be willing to share your design so I can have the same carrier CNC machined as well?

Just to add a few details: the cutout (the recessed area where the display sits) has generous tolerance. This was my first time having something CNC-machined, so I intentionally made it a few millimeters larger than strictly necessary.


The plate also includes mounting holes for a Raspberry Pi 5, which is what I’m currently using.


If it’s helpful, I can send over the STEP files and the technical drawing I provided to the manufacturer. I didn’t model the plate manually - I generated it in Python using the CadQuery library - so I can quickly produce bespoke STEP files if you’d like any changes. Of course, if you’re comfortable with CAD tools, feel free to edit it to your heart’s conten, this is all still pretty new to me, so I’m just sharing how I approached it.

I ended up building a ultra precise rasberry pi5 solution so that I can control latching of time modulated 1bit frames with microsecond precision (from the O/S perspective, the display is running at 20hz, so you are bound by 50ms frame times). I build a bespoke UI that I control projected on the baseboard in the darkroom, using a Nintento switch bluetooth controller Had a lot of fun building this thing. Last step is to figure out how to generate some good LUTs.

michaelbirkmose said:

Just to add a few details: the cutout (the recessed area where the display sits) has generous tolerance. This was my first time having something CNC-machined, so I intentionally made it a few millimeters larger than strictly necessary.


The plate also includes mounting holes for a Raspberry Pi 5, which is what I’m currently using.


If it’s helpful, I can send over the STEP files and the technical drawing I provided to the manufacturer. I didn’t model the plate manually - I generated it in Python using the CadQuery library - so I can quickly produce bespoke STEP files if you’d like any changes. Of course, if you’re comfortable with CAD tools, feel free to edit it to your heart’s conten, this is all still pretty new to me, so I’m just sharing how I approached it.

Click to expand...

Thanks you so much, I would love the STEP files and the drawing. I am not familiar with CAD tools, so I would probably reuse your design exactly. Also if you could tell me which manufacturer you used I'll use the same.

michaelbirkmose said:

I ended up building a ultra precise rasberry pi5 solution so that I can control latching of time modulated 1bit frames with microsecond precision (from the O/S perspective, the display is running at 20hz, so you are bound by 50ms frame times). I build a bespoke UI that I control projected on the baseboard in the darkroom, using a Nintento switch bluetooth controller Had a lot of fun building this thing. Last step is to figure out how to generate some good LUTs.


View attachment 414188View attachment 414189



View attachment 414187

Click to expand...

Very cool. I understand why you mounted the raspberry pi to the carrier, since you don't need an auxilliary display or keyboard. Instead of the switch controller, maybe you could have used a bluetooth mouse?

michaelbirkmose said:

I ended up building a ultra precise rasberry pi5 solution so that I can control latching of time modulated 1bit frames with microsecond precision (from the O/S perspective, the display is running at 20hz, so you are bound by 50ms frame times). I build a bespoke UI that I control projected on the baseboard in the darkroom, using a Nintento switch bluetooth controller Had a lot of fun building this thing. Last step is to figure out how to generate some good LUTs.


View attachment 414188View attachment 414189



View attachment 414187

Click to expand...

If you want to share the software, that would be very cool too!

Clay Harmon has some info on how to build profiles (which are basically LUT I believe) for polymer photogravure negatives, which may be useful: https://clayharmonblog.com/downloads

my email is **** at gmail
Moderator's note: we have deleted most of the posted email, after noting that communication has been established.
While some steps had been taken to make the posted email less of an attraction to scrapers, it remains our advice that sharing an email address - or any other personal information - may not be wise if the post is public.
The scammers are out there!
It is always more prudent to share such information in a more private Conversation, either by initiating one yourself when you have attained the required privileges, or requesting that your correspondent start a private Conversation with you.

Shared the mount files by email

Regarding the controller: I just programmed the UI to match the layout of the gamepad, so there’s nothing to set up - you simply press the corresponding button. It makes things much smoother for me in the darkroom.

As for sharing the software, that one has a lot of moving parts, so it’s not something I’m planning to release. That said, I’m happy to provide pointers if you’re looking to build your own It also looks like quite a few people in this thread have built their own solutions, and I don’t think there’s really a one-size-fits-all approach here.

The biggest takeaway for me was that 1-bit time modulation is a must (at least with my display). Without it, I was getting visible artifacts in areas with smooth tonality.

michaelbirkmose said:

Shared the mount files by email

Regarding the controller: I just programmed the UI to match the layout of the gamepad, so there’s nothing to set up - you simply press the corresponding button. It makes things much smoother for me in the darkroom.

As for sharing the software, that one has a lot of moving parts, so it’s not something I’m planning to release. That said, I’m happy to provide pointers if you’re looking to build your own It also looks like quite a few people in this thread have built their own solutions, and I don’t think there’s really a one-size-fits-all approach here.

The biggest takeaway for me was that 1-bit time modulation is a must (at least with my display). Without it, I was getting visible artifacts in areas with smooth tonality.

Click to expand...

Cool, thanks again. Using a game controller does make sense for using in the dark. I probably will have more questions once I receive the LCD panel and can start playing with the software.
Just curious, what language did you use for the software?

I use Rust for the software - most of the logic is written in Rust, some of it is wrappers around the more low level Linux DRM/KMS/GBM/EGL. My approach was to build this as an appliance and take direct control of the GPU to have very precise control of latching of frames (due to the time modulation trick). My observation is with 1bit mode every frame counts when rendering the highlights (as they build up very fast).

My initial experiments was Python, then I wrote a C version, and finally a Rust version.

michaelbirkmose said:

I use Rust for the software - most of the logic is written in Rust, some of it is wrappers around the more low level Linux DRM/KMS/GBM/EGL. My approach was to build this as an appliance and take direct control of the GPU to have very precise control of latching of frames (due to the time modulation trick). My observation is with 1bit mode every frame counts when rendering the highlights (as they build up very fast).

My initial experiments was Python, then I wrote a C version, and finally a Rust version.

Click to expand...

Hi All

The supplier I was talking to recently updated their 16K screen from 3 bits per pixel to 8 bits per pixel.

Naturally - I got excited and bought one.
I tried running it on an SBC based on the rockchip - a Radxa Rock 5C (similar to the Pi 5) - but ran into a hardware limit because of the unusual dimension of the screen when taking into account the packed-pixels. (3x 8bit mono pixels per 24bit RGB pixel)

I connected to a beefier PC and dedicated NVidia card and managed to get it working. See attached.

The version of the screen I bought also had a special yellow 'UV Coating' that the supplier claims to increase UV transmissivity by 5% - but requires cross polarising to be visible to the naked eye while testing (hence the unusual colouration in the photo) - and is not suitable for visible light processes. I will buy an additional LCD with the normal coatings if I want to make traditional silver prints.

My research is pointing me towards a 'lattepanda' SBC - it has a video card that the LLMs assure me will be able to cope with the unusual dimensions - and has the benefit of a whole lot of GPIO pins for running the PWM for the UV light source, thermocouple input, other controls etc...

An interesting factor is the non-square pixels in the LCD which requires careful management to ensure the image is compensated correctly.

I've managed to get it all running using shell scripts, a little python and ImageMagick - which is super convenient.
I've even put a little web app in front of it so I can upload images and control everything remotely.
I have set up the software to handle LUTs output from QCDN for when I get to printing. This should make linearisation pretty straight forward.

The attached images show:
1. Uncompensated image showing how the non-square pixels naturally want to warp the image
2. A compensated image that takes into account the 0.756:1 ratio of the pixels.
3. A greyscale output at gamma 2.2 - I have no idea how this translates when operating on UV light yet, as my enlarger is not ready.


Happy to answer any questions

B

That's very cool. I'm not quite getting how the additional coating could *increase* the UV transmissivity, I was assuming that the UV not transmitted was absorbed by the LCD material, and why would an additional coating change that? I'm probably missing something.

Also, I'm not quite understanding the benefit of having multiple grey levels. Can't you just simulate it exactly by updating the projected image as the exposure progresses, turning of pixels. You'd need just to update the image 8 times during the exposure to simulate 256 grey levels.

greg7mdp2 said:

That's very cool. I'm not quite getting how the additional coating could *increase* the UV transmissivity, I was assuming that the UV not transmitted was absorbed by the LCD material, and why would an additional coating change that? I'm probably missing something.

Also, I'm not quite understanding the benefit of having multiple grey levels. Can't you just simulate it exactly by updating the projected image as the exposure progresses, turning of pixels. You'd need just to update the image 8 times during the exposure to simulate 256 grey levels.

Click to expand...

I think they use a different material than the standard intrinsic polarisers in a normal LCD screen - and this different material results in lowered absorption of UV. So, ultimately, your instincts are correct.

My hope is that the 256 levels of grey that the screen can display (block) will be sufficient to give me a workable greyscale without having to resort to the complexities of updating the screen within a single exposure.
I am mostly interested in gum and gum adjacent print processes (SBQ, PMF) - and these have a tiny dynamic range that is extended by application of multiple layers.

I note that the 16K screen only has a 10Hz refresh rate.

BenjaminAustin said:

I think they use a different material than the standard intrinsic polarisers in a normal LCD screen - and this different material results in lowered absorption of UV. So, ultimately, your instincts are correct.

My hope is that the 256 levels of grey that the screen can display (block) will be sufficient to give me a workable greyscale without having to resort to the complexities of updating the screen within a single exposure.
I am mostly interested in gum and gum adjacent print processes (SBQ, PMF) - and these have a tiny dynamic range that is extended by application of multiple layers.

I note that the 16K screen only has a 10Hz refresh rate.

Click to expand...

Ah, thank you Benjamin, this makes sense. A better transmittance would be useful indeed to lower the exposure time. In the LCD I ordered (the 9k, 6.9") the transmittance is listed as only 3.5%.
I'm just starting with this process and it is a lot of fun!

Interesting @BenjaminAustin!
Do they sell the screen both with and without the special coating? (I am purely interested in silver gelatin, so personally I hope that the industry doesn't decide to start only produce screens with this special coating )