Messages

yeah i know that it is hdmi input i did say there are other options, but if you can capture a 4k 30/60 fps for $200- 250 from many new dslr or mirrorless on cheaper media for long recordings that would be great .

Ah, implementing a custom HDMI recorder. Aren't there already good options on the market? (no experience with any of them, but I had the impression this market is already saturated).

Assuming the RPi has the processing power to handle a 4K stream (the more powerful ones might have, but I have no experience with them), it could make sense. Found these things, apparently doing exactly what you mentioned:
https://eu.mouser.com/_/?P=1y9f2kt (B110 using the TC358840)
https://auvidea.eu/product-category/csi2bridge/hdmi2csi/
https://eu.mouser.com/datasheet/2/864/B10x_technical_reference_1.4-1130369.pdf (B101 and B102)
https://auvidea.eu/download/manual/JN30/JN30_technical_reference_1.0.pdf (mentions the B112)
https://www.raspberrypi.org/forums/viewtopic.php?t=216903
https://www.youtube.com/watch?v=-r0ZN7LeSlM

there was a board put out by orange pi RK3399

Right, this one has HDMI IN (specs unknown): http://www.orangepi.org/Orange%20Pi%20RK3399/

I think that's the resolution for still photography, no? Video capture seems to be 640x480px (at 60 FPS) (couldn't find in the official documentation - didn't try hard to be fair). It has Raw output though:
https://www.youtube.com/watch?v=8FVoSF34zNM

The H7 is, indeed, limited to 640x480. The H7plus has OV5640, which is capable of 2592x1944 at 15 FPS. I don't expect this board to process such resolutions in real-time, at this frame rate, but working on cropped areas (regions of interest) might be doable.

Both have the option of a 640x480 global shutter module, or a FLIR Lepton module (thermal camera).

For anyone interested, we are building a 10K image dataset for autonomous driving that will be available for free to everybody and will be used in OpenPilot/Comma.ai:
https://github.com/commaai/comma10k

Very nice! Isn't that the self-driving car startup of George Hotz?

There are other options toshiba TC358840 Camera Serial Interface Converter Chipset (4K HDMI to MIPI CSI -2) https://toshiba.semicon-storage.com/content/dam/toshiba-ss/ncsa/en_us/docs/product-brief/assp/14A04_TC358840_ProdBrief.pdf

That chip could be used to feed the video signal from a DSLR into a Raspberry Pi. Not sure why you'd want to do this.

This is their 720p...
Looks like they skip 4 and leave 4.

FYI, in 720p50/60, your Canon DSLR records one line and skips 4 (5x3 column binning / line skipping).

Exceptions:
- 5D3 (with full 5x3 binning, rather than line skipping)
- crop_rec with custom binning factors (3x3, 1x3 etc)

I would ask them why, but its so unreliable at the moment anyways, exposure issues, dcraw issues with white balance, no way to control shutter speed by simpl switches.
It needs a lot of work, and considering that it was started in 2015, i dont have high hopes.
I wonder how 2x binning looks like and whats the max res at 24fps but still , controlling exposure is tricky, there is gain instead of iso and its controlled by command line so yo ucant change stuff mid recording.

Well, yes. The question was whether the RPi can capture raw images. There is a proof of concept for that, and a rather good one in my opinion. Yes, it's not polished for serious use, but it's functional, and - for the intended audience of RPi, i.e. developers, hardware tinkerers, tech students - it's probably enough to start the ball rolling.

To repeat this important point:

Not for replacing DSLR cameras

BTW, the image you are looking at was taken with the *previous* generation of RPi cameras. Compared to that, the newly announced camera is a noticeable improvement, in my opinion (but don't forget I'm terrible at pixel peeping).

https://twitter.com/hashtag/ShotOnRaspberryPi

And you are no longer stuck with the default optics; you can use any other C/CS-mount lenses (heck, there were EOS M users adapting such lenses for filming), or - with adapters - pretty much any DSLR lenses.

I can only imagine this is going to lead to some incredible experiments.

Yep.

I wonder how it compares with something like OpenMV H7plus (2592x1944 15fps, 1080p30, 720p60, 3.6x2.7mm active area, M12 mount) for real-time machine vision applications (visual servoing). In particular, I happen to be looking for a low-cost vision platform for CNC machining, where I'd like to get about 0.01mm positioning accuracy, or even micron levels if possible (with subpixel processing, of course), but the machine is relatively slow, so 3-4K resolution at 10-15 FPS, with optional cropping or pixel-binning for a higher frame rate, might be adequate. A "classic" 640x480 industrial camera is not going to do the trick. Are there other alternatives in this price range?

I'd get them both (RPi cam and OpenMV) for a comparison, but my budget is a little tight atm.

I could also consider an EOS M, but...
1) Good luck running computer vision algorithms on its general-purpose CPU (as Canon's image processing hardware is a big mystery even for us)
2) Exchanging the result with motor controllers or other hardware, is also tricky. UART to Arduino-like? USB to RPi? In any case, a second microcontroller board is needed.

Or, I could offload the processing to a RPi Zero, via USB, but I expect very large lags and very low resolution; maybe OK for a webcam, but not practical for visual servoing.

Magic Lantern port? 

If this camera proves interesting enough, it might happen sooner or later. Don't look at me, but at the target audience of RPi

Edit: some arguments against the RPi cam:
https://twitter.com/marcan42/status/1088472549715918848

High shutter speeds won't work with the "classic" FRSP codebase, but with crop_rec, in LiveView. On some cameras it is possible to increase the resolution to match full-sized CR2 pictures. It is technically possible to implement this capability on all DIGIC 4/5 cameras; possibly on newer and older ones as well.

As for triggering the hot shoe flash, that's the MPU territory. Apparently the decision to trigger the flash is taken on the MPU. This might be a starting point: https://www.magiclantern.fm/forum/index.php?topic=18123

I haven't analyzed the MPU firmware yet, but leegong (from Nikon Hacker, but also present here) did: https://www.magiclantern.fm/forum/index.php?topic=17596.0

There is a catch: fast-shutter silent pictures will be captured with rolling shutter. Readout time will be significantly higher than exposure time, so... if you manage to trigger the flash mid-exposure, you'll only get a thin strip on the image. At least that's what I'd expect.

It was real, but it was tricky getting it working reliably with all my chipped lenses (50/1.8 II, 24mm/2.8 STM, and 18-55 IS II on APS-C), on both DIGIC 4 and 5.

I can share the source if there is any interest in developing this further. For now I can only test with 5D3 and 24mm/2.8 STM, until the lockdown is over.

Not straightforward - they share the same button codes with half-shutter.

Long answer: https://www.magiclantern.fm/forum/index.php?topic=24723.0

Previous camera modules are able to output raw image/video (didn't try):

https://github.com/6by9/raspiraw
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=109137
https://hackaday.com/2019/08/10/660-fps-raspberry-pi-video-captures-the-moment-in-extreme-slo-mo/

BTW - will this work on RPi Zero? Apparently it needs a different cable.

Nice! And to think it's probably the first case of a camera with defective power switch...

Anyway - you can power off the camera by opening the CF card door. It's a 100% clean shutdown, and on these old cameras, I consider it *safer* than using the power switch.

Why?

If you turn off the camera from the power switch, and then you open the card door, Canon firmware will read and execute autoexec.bin from the CF card *without LED activity* (and afterwards, ML will turn on the LED). This happens within 2-3 seconds or so after you open the CF door. If you remove the card during this time, your camera will lock up. You will be puzzled about what happened, as there will be no LED activity.

But, if you keep the power switch on and you turn off the camera by directly opening the card door, Canon firmware will shut down (cleanly) and will no longer access the card afterwards. Therefore, you will be able to safely remove the card as soon as the LED activity stops.

Looks promising, and I see a lot of potential. Not for replacing DSLR cameras, but for things like machine vision, security cameras or... just a half-decent webcam.

LOLOLOLOLOLOLOLOLOLOL I have to buy this thing asap!

Obviously, that picture was made for marketing reasons. This sensor is small: 6.29x4.71 mm active area. Compare to Canon's 22.5x15 mm (APS-C) or 36x24 mm (full frame). A 3x crop on your favourite APS-C camera (EOS M, 700D, 600D etc) is going to have roughly the same size (on the sensor: 7.5x5 mm). Here's a calculator: https://www.scantips.com/lights/fieldofview.html

FYI, the C mount accepts 1" sensors, or even larger:

C-mount lenses are built for the 8 mm and 16 mm film formats and the 1/3", 1/2", 2/3", 1", and 4/3" video formats, which corresponds to a range of image circles approximately from 5 to 22 mm in diameter.

But yes, you will be able to swap lenses between this thing and your Canon DSLR (with adapters). In both directions if you use an EOS M.

Anyway, don't underestimate the power of RPi user community. Pretty sure they have a quite a few highly skilled - active - developers

https://www.techrepublic.com/article/raspberry-pi-why-sales-have-rocketed-in-the-middle-of-the-coronavirus-outbreak/



Edit - found some more details:
- Camera-Guide.pdf
- 2028x1520 at 0.1-50 fps (2x2 binning)
- 4056x3040 at 0.005-10 fps (even if the sensor is faster, probably the bottleneck is on the RPi side)
- long exposures up to 200s

Wanted: complete sensor documentation, not just the 2-page datasheet

At this point, I get the red LED to light up if I open the battery door, CF door and when putting on a lens.

I have got the camera back to the point in which it registers all doors opening/closing and lens changes.  Still no boot up. EoS utility does not recognize anything when connected... What next?

Meaning: the camera turns off gracefully, without locking up. See this flowchart for details.

Best guess (unconfirmed): the power button, which is actually a soft switch. The camera wakes up when you toggle the card/battery door microswitches, or when you swap the lens, then - after going pretty far in the regular boot process - it decides to shut down. When ML is not installed, you don't see any LED activity - it all happens in background, quietly. When a ML card is inserted, it turns on the CF LED at startup before doing anything else.

These might save a log, but I don't have high hopes:
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/

If the shutdown happens because or power switch stuck to "off" (or because of open card door, but not the case here), the above won't save any log.

You could also send me the ROM dumps privately, but I don't expect any surprises. The ROM will probably boot just fine in QEMU (but again, that's just my expectation, based on the above guesswork).

If you don't mind wiring a UART adapter, you can get a log with all Canon messages without running any custom code on the camera:
https://www.magiclantern.fm/forum/index.php?topic=7531.10

I can also try to display a log on the screen, hopefully catching the shutdown reason. No equipment with me to test the testing code, but I do have some half-working experimental code, so I'll also need a volunteer with a good 5D2 for that. If you can get a log via UART instead, that would be preferred.

At this point, is it safe to say any of the following?

-the issue is Hardware-related
-the issue is Not Magic Lantern

It can be pretty much anything - the power button was just a guess. Let's try get a log first (UART if possible), then we'll draw the conclusions.

Thou shalt not crosspost!

His messages somehow passed through moderators' filter, so... at least part of the problem is elsewhere.

https://wiki.magiclantern.fm/userguide#motion_detect

That's not going to solve OP's problem.

"Motion Level: 0."

Guess: using the "frame difference" option, known not to work on a few cameras.

From one of the cross-posts:

Matériel EOS 5D MK3.

=> downgrade to 1.1.3 (feature known not to work on 1.2.3).

And somebody could not be bothered to use their spel chequer [JS required], much less to read subsequent replies

But yes, there is a thread about 2000D on this forum.
https://www.magiclantern.fm/forum/index.php?topic=23606.0

One question: You renamed/deleted all other lua scripts in scripts folder so no other script is loaded?

In lua_fix versions, no script is loaded by default. You need to explicitly enable autorun on each script you want to be loaded/executed at startup.

ASSERT: err == SUCCESS
at GUI.c:679, GuiMainTask:ff0d6a04

Short answer: the keypress event handler runs in GuiMainTask, and it has to return quickly. Photo capture also requires GUI events, so it can't be completed in a keypress handler; you need to offload it to some other task. The shoot_task hook is suitable for this purpose.

Long answers:
https://www.magiclantern.fm/forum/index.php?topic=16614.msg161978#msg161978
https://www.magiclantern.fm/forum/index.php?topic=21590.msg197093#msg197093
https://www.magiclantern.fm/forum/index.php?topic=24319.msg218556#msg218556
https://www.magiclantern.fm/forum/index.php?topic=4997.msg179155#msg179155
https://www.magiclantern.fm/forum/index.php?topic=14309.msg198217#msg198217

Code Select Expand

pkg load image

Haven't touched Matlab in years, but you might be able to run the scripts by commenting any "pkg load" lines, converting comments from # to % and fixing up stuff as you go. Hopefully the changes required are minimal, but no guarantees.

https://en.wikibooks.org/wiki/MATLAB_Programming/Differences_between_Octave_and_MATLAB

Also, looks like octave has a --traditional mode, which should warn about (known) Matlab compatibility issues edit: nope, one has to use warning('on', 'Octave:language-extension'). If you can't get the scripts working otherwise, I might give it a try.

I am not allowed to install Octave on my company computer ..

Well, assuming you are using Windows, Octave can be simply unzipped and ran; no need to install it system-wide. Therefore, as long as you are allowed to use a web browser and a zip extractor, I expect it to work.

https://wiki.octave.org/Octave_for_Microsoft_Windows

I wrote my own scripts and programs for the whole workflow, from raw images processing, bad pixels removal and white balance, to alignment, to focus stacking, and multi-scale sharpening:

https://github.com/pulsar123/Macro-scripts

Very nice. Scripting around align_image_stack and enfuse, with additional processing

The reason I've asked for a test image sequence: I was recently asked by the Apertus folks to help them with a focus stack of a PCB, where align_image_stack was failing (and, as it turned out later, enfuse had suboptimal output on that image sequence). The main problem was the image sequence itself, which apparently was captured wide-open with an old manual lens; I've recommended them some new settings (along the lines of stopping down the aperture and using ISO 100, even if that meant a slightly long exposure), but re-shooting that particular PCB wasn't an option at the time (don't ask me why). So, I ended up rewriting align_image_stack and the focus stacking part of enfuse, from scratch, as Octave scripts, for that particular image sequence. Yes, in that case it was easier - for me - to reinvent the wheel, rather than fine-tuning the existing software.

When seeing your images, I thought my modified align_image_stack / enfuse versions might give slightly better output, so I was tempted to give it a try. Now that I see you are using an workflow based on align_image_stack and enfuse, you might be able to try them yourself (there are minimal modifications on the command line). Please find my scripts here:

http://files.apertus.org/align_image_stack/

The first script is align_image_stack_finetune.m. It uses an initial brute force search, followed by coordinate descent (parameters: X and Y offsets, zoom aka focus breathing, optional rotation), first on low-resolution copies of the original images, then, increasing the resolution until 1/8 x 1/8 of the original (you can change that by editing the script). It aligns all the images in the sequence, to the middle image (as specified on the command line). It's significantly slower than the original align_image_stack, but it worked out of the box on the PCB test sequence (a few images available on that link, but not the entire sequence). It should handle images with tiny depth of field, where align_image_stack is unable to find its control points.

The second one is focus_stack.m, which outputs a weighted average of a pre-aligned image sequence. Weight is computed by looking at how much each image differs from a blurred copy of itself (computed as grayscale, for speed reasons). The output contains less halo artifacting, compared to enfuse, although I didn't use any deconvolution. I haven't tried it on other images.

Before: PB5-enfuse.jpg
After: PB5-focus_stack.jpg

If you decide to try these scripts, please share the results. If this focus stacking algorithm can be useful to a wider audience, I'm happy to contribute it upstream (to be included in the official enfuse). With align_image_stack, it's a bit more complicated, as my approach is fundamentally different; besides, it would take significant work to convert it to another programming language (haven't checked the upstream sources yet).

Reply #5 provides the answer to most of your questions. You don't need our signing key.

You do need some embedded programming knowledge, but I've tried to cover the EOS-specific details in QEMU guides (linked from the homepage).

Unfortunately I'm unable to provide any significant assistance these days (a technical reply might require a few hours of preparation on my side), so... I'm afraid you will have to figure out most of the stuff on your own. Sorry about that. On the upside, the Hello World code was confirmed to work on most DIGIC 6/7/8 models announced at the time of writing that piece of code, so following the discussion from those other models, and the source code commits, should provide the hints you need.

Yeah, really nice.

I'd appreciate a sequence of raw image files (e.g. the one of the CPU pin, or the ant head, since they seem to be a little blurrier than others), and some notes about postprocessing.

Got a report from a user who tried to downgrade from 1.3.6 to either 1.1.3 or 1.2.3 (he tried both versions, a few times each). The upgrade apparently succeeded and showed a confirmation screen (update is complete 1.3.6 ->1.1.3 / 1.2.3), but the camera was rebooting back into 1.3.6. He used the initial method (card swapping), with a SD and CF card (that's what he had). The failed update was jumping from ~ 49% right 100% (video).

Solved by trying the "battery door" method. A successful upgrade/downgrade should take about 4 minutes. The failed one took about 1 minute.

So, the 1.3.6 updater code (aka the "card swapping" method) is probably not the best choice for downgrading, although it did work for some users.

I do think it should be okay for the card as it's not being read/written on, so technically shouldn't be different from it being removed as usual.

Right, just checked. My card reader does not power off the card after safely removing it (I thought it does, but tested with a WiFi-enabled SD card), and found no evidence stating that removing a card while powered on is electrically unsafe. No writing takes place while loading the FIR file (some drivers might have written a "dirty" bit to the filesystem, or changed the last access time when reading a file, but it's not the case here - tested). So it's probably safe, as long as the card is removed after the LED turns off. With the CF card, the LED does not turn on in the first place, which makes the procedure tricky.

When inserting the second card, it will stay powered on for a few seconds, before it will be taken care of. It will be power-cycled before mounting, i.e. after the decryption, so it's probably OK, too.

There is some room for mistakes, though. Just being pedantic, as we are playing with expensive equipment of other users.

Updated the installation instructions on the download page; still open to suggestions.

Yes, please send me a copy of those files, privately.

You may also try getting a log file with one of those:
- https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/
- https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/
- your regular ML card (for 6D); expecting it to save a crash log with more details (there are over 1000 different conditions behind ERR70)

Yes, of course.

[whatever you do, do not remove the battery in the middle of a firmware update!]

Identified a tiny risk - with the original procedure, you will be removing the card while it's powered on (edited the original post). Canon bootloader unmounts the card *after* the decryption, right before executing the firmware updating code; that is, after those ~ 10 seconds when you can remove the card. While it's probably OK, I can imagine some cards may not like a sudden loss of power, so there is some slight possibility of hardware damage (correct me if I'm wrong).

Another quirk: when using a CF card to perform the update, the card will be accessed without LED activity (remember the 5D2/50D?), so you won't know when to remove the card. So, if you follow the original procedure, I highly recommend an SD card.

In any case, if you remove the card too early, you will do so in the middle of a data transfer. The bootloader will be reading from the card (nothing will be written during that access), so I don't expect filesystem corruption. After an interrupted read, the decryption process will fail, so there's no chance to end up flashing an incomplete firmware, even by mistake. I wouldn't exclude a tiny chance of hardware damage, but again, I might be overreacting here.

It's probably a lot more likely to physically damage the SD card while trying to perform the swap in a hurry.

Considering the above, I strongly prefer the second method (also summarized here), which doesn't have any of these risks. Here's a longer description:

- copy firmware 1.3.6 (5D300136.FIR) to the card
- launch Update Firmware from Canon menu, click OK
- open the battery door ASAP, but don't remove the battery!
   - if you did it right, the camera will turn off (wait for a few seconds to make sure it's really off)
   - if you see the Firmware Update Program Loading screen, it means you have opened the battery door a bit too late; wait until it disappears and try again!
- open the card door and remove the card from the camera (do not close the battery door; also leave the power switch on)
- copy firmware 1.1.3 (5D300113.FIR) or 1.2.3 (5D300123.FIR) to the card
   - you may leave the original 1.3.6 FIR on the card, or you may delete it; doesn't matter
- put the card back into the camera, close the card door
- close the battery door; you should see the Firmware Update Program Loading screen
- confirm the firmware downgrade from 1.3.6 to 1.1.3 / 1.2.3
- whatever you do, do not remove the battery in the middle of a firmware update!



That's it. The only tight timing is when opening the battery door; afterwards, the camera will be off, so you can take your time, no need to rush swapping the cards.

To answer a question from another thread:

Can this possibly be used on all Canon cameras?

Yes, I expect this (second method) to work on all current EOS cameras, from DIGIC 2 to DIGIC 8. The only assumption is that, after clicking Firmware Update and opening the battery door right away, the camera will turn off, rather than restarting (and having the bootloader execute the firmware update file). Following this investigation, this is likely to happen on all EOS models.

The original procedure (swapping the cards while the update is loading) depends on what exactly the firmware updating code is doing - will it always re-read the firmware file from scratch? I don't know. It will probably work as well.

Yep, it's probably OK, and here's the long answer:

1. You select Update Firmware from Canon menu (main firmware)
2. Canon code checks the firmware version of every FIR file from the card; if any of them is less than 1.3.6, the update is refused (main firmware)
3. Canon code temporarily disables the main firmware
4. Camera reboots itself
5. Canon bootloader looks for a FIR file on the card
6. Canon bootloader loads the FIR file (card LED on)
7. Canon bootloader decrypts the FIR file (card LED off, simple CPU-based loop, no peripherals checked - that's when you remove the card)
7a. [edit] after decryption, Canon bootloader unmounts the card and - from what I could tell from emulation - turns off its power (so, you will be removing the card while it's powered on!)
8. Canon bootloader executes the FIR file (the one loaded from the first card) which contains a mini DryOS (and a simplified user interface)
9. Firmware updater mounts the card and reads its contents from scratch
10. You confirm the firmware update (from the simplified user interface of the firmware updating program)

From this point, I can no longer tell what exactly is going on, but apparently the firmware file is read once again from the card. In the past, you were able to place multiple FIR files on the card, and the firmware updating program has a feature that allowed selecting one of these FIR files to perform the update. That feature is still there, and it's probably what makes this trick possible. From my limited understanding, you will be using the 1.3.6 updater code, with the payload from the earlier firmware version.

[Edit] you will be removing the card while it's still powered on, so there is a small risk of hardware damage.

While trying to test the above, I've found a slightly different method, which requires a single card and - in my opinion - is a little safer:
A. select Update Firmware from menu, click OK
B. open the battery door ASAP (but don't remove the battery!)
C. make sure the Firmware Update Loading screen does not appear!
D. camera remains turned off; do not close the battery door
E. remove the card, replace the FIR file and insert it back
F. close the battery door

At this point, Canon bootloader will load the newly copied FIR file and execute it from scratch, without any trickery.

So simple, yet so un-obvious

BTW - if you close the battery door without inserting the card (step E), the camera will show an error message. Reboot and you are back to the old firmware. Explanation: see step 3 (main firmware was disabled temporarily, only for one reboot).

If anything goes wrong, I can offer remote assistance, but cannot guarantee a prompt response. Cannot guarantee a 100% success rate either; you perform the procedure at your own risk.

Alright, so the hardware appears to be alive. You might be able to get some diagnostic logs with one of these builds:

https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/

If they don't work, send me - privately - a copy of your ROM. I might be able to reproduce the error in QEMU and figure it out from there.

Looks like Trammell has been busy lately: https://airbreak.dev/



This looks familiar: stubs.S. It really feels like Magic Lantern, Hospital edition

Okay on my side, hopefully others are safe as well.

Looking for ways to help remotely, but it's hard to find a good answer. It's hard to focus on hobbies during these difficult times; there are more important things we can do to stop the virus and/or to help those around us.

Initial ideas:

- Attaching your camera to a microscope, to see the virus, is out of the question.
- I was thinking to suggest using a longer focal length, or something along these lines, for April 1st. Decided to skip this event, but I'd still like to update the ML startup screen with some good advice. Here I need some help, as I'm not a medical doctor.
- Apparently, any mask is better than no mask, even if you've been told otherwise. Leave medical masks for hospitals; consider DIY masks or face shields.
- DIY / 3D printing folks around the world are making face shields and donating them to hospitals. Consider helping them.
- There are several suggestions of COVID19-related open source projects, on the GSoC mentors mailing list (unfortunately not public). I can summarize if there is interest.
- Some stuff worth reading: check the News headline on the forum homepage (updated every now and then). In particular, this one is updated often and provides a good overview for most countries.

Stay safe!